Re: (default) Real->Rat precision should match what compiler uses for literals

[email protected] (yary) Sat, 3 Mar 2018 17:28:10 -0300
Newsgroups perl.perl6.language
Message-ID <CAG2CFAZ=Lw9AA5=5vdVCLvvZGEERxROgYxfayscK3U7NoyXfZA@mail.gmail.com>
--f403043c32cca83f53056687efdc
Content-Type: text/plain; charset="UTF-8"

Zeroing in on one point:

> > A solution might be to instead provide a pragmatic, rather than
> mathematical
> > parameter:
> >
> >     :$numbits = 64
> >
> > This would say to keep as much precision as possible while making the
> result
> > fit in 64 bits.   For example 2.147483647e0.Rat would result in
> > 2147483647/1000000000 instead of 4310/2007.
>
> The Num type basically has a denominator which is based on 2s, not 10s.
>

The proposal is more-or-less expressible as having epsilon = 2/:numbits -
presuming that the numerator and denominator are about the same size.

From my POV the default epsilon is fine for practical use, but imprecise
enough to have this conversation come up repeatedly. Search this list for
"$epsilon = 1.0e-6 feels too big for Rat()"

How about setting the default epsilon to 1/2**32 or 1/2**64 and closing
that 2015 New Year's Eve post & this one too?

-y

--f403043c32cca83f53056687efdc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Zeroing in on one point:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><span class=3D"gmail-im">&gt; A solution might be to in=
stead provide a pragmatic, rather than mathematical</span><br><span class=
=3D"gmail-im">
&gt; parameter:</span><br><span class=3D"gmail-im">
&gt;</span><br><span class=3D"gmail-im">
&gt;=C2=A0 =C2=A0 =C2=A0:$numbits =3D 64</span><br><span class=3D"gmail-im"=
>
&gt;</span><br><span class=3D"gmail-im">
&gt; This would say to keep as much precision as possible while making the =
result</span><br><span class=3D"gmail-im">
&gt; fit in 64 bits.=C2=A0 =C2=A0For example 2.147483647e0.Rat would result=
 in</span><br><span class=3D"gmail-im">
&gt; <a href=3D"tel:2147483647" value=3D"+12147483647">2147483647</a>/10000=
00000 instead of 4310/2007.</span><br><span class=3D"gmail-im">
</span><br><span class=3D"gmail-im">
</span>The Num type basically has a denominator which is based on 2s, not 1=
0s.<br></blockquote><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra">The proposal is more-or-less expressible as having epsilon =3D 2/:=
numbits - presuming that the numerator and denominator are about the same s=
ize.<br><br></div><div class=3D"gmail_extra">From my POV the default epsilo=
n is fine for practical use, but imprecise enough to have this conversation=
 come up repeatedly. Search this list for &quot;$epsilon =3D 1.0e-6 feels t=
oo big for Rat()&quot; <br><br>How about setting the default epsilon to 1/2=
**32 or 1/2**64 and closing that 2015 New Year&#39;s Eve post &amp; this on=
e too?<br></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature">-y<br></div></div>
<br></div></div>

--f403043c32cca83f53056687efdc--