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
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 w
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 dimensi
2012/9/15 Robby Findler :
>
> 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 computations to a graphics
ca
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 good
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 N
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 wrote:
> TR doesn't support them anyways because there are only typed f64
> vectors and not type
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
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
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
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
wrote:
>
> On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote:
>
>> On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto wrote:
>>> Compat
On Sep 12, 2012, at 1:03 PM, Jay McCarthy wrote:
> On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto 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
On Wed, Sep 12, 2012 at 3:47 PM, Matthew Flatt 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
> that I wante
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
that I wanted to replicate exactly in Racket (ok, MzScheme).
Eventually, I so
On Wed, Sep 12, 2012 at 8:31 AM, Neil Toronto 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
On Wed, Sep 12, 2012 at 11:24 AM, 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
> single-
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 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].
Interesti
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
> single-pr
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 dou
I ask because I'm tired of worrying about them. More precisely, I'm
tired of Typed Racket (rightly) making me worry about them.
I'm also a little bit tired of this:
(: foo (case-> (Single-Flonum -> Single-Flonum)
(Flonum -> Flonum)
(Real -> Real)))
(define (foo x)
20 matches
Mail list logo