From @bacek

Hello.

There is implementation of prefix​:+, prefix​:-, sqrt, exp for Complex.

More to come.

--
Bacek.

From @bacek

diff --git a/languages/perl6/src/builtins/math.pir b/languages/perl6/src/builtins/math.pir
index 1edd996..229648e 100644
--- a/languages/perl6/src/builtins/math.pir
+++ b/languages/perl6/src/builtins/math.pir
@@ -123,12 +123,18 @@ C<$x ** 0.5>
 
 =cut
 
-.sub 'sqrt'
+.sub 'sqrt' :multi(_)
     .param num a
     a = sqrt a
     .return (a)
 .end
 
+.sub 'sqrt' :multi(Complex)
+    .param pmc a
+    a = sqrt a
+    .return (a)
+.end
+
 
 =item truncate
 
@@ -172,12 +178,18 @@ constant I<e>.
 
 =cut
 
-.sub 'exp'
+.sub 'exp' :multi(_)
     .param num a
     a = exp a
     .return (a)
 .end
 
+.sub 'exp' :multi(Complex)
+    .param pmc a
+    a = exp a
+    .return (a)
+.end
+
 
 =item log
 
diff --git a/languages/perl6/src/builtins/op.pir b/languages/perl6/src/builtins/op.pir
index 4d072fc..e8b4a29 100644
--- a/languages/perl6/src/builtins/op.pir
+++ b/languages/perl6/src/builtins/op.pir
@@ -80,6 +80,11 @@ src/builtins/op.pir - Perl6 builtin operators
     .return (a)
 .end
 
+.sub 'prefix:+' :multi('Complex')
+    .param pmc a
+    .return (a)
+.end
+
 
 .sub 'prefix:-' :multi(_)
     .param num a
@@ -94,6 +99,12 @@ src/builtins/op.pir - Perl6 builtin operators
     .return ($I0)
 .end
 
+.sub 'prefix:-' :multi('Complex')
+    .param pmc a
+    a = neg a
+    .return (a)
+.end
+
 
 .sub 'prefix:~' :multi(_)
     .param string a

From @moritz

Vasily Chekalkin (via RT) wrote​:

There is implementation of prefix​:+, prefix​:-, sqrt, exp for Complex.

I noticed that you put these into the same files as their non-Complex
counterparts.

What's the general policy for that? Just like this, and Complex-only
multis in classes/Complex.pir?
Or everything into Complex.pir?
Or everything but the ops in Complex.pir, and ops into builtins/op.pir?

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

The RT System itself - Status changed from 'new' to 'open'

From @pmichaud

On Wed, Jun 25, 2008 at 09​:27​:18AM -0700, Moritz Lenz via RT wrote​:

Vasily Chekalkin (via RT) wrote​:

There is implementation of prefix​:+, prefix​:-, sqrt, exp for Complex.

I noticed that you put these into the same files as their non-Complex
counterparts.

What's the general policy for that? Just like this, and Complex-only
multis in classes/Complex.pir?
Or everything into Complex.pir?
Or everything but the ops in Complex.pir, and ops into builtins/op.pir?

Short answer​: We're still working out the policy for this. Many operators
were added to Rakudo before we had a clear idea of how classes would be
structured.

With the recent class restructures we have a clearer idea than before,
although there are still a few fuzzy areas that will likely remain for
some time. For the time being I have a general bias towards moving things
out of src/builtins/ and into src/classes/ .

In this specific instance I'd prefer that the Complex operator
definitions go into src/classes/Complex.pir .

Pm

From @pmichaud

On Wed, Jun 25, 2008 at 12​:19​:13PM -0500, Patrick R. Michaud wrote​:

What's the general policy for that? Just like this, and Complex-only
multis in classes/Complex.pir?
Or everything into Complex.pir?
Or everything but the ops in Complex.pir, and ops into builtins/op.pir?

In this specific instance I'd prefer that the Complex operator
definitions go into src/classes/Complex.pir .

Another possibility would be to have the operators always use the
PMC forms of the opcodes (instead of the int/string/num versions),
and make vtable overrides in Object/Any/(whatever) so that the
opcodes still dtrt when passed a PMC that doesn't already map to
the operation.

This is one of those areas where Parrot gets a little confusing --
we can either solve the problem via multisub dispatch at the HLL
level, or we can solve it via vtable dispatch at the Parrot level
(and whichever way we do it needs to work in both contexts).
I haven't decided whether we should be giving primacy to
multisub dispatch, vtable dispatch, or a convoluted mixture of
both.

Pm

From @moritz

Another question​:

Vasily Chekalkin (via RT) wrote​:

+.sub 'sqrt' :multi(Complex)
+ .param pmc a
+ a = sqrt a
+ .return (a)
+.end

Do we actually want a sqrt(Complex)? Somebody who is sufficiently
mathematically educated to work with complex numbers should now that
sqrt() is ambigous, because there are two possible results, and will
revert to roots() for that.

Any thoughts?

Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

From @moritz

Resolved in r28924, (with patch partly applied to
src/classes/Complex.pir instead of src/builtins/math.pir).

Thank you very much for your contribution.

@moritz - Status changed from 'open' to 'resolved'

From @bacek

On Tue Jul 01 15​:20​:03 2008, moritz wrote​:

Resolved in r28924, (with patch partly applied to
src/classes/Complex.pir instead of src/builtins/math.pir).

Thank you very much for your contribution.

You've put exp and sqrt in wrong namespace :)

Attached patch fix it. S29-num/exp.t is #pure. Last 2 tests in
t/spec/S29-num/sqrt.t can be unfudged.

--
Bacek

From @bacek

diff --git a/languages/perl6/src/classes/Complex.pir b/languages/perl6/src/classes/Complex.pir
index 3f714f3..a275a58 100644
--- a/languages/perl6/src/classes/Complex.pir
+++ b/languages/perl6/src/classes/Complex.pir
@@ -45,26 +45,6 @@ Returns a Perl representation of the Complex.
 
 =over 4
 
-=item exp
-
-=cut
-
-.sub 'exp' :multi(Complex)
-    .param pmc a
-    a = exp a
-    .return(a)
-.end
-
-=item sqrt
-
-=cut
-
-.sub 'sqrt' :multi(Complex)
-    .param pmc a
-    a = sqrt a
-    .return (a)
-.end
-
 
 =back
 
@@ -190,6 +170,27 @@ Returns a Perl representation of the Complex.
     .return ($P0)
 .end
 
+
+=item exp
+
+=cut
+
+.sub 'exp' :multi(Complex)
+    .param pmc a
+    a = exp a
+    .return(a)
+.end
+
+=item sqrt
+
+=cut
+
+.sub 'sqrt' :multi(Complex)
+    .param pmc a
+    a = sqrt a
+    .return (a)
+.end
+
 =back
 
 =cut

@bacek - Status changed from 'resolved' to 'open'

From @pmichaud

On Wed Jun 25 10​:19​:36 2008, pmichaud wrote​:

With the recent class restructures we have a clearer idea than before,
although there are still a few fuzzy areas that will likely remain for
some time. For the time being I have a general bias towards moving things
out of src/builtins/ and into src/classes/ .

Just for the record (and for future patch contributors), I modified my
bias on this yesterday. There is still a bias towards moving things
into src/classes/, but the role-based builtin methods of the C<Any>
class typically go into one of src/builtins/any-list.pir,
src/builtins/any-num.pir, or src/builtins/any-str.pir .

Pm

From @pmichaud

Resolved in r29045 (by making exp and sqrt into exported methods of
Complex). Thanks!

Pm

@pmichaud - Status changed from 'open' to 'resolved'