r28523 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

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

[Jon Lang]

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

object possible representations (was Re: r28523 - ...)

[Darren Duncan]

Jon Lang wrote:

On Wed, Sep 30, 2009 at 11:58 PM, pugs-comm...@feather.perl6.nl wrote:

+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.


I'm not sure if the idea is applicable to Perl 6 because Perl 6 already has an 
alternative but ...


One of the features of my Muldis D language is called possreps (possible 
representations) where you may define more than one alternative set of 
attributes for a data type (and if more than one, you also define functions to 
map between each attribute set) and then the implementation can choose for 
itself which of those representations (or it can pick yet another one of its 
own) is the actual one used physically behind the scenes and which is virtual, 
and the user could use either as if it were the real one.


What Perl 6 could do with this concept is for example it can define for some 
classes multiple possible object attribute sets, so users know they can use any 
of those, and then each Perl 6 implementation can choose what to do natively.


So the Perl 6 spec can and should enumerate the various reasonable alternative 
sets of attributes that a Complex object could have, and the Parrots can choose 
which to use internally, or could use more than one on a case-by-case basis.


Note that ideally this would be a feature that user-defined classes can use, and 
not just language built-in ones.


Now that I think about it, one way this could work within Perl 6's existing 
features is that Complex could be a role and each of the possible 
representations could be a class that does that role.  On the other hand ...


Perhaps how my actual proposal could be realized is as sugar in the language 
where one could write say:


  class A {
possrep B {
  has $c;
  has $d;
}
possrep E {
  has $f;
  has $g;
}
my submethod E_from_B ($c, $d) { returns $f, $g values }
my submethod B_from_E ($f, $g) { returns $c, $d values }
  }

Then users could say for example:

  my A $x = A.B.new( :c1, :d2 );
  my A $y = A.E.new( :f4, :g5 );
  my $c = $y.B.c;
  my $f = $x.E.f;

Of course, actual details or syntax could be different, but I think this general 
idea would be useful.


Note that in my actual proposal, B and E are *not* classes so doing my E $foo 
is invalid; the only class here is A.  Now Perl 6 may choose to design differently.


Now in Muldis D this system is strict and requires that one can round-trip 
between any 2 possreps and have identical attribute values to what one started 
with, so the Complex example where conversion would by nature be approximate 
wouldn't work there; but in Perl or a language where nonidentical round-trips 
are allowed, this may work for Complex too.  But then the implementation would 
have to always use the same physical representation for all objects of the same 
class, or else it wouldn't always DWIM when some one tries an exact equality 
test with objects.


-- Darren Duncan

Re: object possible representations (was Re: r28523 - ...)

[Jon Lang]

Darren Duncan wrote:
 Jon Lang wrote:
 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.

 I'm not sure if the idea is applicable to Perl 6 because Perl 6 already has
 an alternative but ...

 One of the features of my Muldis D language is called possreps (possible
 representations) where you may define more than one alternative set of
 attributes for a data type (and if more than one, you also define functions
 to map between each attribute set) and then the implementation can choose
 for itself which of those representations (or it can pick yet another one of
 its own) is the actual one used physically behind the scenes and which is
 virtual, and the user could use either as if it were the real one.

 What Perl 6 could do with this concept is for example it can define for some
 classes multiple possible object attribute sets, so users know they can use
 any of those, and then each Perl 6 implementation can choose what to do
 natively.

 So the Perl 6 spec can and should enumerate the various reasonable
 alternative sets of attributes that a Complex object could have, and the
 Parrots can choose which to use internally, or could use more than one on a
 case-by-case basis.

 Note that ideally this would be a feature that user-defined classes can use,
 and not just language built-in ones.

This sounds a bit like how the multi keyword applies to Perl 6
routines to define several routines that share one name.  Perhaps
there's a way to say multi class, letting you define several
classes that are different implementations of the same thing, with
each class definition within the multi class being a possrep.  I'm
not exactly sure how this would work (you'd need some way to
distinguish between the different class definitions, much like multi
routines each have a unique long name even though they share the same
short name); but it strikes me as being more in keeping with the
nature of Perl than nesting several possrep blocks within a single
class definition.  Perhaps a multi class would involve some sort of
implicit version control, with each class definition being given a
slightly different version?  (Do we still have proto routines to go
along with multi routines?  If so, you could use a proto class to
define common features shared by all of the implementations, such as
identifying which roles the multi class does.)

Whatever mechanism gets established, the basics would involve being
able to establish more than one possible implementation for a class,
combined with an ability to identify each implementation's relative
strengths and weaknesses so that the compiler has a way to choose
which one to use.

 Now in Muldis D this system is strict and requires that one can round-trip
 between any 2 possreps and have identical attribute values to what one
 started with, so the Complex example where conversion would by nature be
 approximate wouldn't work there; but in Perl or a language where
 nonidentical round-trips are allowed, this may work for Complex too.  But
 then the implementation would have to always use the same physical
 representation for all objects of the same class, or else it wouldn't always
 DWIM when some one tries an exact equality test with objects.

If only there was a way for Perl to track exact values for irrational
numbers like it does for rationals, rather than trying to approximate
them with Num; then one _could_ set up a round trip between
rectilinear and polar coordinates that preserves the original values
(in theory, at least; you'd still have to figure out how to address
the 0 = 2 * pi problem).

-- 
Jonathan Dataweaver Lang

Re: object possible representations (was Re: r28523 - ...)

[Jon Lang]

Some further thoughts:

Essentially, this could be done as an extension of the versioning
system.  The difference between possrep versioning and normal
versioning would lie in the means by which the possrep dimension would
be resolved if not specified.  Namely, the compiler would make the
decision based on the natures of the various classes and the
preferences of the various function calls.  To illustrate, let's say
that we have two implementations for Complex: one that's optimized for
rectilinear coordinates, and another that's optimized for polar
coordinates.

class Complex:optrect { ... }
class Complex:optpolar { ... }

...where opt is short for optimized implementation.  Both
implementations of Complex would be able to use rectilinear and polar
accessors; indeed, the assumption is that both are capable of handling
the exact same interfaces, differing only in terms of how well they
handle various aspects thereof.

A routine's signature could then include a request for one or the
other - say, something like:

sub foo(Complex:optpolar) { ... }

This would not _require_ that a Complex:optpolar be provided; only
that a Complex be provided.  But if I were to say my Complex $x;,
followed by a large number of foo $x calls, the compiler might
choose to implement $x as a Complex:optpolar.

More radically, the sig might be able to provide a priority number as
well as an option name: e.g., 0 for this is just a suggestion; 1
for it's strongly recommended that you supply this implementation;
and 2 for do whatever it takes to supply this implementation.  So:

sub foo(Complex:optrect 1) { ... }
sub bar(Complex:optrect 0) { ... }

...Would mean that if you try to hand foo a Complex:optpolar, foo
will coerce it into a Complex:optrect before using it; whereas bar
would accept it as is.  But if the compiler sees that a lot of bar $x
calls are coming up, and $x is currently a Complex:optpolar (or it's
at the declarator and no implementation preference has been given), it
might convert $x to a Complex:optrect before it gets to the first of
them, just to smooth the way.

-- 
Jonathan Dataweaver Lang

r28528 - in docs/Perl6/Spec: . S32-setting-library

[pugs-commits]

Author: lwall
Date: 2009-10-01 18:53:43 +0200 (Thu, 01 Oct 2009)
New Revision: 28528

Modified:
   docs/Perl6/Spec/S04-control.pod
   docs/Perl6/Spec/S32-setting-library/Basics.pod
   docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S04] add statement_prefix:quietly
[IO] add note function as say to stderr
[Basics] clarify semantics of warning exceptions


Modified: docs/Perl6/Spec/S04-control.pod
===
--- docs/Perl6/Spec/S04-control.pod 2009-10-01 11:49:58 UTC (rev 28527)
+++ docs/Perl6/Spec/S04-control.pod 2009-10-01 16:53:43 UTC (rev 28528)
@@ -13,8 +13,8 @@
 
 Created: 19 Aug 2004
 
-Last Modified: 4 Sep 2009
-Version: 82
+Last Modified: 1 Oct 2009
+Version: 83
 
 This document summarizes Apocalypse 4, which covers the block and
 statement syntax of Perl.
@@ -720,7 +720,7 @@
 Xdo
 
 Other similar forms, where a keyword is followed by code to be controlled by 
it, may also take bare statements,
-including Ctry, Ccontend, Casync, Clazy, and Cvoid.  These constructs
+including Ctry, Cquietly, Ccontend, Casync, Clazy, and Cvoid.  
These constructs
 establish a dynamic scope without necessarily establishing a lexical
 scope.  (You can always establish a lexical scope explicitly by using
 the block form of argument.)  As statement introducers, all these
@@ -870,7 +870,7 @@
 
 The Perl 6 equivalent to Perl 5's Ceval {...} is Ctry {...}.
 (Perl 6's Ceval function only evaluates strings, not blocks.)
-A Ctry block by default has a CCATCH block that handles all
+A Ctry block by default has a CCATCH block that handles all fatal
 exceptions by ignoring them.  If you define a CCATCH block within
 the Ctry, it replaces the default CCATCH.  It also makes the Ctry
 keyword redundant, because any block can function as a Ctry block

Modified: docs/Perl6/Spec/S32-setting-library/Basics.pod
===
--- docs/Perl6/Spec/S32-setting-library/Basics.pod  2009-10-01 11:49:58 UTC 
(rev 28527)
+++ docs/Perl6/Spec/S32-setting-library/Basics.pod  2009-10-01 16:53:43 UTC 
(rev 28528)
@@ -19,8 +19,8 @@
 
 Created: 19 Mar 2009 extracted from S29-functions.pod
 
-Last Modified: 30 Apr 2009
-Version: 2
+Last Modified: 1 Oct 2009
+Version: 3
 
 The document is a draft.
 
@@ -191,9 +191,20 @@
 
  our multi method warn ( Object $o: ) is export
 
-Prints a warning to C$*ERR, which is usually finds C$PROCESS::ERR. See
-CSynopsis 16: IPC / IO / Signals for details.
+Throws a resumable warning exception, which is considered a control
+exception, and hence is invisible to most normal exception handlers.
+The outermost control handler will print the warning to C$*ERR
+(which is usually finds C$PROCESS::ERR; see CSynopsis 16: IPC /
+IO / Signals for details).  After printing the warning, the exception
+is resumed where it was thrown.  To override this behavior, catch the
+exception in a CONTROL block.  A quietly {...} block is the opposite of a
+try {...} block in that it will suppress any warnings but pass fatal
+exceptions through.
 
+To simply print to C$*ERR, please use Cnote instead.  Cwarn
+should be reserved for use in threatening situations when you don't
+quite want to throw an exception.
+
 =back
 
 =head2 Pattern

Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod  2009-10-01 11:49:58 UTC (rev 
28527)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod  2009-10-01 16:53:43 UTC (rev 
28528)
@@ -22,8 +22,8 @@
 
 Created: 19 Feb 2009 extracted from S29-functions.pod; added stuff from 
S16-IO later
 
-Last Modified: 18 Aug 2009
-Version: 7
+Last Modified: 1 Oct 2009
+Version: 8
 
 The document is a draft.
 
@@ -92,6 +92,13 @@
 
 See below for details.
 
+=item note
+Xnote
+
+multi note (*...@list -- Bool)
+
+See below for details.
+
 =item printf
 Xprintf
 
@@ -439,6 +446,10 @@
 As with Cprint, it is a compiler error to use a bare Csay without
 arguments.
 
+=item multi note (*...@list -- Bool)
+
+Does a say to C$*ERR.
+
 =item method printf ($self: Str $fmt, *...@list -- Bool)
 
 =item multi printf (Str $fmt, *...@list -- Bool)

Re: r28528 - in docs/Perl6/Spec: . S32-setting-library

[Jon Lang]

On Thu, Oct 1, 2009 at 9:53 AM,  pugs-comm...@feather.perl6.nl wrote:
  The Perl 6 equivalent to Perl 5's Ceval {...} is Ctry {...}.
  (Perl 6's Ceval function only evaluates strings, not blocks.)
 -A Ctry block by default has a CCATCH block that handles all
 +A Ctry block by default has a CCATCH block that handles all fatal
  exceptions by ignoring them.  If you define a CCATCH block within
  the Ctry, it replaces the default CCATCH.  It also makes the Ctry
  keyword redundant, because any block can function as a Ctry block

OK; so any block with a CATCH block in it is effectively a 'try' block...

  our multi method warn ( Object $o: ) is export

 -Prints a warning to C$*ERR, which is usually finds C$PROCESS::ERR. See
 -CSynopsis 16: IPC / IO / Signals for details.
 +Throws a resumable warning exception, which is considered a control
 +exception, and hence is invisible to most normal exception handlers.
 +The outermost control handler will print the warning to C$*ERR
 +(which is usually finds C$PROCESS::ERR; see CSynopsis 16: IPC /
 +IO / Signals for details).  After printing the warning, the exception
 +is resumed where it was thrown.  To override this behavior, catch the
 +exception in a CONTROL block.  A quietly {...} block is the opposite of a
 +try {...} block in that it will suppress any warnings but pass fatal
 +exceptions through.

...while any block with a CONTROL block in it is effectively a
'quietly' block.  Right?  If so, could this be spelled out in S04,
immediately after the discussion about 'try'?

-- 
Jonathan Dataweaver Lang

Re: r28523 - docs/Perl6/Spec/S32-setting-library

[Moritz Lenz]

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

[Jan Ingvoldstad]

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

[Minimiscience]

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

[Minimiscience]

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

[Moritz Lenz]

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

99problems-31-to-40 failure

[Kevin Phair]

# P35 (**) Determine the prime factors of a given positive integer.

This test fails for me with the latest Rakudo.  It looks like this is 
because when a variable is pushed onto an array, and then 
auto-incremented, it is also auto-incremented inside the array.


my @stuff;
my $w = 1;
@stuff.push($w);
@stuff.say;
$w++;
@stuff.say;

gives an output of:
1
2

I'm still catching up, so I'm not sure if that behavior is expected and 
the test is wrong or vice versa (or if I'm just completely missing 
something).

Re: r28523 - docs/Perl6/Spec/S32-setting-library

[Jan Ingvoldstad]

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

Re: object possible representations (was Re: r28523 - ...)

[Darren Duncan]

Jon Lang had some good thoughts on this.

I want to clarify or expand on my proposal so it is more clearly understood.

1.  First of all, and there may have been no confusion on this but I'll say it 
anyway:


When a class has multiple possreps, one main point here is that users could use 
the class by way of the API implicitly defined by one possrep as if it were the 
only one.  Similarly, an ordinary class that doesn't explicitly use the possreps 
feature is semantically the same as a class that does and declared exactly one.


Now, if it were the case that possreps did not have any attribute names in 
common with other possreps, then users would never even need to mention a 
possrep name when using it.


On the other hand, if (and there is no reason they can't be able to) several 
possreps have same-named attributes, because that makes sense design-wise, then 
user code may have to qualify its access using the possrep name, such as in my 
examples in the first email.


2.  Another main point of possreps is that in general all of the class' own 
methods also shouldn't need to know what the physical representation is, and so 
all $.foo or $!foo inside a class, both when referring to the self object or 
another object of the class, should be able to refer to the attributes of any 
possrep and just work.  Some methods may wish to talk in terms of one possrep 
and some in terms of others, whatever's more natural for them, and it would just 
work.  Conceptually, all class attributes are virtual.


3.  Unless another syntax would work better, I suggest that 
possrep-name-qualified attribute references could be formatted as a foo; 
prefix; for example, $!rect;foo or $!polar;foo if both possreps have a foo, or 
that would always work in the general case but plain $!foo would also work when 
there's no ambiguity.


4.  While in general a sufficiently advanced Parrot can figure out for itself 
what physical representation would best do the job, it can be useful for 
programmers to explicitly annotate one of their possreps as a recommended 
default to use for the physical if the Parrot can't figure out an optimal 
solution itself, especially useful for more naive/simple implementations (if no 
annotation is done, then a naive implementation may just pick one at random).


5.  If there are 3 or more possreps, then the possrep attribute map functions 
(the A_from_B I mentioned) only need to exist in enough numbers that if we had a 
directed graph where possreps were nodes and the map functions were arcs, then a 
path exists between any 2 nodes.  You can add more but they aren't necessary.


6.  A third main point of possreps is that you should be able to extend a class 
with additional possreps, through the normal sub-classing or subset mechanism.


At least this would be assuming that we are just performing specialization by 
constraint (as subset Foo of Bar where ... does, example circle is subtype 
of ellipse), and not specialization by extension (as a subclass that adds 
attributes does, example colored circle is subtype of circle).


For example, you could have an initial class ellipse and a subclass circle 
(every circle is a ellipse), and while an ellipse possrep may have 2 
attributes for major-axis and minor-axis, the possrep added by circle may have 
just the 1 radius attribute.  So any time you have an Ellipse object where 
$.major == $.minor, you can also refer to $.radius, because that Ellipse then 
is also a Circle.


7.  Another point is, like with Perl's subset Foo of ..., if someone does say 
$e = Ellipse.new( :major2, :minor2 ) then $e.isa(Circle) would be true 
(and $e.isa(Ellipse) would also still be true).


Now, conceptually all this is easier to deal with when we just have value 
types that have immutable objects but it could still work with mutable objects; 
then you just have situations where an Ellipse object that was once a Circle no 
longer is because you updated just $.minor to be unequal.


8.  So a point that raises then is that a savvy Parrot may not use the same 
physical representation for every object of the same class, when a subclass may 
add a more efficient possrep for just some of its possible objects.  Or it could 
still use the same physical as the parent class anyway all the time.


9.  A subclass can be defined simply to add a possrep but without restricting 
the value set; for example if an initial Complex only defines a 'rect'($a1,$a2) 
possrep, then a ComplexP subclass could be defined that adds a 'polar'($a3,$a4) 
possrep.  And then one doesn't have to know the name of the subclass because 
they can still say $n = Complex.new( :a34, :a41 ).


10.  A subclass can reference the attributes of possreps declared by the parent 
class, but the reverse can't happen; all association is just done in the 
subclass ... or by users.


11.  You can have diamond inheritence in class hierarchies that use possreps, 
same as normal classes.  For example, you could have these 4 classes 

Re: 99problems-31-to-40 failure

[Daniel Ruoso]

Em Qui, 2009-10-01 às 12:22 -0400, Kevin Phair escreveu:
 This test fails for me with the latest Rakudo.  It looks like this is 
 because when a variable is pushed onto an array, and then 
 auto-incremented, it is also auto-incremented inside the array.
 my @stuff;
 my $w = 1;
 @stuff.push($w);
 @stuff.say;
 $w++;
 @stuff.say;
 gives an output of:
 1
 2

This is a rakudo bug, what's probably happening here is that rakudo is
just adding the push *...@args to the end of @stuff, while it was supposed
to get an iterator for it and consume it while copying the values into
@stuff, which is basically the difference between assign and bind.

daniel