Matthew,

Thank you very much for merging Mikhail's code into the Racket
source tree. We agree with your position about keeping
extflonums separate from the numeric tower.

Neil, thank you for your valuable comments.

Recently Mikhail has been working on:
  - FFI-ing long double values (I forgot to mention that task
    before, but we need it for our project)
  - Adding extflonum tests to optimize.rktl

The patch with the above will be sent to you as soon
as it is ready, most probably this month. Also we get
your point about ways to implement proper unboxing in
JIT. One thing is not quite clear from your message:
if Mikhail now starts to work on unboxing, will not he
be duplicating your own work? You said

Unboxing of locally-bound extflonums is still not implemented, but I
think it's probably not too far away.

so I am wondering whether it has already happened.

Best regards,

Dmitry Pavlov
Institute of Applied Astronomy, St. Petersburg, Russia


On 01/31/2013 10:08 AM, Matthew Flatt wrote:
At Tue, 29 Jan 2013 19:01:30 -0500, Sam Tobin-Hochstadt wrote:
On Mon, Jan 28, 2013 at 8:18 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
At Sat, 29 Dec 2012 14:05:08 +0300, Michael Filonenko wrote:
I have prepared a new version of the patch (attached).

Thanks!

A question on the design here: why not make extflonums part of the
numeric tower?

I thought about this, and it was tempting to try, but including
extflonums in the numeric tower appears to require a lot more code:
extra cases in arithmetic functions to handle extflonums and select
coercions when extflonums are combined with other values.

Since the intent of extflonums is (I believe) to use them with other
extflonums for precision and speed, it seems like a good place to
experiment with non-`number?' numbers.

Also, when are extflonums *not* likely to be available?  Only on
non-x86 processors?

They're also not available on x86 processors when Racket is compiled to
use x87 floating-point operations for flonums (in the C implementations
of primitives). I think x87 floating point is still the default on most
32-bit x86 platforms so that the executables run on old processors.

Also, the C compiler must support extended precision via the `long
double' type (for the C implementation of extflonum primitives). On
Windows via MSVC, that rules out even 64-bit builds. We may be able to
improve that situation, though.

Overall, expect extflonums on non-Windows x86_64 platforms plus Mac OS
X x86.




_________________________
 Racket Developers list:
 http://lists.racket-lang.org/dev

Reply via email to