Lispers know that
(coerce <rational> 'complex)
returns a rational, but is a conforming implementation required to
respond to
(coerce <rational> '(complex float))
with a complex float? CLtL2 seems to suggest a complex float, as
one would expect. What is the opinion of the fine CLHS?
--
"I believe in the horse. The automobile is a passing phenomenon."
-- Kaiser Wilhelm II. (1859-1941)
·····@gmx.net (Wolfhard Bu�) writes:
> (coerce <rational> '(complex float))
>
> with a complex float? CLtL2 seems to suggest a complex float, as
> one would expect. What is the opinion of the fine CLHS?
In case it's useful information, this coercion works in ACL and LW.
It would be interesting to find out why others would do this --
especially for complex numbers. I can think of one or two possible
reasons.
The basic situation where I use rationals and then convert to a floating
point representation is when I deal with money. I love the ``infinite''
precision of using rational numbers in calculations, and then only
converting and rounding at the end.
I've been working on financial systems, and have seen some other code
(e.g. in C), where all monetary values are converted to integers, and
then at the end converted back (i.e. multiply all monies by 100 and then
divide by 100 and round at the end). I don't like that, because you're
not only changing the format of the number, but changing the value, and
mistakes can be very dangerous. If you try to write "2/3" to a database
column of type MONEY or NUMERIC(10,2), then you at least get an error.
dave
Dave Bakhash <·····@alum.mit.edu> wrote:
+---------------
| ·····@gmx.net (Wolfhard Bu�) writes:
| > (coerce <rational> '(complex float))
| > with a complex float? CLtL2 seems to suggest a complex float, as
| > one would expect. What is the opinion of the fine CLHS?
|
| In case it's useful information, this coercion works in ACL and LW.
+---------------
Well, maybe it *doesn't* "work"; see below... ;-}
In CLISP (admittedly an older one):
(coerce 3.14 '(complex float)) ==> #C(3.14 0.0)
[1] (coerce 22/7 '(complex float)) ==> #C(3.142857 0.0)
[2] (coerce 22/7 'complex) ==> 22/7
(coerce 22/7 'float) ==> 3.142857
And CMUCL (also an old one):
(coerce 3.14 '(complex float)) ==> #C(3.14 0.0)
[3] (coerce 22/7 '(complex float)) ==> 22/7
[4] (coerce 22/7 'complex) ==> 22/7
(coerce 22/7 'float) ==> 3.142857
Hmmm... Looks like CMUCL may be doing the right thing here
in cases #3 & #4 above, CLISP in case #2, while CLISP may be
doing the wrong thing in case #1. The CHLS "Function COERCE" says:
Otherwise, the object is coerced to type result-type
according to the following rules:
[list of result-types]
...
complex
...
(If the real part is a rational, however, then the result
must be represented as a rational rather than a complex;
see Section 12.1.5.3 (Rule of Canonical Representation for
Complex Rationals). So, for example, (coerce 3 'complex)
is permissible, but will return 3, which is not a complex.)
And CLHS 12.1.5.3 (non-glossary links in caps):
If the result of any computation would be a complex number whose
real part is of type RATIONAL and whose imaginary part is zero,
the result is converted to the rational which is the real part.
So CMUCL does the right thing here, too:
(coerce 4 '(complex float)) ==> 4
(coerce 4 'complex) ==> 4
(coerce 4 'float) ==> 4.0
However:
This rule does not apply to complex numbers whose parts are
floats. For example, #C(5 0) and 5 are not different objects
in Common Lisp (they are always the same under EQL); #C(5.0 0.0)
and 5.0 are always different objects in Common Lisp (they are
never the same under EQL, although they are the same under
EQUALP and =).
-Rob
-----
Rob Warnock, 30-3-510 <····@sgi.com>
SGI Network Engineering <http://www.rpw3.org/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
>>>>> "Rob" == Rob Warnock <····@rigden.engr.sgi.com> writes:
Rob> Dave Bakhash <·····@alum.mit.edu> wrote:
Rob> +---------------
Rob> | ·····@gmx.net (Wolfhard Bu�) writes:
Rob> | > (coerce <rational> '(complex float))
Rob> | > with a complex float? CLtL2 seems to suggest a complex float, as
Rob> | > one would expect. What is the opinion of the fine CLHS?
Rob> |
Rob> | In case it's useful information, this coercion works in ACL and LW.
Rob> +---------------
Rob> Well, maybe it *doesn't* "work"; see below... ;-}
Rob> In CLISP (admittedly an older one):
Rob> (coerce 3.14 '(complex float)) ==> #C(3.14 0.0)
Rob> [1] (coerce 22/7 '(complex float)) ==> #C(3.142857 0.0)
Rob> [2] (coerce 22/7 'complex) ==> 22/7
Rob> (coerce 22/7 'float) ==> 3.142857
Rob> And CMUCL (also an old one):
Rob> (coerce 3.14 '(complex float)) ==> #C(3.14 0.0)
Rob> [3] (coerce 22/7 '(complex float)) ==> 22/7
Rob> [4] (coerce 22/7 'complex) ==> 22/7
Rob> (coerce 22/7 'float) ==> 3.142857
Rob> Hmmm... Looks like CMUCL may be doing the right thing here
Rob> in cases #3 & #4 above, CLISP in case #2, while CLISP may be
Rob> doing the wrong thing in case #1. The CHLS "Function COERCE" says:
Rob> Otherwise, the object is coerced to type result-type
Rob> according to the following rules:
Rob> [list of result-types]
Rob> ...
Rob> complex
Rob> ...
Rob> (If the real part is a rational, however, then the result
Rob> must be represented as a rational rather than a complex;
Rob> see Section 12.1.5.3 (Rule of Canonical Representation for
Rob> Complex Rationals). So, for example, (coerce 3 'complex)
Rob> is permissible, but will return 3, which is not a complex.)
Rob> And CLHS 12.1.5.3 (non-glossary links in caps):
Rob> If the result of any computation would be a complex number whose
Rob> real part is of type RATIONAL and whose imaginary part is zero,
Rob> the result is converted to the rational which is the real part.
Rob> So CMUCL does the right thing here, too:
Rob> (coerce 4 '(complex float)) ==> 4
Rob> (coerce 4 'complex) ==> 4
Rob> (coerce 4 'float) ==> 4.0
Somehow, I think Clisp and CMUCL are wrong for the (complex float)
case. I want a complex number whose components are float, so I should
get that. For the case of just complex, I get a complex number whose
components are an any real type, which is rational in this case. The
the rule about complex rationals becoming rationals apply since the
imaginary part is the integer 0.
FWIW, ACL and LW both say #c(4.0 0.0).
Ray