r28523 - docs/Perl6/Spec/S32-setting-library
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$nth (complex) roots of C$x
+Returns a list of all C$nth (complex) roots of C$x. Returns CNaN if
+C $n = 0 , itself if C$n == 0, and is free to return a single CNaN
+if C$x is CNaN or CInf, or in case of complex numbers if one of the
+components is.
=item cis
@@ -207,6 +210,16 @@
=head2 Complex
+CComplex is an immutable type. Each CComplex object stores two numbers,
+the real and imaginary part. For all practical purposes a CComplex with
+a CNaN in real or imaginary part may be considered a CNaN itself (and
+C(NaN + 1i) ~~ NaN is CTrue).
+
+Coercion of a CComplex to any CReal returns the real part (coerced, if
+necessary) if the imaginary part is 0, and fails otherwise. Comparison
+between a CReal number and a CComplex must be smart enough not to coerce
+the CComplex to a real number blindly.
+
=over 4
=item polar
@@ -218,13 +231,13 @@
=item re
-method re() {...}
+our Real multi method re()
Returns the real part of the complex number.
=item im
-method im() {...}
+our Real multi method im()
Returns the imaginary part of a complex number.
Re: r28523 - docs/Perl6/Spec/S32-setting-library
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$nth (complex) roots of C$x +Returns a list of all C$nth (complex) roots of C$x. Returns CNaN if +C $n = 0 , itself if C$n == 0, and is free to return a single CNaN 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 CNaN or CInf, 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 +CComplex is an immutable type. Each CComplex object stores two numbers, +the real and imaginary part. For all practical purposes a CComplex with +a CNaN in real or imaginary part may be considered a CNaN itself (and +C(NaN + 1i) ~~ NaN is CTrue). I'm not sure that I feel comfortable locking CComplex 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
Re: r28523 - docs/Perl6/Spec/S32-setting-library
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$nth (complex) roots of C$x +Returns a list of all C$nth (complex) roots of C$x. Returns CNaN if +C $n = 0 , itself if C$n == 0, and is free to return a single CNaN 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. +CComplex is an immutable type. Each CComplex object stores two numbers, +the real and imaginary part. For all practical purposes a CComplex with +a CNaN in real or imaginary part may be considered a CNaN itself (and +C(NaN + 1i) ~~ NaN is CTrue). I'm not sure that I feel comfortable locking CComplex 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
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: 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. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. By enforcing NaN for a list of roots, math code suddenly has to include a set of extraneous tests in order to coerce the result to a list of ones. And that _is_ nonsensical. -- Jan
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Oct 1, 2009, at 4:15 PM, Moritz Lenz wrote: -Returns a list of all C$nth (complex) roots of C$x +Returns a list of all C$nth (complex) roots of C$x. Returns CNaN if +C $n = 0 , itself if C$n == 0, and is free to return a single CNaN 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. But the very next part of the sentence reads [returns] itself if C$n == 0. If root($x, 0) is supposed to return a list containing both NaN and $x, the specification should probably be explicit. If it's meant to only return NaN, the itself if C$n == 0 part needs to be deleted. -- Minimiscience
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Oct 1, 2009, at 4:43 PM, Jan Ingvoldstad wrote: On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: 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. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. I think you're confusing root with power. Any number raised to the zeroth power is one (except, arguably, zero itself), but, given a number $num, its zeroth root is a number $base such that $base ** 0 == $num, which, as stated above, only makes sense when $num == 1. -- Minimiscience
Re: r28523 - docs/Perl6/Spec/S32-setting-library
Jan Ingvoldstad wrote: On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: 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. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. Excuse me? given a number $x, roots($x, $n) returns a List (mathematically speaking a Set) of numbers $y, for which $y**$n == $x holds true. If roots(3, 0) returned 1, then 1**0 == 1, which is not 3. It's bettter to return NaN to indicate an impossible operation, rather than to return an ordinary number which is a wrong result. It is not obvious to me why 1 or in fact any defined number at all would be a mathematically sensible result - care to elaborate? Cheers, Moritz
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Thu, Oct 1, 2009 at 11:03 PM, Minimiscience minimiscie...@gmail.comwrote: On Oct 1, 2009, at 4:43 PM, Jan Ingvoldstad wrote: On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: 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. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. I think you're confusing root with power. Any number raised to the zeroth power is one (except, arguably, zero itself), but, given a number $num, its zeroth root is a number $base such that $base ** 0 == $num, which, as stated above, only makes sense when $num == 1. You're of course right, that was an amazing brainfart. I blame society. -- Jan
