develooper Front page | perl.perl6.compiler | Postings from September 2009

Struggles with Trig

Thread Next
Moritz Lenz
September 6, 2009 12:08
Struggles with Trig
Message ID:
(This is a reply to "Struggles with Trig",
<> - I also write to
perl6-compiler because parts of it might be of a bit broader interested,
or others might want to comment on it too).

> 1) Passing non-default $base value does not work for Num.sin / Num.cos
> or Complex.sin / Complex.cos. As far as I can tell the code is fine,
> and Num.sin("degrees") seems to work fine using p6eval, but the tests
> fail for me in trig.t. I thought it was some weird interaction with
> the fact sin is declared as an operator, but Rat.sin("degrees") works
> just fine in the tests. I'm stumped on this, if anyone else can offer
> some insight I'm all ears.

Currently all the tests which are not fudged in trig.t pass here (amd64
linux), if that's not the case for you, maybe you have some local
modifications? Try
$ git checkout origin/master
and rebuild, in that case.

> 2) Equally weirdly, I've got working implementations of sin(Complex)
> and sin(Complex, $base). But they only work if defined trig.t, moving
> them to made those tests fail. Do they need "is export"
> added or something like that? What is "is export" for, anyway?

"is export" makes a method also a sub.

So if you write

# in Rakudo actually 'class Complex is also'
augment class Complex {
    multi method sin($base = 'degree') {


you only get the method form, (1+1i).sin(). If you write it as

multi method sin(...) is export { ... }

instead, you get the method form plus the sub form, ie a

mutli sin(Complex $self, $base = 'degree') { ... }

That said, I also had some troubles with multi dispatch related to
Complex numbers when I tried to move stuff to the setting.

It would be helpful if you could send a patch that adds these methods to
the setting, so we can take a look at this together.

> 3) In general, I'd love it if a few people could look over the new
> tests for sine (cosine duplicates them). I'm not 100% comfortable with
> how repetitive they are.

I know that feeling, but I stopped bothering about it some time ago.
Testing the basics just requires lots of repetition. Especially
numerical stuff.

Data driven testing promises an escape route, but it's rather hard to
fudge it properly, and thus an option I try to avoid.

> You could obviously change my little
> AngleAndResult to have a method which allows you to select the base
> and the numeric type to return, but I don't know how to make that
> cleanly work with the very much needed SKIP directives.

If you write the testing stuff as subs instead, it's much easier.

Suppose you want to write a sub that executes three tests each time it's

#?DOES 3
sub that_executes_tests(...) {


#?rakudo skip 'NYI'

(I hope that answers your question - if not, feel free to ask again).

> (BTW, these
> changes I've made add over 1000 tests in trig.t, and they are only the
> tip of the iceberg.)

Since the visible tip of the iceberg is usually about 1/9 th of the
volume, I'm looking forward to another 8k tests ;-)

I don't worry if that skews any spectest statistics as long as it means
that Perl 6 gets lots of good tests for the trigonometric functions.

All in all I like these tests, but they need to get switched to the new
 way of passing units (ie an enum instead of strings).

Cheers, and keep up the good work,

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About