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
t
One last final piece I want to add in while we prepare to document
what is worth documenting in issues is what I was trying to get at in
this comment:
https://www.reddit.com/r/perl/comments/93dabg/perl_6_small_stuff_4_why_perl_isnt_cobol_nor/e3etgvf/
Reviewing it I think I got a couple things wro
Another thing I've bumped into in my travels:
> From: Zefram
> Sent: Thursday, February 18, 2016 4:08 AM
> To: perl5-port...@perl.org
> Subject: Re: [perl #127182] One digit short to correctly stringify a double
>> To have different NVs stringify identically is surprising; to have the
>> closest
On Thu, Apr 8, 2021 at 3:25 AM Ralph Mellor wrote:
>
> On Wed, Apr 7, 2021 at 2:12 PM sisyphus 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 th
On Thu, Apr 8, 2021 at 3:25 AM Ralph Mellor wrote:
>
> On Wed, Apr 7, 2021 at 2:12 PM sisyphus wrote:
>
> > I also stick to my view that the latter should be the default
> > behaviour, as is the case with python3
> ...
> I can't imagine making an exception for converting nums into
> their exact r
