On Fri, Apr 16, 2021 at 7:22 AM sisyphus <sisyphus...@gmail.com> 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. OK. `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?: https://github.com/MoarVM/MoarVM/pull/1472 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! -- raiph
