On Thu, Apr 8, 2021 at 3:25 AM Ralph Mellor <ralphdjmel...@gmail.com> wrote:
>
> On Wed, Apr 7, 2021 at 2:12 PM sisyphus <sisyphus...@gmail.com> wrote:
>
> > 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").
Some excerpts from 5519 that shine light on 5013:
----
Patrick Michaud wrote:
> Nums hold only 15-17 digits of precision
...
> I agree that having sprintf("%f") automatically truncate with zeros
> after 15 digits of precision is perhaps not the best approach here.
> I think it should perhaps be available to at least 17 places, and
> possibly even more in examples like 2**70. But that's a language
> specification call that someone outside of Rakudo probably needs
> to make.
(I'm pretty sure you know who PM is. We need to take that last
sentence to heart. As such it sounds like there's a need to open
a problem-solving ticket if we wish to propose sprintf going beyond
17 digits. It seems plausible we would best first try get consensus
on that as the ultimate goal, or rejection of that, before pursuing
trying to get from 15 plus a buggy 16th as it is now, to just 17.)
----
Zefram wrote:
> the implementation is first converting to decimal with its default of
> 15 total digits ... and then rounding *that* to the output length ...
> This is double rounding, a classic type of mistake in numerical
> computation.
My guess is that explains the buggy 16th digit which you were
presumably planning to add to 5013.
----
Zefram also wrote a Raku sprintf implementation of fp conversions
and added it to 5519, saying:
> I believe it to be correct. In addition to the decimal %e, %f, and %g, I
> did the rather useful hexadecimal %a, thus far entirely missing from
> Rakudo's sprintf.
Here it is in an online evaluator:
https://replit.com/@RalphMellor/sprintf#main.raku
Does it work as you expect for all tests you are currently working with?
----
Also, if there's a decision to switch out to a new implementation
for the fp format tokens (`%`s), then this should be added to the
issue: https://github.com/rakudo/rakudo/issues/2187
--
raiph
