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<$n>th (complex) roots of C<$x>
+Returns a list of all C<$n>th (complex) roots of C<$x>. Returns C if
+C<< $n <= 0 >>, itself if C<$n == 0>, and is free to return a single C
+if C<$x> is C or C, or in case of complex numbers if one of the
+components is.
=item cis
@@ -207,6 +210,16 @@
=head2 Complex
+C is an immutable type. Each C object stores two numbers,
+the real and imaginary part. For all practical purposes a C with
+a C in real or imaginary part may be considered a C itself (and
+C<(NaN + 1i) ~~ NaN> is C).
+
+Coercion of a C to any C returns the real part (coerced, if
+necessary) if the imaginary part is 0, and fails otherwise. Comparison
+between a C number and a C must be smart enough not to coerce
+the C 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: "&&" in list context
On Tue, Sep 29, 2009 at 03:49:31PM +0200, Christoph Bussenius wrote:
: Hi,
:
: I read is S03,
:
: The && and || operators are smarter about list context and return ()
: on failure in list context rather than Bool::False. The operators
: still short-circuit, but if either operator would return a false
: value, it is converted to the null list in list context so that the
: false results are self-deleting.
:
: For "&&", wouldn't it be a better idea to return an empty list only if
: the *first* operand is false? In other words, I suggest that "$a && $b"
: behave in list context like this:
:
: * If $a is false, return ()
: * Otherwise, return $b
:
: Here's a use case that would benefit from this behaviour:
:
: Suppose you want to generate an argument list for an external command.
: For some reason you have a boolean value $include_arg3 and you want to
: include $arg3 only if $include_arg3 is true:
:
:my @args = $arg1, $arg2, $include_arg3 && $arg3, $arg4;
:
: Here you probably want to include $arg3 even if it is a false value like
: "0", provided that $include_arg3 is true.
Hmm, well, I see your point, but there are some arguments for the current
behavior as well:
* Changing && without changing || would introduce a strange asymmetry.
* Changing && to be pure conditional kinda undoes the list associative
meaning of 'return the first false value or the last value'.
* It would imply propagating list context to the left side but not
the right side, which is time-travelishly problematic in a
lazy language.
* Alternately, it would mean that the result would have to be marked
as to whether it came from the left or the right so that binding
into a list context would know whether to throw it away or not.
* Or one could return Nil instead of the left value, but then you
lose any interesting value of false.
* If one wants it to mean
my @args = $arg1, $arg2, ($arg3 if $include_arg3), $arg4;
one can write it that way, since C already knows it's about
control flow, not data selection, and returns Nil on false. Or
you can write:
my @args = $arg1, $arg2, (if $include_arg3 {$arg3}), $arg4;
if you want them in the other order.
* If you know you're generating *positional* arguments ahead
of time, you probably don't want list processing anyway; you
probably want to put the args into a parcel/capture anyway to
delay the application of context until binding time:
my $args = \($arg1, $arg2, $include_arg3 && $arg3, $arg4);
In this case the result of the && is its own parcel/capture
that waits until binding time to decide how to behave.
But I agree that it's a trap of sorts. My gut feeling is that it
won't happen often enough to become a FAQ, but I could be wrong.
Larry
r28514 - docs/Perl6/Spec/S32-setting-library
Author: colomon Date: 2009-09-30 13:53:58 +0200 (Wed, 30 Sep 2009) New Revision: 28514 Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod Log: [docs/Perl6] postfix: should take a Numeric. Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod === --- docs/Perl6/Spec/S32-setting-library/Numeric.pod 2009-09-30 06:10:48 UTC (rev 28513) +++ docs/Perl6/Spec/S32-setting-library/Numeric.pod 2009-09-30 11:53:58 UTC (rev 28514) @@ -193,7 +193,7 @@ =item i - our Complex multi postfix: ( Num $x ) + our Complex multi postfix: ( Numeric $x ) Returns a complex number representing the parameter multiplied by the imaginary unit C. Note that there is no C<.i> method. To follow a variable name
