[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Numerical example (real? -2.5+0.0i)
| Date: Tue, 16 Aug 2011 14:25:11 -0400
| From: John Cowan <cowan@x>
|
| Aubrey Jaffer scripsit:
|
| > Algebraically, the complex numbers are the field of reals extended by
| > a solution of x^2+1=0. All reals are complex; there is no difference
| > between real 2.0 and 2.0+0.0i.
|
| I used the term "general complex number" in the same sense it is used
| in R5RS, to mean a number whose imaginary part is nonzero.
|
| > FreeSnell <http://people.csail.mit.edu/jaffer/FreeSnell> is a Scheme
| > application for computing the optical properties of thin-films. It
| > uses complex numbers intensively in its computations. The only
| > effects of distinguishing real real from complex real numbers would be
| > to increase its storage and reduce its performance.
|
| I don't understand this. How can either storage or performance depend
| on the result returned by the real? procedure?
In SCM, inexacts are created by the C procedure:
SCM makdbl(double x, double y).
If y is nonzero then 16.B are allocated and a tc_dblc is returned.
Otherwise only 8.B are allocated and a tc_dblr is returned.
( Actually, if x fits in a 32.bit float without loss of accuracy when
converting back to double, then a 32.bit float is put in the CDR of
the header cell and no malloc() is done. )
Making "complex reals" occupy 16.B would increase the storage used and
make every mathematical operation on them slower because complex
operations are more complicated than real ones.
I could play games with type bits, but with 6 internal numeric types
already (INUM, flo, dblr, dblc, bigpos, and bigneg), modifying all the
numeric dispatch code would require significant effort, all for a
distinction which I have neither wanted nor needed in years of heavy
complex-number crunching.
| > So no, SCM won't be distinguishing "real reals" from "complex reals".
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports