On 09/16/2012 04:10 PM, Matthias Felleisen wrote:
Suppose we had started Racket long ago and maintained it until now. Then we'd
be looking at 8bit, 16, 32, and 64 precision. In some N years from now, we may
need 128. (Actually there were machines in the past that did, but never mind.)
Could
At Sun, 16 Sep 2012 17:10:01 -0500,
Matthias Felleisen wrote:
Suppose we had started Racket long ago and maintained it until
now. Then we'd be looking at 8bit, 16, 32, and 64 precision. In some N
years from now, we may need 128. (Actually there were machines in the
past that did, but never
2012/9/15 Robby Findler ro...@eecs.northwestern.edu:
At this point, I'm still left wondering if Single-Flonums are good for
anything, but I can imagine that they are good for not breaking old
programs, so probably best to leave well enough alone.
One use case for singles is offloading
Suppose we had started Racket long ago and maintained it until now. Then we'd
be looking at 8bit, 16, 32, and 64 precision. In some N years from now, we may
need 128. (Actually there were machines in the past that did, but never mind.)
Could we separate precision and type into separate
At Fri, 14 Sep 2012 23:45:43 -0500,
Robby Findler wrote:
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.
Right, TR supports `Single-Flonum's, but not `f32vector's.
Part of the complexity in
Thanks for the explanation. I see how this is not a typed-specific
problem (indeed, it is probably a Good Thing that TR helps us be
careful about this distinction when it matters).
At this point, I'm still left wondering if Single-Flonums are good for
anything, but I can imagine that they are
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
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
Two hours ago, John Clements wrote:
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
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
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
Single-precision float support used to be enabled via a configure
option, which meant that some Racket installations would support them,
and some would not.
Since zo files are meant to be portable, they could not contain
single-precision floats. So, compilation would promote single literals
to
On Sep 12, 2012, at 12:24 PM, Vincent St-Amour wrote:
Single-precision float support used to be enabled via a configure
option, which meant that some Racket installations would support them,
and some would not.
Since zo files are meant to be portable, they could not contain
On 09/12/2012 10:24 AM, Vincent St-Amour wrote:
I agree that having to handle single floats when reasoning about numbers
complicates things, and it annoys me too. But I still think it's less
problematic than what I describe above [compilation could change the behavior
of a program].
Two hours ago, Stephen Bloch wrote:
Would it be even less problematic to get rid of them entirely,
except in FFI?
(They're not really an issue for the FFI, since you'd just translate
the numbers to them when needed. IOW, racket doesn't even need
exact integers to have an FFI with them.)
--
On Wed, Sep 12, 2012 at 11:24 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote:
Single-precision float support used to be enabled via a configure
option, which meant that some Racket installations would support them,
and some would not.
Since zo files are meant to be portable, they could not
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
On Wed, Sep 12, 2012 at 3:47 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Wed, 12 Sep 2012 08:31:29 -0600, Neil Toronto wrote:
Why do we have these things?
I'm not sure this reason from 1996 is still relevant, but FWIW:
Originally, there were drawing-related `float' computations in C code
18 matches
Mail list logo
