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

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
>