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 >>"? 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. > +if C<$x> is C<NaN> or C<Inf>, or in case of complex numbers if one of the > +components is. Ideally, the complex numbers case should be a moot point: if one of a complex number's components is NaN or Inf, then the complex number should be, too (with NaN taking precedence over Inf in the two cases where one component is NaN and the other is Inf). Exception: when a complex number's arg is Inf, the complex number should be NaN: the magnitude may be known, but the direction is completely indeterminate. > =item cis > > @@ -207,6 +210,16 @@ > > =head2 Complex > > +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, 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. -- Jonathan "Dataweaver" Lang
