<div dir="auto">Hi Phil,<div dir="auto">It is essential. Without it, it's very difficult to have correctly rounded conversion float -> ascii decimal ->float.</div><div dir="auto">Also, it may help to implement correctly rounded float functions.</div><div dir="auto"><span style="font-family:sans-serif">GNU libc uses gmp.</span><br><div dir="auto">Sometimes, you don't know the accuracy of a float calculus. There are several possible easy strategies like changing the rounding direction, or double the precision, and check the interval you obtain. It's far easier to implement multi precision with integer than with float (though possible).</div><div dir="auto">Chryptography heavily rely on large integer arithmetics.</div><div dir="auto">Symbolic computer algebra also rely on it (the p-adic factorization of polynomials may rapidly lead to huge integers).</div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 28 janv. 2020 à 04:56, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Phil,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 6:07 PM Phil B <<a href="mailto:pbpublist@gmail.com" target="_blank" rel="noreferrer">pbpublist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">That article was an interesting read.  One thing I've always been curious about: what applications are people using the arbitrary precision stuff in Squeak for?  (I generally make an effort to avoid straying into large integers due to the performance implications, but the things I'm working on don't require the precision they offer.)</div></blockquote><div><br></div><div>One thing I used it for was in implementing 64-bit Spur VM above the 32-bit Spur implementation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 8:28 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank" rel="noreferrer">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sun, Jan 26, 2020 at 01:59:21PM -0800, tim Rowledge wrote:<br>
> Remember the fun with we had calculating 4784969 fibonacci? There's an<br>
> interesting article in the Comm.ACM this month about the maybe-final<br>
> improvement in huge number multiplication;<br>
> <a href="https://cacm.acm.org/magazines/2020/1/241707-multiplication-hits-the-speed-limit/fulltext" rel="noreferrer noreferrer" target="_blank">https://cacm.acm.org/magazines/2020/1/241707-multiplication-hits-the-speed-limit/fulltext</a><br>
> <br>
> tim<br>
> --<br>
> tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank" rel="noreferrer">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
> Strange OpCodes: RIW: Re-Invent Wheel<br>
> <br>
<br>
Very interesting stuff. Probably not ready for a practical implementation<br>
in Squeak though. The performance benefits come into play only for very<br>
large numbers. The ACM article says:<br>
<br>
  The n(logn) bound means Harvey and van der Hoeven's algorithm is faster<br>
  than Schönhage and Strassen's algorithm, or Fürer's algorithm,<br>
  or any other known multiplication algorithm, provided n is sufficiently<br>
  large. For now, "sufficiently large" means almost unfathomably large:<br>
  Harvey and van der Hoeven's algorithm doesn't even kick in until the<br>
  number of bits in the two numbers being multiplied is greater than 2<br>
  raised to the 172912 power. (By comparison, the number of particles in<br>
  the observable Universe is commonly put at about 2270.)<br>
<br>
Checking the size of that boundary in Squeak:<br>
<br>
  (2 raisedTo: 172912) digitLength. ==> 21615<br>
  (2 raisedTo: 172912) asFloat. ==> Infinity<br>
<br>
I don't know nothin' about nothin' but even I know that 'Infinity' is<br>
a very big number ;-)<br>
<br>
But maybe that is missing the point. After all, we actually do a<br>
very good job of implementing large integer arithmetic in Squeak.<br>
Well OK, it is not exactly "we", Nicolas is the one who did most<br>
of it.<br>
<br>
Indeed, Squeak has no problem at all dealing with a rediculous<br>
expression such as this:<br>
<br>
  (((2 raisedTo: 172912) <br>
    cubed cubed cubed + 13 / (2 raisedTo: 172912)<br>
    * Float pi asScaledDecimal) asInteger) cubed cubed digitLength.<br>
<br>
     " ==> 5057678 "<br>
<br>
That's an integer with about 5 MB of internal representation. So maybe<br>
there is one more LargePositiveInteger>>digitMulXXXX method waiting<br>
to be created?<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
<br>
</blockquote></div>