On Sun, Oct 3, 2010 at 7:48 PM, Matthew Flatt wrote:
>
>> I worry that this is a hazard for existing code. For example, this
>> plain Racket code:
>> [snip]
>
> I imagined that there would be some time between introducing `flonum?'
> and enabling 32-bit floats. During that in-between time, both `
At Sun, 3 Oct 2010 11:24:54 -0400, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 3, 2010 at 10:42 AM, Matthew Flatt wrote:
> > The `flonum?' predicate would be the only new predicate for now. The
> > `inexact-integer?' predicate would imply `flonum?', but not vice-versa.
>
> I assume you mean `inexact
Vincent and I briefly discussed tools for 'numeric debugging'
in my office. Hooking it up with CS is the right way to go. It
should have occurred to us.
On Oct 3, 2010, at 10:49 AM, Robby Findler wrote:
> Would it make sense for typed scheme to hook up with check syntax to
> show the type of
On Sun, Oct 3, 2010 at 10:42 AM, Matthew Flatt wrote:
> The `flonum?' predicate would be the only new predicate for now. The
> `inexact-integer?' predicate would imply `flonum?', but not vice-versa.
I assume you mean `inexact-real?' here.
> The flonum operators (with names that start `fl' or `un
At Sun, 3 Oct 2010 08:42:47 -0600,
Matthew Flatt wrote:
> Reader syntax is the main way to get inexacts of different precision,
> though probably we should add a operators to convert numbers to a
> specific precision.
Sounds good.
> With generic arithmetic:
>
> * When mixing variants of inexact
On Sun, Oct 3, 2010 at 9:52 AM, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 3, 2010 at 10:49 AM, Robby Findler
> wrote:
>> Would it make sense for typed scheme to hook up with check syntax to
>> show the type of subexpressions (say when mousing over parens or
>> something)? I'm not sure if that's to
On Sun, Oct 3, 2010 at 10:49 AM, Robby Findler
wrote:
> Would it make sense for typed scheme to hook up with check syntax to
> show the type of subexpressions (say when mousing over parens or
> something)? I'm not sure if that's too late in general, but it seems
> like we're getting the point wher
Would it make sense for typed scheme to hook up with check syntax to
show the type of subexpressions (say when mousing over parens or
something)? I'm not sure if that's too late in general, but it seems
like we're getting the point where we want to give programmers
interactive feedback, at least ab
At Sun, 3 Oct 2010 10:01:31 -0400, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 3, 2010 at 7:43 AM, Matthew Flatt wrote:
> >
> > Sam and Vincent: Any thoughts on how easy or difficult the change would
> > be for Typed Racket (and its optimizer)?
>
> What would the precise hierarchy be? In other word
At Sun, 03 Oct 2010 10:14:04 -0400, Vincent St-Amour wrote:
> At Sun, 3 Oct 2010 05:43:52 -0600,
> Matthew Flatt wrote:
> > Sam and Vincent: Any thoughts on how easy or difficult the change would
> > be for Typed Racket (and its optimizer)?
>
> It depends on how the 32-bit floats are integrated wi
At Sun, 3 Oct 2010 05:43:52 -0600,
Matthew Flatt wrote:
> Sam and Vincent: Any thoughts on how easy or difficult the change would
> be for Typed Racket (and its optimizer)?
It depends on how the 32-bit floats are integrated with the
library. If the existing library keeps using 64-bit floats as the
On Sun, Oct 3, 2010 at 7:43 AM, Matthew Flatt wrote:
>
> Sam and Vincent: Any thoughts on how easy or difficult the change would
> be for Typed Racket (and its optimizer)?
What would the precise hierarchy be? In other words, what would be
the predicate for each type? Would there be automatic co
At Sun, 3 Oct 2010 11:17:44 +0100, Noel Welsh wrote:
> On Sat, Oct 2, 2010 at 7:48 PM, Matthew Flatt wrote:
> > With the current memory manager, I don't think there's any potential space
> > gain from using 32-bit floats instead of 64-bit floats. Is there any
> > other reason to use 32-bit floatin
At Sat, 02 Oct 2010 17:12:20 -0600, Neil Toronto wrote:
> @Matthew: is there a problem with declaring "float" to mean
> "platform-dependent floating-point format?" Embedded devices don't
> always easily support 64 bits, and I'd hate to be stuck with 64 if
> 128-bit floats become ubiquitous.
I t
At Sat, 2 Oct 2010 13:52:40 -0500, Robby Findler wrote:
> Is there any value to, on a 64 bit machine, having 32 bit floats be
> immediate values to avoid boxing?
Sounds plausible. Distinguishing `flonum' from `inexact-real?' would
let us try the experiment more easily.
___
On Sat, Oct 2, 2010 at 7:48 PM, Matthew Flatt wrote:
> With the current memory manager, I don't think there's any potential space
> gain from using 32-bit floats instead of 64-bit floats. Is there any
> other reason to use 32-bit floating point?
In theory one can get better performance with float
16 matches
Mail list logo
