in reply to Something that bugs me about the Numeric class hierarchy in Perl 6

Hum, this probably does not really answer your question, and I am not even sure I really understand your question, but it seems to me that the intermediate results are not always integers, but sometimes rats. So that when you multiply them, even if you end up with something looking like an integer, it has been computed as a rat.

Removing the list product from your function to see the list of computed values:

sub infix:<list_vals> { ($^n ... 0) Z/ 1 .. $^p } say 10 list_vals 3; # -> (10 4.5 2.666667) sub infix:<choose> { [*] ($^n ... 0) Z/ 1 .. $^p } say 10 choose 3; # -> 120 (rat)
  • Comment on Re: Something that bugs me about the Numeric class hierarchy in Perl 6
  • Download Code

Replies are listed 'Best First'.
Re^2: Something that bugs me about the Numeric class hierarchy in Perl 6
by grondilu (Friar) on Nov 27, 2015 at 10:36 UTC

    The intermediate results are indeed rats. And yes the result is a rat that looks like an integer. My point was that I wish there was no difference between a "rat that looks like an integer" and an actual integer. In other words, I wish integers were a special case of rats, because in math that's what they are, maybe not by definition, but at least by property : the set Z in included in the set Q. Thus my suggestion of using perl6's subset concept.

      I just noticed this discussion and it's a difference of opinion I've also had with the core P6 devs: integers and rats are the same. That being said, integer math should be much faster than rational math and I don't know how difficult it would be to special case the code for that.

      On the flip side, by restricting this behavior now, they wouldn't need to take it away later if it proved problematic. I expect that heavier usage of the language over time is what will impact decision making here.