http://qs1969.pair.com?node_id=1104917

in reply to Perl can't make some easy arithmetics :(

Understanding the limitations of floating point arithmetics is a basic requirement for any programmer - no matter which language.

Cheers Rolf

(addicted to the Perl Programming Language and ☆☆☆☆ :)

• Comment on Re: rsFalse can't make some easy arithmetics :)

Replies are listed 'Best First'.
Re^2: rsFalse can't make some easy arithmetics :)
by no_slogan (Deacon) on Oct 24, 2014 at 22:26 UTC
From a language design perspective, what do we gain by using machine-precision floating point as our default numeric representation? Nothing, really, except that it's easy to implement. I think modern languages should follow Python's lead and switch to extended-precision formats.
what do we gain by using machine-precision floating point as our default numeric representation?

I just watched an HD movie on my PC. In the 105 minutes of runtime, approximately 100 billion calculations are performed.

If these calculations were done using bigint, then the movie would take 34.5 days to watch...

```cmpthese -1, {
a=>q[my \$t=0; \$t *= \$_ for 1 .. 1e3;],
b=>q[use bigint; my \$t=0; \$t *= \$_ for 1 .. 1e3 ]
};;
Rate      b      a
b  23.8/s     --  -100%
a 11263/s 47292%     --

I'm more than happy to have to consider the limitations of native machine precision.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

If you read what I wrote carefully, you'll see that I said "default representation." Hardware floating-point is very useful for certain applications, and I certainly wouldn't want to give it up completely. But, more and more, it's usually not what you want.

Also, your video codec is almost certainly using parallelized fixed-point calculations, not floating-point.

Also also, are you using a pure-perl bigint implementation? That's the default.

A reply falls below the community's threshold of quality. You may see it by logging in.
I don't know much about "Python's extended-precision formats" and I'd probably agree.

The OP wasn't very clear about what his problem is, it looked like the usual "why is FP arithmetics not DWIM".

As it turned out later, he has a problem with some bigint automatisms and not Perl (like his rather naive title indicated).

Anyway - modern language or not - understanding FP's limitations is still crucial.

Cheers Rolf

(addicted to the Perl Programming Language and ☆☆☆☆ :)