Jon Lang wrote: > On Wed, Sep 30, 2009 at 11:58 PM, <pugs-comm...@feather.perl6.nl> wrote: >> >> Author: moritz >> Date: 2009-10-01 08:58:00 +0200 (Thu, 01 Oct 2009) >> New Revision: 28523 >> >> Modified: >> docs/Perl6/Spec/S32-setting-library/Numeric.pod >> Log: >> [S32::Num] More thoughts on Inf/NaN Complex, and on comparing Complex and >> Real numbers >> >> Also bring the goodness of the newly defined Numeric and Real roles to some >> of >> the signatures. >> >> Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod >> =================================================================== >> --- docs/Perl6/Spec/S32-setting-library/Numeric.pod 2009-10-01 02:34:54 >> UTC (rev 28522) >> +++ docs/Perl6/Spec/S32-setting-library/Numeric.pod 2009-10-01 06:58:00 >> UTC (rev 28523) >> @@ -175,9 +175,12 @@ >> >> =item roots >> >> - (in Num) method roots (Num $x: Int $n --> List of Num) is export >> + (in Num) method roots (Numeric $x: Int $n --> List of Num) is export >> >> -Returns a list of all C<$n>th (complex) roots of C<$x> >> +Returns a list of all C<$n>th (complex) roots of C<$x>. Returns C<NaN> if >> +C<< $n <= 0 >>, itself if C<$n == 0>, and is free to return a single C<NaN> > > Shouldn't this be "C<< $n < 0 >>"?
What's the 0th root of a number, then? It would be a number $y for which $y ** 0 == $x, which can only be fulfilled for $x == 1. So in the general cases the answer to the question root($x, 0) is nonsense, which is best mapped to NaN. > Also, I'm not sold that this > should return List of Num; I'd expect it to return a List of Numeric, > with the possibility (and, indeed, likelihood) that subsequent roots > will be Complex. Aye, Numeric would be better. Feel free to fix that. >> +C<Complex> is an immutable type. Each C<Complex> object stores two numbers, >> +the real and imaginary part. For all practical purposes a C<Complex> with >> +a C<NaN> in real or imaginary part may be considered a C<NaN> itself (and >> +C<(NaN + 1i) ~~ NaN> is C<True>). > > I'm not sure that I feel comfortable locking C<Complex> into > rectilinear coordinates as its internal storage method, Maybe my language wasn't all too clear, but please remember that a a use of the Complex type can't be aware of the internal storage anyway - it only uses methods and subs that work with Complex types. So an implementation is still free to store in polar coordinates internally. But FYI I looked into several implementations of Complex numbers, and they all store in (re, im), not in (mag, angle). That's because the most basic operations, + and -, are much faster with rectangular storage (polar ones need trig functions), and * and / are only slightly slower in rectangular storage (but only a few more additions and multiplications, no trig functions involved). If you're doing any kind of linear algebra, you're far better off that way. > as there will > be cases where the code operates more smoothly if you're using polar > coordinates to store the numbers: we should leave the inner workings > up to the Parrots to decide. But whichever approach gets used, if > either component is NaN, then the complex number should also be NaN. Wasn't that exactly what I said? ;-) Cheers, Moritz
