On Wed, Apr 7, 2021 at 2:12 PM sisyphus <sisyphus...@gmail.com> wrote:
>
> I think the important flaw is raku's incapacity to convert a Num
> to its exact Rat/FatRat expression.
My 2c is that I agree that that needs to be addressed.
I currently see that as something to first address via sprintf.
Do you agree? I get the impression you might.
Once that's done, I think it's plausible nothing else need be done
regarding this aspect in terms of built ins in standard Raku.
I get the impression you will *not* agree with that at first,
but I'm hopeful that if so, you'll come around to my way
of thinking after a bit of back and forth. :)
> I think the option to compare Num and Rat/FatRat as
> 2 Rats/FatRats is an option that ought to be available.
If sprintf worked as I presume it ought, that would be doable.
> I also stick to my view that the latter should be the default
> behaviour, as is the case with python3
That's so not Raku.
Last night I mentioned infectiousness and then thought I'd
misread the doc. Tonight I've realized I was right in the first
place, and my original explanation was sound.
Raku's infection system is why you see the behaviour you see.
When you mix integers and rationals, the result is rationals.
When you mix exact and inexact values, the result is inexact.
And so on.
It's a nice system. It's broadly useful, simple to explain, simple
to use, and intuitive.
It's also well established and broadly used.
I can't imagine making an exception for converting nums into
their exact rational equivalents, with all the negative impact
that a special case brings, including that code like this:
0.1 == 1e0
which currently returns `True`, would instead return `False`.
Aiui you are saying we should upend all that nice behaviour
so a value that is by definition approximate, when converted
to a rational, is not set to the nearest rational rounded number
but instead one that will frequently be a hair off that, and thus
a long crazy value. If I'm right that you mean that, well...
> but that's not really an issue.
...I'm glad to hear that! :)
> [sprintf issues]
There are several issues. But I need to go to sleep.
> 1) Open a new issue about the fact that The Num to
> Rat/FatRat conversion cannot be made;
Well it can. It's just that it's an intelligent coercion, one that
takes into account the nature of a num as an approximate
format, not an exact one, and thus picks a nearest neatly
rounded rational. So this returns `True`:
0.1 == 1e0.Rat; # True
I currently think the sensible path for the sake of the sanity
and health of us Rakoons collectively is to first focus on
fixing problems with sprintf so one can generate the precise
rational corresponding to a num via sprintf.
> 2) Update Issue 5013 to better reflect the current state of
> the bugginess of "%.*g" formatting.
Yeah. I'm focusing on 5519 ("sprintf %f bogus rounding").
(Have you looked thru the other issues?)
> Is there any reason that I should not do either/both of those ?
> (I keep wondering if I've missed something.)
It might be best to get rough consensus here on what the issues
really seem to be. No doubt there will be further discussion in the
filed issues themselves, but we can perhaps reduce noise and
confusion there by working thru it here for a few days / week or so.
--
raiph
