[racket-dev] What are single flonums good for?

The original message in this thread suggests that there is a type
Single-Flonum and that it is making Neil wrangle his code to be
careful about it.

Robby

On Fri, Sep 14, 2012 at 3:55 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> TR doesn't support them anyways because there are only typed f64
> vectors and not typed f32 vectors.
>
> Jay
>
> On Fri, Sep 14, 2012 at 11:28 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> As far as I can tell, if this pollutes TR programs in any interesting
>> way, then it would be a cause for concern.
>>
>> Robby
>>
>> On Fri, Sep 14, 2012 at 12:21 PM, John Clements
>> <clements at brinckerhoff.org> wrote:
>>>
>>> On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote:
>>>
>>>> On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto <neil.toronto at gmail.com> wrote:
>>>>> Compatibility with C code? Why not have the FFI convert them?
>>>>>
>>>>> Save space? I can see that. It won't help much if they're sent to math
>>>>> library functions, though. Those will convert them to flonums and usually
>>>>> box the converted values.
>>>>
>>>> I think these are big deals with respect to libraries that you deliver
>>>> large float matrices to where you want to efficiently store a big
>>>> f32vector rather than an f64vector. Examples of this include OpenGL
>>>> where vector coordinates, colors, etc are typically floats and not
>>>> doubles.
>>>
>>> Jay's concern is the same as mine; there are situations (getting rarer) where a huge c-style array of f32s is the only way to interact with a library. For instance, in the extremely popular "JACK" library (Golly, I wish it worked on windows…), "all audio data is represented as 32-bit floating point values" (from their web page).
>>>
>>> I haven't followed the conversation closely enough to understand the ramifications of the proposed change, though; my guess is that the ffi can still address such arrays, it's just that computing with these values will require coercion. I could be okay with that; based on my understanding of the IEEE floating-point spec, such a translation could be pretty fast; 32bit -> 64bit looks like it would just be adding zeros, and 32bit to 64bit would require checking for exponent overflow; either way, this sounds like something that might be done on-chip by modern processors, and in fact might *already* be taking place in floating point 32-bit operations. (Anyone know whether Intel chips internally represent 32-bit floats as 64-bit ones?)
>>>
>>> John
>>>
>>>
>>> _________________________
>>>   Racket Developers list:
>>>   http://lists.racket-lang.org/dev
>>>
>
>
>
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93