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 <ro...@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 > <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 >> -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
