[plt-dev] `unsafe-fl' and unboxing

From: Doug Williams (m.douglas.williams at gmail.com)
Date: Sun Oct 4 14:58:57 EDT 2009

I have implemented the changes in the statistics, Chebyshev evaluation, and
ordinary differential equation solver routines in the science collection.
They work under the pre-release 4.2.2 ( and the latest nightly
build ( I will put the new version on the Schematics site, but not
to PLaneT for a while. I need to make sure they are at least as robust as
the current version (for the checked versions anyway). I may wait until the
4.2.3 release to put it on PLaneT - so I can use the latest unsafe
operations Matthew is providing, in which case they won't run under 4.2.2.

If anyone wants to play around with them in the meantime, just let me know.
Matthew, the differential equation solver in particular has much more
complex mathematical operations that might be useful to test the unsafe
operations with.


On Sun, Oct 4, 2009 at 2:46 PM, Doug Williams
<m.douglas.williams at gmail.com>wrote:

> When you use mutable data structures, you live with the choice. For the
> statistics routines, I use exact->inexact inside the loop at the point where
> I use the value, so I'm not worried about it. Off the top of my head, the
> only problem I see is that exact->inexact also works on complex numbers, so
> I may still not have a simple float. I assume +inf.0, -inf.0, and +nan.0
> (and, therefore, -nan.0) also pass through exact->inexact. I further assume
> those are stored as floats (in an IEEE format) and work as expected - at
> least they seem to in the REPL. Is that a correct assumption? Are there
> other cases where exact->inexact does not give me a float? [I need to decide
> on a case by case basis what to do about complex numbers.]
> On Sun, Oct 4, 2009 at 12:53 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>> At Sat, 3 Oct 2009 08:34:03 -0600, Matthew Flatt wrote:
>> > (while the contract on the "checked" version ensures that the unsafe
>> > operations will not cause a crash).
>> Not true. Sam points out that a vector (or other sequence) can be
>> mutable, so checking elements at the beginning does not make `variance'
>> safe if it uses unsafe operations on the elements internally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091004/a8851d38/attachment.html>

Posted on the dev mailing list.