[racket-dev] long double for racket

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 <mflatt at 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.
>
>
>