Multimethods for Complex.

[p6rt]

Migrated from rt.perl.org#56230 (status was 'resolved')

Searchable as RT56230$

[p6rt]

From @bacek

Hello.

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

More to come.

-- Bacek.

[p6rt]

From @bacek

complex.diff

```diff 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. =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 ```

[p6rt]

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/

[p6rt]

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

[p6rt]

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

[p6rt]

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

[p6rt]

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/

[p6rt]

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.

[p6rt]

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

[p6rt]

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

[p6rt]

From @bacek

complex.diff

```diff 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 ```

[p6rt]

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

[p6rt]

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\ class typically go into one of src/builtins/any-list.pir, src/builtins/any-num.pir, or src/builtins/any-str.pir .

Pm

[p6rt]

From @pmichaud

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

Pm

[p6rt]

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