Can anyone comment how they handle floating point precision situations
like this?

Here is a basic toy program:
#!/usr/bin/perl

use strict;

my $total = 0;
my $a = 21835.30;
my $b = -21715.90;
my $c = 9652.20;
my $d = -9771.60;

print ("total = $total\n");
$total += $a;
print ("total = $total\n");
$total += $b;
print ("total = $total\n");
$total += $c;
print ("total = $total\n");
$total += $d;
print ("total = $total\n");
$total = sprintf("%.2f", $total);
print ("total = $total\n");


And here is the output:
total = 0
total = 21835.3
total = 119.399999999998
total = 9771.6
total = -1.81898940354586e-12
total = -0.00

Note the lack of precision adding these simple numbers which do not have
a large number of digits to the right of the decimal.

If the line:
$total = sprintf("%.2f", $total);
would produce 0.00 rather than -0.00 I could live with this.

But the only solution I have to get the final answer to properly be 0.00
is to format
$total = sprintf("%.2f", $total);
after each increment is added to $total

or maybe put a string comparison at the end checking for "-0.00" and
changing it to "0.00" if it matches.

I don't like either of these solutions.

How do others deal with this?

Thanks,
Jim

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Wed, Sep 1, 2010 at 16:46, Jim <jim [at] lowcarbfriends.com> wrote:
> Can anyone comment how they handle floating point precision situations like
> this?
snip
> I don't like either of these solutions.
>
> How do others deal with this?
snip

Short answer: floating point numbers suck, but are fast. If you need
accuracy you should convert your numbers into integers (for instance,
financial programs tend to use fractions of a penny, so 1000 is one
cent) or move to a slower but exact math system like
[Math::Currency][0] (note, this is not an endorsement of that module,
I have never used it).

[0]: http://search.cpan.org/~jpeacock/Math-Currency-0.47/lib/Math /Currency.pm


--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/1/2010 5:04 PM, Chas. Owens wrote:
> On Wed, Sep 1, 2010 at 16:46, Jim<jim [at] lowcarbfriends.com> wrote:
>> Can anyone comment how they handle floating point precision situations like
>> this?
> snip
>> I don't like either of these solutions.
>>
>> How do others deal with this?
> snip
>
> Short answer: floating point numbers suck, but are fast. If you need
> accuracy you should convert your numbers into integers (for instance,
> financial programs tend to use fractions of a penny, so 1000 is one
> cent) or move to a slower but exact math system like
> [Math::Currency][0] (note, this is not an endorsement of that module,
> I have never used it).
>
> [0]: http://search.cpan.org/~jpeacock/Math-Currency-0.47/lib/Math /Currency.pm
>
>

Thanks... that's the sort of answer I've been reading about... not crazy
about it... but it is what it is. This problem is more infuriating than
unsolvable in terms of why I need to even think about something like
this. My $0.99 calculator can computer those numbers precisely, but my
$3000 server can't.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 10-09-01 05:32 PM, Jim wrote:
> Thanks... that's the sort of answer I've been reading about... not crazy
> about it... but it is what it is. This problem is more infuriating than
> unsolvable in terms of why I need to even think about something like
> this. My $0.99 calculator can computer those numbers precisely, but my
> $3000 server can't.

Your $99 calculator can do it because it uses BCD
<http://en.wikipedia.org/wiki/Binary-coded_decimal> not binary numbers.
There is a whole field in mathematics for dealing with these types of
problems called Numerical Analysis
<http://en.wikipedia.org/wiki/Numerical_Analysis>. Enjoy.


--
Just my 0.00000002 million dollars worth,
Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Wed, Sep 1, 2010 at 17:32, Jim <jim [at] lowcarbfriends.com> wrote:
> On 9/1/2010 5:04 PM, Chas. Owens wrote:
>>
>> On Wed, Sep 1, 2010 at 16:46, Jim<jim [at] lowcarbfriends.com> =C2=A0wrote:
>>>
>>> Can anyone comment how they handle floating point precision situations
>>> like
>>> this?
>>
>> snip
>>>
>>> I don't like either of these solutions.
>>>
>>> How do others deal with this?
>>
>> snip
>>
>> Short answer: floating point numbers suck, but are fast. =C2=A0If you ne=
ed
>> accuracy you should convert your numbers into integers (for instance,
>> financial programs tend to use fractions of a penny, so 1000 is one
>> cent) or move to a slower but exact math system like
>> [Math::Currency][0] (note, this is not an endorsement of that module,
>> I have never used it).
>>
>> =C2=A0[0]:
>> http://search.cpan.org/~jpeacock/Math-Currency-0.47/lib/Math /Currency.pm
>>
>>
>
> Thanks... that's the sort of answer I've been reading about... not crazy
> about it... but it is what it is. This problem is more infuriating than
> unsolvable in terms of why I need to even think about something like this=
..
> My $0.99 calculator can computer those numbers precisely, but my $3000
> server can't.
>

Well, I call bullshit on that. You calculator probably has the same
crappy IEEE 754 floating point implementation as everything else, it
is just rounding the output so you don't notice it and you never push
a crappy calculator they way you do a $3000 server. The problem is a
simple one: some numbers can't be represented. I am not even talking
about weird ones like pi. Simple numbers like .1 cannot be
represented by floating point numbers:

perl -e 'printf "%32.32f\n%32.32f\n", .5 - .4, .1'
0.09999999999999997779553950749687
0.10000000000000000555111512312578

The problem is not unique to Perl 5, it is inherent in floating point numbe=
rs:

#include <stdio.h>

int main(int argc, char** argv) {
printf("%32.32f\n%32.32f\n", .5 - .4, .1);
return 0;
}

0.09999999999999997779553950749687
0.10000000000000000555111512312578

If you are willing to live with rounding you can make the problem
harder to see, but it is still there.

--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/1/10 Wed Sep 1, 2010 1:46 PM, "Jim" <jim [at] lowcarbfriends.com>
scribbled:

> Can anyone comment how they handle floating point precision situations
> like this?
>
> Here is a basic toy program:
> #!/usr/bin/perl
>
> use strict;
>
> my $total = 0;
> my $a = 21835.30;
> my $b = -21715.90;
> my $c = 9652.20;
> my $d = -9771.60;
>
> print ("total = $total\n");
> $total += $a;
> print ("total = $total\n");
> $total += $b;
> print ("total = $total\n");
> $total += $c;
> print ("total = $total\n");
> $total += $d;
> print ("total = $total\n");
> $total = sprintf("%.2f", $total);
> print ("total = $total\n");
>
>
> And here is the output:
> total = 0
> total = 21835.3
> total = 119.399999999998
> total = 9771.6
> total = -1.81898940354586e-12
> total = -0.00
>
> Note the lack of precision adding these simple numbers which do not have
> a large number of digits to the right of the decimal.
>
> If the line:
> $total = sprintf("%.2f", $total);
> would produce 0.00 rather than -0.00 I could live with this.
>
> But the only solution I have to get the final answer to properly be 0.00
> is to format
> $total = sprintf("%.2f", $total);
> after each increment is added to $total
>
> or maybe put a string comparison at the end checking for "-0.00" and
> changing it to "0.00" if it matches.
>
> I don't like either of these solutions.
>
> How do others deal with this?

I don't worry about it. I do the calculations and print out the result with
printf to whatever precision I need and what I feel is warranted by the
accuracy of the input data. Double-precision 64-bit floating-point has
ALWAYS been accurate enough for my needs.

If I happen to print out some intermediate results, I don't worry about such
"errors" as you have shown, since I know they are normal for computer-based
arithmetic. In real life, an arithmetic evaluation never results in a value
that will print as "-0.00". And if it did, it wouldn't bother me. It is
still zero to two places.

One good approach: plot your data rather than printing it, if possible. It
is easier to see patterns, averages, outliers, etc. in a plot than it is in
a list of numbers.




--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Wed, Sep 01, 2010 at 04:46:30PM -0400, Jim wrote:
> Can anyone comment how they handle floating point precision situations
> like this?
>
> Here is a basic toy program:
> #!/usr/bin/perl
>
> use strict;
>
> my $total = 0;
> my $a = 21835.30;
> my $b = -21715.90;
> my $c = 9652.20;
> my $d = -9771.60;
>
> print ("total = $total\n");
> $total += $a;
> print ("total = $total\n");
> $total += $b;
> print ("total = $total\n");
> $total += $c;
> print ("total = $total\n");
> $total += $d;
> print ("total = $total\n");
> $total = sprintf("%.2f", $total);
> print ("total = $total\n");
>
>
> And here is the output:
> total = 0
> total = 21835.3
> total = 119.399999999998
> total = 9771.6
> total = -1.81898940354586e-12
> total = -0.00
>
> Note the lack of precision adding these simple numbers which do not have
> a large number of digits to the right of the decimal.
>
> If the line:
> $total = sprintf("%.2f", $total);
> would produce 0.00 rather than -0.00 I could live with this.
>
> But the only solution I have to get the final answer to properly be 0.00
> is to format
> $total = sprintf("%.2f", $total);
> after each increment is added to $total
>
> or maybe put a string comparison at the end checking for "-0.00" and
> changing it to "0.00" if it matches.
>
> I don't like either of these solutions.
>
> How do others deal with this?

Depending on exactly what you require, something like this might do what
you want:

#!/usr/bin/perl

use strict;

my $total = 0;
my $a = 21835.30;
my $b = -21715.90;
my $c = 9652.20;
my $d = -9771.60;

sub to2dp { sprintf "%.2f", $_[0] + 1e-8 }

print ("total = $total\n");
print "to2dp = ", to2dp($total), "\n";
$total += $a;
print ("total = $total\n");
print "to2dp = ", to2dp($total), "\n";
$total += $b;
print ("total = $total\n");
print "to2dp = ", to2dp($total), "\n";
$total += $c;
print ("total = $total\n");
print "to2dp = ", to2dp($total), "\n";
$total += $d;
print ("total = $total\n");
print "to2dp = ", to2dp($total), "\n";
$total = sprintf("%.2f", $total);
print ("total = $total\n");
print "to2dp = ", to2dp($total), "\n";

This produces the output:

total = 0
to2dp = 0.00
total = 21835.3
to2dp = 21835.30
total = 119.399999999998
to2dp = 119.40
total = 9771.6
to2dp = 9771.60
total = -1.81898940354586e-12
to2dp = 0.00
total = -0.00
to2dp = 0.00

When you want to compare floating point numbers, check that their
difference is less than some appropriately small delta:

$delta = 1e-8;

if (abs($a - $b) < $delta) # numbers are "equal"


But ideally do it all in integers or use a special purpose library if
you need a greater range. If you use floating point then ensure you
know its limits.

--
Paul Johnson - paul [at] pjcj.net
http://www.pjcj.net

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2010-09-02 00:49, Paul Johnson wrote:

> When you want to compare floating point numbers, check that their
> difference is less than some appropriately small delta:
>
> $delta = 1e-8;
>
> if (abs($a - $b)< $delta) # numbers are "equal"

Why call it delta when you can call it epsilon?
;)

It also has no 'my', why is that?


And OP should read at least one of these:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://en.wikipedia.org/wiki/Floating_point
http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floatin g-point-article.pdf

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2010-09-01 22:46, Jim wrote:

> Can anyone comment how they handle floating point precision situations
> like this?
>[...]
> Note the lack of precision adding these simple numbers which do not have
> a large number of digits to the right of the decimal.
>
> If the line:
> $total = sprintf("%.2f", $total);
> would produce 0.00 rather than -0.00 I could live with this.

You could work in cents, so calculate with integers.

But with division, you would get into the same zone again.
Unless you accept rounding to integer there.

Also try bigrat.

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Sep 02, 2010 at 01:11:07AM +0200, Dr.Ruud wrote:
> On 2010-09-02 00:49, Paul Johnson wrote:
>
>> When you want to compare floating point numbers, check that their
>> difference is less than some appropriately small delta:
>>
>> $delta = 1e-8;
>>
>> if (abs($a - $b)< $delta) # numbers are "equal"
>
> Why call it delta when you can call it epsilon?
> ;)

You're absolutely right. And see Test::Number::Delta on CPAN for an
easier way of doing this in tests.

> It also has no 'my', why is that?

Because it is a short snippet of code designed to show one principle.
Adding "my" would not have contributed to that goal. I was also
expecting someone to pick me up on using $a and $b. Perhaps they still
will. The answer would be very similar.

> And OP should read at least one of these:
> http://docs.sun.com/source/806-3568/ncg_goldberg.html
> http://en.wikipedia.org/wiki/Floating_point
> http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floatin g-point-article.pdf

Yes, this is a well understood problem that nevertheless manages to
perplex many beginning programmers.

--
Paul Johnson - paul [at] pjcj.net
http://www.pjcj.net

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/2/2010 8:53 AM, Paul Johnson wrote:
> On Thu, Sep 02, 2010 at 01:11:07AM +0200, Dr.Ruud wrote:
>> On 2010-09-02 00:49, Paul Johnson wrote:
>>
>>> When you want to compare floating point numbers, check that their
>>> difference is less than some appropriately small delta:
>>>
>>> $delta = 1e-8;
>>>
>>> if (abs($a - $b)< $delta) # numbers are "equal"
>>
>> Why call it delta when you can call it epsilon?
>> ;)
>
> You're absolutely right. And see Test::Number::Delta on CPAN for an
> easier way of doing this in tests.
>
>> It also has no 'my', why is that?
>
> Because it is a short snippet of code designed to show one principle.
> Adding "my" would not have contributed to that goal. I was also
> expecting someone to pick me up on using $a and $b. Perhaps they still
> will. The answer would be very similar.
>
>> And OP should read at least one of these:
>> http://docs.sun.com/source/806-3568/ncg_goldberg.html
>> http://en.wikipedia.org/wiki/Floating_point
>> http://hal.archives-ouvertes.fr/docs/00/28/14/29/PDF/floatin g-point-article.pdf
>
> Yes, this is a well understood problem that nevertheless manages to
> perplex many beginning programmers.
>

It's really not a question of it being perplexing more so than like I
said maddening in terms of why solutions just aren't intrinsic to the
programming language. If ops are slower, so what... throw some more hw
at the problem... hw is cheap... people's time isn't.

I was hoping I'd see some answer like... oh yeah... perl is smart enough
to handle that for you if you are willing to accept a performance hit...
just turn on so-and-so directive and perl will perform in non-floating
point mode and return precise answers up to some level of precision...
just like your calculator. I undertand there are modules that will help,
but it sounds like those involve significant coding changes. Or like
others suggest, convert everything to cents or fractions of cents and
then divide at the end... requires a lot of foresight or backtracking.

perl already does smart things like garbage collection, so I don't have
to think about things like malloc and free... very nice. I figured there
would be some similar perl-specific solution.

And like I mentioned, for the most part a final %.2f I believe will
handle the problem, unless you are combining *lots* of numbers with fp
error. The problem I really dislike is the final -0.00. When the answer
due to fp error is slightly less than 0.00. Putting some check on that
whenever real numbers are added is a drag.

But thanks again for all the feedback.

Jim

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 10-09-02 09:32 AM, Jim wrote:
> It's really not a question of it being perplexing more so than like I
> said maddening in terms of why solutions just aren't intrinsic to the
> programming language. If ops are slower, so what... throw some more hw
> at the problem... hw is cheap... people's time isn't.

See `perldoc perlfaq4` and search for /Does Perl have a round()
function? What about ceil() and floor()? Trig functions?/

The question is: Does Perl round off numbers, or take their floor(), or
their ceil()? The answer depends on the circumstances. Since Perl
cannot read your mind, it leaves it up to you to determine what it does.

As I said before, there's a whole field of mathematics called Numerical
Analysis on this. If very smart mathematicians need to study this
problem for years before they can get it right, how do you expect Perl
to do it so simply?


--
Just my 0.00000002 million dollars worth,
Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 10-09-02 09:32 AM, Jim wrote:
> It's really not a question of it being perplexing more so than like I
> said maddening in terms of why solutions just aren't intrinsic to the
> programming language. If ops are slower, so what... throw some more hw
> at the problem... hw is cheap... people's time isn't.

See `perldoc perlfaq4` and search for /Does Perl have a round()
function? What about ceil() and floor()? Trig functions?/

The question is: Does Perl round off numbers, or take their floor(), or
their ceil()? The answer depends on the circumstances. Since Perl
cannot read your mind, it leaves it up to you to determine what it does.

As I said before, there's a whole field of mathematics called Numerical
Analysis on this. If very smart mathematicians need to study this
problem for years before they can get it right, how do you expect Perl
to do it so simply?


--
Just my 0.00000002 million dollars worth,
Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Sep 2, 2010 at 09:32, Jim <jim [at] lowcarbfriends.com> wrote:
snip
> It's really not a question of it being perplexing more so than like I said
> maddening in terms of why solutions just aren't intrinsic to the programming
> language. If ops are slower, so what... throw some more hw at the problem...
> hw is cheap... people's time isn't.
snip

The idea that hardware is cheap and people's time is expensive is a
relatively new idea. For most of computing history, CPU time has been
more valuable than a human's time. And the idea that human time is
more important than CPU time will only last so long as Moore's Law
holds out and we have cheap power sources.

> I was hoping I'd see some answer like... oh yeah... perl is smart enough to
> handle that for you if you are willing to accept a performance hit... just
> turn on so-and-so directive and perl will perform in non-floating point mode
> and return precise answers up to some level of precision... just like your
> calculator. I undertand there are modules that will help, but it sounds like
> those involve significant coding changes. Or like others suggest, convert
> everything to cents or fractions of cents and then divide at the end...
> requires a lot of foresight or backtracking.

There are pragmas that transparently use higher precision and accuracy
libraries for you in the Perl 5 core: take a look at [bigint][0],
[bignum][1], and [bigrat][2], but there is a performance hit. Using
bignum with your original code outputs:

total = 0
total = 21835.3
total = 119.4
total = 9771.6
total = 0
total = 0.00

#!/usr/bin/perl

use strict;
use warnings;

use bignum;

my $total = 0;
my $a = 21835.30;
my $b = -21715.90;
my $c = 9652.20;
my $d = -9771.60;

print ("total = $total\n");
$total += $a;
print ("total = $total\n");
$total += $b;
print ("total = $total\n");
$total += $c;
print ("total = $total\n");
$total += $d;
print ("total = $total\n");
$total = sprintf("%.2f", $total);
print ("total = $total\n");

[0]: http://perldoc.perl.org/bigint.html
[1]: http://perldoc.perl.org/bignum.html
[2]: http://perldoc.perl.org/bigrat.html

--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Sep 2, 2010 at 10:03, Shawn H Corey <shawnhcorey [at] gmail.com> wrote:
snip
> See `perldoc perlfaq4` and search for /Does Perl have a round() function?
> =C2=A0What about ceil() and floor()? =C2=A0Trig functions?/
snip

Or just say perldoc -q round, or go to
http://perldoc.perl.org/perlfaq4.html#Does-Perl-have-a-round ()-function%3f-=
-What-about-ceil()-and-floor()%3f--Trig-functions%3f


--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/2/2010 2:51 PM, Ruud H.G. van Tol wrote:
> On 2010-09-02 15:32, Jim wrote:
>
>> I was hoping I'd see some answer like... oh yeah... perl is smart enough
>> to handle that for you if you are willing to accept a performance hit...
>
> My "bigrat" was meant like that. Did you already try it?
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use bigrat;
>
> <your code>
>
> __END__
>
>

Sorry, I glanced over your advice. But both bigrat and bignum both
transparently do what I had hoped for. bigint looks like it truncates to
integers which is not a choice for my current problem.

Does anyone have significant experience with both bigrat and bignum such
that you would advise of use of one over the other. They seem to be very
similar.

Thank you. I'll work use of one of these into a bit of code at a time to
watch for any side effects.

Jim

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/2/10 Thu Sep 2, 2010 12:52 PM, "Jim" <jim [at] lowcarbfriends.com>
scribbled:

> On 9/2/2010 2:51 PM, Ruud H.G. van Tol wrote:
>> On 2010-09-02 15:32, Jim wrote:
>>
>>> I was hoping I'd see some answer like... oh yeah... perl is smart enough
>>> to handle that for you if you are willing to accept a performance hit...
>>
>> My "bigrat" was meant like that. Did you already try it?
>>
>> #!/usr/bin/perl
>> use strict;
>> use warnings;
>> use bigrat;
>>
>> <your code>
>>
>> __END__
>>
>>
>
> Sorry, I glanced over your advice. But both bigrat and bignum both
> transparently do what I had hoped for. bigint looks like it truncates to
> integers which is not a choice for my current problem.
>
> Does anyone have significant experience with both bigrat and bignum such
> that you would advise of use of one over the other. They seem to be very
> similar.
>
> Thank you. I'll work use of one of these into a bit of code at a time to
> watch for any side effects.

Do you have any evidence that the use of either of these is warranted? So
far, you have only shown that printing floating-point numbers to some
limited precision involves rounding and can produce unexpected results. You
have not shown that the results are wrong, only that you expected something
else.


My advice is to stay away from these modules unless you know what you are
doing. I find that double-precision floating-point arithmetic is always good
enough. I have been programming in scientific and technical fields for 40
years and have yet to need extended-precision arithmentic.

If, on the other hand, you are working with large, financial transactions or
cryptography, you may need these modules. If that is the case, however, you
probably shouldn't be looking for help on a Perl beginner's list.

I just do not want anybody to get the impression that these modules are
needed for accurate arithmetic in Perl and that standard Perl arithmetic
operations are inaccurate.



--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/2/2010 4:15 PM, Jim Gibson wrote:
> On 9/2/10 Thu Sep 2, 2010 12:52 PM, "Jim"<jim [at] lowcarbfriends.com>
> scribbled:
>
>> On 9/2/2010 2:51 PM, Ruud H.G. van Tol wrote:
>>> On 2010-09-02 15:32, Jim wrote:
>>>
>>>> I was hoping I'd see some answer like... oh yeah... perl is smart enough
>>>> to handle that for you if you are willing to accept a performance hit...
>>>
>>> My "bigrat" was meant like that. Did you already try it?
>>>
>>> #!/usr/bin/perl
>>> use strict;
>>> use warnings;
>>> use bigrat;
>>>
>>> <your code>
>>>
>>> __END__
>>>
>>>
>>
>> Sorry, I glanced over your advice. But both bigrat and bignum both
>> transparently do what I had hoped for. bigint looks like it truncates to
>> integers which is not a choice for my current problem.
>>
>> Does anyone have significant experience with both bigrat and bignum such
>> that you would advise of use of one over the other. They seem to be very
>> similar.
>>
>> Thank you. I'll work use of one of these into a bit of code at a time to
>> watch for any side effects.
>
> Do you have any evidence that the use of either of these is warranted? So
> far, you have only shown that printing floating-point numbers to some
> limited precision involves rounding and can produce unexpected results. You
> have not shown that the results are wrong, only that you expected something
> else.
>
>
> My advice is to stay away from these modules unless you know what you are
> doing. I find that double-precision floating-point arithmetic is always good
> enough. I have been programming in scientific and technical fields for 40
> years and have yet to need extended-precision arithmentic.
>
> If, on the other hand, you are working with large, financial transactions or
> cryptography, you may need these modules. If that is the case, however, you
> probably shouldn't be looking for help on a Perl beginner's list.
>
> I just do not want anybody to get the impression that these modules are
> needed for accurate arithmetic in Perl and that standard Perl arithmetic
> operations are inaccurate.

I'm open to more advice. How would you rewrite my original toy code?

Jim

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 9/2/10 Thu Sep 2, 2010 2:00 PM, "Jim" <jim [at] lowcarbfriends.com>
scribbled:

> On 9/2/2010 4:15 PM, Jim Gibson wrote:

>> My advice is to stay away from these modules unless you know what you are
>> doing. I find that double-precision floating-point arithmetic is always good
>> enough. I have been programming in scientific and technical fields for 40
>> years and have yet to need extended-precision arithmentic.
>>
>> If, on the other hand, you are working with large, financial transactions or
>> cryptography, you may need these modules. If that is the case, however, you
>> probably shouldn't be looking for help on a Perl beginner's list.
>>
>> I just do not want anybody to get the impression that these modules are
>> needed for accurate arithmetic in Perl and that standard Perl arithmetic
>> operations are inaccurate.
>
> I'm open to more advice. How would you rewrite my original toy code?

I wouldn't. It doesn't contain any errors. What you are seeing is the
expected behavior. The internal representation of most floating-point
numbers is approximate. If you print out binary floating-point numbers at
enough precision you will see differences from decimal representations. If
you are using double-precision floating-point, the accuracy is about 16
decimal places. If you need more accuracy than that, then you need to use
extended precision. But those applications are rare.



--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2010-09-02 15:32, Jim wrote:

> I was hoping I'd see some answer like... oh yeah... perl is smart enough
> to handle that for you if you are willing to accept a performance hit...

My "bigrat" was meant like that. Did you already try it?

#!/usr/bin/perl
use strict;
use warnings;
use bigrat;

<your code>

__END__


--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/