Yes, I think that the question of whether raku should be able to output
more than 17 significant digits for Nums should be settled.
Most libC's will happily do that, but C99 and C11 standards do not enforce
such behaviour.
This is something that I think should be addressed irrespective of any Num
to FatRat conversion considerations.
I've realized that there's a problem in expecting "%g" formatting to be
useful in the way that I was hoping.
If "%g" formatting outputs a string of the format 0.xxxxx...x, then all is
fine:
C:\_32>raku -e "my $x =
FatRat('0.1000000000000000055511151231257827021181583404541015625'); say
$x.nude;"
(3602879701896397 36028797018963968)
But if, as happens with many Num values, "%g" formatting specifies an
exponent, then we're back to square 1:
C:\_32>raku -e "my $x =
FatRat('0.1000000000000000055511151231257827021181583404541015625e0'); say
$x.nude;"
(1 10)
In essence, I'm trying to express the view that it would be useful for raku
to have a function that will take a Num as its argument and return a FatRat
that expresses the precise value of that given argument.
Example:
my $fatrat = some_func(1e-1);
say $fatrat.nude; # outputs (3602879701896397 36028797018963968)
I don't think it matters if some_func() utilizes sprintf() or not.
It's always nice to be able to compare/crosscheck perl5 behaviour against
python3 and raku.
But I'd be overstating the case if I were to say that I actually *need* a
certain behaviour from raku.
I don't need anything from raku, but I'll happily take what I can get and
perform those comparisons/crosschecks within the limitations of what raku
has to offer.
The main thing is that I grasp just what those limitations are, and whether
they will likely ever change..
Much progress has been made in my understanding of that in the last few
days.
One thing that I don't know but would like to ascertain is whether that
some_func() routine that I'm seeking will ever become available.
Cheers,
Rob
PS I'm a bit pressed for time until about Monday, but I'll try to address
other interesting points that you've made as time permits.
On Fri, Apr 9, 2021 at 8:22 AM Ralph Mellor <ralphdjmel...@gmail.com> wrote:
> 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
>
