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

[Matthew Flatt]

At Sat, 3 Oct 2009 15:27:57 -0400, Doug Williams wrote:
 Do you think you can sneak in unsafe-fx-abs and unsafe-fl-abs?

Added in 4.2.2.4 (which is the most recent nightly build).

_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Matthew Flatt]

At Sat, 3 Oct 2009 16:54:26 -0400, Doug Williams wrote:
 One more thing. Is there a one argument unsafe-fx- and unsafe-fl- to negate
 a fixnum or float? [I suppose the same question would apply to
 division/inversion, although I don't use it as much.] Obviously, I can use
 (unsafe-fl- 0.0 x) for (unsafe-fl- x).

There are no one-argument versions, currently.
_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Matthew Flatt]

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.


_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Matthew Flatt]

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 mfl...@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.
 
 
 
_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Doug Williams]

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 mfl...@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 mfl...@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.
  
  
  

_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Dave Herman]

;;; (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.


I feel a little dirty suggesting it, but you could also do:

(define-syntax-rule (real-float exp)
  (let ([x exp])
(if (real? x)
(exact-inexact x)
(error expected real, given x

I'm not sure whether the mzscheme compiler obeys the Macro Writer's  
Bill of Rights in optimizing the case where exp is just a variable  
reference. If not, you could do the optimization yourself:


(define-syntax (real-float stx)
  (syntax-case stx ()
[(_ x)
 (identifier? #'x)
 #'(if (real? x)
   (exact-inexact x)
   (error expected real, given x))]
[(_ exp)
 #'(let ([x exp])
 (real-float x))]))

Dave

_
 For list-related administrative tasks:
 http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Eli Barzilay]

On Oct  4, Dave Herman wrote:
 I'm not sure whether the mzscheme compiler obeys the Macro Writer's  
 Bill of Rights in optimizing the case where exp is just a variable  
 reference.

- (compile '(define (fib1 n) (if (= n 1) n (+ (fib1 (- n 1)) (fib1 (- n 
2))
#~binary junk

- (compile '(define (fib2 n) (let* ([x n] [n x]) (if (= n 1) n (+ (fib2 (- n 
1)) (fib2 (- n 2)))
#~same-looking binary junk

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Doug Williams]

When I was originally thinking about it, I was thinking a macro, too. I like
the real-float as an exported function for simplicity - I think most users
of the science collection would be more comfortable with it in their own
code. But I like the syntax of the following macro.

(define-syntax (with-float stx)
  (syntax-case stx ()
((_ (x ...) expr ...)
 (for ((id (in-list (syntax-list #'(x ...)
   (unless (identifier? id)
 (raise-syntax-error #f
 not an identifier
 stx
 id)))
 #`(let ((x (if (real? x)
(exact-inexact x)
(error expected real, given x)))
 ...)
 expr ...

It would be used in something like:

(define (test x y)
  (with-float (x y)
(printf x = ~a, y = ~a~n x y)))

The expr's are executed with x and y guaranteed to be floats. So, (test 10
20) prints x = 10.0 y = 20.0 and (test 10+10i 20) errors with expected real,
given 10+10i. Also, the x's must be identifiers or a syntax error is raised
at expansion time.

Can any of the macro gurus comment on whether this make sense? It works, but
for example, there might be a cleaner way than the (syntax-list #'(x ...))
to do the iteration.


On Sun, Oct 4, 2009 at 4:55 PM, Dave Herman dher...@ccs.neu.edu wrote:

 ;;; (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.


 I feel a little dirty suggesting it, but you could also do:

 (define-syntax-rule (real-float exp)
  (let ([x exp])
(if (real? x)
(exact-inexact x)
(error expected real, given x

 I'm not sure whether the mzscheme compiler obeys the Macro Writer's Bill of
 Rights in optimizing the case where exp is just a variable reference. If
 not, you could do the optimization yourself:

 (define-syntax (real-float stx)
  (syntax-case stx ()
[(_ x)
 (identifier? #'x)
 #'(if (real? x)
   (exact-inexact x)
   (error expected real, given x))]
[(_ exp)
 #'(let ([x exp])
 (real-float x))]))

 Dave


_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Ryan Culpepper]

Dave Herman wrote:

;;; (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.


I feel a little dirty suggesting it, but you could also do:

(define-syntax-rule (real-float exp)
  (let ([x exp])
(if (real? x)
(exact-inexact x)
(error expected real, given x

I'm not sure whether the mzscheme compiler obeys the Macro Writer's Bill 
of Rights in optimizing the case where exp is just a variable reference. 
If not, you could do the optimization yourself:


(define-syntax (real-float stx)
  (syntax-case stx ()
[(_ x)
 (identifier? #'x)
 #'(if (real? x)
   (exact-inexact x)
   (error expected real, given x))]
[(_ exp)
 #'(let ([x exp])
 (real-float x))]))


No! 'identifier?' does not check whether a syntax object represents a 
variable reference, given 1) identifier macros and 2) #%top transformers 
for unbound variables. If you really, really want to check if something 
is a variable reference, 'local-expand' it and look at the result.


But even if it is a variable reference, there's no guarantee that there 
isn't another thread holding a reference to it, waiting to change it 
from a real to, say a complex number right after the 'real?' check is done.


Ryan

_
 For list-related administrative tasks:
 http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Dave Herman]

No! 'identifier?' does not check whether a syntax object represents  
a variable reference, given 1) identifier macros and 2) #%top  
transformers for unbound variables. If you really, really want to  
check if something is a variable reference, 'local-expand' it and  
look at the result.


Oh, yes, of course. All the more reason to hope mzscheme supports  
MWBoR. (Eli's email suggests it does.)


Dave

_
 For list-related administrative tasks:
 http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Doug Williams]

 No! 'identifier?' does not check whether a syntax object represents a
 variable reference, given 1) identifier macros and 2) #%top transformers for
 unbound variables. If you really, really want to check if something is a
 variable reference, 'local-expand' it and look at the result.


Will I not always get an unbound identifier in module (or something
similar) with the offending variable explicitly in the message? That's as
good to me as any message I make up. If not, it would be worth the effort.


 But even if it is a variable reference, there's no guarantee that there
 isn't another thread holding a reference to it, waiting to change it from a
 real to, say a complex number right after the 'real?' check is done.


I'm sure one can always come up with pathological things that can be done.
Even if I do something to ensure that the test and binding are atomic, I not
sure it doesn't defeat the purpose of the macro - to protect unsafe code. I
would say don't use unsafe code on variables that are shared among
processes.

But thanks for the comments.



 Ryan


_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Matthew Flatt]

As of v4.2.2.3 (in SVN), the JIT can unbox some intermediate flonum
values in `unsafe-fl' combinations. For example, in

 (unsafe-fl+ 1.0 (unsafe-fl- x y))

the JIT can see that `unsafe-fl-' will produce a flonum while
`unsafe-fl+' consumes a flonum, so there is no reason to box the flonum
and then immediately unbox it. Instead, the subtraction result is left
in a register for the addition operation.

As an example application, Doug's statistics library includes

 (define (mean-and-variance data)
   (let-values (((n m s)
 (dispatch-for/fold ((i-old 0)
 (m-old 0.0)
 (s-old 0.0))
((x data))
   (let ((i-new (add1 i-old)))
 (if (= i-new 1)
 (values i-new (exact-inexact x) 0.0)
 (let* ((m-new (+ m-old (/ (- x m-old) i-new)))
(s-new (+ s-old (* (- x m-old) (- x m-new)
   (values i-new m-new s-new)))
 (values m (if ( n 1) (/ s (sub1 n)) 0.0

If you're willing to re-write that as

 (define (mean-and-variance data)
   (let-values (((n m s)
 (dispatch-for/fold ((i-old 0)
 (m-old 0.0)
 (s-old 0.0))
((x data))
   (let ((i-new (unsafe-fx+ i-old 1))
 (x (exact-inexact x))) ; ensure flonum, assuming real
 (if (unsafe-fx= i-new 1)
 (values i-new x 0.0)
 (let* ((m-new (unsafe-fl+ m-old 
   (unsafe-fl/ 
(unsafe-fl- x m-old) 
(unsafe-fx-fl i-new
(s-new (unsafe-fl+ s-old
   (unsafe-fl*
(unsafe-fl- x m-old) 
(unsafe-fl- x m-new)
   (values i-new m-new s-new)))
 (values m (if ( n 1) (/ s (sub1 n)) 0.0

then the JIT can avoid about 6 boxes every iteration (leaving abut 2
boxes, assuming that `data' is a vector of flonums).


To measure the effect of unsafe operations and unboxing, I used code
that Doug posted recently:

  (let ((data1 (build-vector
10
(lambda (i)
  (random-unit-gaussian)
;; Don't time first call
(variance data1)
;; Checked:
(time
 (for ((i (in-range 10)))
   (variance data1)))
(collect-garbage)
;; Unchecked:
(time
 (for ((i (in-range 10)))
   (unchecked-variance data1


The times in msec on Mac OS X 10.6.1 using a 2.53 GHz MacBook Pro:

 x86  x86_64
 chkd/unchkdchkd/unchkd

   original   165 / 155 143 / 129
   unsafe (~v4.2.2)   138 / 128 138 / 123
   unsafe+unboxed (new)94 / 70   67 / 55

Each table cell shows the checked version of the function, which
includes a contract (to ensure that `data' is a sequence of reals), and
the contract-less unchecked version. The unchecked comparison is
not apples-to-apples for users of the library, because using unsafe
operations makes the unchecked version unsafe at the Scheme level
(while the contract on the checked version ensures that the unsafe
operations will not cause a crash).


The JIT only unboxes in expressions that combine

 * `unsafe-fl' operations,
 * `unsafe-fx-fl', or
 * variable access (local or global)

For example, the bytecode compiler currently leaves the `z' intact in

 (let ([z (unsafe-fl- x y)])
   (unsafe-fl+ 1.0 z))

which means that the JIT cannot avoid the box for `z'. I'm planning
improvements for the bytecode compiler to help the JIT in such cases.

Other directions for future improvement include allowing more
`unsafe-fx' operations in unboxable combinations and adding support for
reading and writing to an array of flonums without extra boxing.

_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Doug Williams]

About a 2x speed improvement is worth the rewrite. And, in the case of the
statistics functions, for example, most always return a float result (even
with non-float inputs) and would benefit from the rewrite. [Most that don't
always return a float, like minimum and maximum, aren't don't much
computation anyway.] I'd really like to try in on things like the Chebyshev
evaluator (which is basically used for all of the special functions) and the
differential equation solver (which is used by the simulation engine for
continuous simulations).

Are the basic unsafe-fl, unsafe-fx, and unsafe-vector-ref operations
included in 4.2.2? [I realize that the JIT enhancements here would not be.]
If they are, then I can put them into a new version of the science
collection that is dependent on 4.2.2 instead of some upcoming release.

Doug

On Sat, Oct 3, 2009 at 10:34 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 As of v4.2.2.3 (in SVN), the JIT can unbox some intermediate flonum
 values in `unsafe-fl' combinations. For example, in

  (unsafe-fl+ 1.0 (unsafe-fl- x y))

 the JIT can see that `unsafe-fl-' will produce a flonum while
 `unsafe-fl+' consumes a flonum, so there is no reason to box the flonum
 and then immediately unbox it. Instead, the subtraction result is left
 in a register for the addition operation.

 As an example application, Doug's statistics library includes

  (define (mean-and-variance data)
   (let-values (((n m s)
 (dispatch-for/fold ((i-old 0)
 (m-old 0.0)
 (s-old 0.0))
((x data))
   (let ((i-new (add1 i-old)))
 (if (= i-new 1)
 (values i-new (exact-inexact x) 0.0)
 (let* ((m-new (+ m-old (/ (- x m-old) i-new)))
(s-new (+ s-old (* (- x m-old) (- x
 m-new)
   (values i-new m-new s-new)))
 (values m (if ( n 1) (/ s (sub1 n)) 0.0

 If you're willing to re-write that as

  (define (mean-and-variance data)
   (let-values (((n m s)
 (dispatch-for/fold ((i-old 0)
 (m-old 0.0)
 (s-old 0.0))
((x data))
   (let ((i-new (unsafe-fx+ i-old 1))
 (x (exact-inexact x))) ; ensure flonum, assuming
 real
 (if (unsafe-fx= i-new 1)
 (values i-new x 0.0)
 (let* ((m-new (unsafe-fl+ m-old
   (unsafe-fl/
(unsafe-fl- x m-old)
(unsafe-fx-fl i-new
(s-new (unsafe-fl+ s-old
   (unsafe-fl*
(unsafe-fl- x m-old)
(unsafe-fl- x m-new)
   (values i-new m-new s-new)))
 (values m (if ( n 1) (/ s (sub1 n)) 0.0

 then the JIT can avoid about 6 boxes every iteration (leaving abut 2
 boxes, assuming that `data' is a vector of flonums).


 To measure the effect of unsafe operations and unboxing, I used code
 that Doug posted recently:

  (let ((data1 (build-vector
10
(lambda (i)
  (random-unit-gaussian)
;; Don't time first call
(variance data1)
;; Checked:
(time
 (for ((i (in-range 10)))
   (variance data1)))
(collect-garbage)
;; Unchecked:
(time
 (for ((i (in-range 10)))
   (unchecked-variance data1


 The times in msec on Mac OS X 10.6.1 using a 2.53 GHz MacBook Pro:

 x86  x86_64
 chkd/unchkdchkd/unchkd

   original   165 / 155 143 / 129
   unsafe (~v4.2.2)   138 / 128 138 / 123
   unsafe+unboxed (new)94 / 70   67 / 55

 Each table cell shows the checked version of the function, which
 includes a contract (to ensure that `data' is a sequence of reals), and
 the contract-less unchecked version. The unchecked comparison is
 not apples-to-apples for users of the library, because using unsafe
 operations makes the unchecked version unsafe at the Scheme level
 (while the contract on the checked version ensures that the unsafe
 operations will not cause a crash).


 The JIT only unboxes in expressions that combine

  * `unsafe-fl' operations,
  * `unsafe-fx-fl', or
  * variable access (local or global)

 For example, the bytecode compiler currently leaves the `z' intact in

  (let ([z (unsafe-fl- x y)])
   (unsafe-fl+ 1.0 z))

 which means that the JIT cannot avoid the box for `z'. I'm planning
 improvements for the bytecode compiler to help the JIT in such cases.

 

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

[Matthew Flatt]

At Sat, 3 Oct 2009 12:29:01 -0400, Doug Williams wrote:
 Are the basic unsafe-fl, unsafe-fx, and unsafe-vector-ref operations
 included in 4.2.2?

Yes --- except for `unsafe-fx-fl', which is new in 4.2.2.3.

_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Matthew Flatt]

`inexact-real?'

At Sat, 3 Oct 2009 12:47:35 -0400, Doug Williams wrote:
 Is there an existing contract to check for a float? For example, mean would
 now be guaranteed to return a float instead of a real. It would be nice to
 specify this is the contract.
 
 On Sat, Oct 3, 2009 at 12:36 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 
  At Sat, 3 Oct 2009 12:29:01 -0400, Doug Williams wrote:
   Are the basic unsafe-fl, unsafe-fx, and unsafe-vector-ref operations
   included in 4.2.2?
 
  Yes --- except for `unsafe-fx-fl', which is new in 4.2.2.3.
 
 
_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Doug Williams]

Matthew,

Do you think you can sneak in unsafe-fx-abs and unsafe-fl-abs? It's a pretty
common function - at least in the science collection - that I assume would
compile nicely. [I promise not to ask for too many of these.]

Doug

On Sat, Oct 3, 2009 at 12:56 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 `inexact-real?'

 At Sat, 3 Oct 2009 12:47:35 -0400, Doug Williams wrote:
  Is there an existing contract to check for a float? For example, mean
 would
  now be guaranteed to return a float instead of a real. It would be nice
 to
  specify this is the contract.
 
  On Sat, Oct 3, 2009 at 12:36 PM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
 
   At Sat, 3 Oct 2009 12:29:01 -0400, Doug Williams wrote:
Are the basic unsafe-fl, unsafe-fx, and unsafe-vector-ref operations
included in 4.2.2?
  
   Yes --- except for `unsafe-fx-fl', which is new in 4.2.2.3.
  
  

_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev

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

[Doug Williams]

One more thing. Is there a one argument unsafe-fx- and unsafe-fl- to negate
a fixnum or float? [I suppose the same question would apply to
division/inversion, although I don't use it as much.] Obviously, I can use
(unsafe-fl- 0.0 x) for (unsafe-fl- x).

On Sat, Oct 3, 2009 at 4:07 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Yes, I can add those.

 At Sat, 3 Oct 2009 15:27:57 -0400, Doug Williams wrote:
  Matthew,
 
  Do you think you can sneak in unsafe-fx-abs and unsafe-fl-abs? It's a
 pretty
  common function - at least in the science collection - that I assume
 would
  compile nicely. [I promise not to ask for too many of these.]
 
  Doug
 
  On Sat, Oct 3, 2009 at 12:56 PM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
 
   `inexact-real?'
  
   At Sat, 3 Oct 2009 12:47:35 -0400, Doug Williams wrote:
Is there an existing contract to check for a float? For example, mean
   would
now be guaranteed to return a float instead of a real. It would be
 nice
   to
specify this is the contract.
   
On Sat, Oct 3, 2009 at 12:36 PM, Matthew Flatt mfl...@cs.utah.edu
   wrote:
   
 At Sat, 3 Oct 2009 12:29:01 -0400, Doug Williams wrote:
  Are the basic unsafe-fl, unsafe-fx, and unsafe-vector-ref
 operations
  included in 4.2.2?

 Yes --- except for `unsafe-fx-fl', which is new in 4.2.2.3.


  

_
  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-dev