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

I added real->float in the math functions in the science collection that
I'll call.

;;; (real->float x) -> inexact-real?
;;;   x : real?
;;; Returns an inexact real (i.e., a float) given real x. Raises an error if
x
;;; is not a real. This can be used to ensure a real value is a float, even
in
;;; unsafe code.
(define (real->float x)
  (if (real? x)
      (exact->inexact x)
      (error "expected real, given" x)))

I'll use it to protect unsafe code. I'm sure it's more overhead than putting
it in-line, but hopefully not too much. Putting a contract on it would
probably not make much sense.

On Sun, Oct 4, 2009 at 4:27 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> At Sun, 4 Oct 2009 14:46:48 -0400, Doug Williams 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.
>
> Right. You'd need a `real?' or (after conversion) `inexact-real?' test.
>
> In the `mean-and-variance' example, I changed `(exact->inexact x)' in
> the loop to `(if (real? x) (exact->inexact x) 0.0)'. The overhead of
> the test was just 1 msec out of 90 msec, so that's probably a good
> option for preserving safety.
>
> > 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?
>
> Yes.
>
> > Are there
> > other cases where exact->inexact does not give me a float?
>
> No, the only issue is 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/40c256d3/attachment.html>