Front page | perl.perl6.users |
Postings from April 2021
Re: Comparing Int and Num
From: Ralph Mellor
April 24, 2021 17:57
Re: Comparing Int and Num
Message ID: CAPLR5SfJc+0rMiDaf7EG-kSMK-cnGdZUYDCFWgH59Aj-o825GQ@mail.gmail.com
On Fri, Apr 16, 2021 at 7:22 AM sisyphus <firstname.lastname@example.org> wrote:
> The conversion from int to num looks sane.
Sounds good. :)
So presumably our early tentative conclusion of what we hope
will pan out is that if one wants precise IEEE float behaviour,
one uses `num` instead of `Num`. Right?
> However, the second of those integers should assign to the double
> 9.223372036854775e+18 (0x1.fffffffffffffp+62) - yet this happens only
> for the 'num' case
So that's happening in the `Num` type's storage, not its stringification, right?
> I don't think it's a big deal if that is deemed to be NOT buggy.
`Num` is considered an approximate float, `num` the exact one.
> We would just have to be mindful of avoiding Nums when we're
> not prepared to accept that the usual "round to nearest, ties to
> even" rule might not be enforced.
Is that about storage or stringification?
Have you seen this active PR by Nicholas Clark?:
Do you understand it?
One important thing is that Rakudo is quite unlike the `perl`
approach as an implementation in the sense that:
* Most of the code is Raku, so very high level, and relatively
understandable if one knows any of the language.
* Another big chunk is nqp, which is essentially just a subset of
Raku. So that's approachable too.
* The main VM to focus on is MoarVM. An outsider reviewer
wrote in 2017 that it they considered it clean code that is well
organized, written, documented, and tested.
So, I don't know C, and I don't consider NQP especially easy to
get into, so it's all a bit intimidating, but I have dipped into the
various parts of the compiler, and have never felt "I have zero
chance of ever understanding this even if I put in significant effort".
So at some point, perhaps during our exchange here, I think
it makes sense for me to anticipate me and/or you digging into
the compiler's source code, whether it's Raku, nqp, or C
(MoarVM is C89), and perhaps you'll find you will understand
whatever code I find, or even dig in yourself.
> Mind you, it's hard to work out just what rounding rule *is* being
> enforced - it's definitely not one that I've ever encountered before.
I think a useful objective, to be reached before filing a new issue,
is to find out what intent is embodied in the relevant code. It may
be that it's appropriate to verify that the intent has been achieved,
or there are bugs relative to it, or that the intent needs to change.
But it would be appropriate to know that before filing an issue. It
might be that what's needed is a *doc* issue, or it might be that it's
a MoarVM, or nqp, or Raku, or Rakudo issue.
> Though there seems to be a pattern emerging:
> 9223372036854775295 - 9223372036854775231 == 64
> and from my initial post in this thread:
> (18446744073709551615 - 1024) - (18446744073709551615 - 1088) == 64.
> I suspect some little optimization trick might be doing something unexpected.
Perhaps. Hopefully we agree it would be good to know what's going on.
And if it can be stated more usefully than "hey, it's approximate, deal",
it would be great to distill a pithy explanation and add it to the doc at
the very least. Or if it's just a weak implementation, it would be good
to at least file an appropriate issue.
Maybe also agree to some tests that can be added to roast to ensure it
doesn't get worse in the face of any future changes such as optimizations,
if indeed that's what's going on.
>> I hope to get time to respond to your earlier posts this weekend.
> No rush, and please, don't stress over any of this.
Thus far our exchange has been delightful. No stress. :)
I love the Perl community, and respect the perl implementation, and
acknowledge that Raku and Rakudo aren't yet remotely in the same
league with Perl maturity wise. And Raku is much more ambitious
and has a much smaller community. (Double understatement!)
But Larry long ago persuaded me that what he was trying to pull off
could actually be pulled off, and was worth pulling off for the long
term sake of the Perl community and/or devs that have a Perl like
mindset, even if they won't realize that until it's *extremely* evident,
which may not be the case until around the end of this decade.
In the meantime, I folk who care about Perl also caring about Raku
is a godsend, especially when they're as friendly as you. :)
Have a good weekend!