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