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 <cleme...@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.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 > > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev > _________________________ Racket Developers list: http://lists.racket-lang.org/dev