[r6rs-discuss] [Formal] Clarification of chapter 1 overview bits re: exactness and complex numbers

From: Aubrey Jaffer <agj>
Date: Thu Jan 25 21:27:09 2007

 | Date: Thu, 25 Jan 2007 10:40:46 -0500
 | From: John Cowan <cowan_at_ccil.org>
 |
 | Michael Sperber scripsit:
 |
 | > (The report doesn't really mandate exact complex numbers anymore
 | > as of the 5.92 draft.)
 |
 | Say what? 9.9.1 includes make-rectangular among the procedures
 | that "must return the correct exact result provided all their
 | arguments are exact". Furthermore, the token "1+i" must represent
 | an exact number.
 |
 | And why on earth would the requirement for exact complex numbers be
 | dropped?

The questions should be:

 * What purposes do exact non-real complex numbers serve?

 * Are those uses important enough to justfiy the labor and code bloat
   created by mandating their implementation?

SCM does millions of (non-real) complex operations for my optical
simulations (http://swiss.csail.mit.edu/~jaffer/FreeSnell/).

A non-real complex number in SCM is represented by two flonums in a
single box; it is always inexact. Support for complex numbers is
coded directly in the C arithmetic routines. Because complex
operations are composed of multiple floating-point instructions (and
manipulate more data), the interpreter penalty when executing complex
calculations is significantly less severe than for, say, real flonums.

SCM's SRFI-63 arrays include complex uniform-arrays which store
complex flonums compactly. But r6rs-lib_92 bytevectors (page 8-9) do
not support non-real numbers.

To represent exact complexes requires either boxing two potentially
boxed numbers or a flury of new combination types:

 real-bignum with imag-bignum
 real-bignum with imag-fixnum
 real-bignum with imag-ratnum
 real-fixnum with imag-bignum
 real-fixnum with imag-fixnum
 real-fixnum with imag-ratnum
 real-ratnum with imag-bignum
 real-ratnum with imag-fixnum
 real-ratnum with imag-ratnum

where each ratnum can be:

 num-bignum with den-bignum
 num-bignum with den-fixnum
 num-fixnum with den-bignum
 num-fixnum with den-fixnum

Adding so many new types will impact type-code space and swell the
run-time program.

In the double-boxing scenario when one component is a ratnum, a number
can be triple-boxed! Wading through so many levels of boxing will
perform tepidly at best.

With inexact complex numbers, even interpreted R5RS implementations
can provide good platforms for physics, optics, and electronics
calculations and simulations. What "killer apps" become possible with
exact complex numbers?
Received on Thu Jan 25 2007 - 21:26:26 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC