On Sun, Sep 6, 2009 at 3:08 PM, Moritz Lenz<mor...@faui2k3.org> wrote:
> (This is a reply to "Struggles with Trig",
> <http://use.perl.org/~colomon/journal/39590> - 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?
Apologies if I was not clear about this. I have only checked in files
in a state where everything tests cleanly. The problems I am
complaining about are exactly the ones that are fudged. As far as I
know the code is implemented for every one of the sine tests, but the
weird problems I'm talking about forces all those skips.
>> 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 Complex.pm 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.
Let me know how you'd like this. As I said, the functions are already
present in trig.t, so it would be easy enough to move them for you.
>> 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.
Actually data driven testing seems to work pretty well for the trig
functions. Mostly if they work, they work for the entire data set, it
seems.
>> 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
> run:
>
> #?DOES 3
> sub that_executes_tests(...) {
>
> }
>
> #?rakudo skip 'NYI'
> that_executes_tests(...)
>
>
> (I hope that answers your question - if not, feel free to ask again).
Hmmm... it doesn't exactly answer my question, but it certainly
provides grounds for thought!
>> (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 ;-)
Seriously, I wouldn't be surprised if it ends up being something like that.
> 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).
I will see what I can do about that. But notice that the new tests
only take four lines changed to get that working. (The old tests, on
the other hand, will need a massive search and replace...)
Thanks,
--
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
