Hi Ralph, I think the important flaw is raku's incapacity to convert a Num to its exact Rat/FatRat expression. (Note that every finite Num can be expressed exactly as a Rat/FatRat.) Without that option we are currently forced to compare Num and Rat/FatRat as 2 Nums, and I think the option to compare Num and Rat/FatRat as 2 Rats/FatRats is an option that ought to be available.
I also stick to my view that the latter should be the default behaviour, as is the case with python3 .... but that's not really an issue. (In practice, I myself am guilty of being a little inconsistent when it comes to mixing floats and rationals.) Looking at https://github.com/Raku/old-issue-tracker/issues/5013 (for which raku behaviour has now changed a little) and also some other Num values, it occurred to me that "%.*g" formatting of a Num $x is limited by what "say $x" outputs. EXAMPLE 1: $ raku -e 'say 0.1e0' 0.1 That is a 1-significant-digit value, so asking for more than one significant digit will result in disappointment : raku -e 'printf "%.1g %.2g\n", 0.1e0, 0.1e0' 0.1 0.1 EXAMPLE 2: $ raku -e 'say log(2)' 0.6931471805599453 That is a 16-significant-digit value, so asking for more than 16 significant digits in disappointment : $ raku -e 'printf "%.16g %.17g\n", log(2), log(2)' 0.6931471805599454 0.6931471805599453 (Not sure why the last digit changes. Correct value is "3" - I guess it's another little bug.) EXAMPLE 3: $ raku -e 'say sqrt(2)' 1.4142135623730951 That is a 17-significant-digit value, so asking for more than 17 significant digits in disappointment : $ raku -e 'printf "%.17g %.18g\n", sqrt(2), sqrt(2)' 1.4142135623730951 1.4142135623730951 I think the other issues you linked to (ie other than Issue 5013) are probably separate to this problem with "%.*g" formatting. I now intend to: 1) Open a new issue about the fact that The Num to Rat/FatRat conversion cannot be made; 2) Update Issue 5013 to better reflect the current state of the bugginess of "%.*g" formatting. Is there any reason that I should not do either/both of those ? (I keep wondering if I've missed something.) Cheers, Rob On Wed, Apr 7, 2021 at 9:26 AM Ralph Mellor <ralphdjmel...@gmail.com> wrote: > > 1/10 == 1e1 # True > > > > Aiui this is correct (and to me intuitive) behaviour described here: > > Except A) that's not what the doc says, and B) how does one > compare numbers *without* infection, if that's what's going on? > > So it probably makes sense to ignore at least that part of my > previous email. Maybe the rest of it too. I shouldn't be writing > emails after midnight. Goodnight. > > -- > raiph >
