On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote: > On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto <neil.toro...@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
smime.p7s
Description: S/MIME cryptographic signature
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
