Hi,
Just replacing a garbled typo that began just below "When you throw in"
with the text that should have been there.
On Sun, Apr 11, 2021 at 11:24 PM sisyphus wrote:
>
> But I find the "logic" of what is going on here to be confusing.
>
> C:\_32>raku -e "say 1.8446744073709552e+19 ==
On Wed, Apr 7, 2021 at 9:16 AM Ralph Mellor wrote:
[snip]
>
> Aiui this is correct (and to me intuitive) behaviour described here:
>
> https://docs.raku.org/language/numerics#Numeric_infectiousness
>
>
An overly simplified rule is being specified, without any mention of the
underlying
On Fri, Apr 9, 2021 at 10:26 AM Ralph Mellor
wrote:
> 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
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
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
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
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
On Wed, Apr 7, 2021 at 2:12 PM sisyphus wrote:
>
> I think the important flaw is raku's incapacity to convert a Num
> to its exact Rat/FatRat expression.
My 2c is that I agree that that needs to be addressed.
I currently see that as something to first address via sprintf.
Do you agree? I get
On Wed, Apr 7, 2021 at 3:29 PM Simon Proctor wrote:
>
> Would =~= be what you're looking for?
To quote Wikipedia, "A floating-point number is a rational number".
Rob wants to compare a float with its exact equivalent rational and
get True if they're exactly the same and False otherwise.
--
Would =~= be what you're looking for?
Personally I like Rationals and am looking forward to being able to signify
that they should automatically become FatRats.
But if you're wedded to floating point then :
say 3602879701896397/36028797018963968 =~= 0.1 => True
say
On Wed, Apr 7, 2021 at 11:31 PM Vadim Belman wrote:
>
> For exact match one can use eqv:
>
> say 1/10 eqv 0.1e0; # False
> say 1/10*1e0 eqv 0.1e0; # True
>
I don't think this is quite what I'm after.
I would want the following to be True, but it's False:
C:\> raku -e "say
For exact match one can use eqv:
say 1/10 eqv 0.1e0; # False
say 1/10*1e0 eqv 0.1e0; # True
Best regards,
Vadim Belman
> On Apr 6, 2021, at 7:25 PM, Ralph Mellor wrote:
>
>> 1/10 == 1e1 # True
>>
>> Aiui this is correct (and to me intuitive) behaviour described here:
>
> Except A) that's
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
> 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.
On Tue, Apr 6, 2021 at 11:54 AM sisyphus wrote:
>
1/10 == 1e1 # True
Aiui this is correct (and to me intuitive) behaviour described here:
https://docs.raku.org/language/numerics#Numeric_infectiousness
So if there's a `Num` (float) in a numeric operation (like `==`) then any
other number
On Tue, Apr 6, 2021 at 11:09 AM sisyphus wrote:
> [snip]
> Is there behaviour in other languages (eg python ?) that supports this
> approach that raku has taken ?
>
>
I'm as unfamiliar with python3 as I am with raku, but it seems to me that
python3 takes the approach that makes better sense to
Hi,
With perl5 (configured with $Config{nvtype} of "double") we can get a
rational expression of the exact value held (for example) by the double 0.1
by doing:
$ perl -e 'printf "%.60g\n", 1.0e-1;'
0.155511151231257827021181583404541015625
How can we achieve the same in raku ?
18 matches
Mail list logo
