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.mccar...@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 > <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