[32992] in Perl-Users-Digest
Perl-Users Digest, Issue: 4268 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 16 09:09:17 2014
Date: Sat, 16 Aug 2014 06:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 16 Aug 2014 Volume: 11 Number: 4268
Today's topics:
Re: Perl bug ; <jurgenex@hotmail.com>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <richardn@nospam.com>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <gamo@telecable.es>
Re: Perl bug ; <hjp-usenet3@hjp.at>
Re: Perl bug ; <gamo@telecable.es>
Re: perl6 too much pointless functionality <hjp-usenet3@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 15 Aug 2014 08:55:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl bug ;
Message-Id: <8o8su99tq05fl5934mmimplspvq7ni286b@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 15/08/14 a las 01:00, gamo escribió:
>> El 15/08/14 a las 00:46, jurgenex@hotmail.com escribió:
>>>> could compile perl with support for long doubles (which I don't know
>>>> >why it's not done by default)
>>
>>> Because it wouldn't solve anything. There are many more rational numbers
>>> than floating point numbers and that is not going to change, no matter
>>> how many digits you are using.
>>>
>>> Example from the dezimal world:
>>> 0.3333333333 + 0.3333333333 + 0.3333333333 = 0.9999999999
>>> It doesn't matter if you are using 3 digits or 10 digits or 500 digits.
>>>
>>
>> Well, I expect more a response like because "are slower" or that
>> long doubles "take more space" but not the exceptions. The thing
>> is that a 32-bit computer using long doubles could be more
>> precise than a 64-bit computer. The better, must be the best.
>>
>> But thanks for the explanation.
>>
>
>More on reasons: standarization of results between versions and
>machines. OK. It could be all debatable. But despite all, the
>advantage is clear: the error is less important. Take your example
>with decimals.
>
>case a) 2 digits of precision
>1/3 + 1/3 + 1/3 = 0.33 * 3 = 0.99 -> error = 0.01
>
>case b) 3 digits of precision
>1/3 + 1/3 + 1/3 = 0.333 * 3 = 0.999 -> error = 0.001
>
>That's a big deal if for every digit we use, one digit less in error.
No, it is not. It is rather luring the nincompoops into a false sense of
safety. Wrong is still wrong.
You have to understand how floating point computations work in order to
use them safely. Otherwise the next question will be "Why do I get
'false' when comparing 1/3 + 1/3 + 1/3 with 1?"
You have to know that in floating point arithmetic time-honoured
mathematical laws simply don't apply. Even something as simple as
Number1 plus ( a million times Number2) equals
Number1 (a million times plus) Number2
is not correct any longer. With number1 being very large and number2
being very small this becomes obvious very fast.
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems has a
short overview of some well-known inherent limitations of floating point
numbers.There are good reasons why Computer Numerics has its own
scientific standing and you better have at least a basic understanding
or you shouldn't use floating point numbers to begin with.
Not to mention that there are extremely few cases where high precision
adds any value in real-world applications. Where do the values for your
floating point numbers are coming from? A number returned by some
measuring device? How many valid digits does that devise generate? 4? 5?
Then why would you decive your users by displaying 10 or 15 or 20
seemingly valid digits?
Do you really weight exactly 1.10231117 avoirdupois pounds if the recipe
calls for 1/2kg? Do you really need to know the distance between 2
cities to an accuracy of 20 valid digits?
I am truely hard pressed to find any everyday application where you need
more than maybe 5 valid digits and even that is a bit of a stretch
already. Science may be different but those people better know how to
handle computer numerics anyway.
jue
------------------------------
Date: Fri, 15 Aug 2014 21:25:28 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lslmrn$u95$1@speranza.aioe.org>
El 15/08/14 a las 17:55, jurgenex@hotmail.com escribió:
> I am truely hard pressed to find any everyday application where you need
> more than maybe 5 valid digits and even that is a bit of a stretch
> already. Science may be different but those people better know how to
> handle computer numerics anyway.
>
> jue
You have an example at hand: it's called clock. Any other
analogic-digital conversion, simulation will need precision. There are
cases
in which the error could be measured and it happens must be 0.0
For that, there are simple routines that calculate the EPS (epsilon)
of error in your language/compiler/machine combination and the minimum
it is, the better the computation. As expected, long doubles have
better, minor EPS errors.
I.e.
my $eps=1;
do {
$eps /= 2;
} until (1+$eps == 1);
print "$eps\n";
Mine is EPS = 1.11022302462516e-16
with a 64 bit machine. Any hillbilly
with perl compiled with long doubles
in a 32 bit machine will lower that.
Which remaind me to check what other options my distro-perl has.
Best regards.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Fri, 15 Aug 2014 18:15:09 -0500
From: Richard Nicholas <richardn@nospam.com>
Subject: Re: Perl bug ;
Message-Id: <MPG.2e5850788a9e25a29897f2@news.eternal-september.org>
In article <87mwb6olnf.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
says...
>
> gamo <gamo@telecable.es> writes:
>
> [floating point rounding errors]
>
> > If you are interested in monetary values, treating every amount as an
> > integer in cents, is another trick.
>
> This is more generally applicable. Eg, the original algorithm could be
> rewritten as
>
> my $d = 921;
> my $n = 10;
> do {
> $d -= 200;
> print($d / 100, "\n");
> } while --$n;
>
> to prevent error accumulation.
Perl does not let you tell it if a scalar is an int or a float so what's going on here? Does
Perl treat $d as an int whenever it can and use a float format only when it must? Or is $d a
float internally but there are no errors here because integer "values" always have exact
representations in floating point format?
Richard Nicholas
------------------------------
Date: Sat, 16 Aug 2014 10:22:41 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnluu56h.hl4.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-15 19:25, gamo <gamo@telecable.es> wrote:
> El 15/08/14 a las 17:55, jurgenex@hotmail.com escribió:
>> I am truely hard pressed to find any everyday application where you need
>> more than maybe 5 valid digits and even that is a bit of a stretch
>> already. Science may be different but those people better know how to
>> handle computer numerics anyway.
>
> You have an example at hand: it's called clock.
That depends on what you want to measure. The time it takes me to get to
my office? 2 digits are sufficient for that. A downhill race? 5 digits
are sufficient, and one could argue that the 5th digit just adds
pseudo-precision.
The time between the epoch and the posting of this article with 1 second
precision? Yes, you need 10 digits for that, but:
* This time is not as precise as you would think: There have been a
number of leap seconds which aren't reflected in unix time.
* You very rarely need to determine a 40+ year time to 1 second
precision. You need that precision to get a common time scale
on which you can compare events which are much closer together.
> Any other analogic-digital conversion,
Any measurement in the analog world has an inherent measurement error.
If the additional error introduced by rounding to a fp number is well
below this measurement error, any additional precision is pointless.
If you are measuring voltages in the ±1 V range and your voltmeter has
an accuracy of ±1 mV, single precision FP is more than enough. Sure, you
can't store 0.987 exactly, but only 0.986999988555908203125, but the
real value is somewhere between 0.986 and 0.988 and
0.986999988555908203125 is well within that range (this is something
that even electrical engineers, who should know better, sometimes get
wrong).
> simulation will need precision.
Yes, although you usually need that extra precision to keep the
accumulated error small, not for the result. This is the case where
higher precision fp numbers really shine. Add a billion values and you
have just increased your rounding error by 1 billion. But if you are
computing to 15 significant digits, you still have 6 digits left.
> There are cases in which the error could be measured and it happens
> must be 0.0
If you have to measure (as opposed to count) something, the error will
never be 0.0 because there will always be a measurement error. You
cannot measure anything in the real world to infinite precision.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 16 Aug 2014 10:52:07 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnluu6tn.hl4.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-15 23:15, Richard Nicholas <richardn@nospam.com> wrote:
> In article <87mwb6olnf.fsf@sable.mobileactivedefense.com>,
> rweikusat@mobileactivedefense.com says...
>> gamo <gamo@telecable.es> writes:
>> [floating point rounding errors]
>>
>> > If you are interested in monetary values, treating every amount as an
>> > integer in cents, is another trick.
Yup. I learned that little trick from a tax advisor on my first
programming job, almost 30 years ago.
>> This is more generally applicable. Eg, the original algorithm could be
>> rewritten as
>>
>> my $d = 921;
>> my $n = 10;
>> do {
>> $d -= 200;
>> print($d / 100, "\n");
>> } while --$n;
>>
>> to prevent error accumulation.
>
> Perl does not let you tell it if a scalar is an int or a float so
> what's going on here? Does Perl treat $d as an int whenever it can
> and use a float format only when it must?
Yes, but this is irrelevant here, because:
> Or is $d a float internally but there are no errors here because
> integer "values" always have exact representations in floating point
> format?
Yes. Or rather, some integer values have exact representations in a
floating point format, just like some integers can be represented in a
fixed length int format (Since there are infinitely many integers, it is
impossible to represent all of them in a finite number of bits).
In both cases there is a contiguous range of representable integers. A
32 bit signed int can represent [-2147483648, 2147483647], a 32 bit
unsigned int can represent [0, 4294967295]. A 64 bit IEEE 754 FP number
can represent all integers in [-9007199254740992, +9007199254740992].
For larger ranges, there are holes: For [-2**54, +2**54], it can
represent all even integers, for [-2*55, +2**54] it can represent all
integers divisible by 4, and so on. And for smaller ranges, it can
represent non-integers: For [-1, +1] it can represent all multiples of
2**-53.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 16 Aug 2014 13:27:14 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsnf74$97b$1@speranza.aioe.org>
El 16/08/14 a las 10:22, Peter J. Holzer escribió:
>> simulation will need precision.
> Yes, although you usually need that extra precision to keep the
> accumulated error small, not for the result. This is the case where
> higher precision fp numbers really shine. Add a billion values and you
> have just increased your rounding error by 1 billion. But if you are
> computing to 15 significant digits, you still have 6 digits left.
>
I don't get it. If I sum up one billion times (american billions)
a float number, constant, what I get is a pretty random number.
I can't see what digits are left. This is another argument in favor
of long doubles.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 16 Aug 2014 14:35:06 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Perl bug ;
Message-Id: <slrnluujvq.7k2.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-16 11:27, gamo <gamo@telecable.es> wrote:
> El 16/08/14 a las 10:22, Peter J. Holzer escribió:
>>> simulation will need precision.
>> Yes, although you usually need that extra precision to keep the
>> accumulated error small, not for the result. This is the case where
>> higher precision fp numbers really shine. Add a billion values and you
>> have just increased your rounding error by 1 billion. But if you are
>> computing to 15 significant digits, you still have 6 digits left.
>>
>
> I don't get it. If I sum up one billion times (american billions)
> a float number, constant, what I get is a pretty random number.
That depends on the number of digits in the float number, or ...
> I can't see what digits are left. This is another argument in favor
> of long doubles.
... using long doubles wouldn't help.
A double precision fp number has about 15 significant digits, so if you
lose the last 9 to rounding errors, your result is still accurate to 6
digits. An 80 bit "long double" has about 21 significant digits, so if
you lose the last 9, your result is accurate to 12 digits. Now ask
yourself: Are 6 digits enough or do you need 12? Or do you need even
more? That depends entirely on the problem.
Of course a single precision fp number has only 6 significant digits, so
if you lose 9 digits, your result is entirely random.
(Losing 9 digits from summing up 1 billion numbers is of course just a
ballpark number: That only happens if the result is of the same order as
the terms and all the errors point in the same direction. OTOH you can
lose all significant digits even with 3 terms: E.g. 1 + 1E30 - 1E30.)
> This is another argument in favor of long doubles.
Yes, I wrote that:
>> This is the case where higher precision fp numbers really shine.
But note that while 80 bit fp numbers (almost) always give more precise
results than 64 bit fp numbers, 128 bit fp numbers would give even more
precise results. So should we always use 128 bit fp numbers? Or 256 bit
fp numbers, since those given even better results? Where do we stop?
In the end for any generic solution (such as hardware support in a
processore or the generic "number" type in a weakly typed language like
Perl or Javascript) you have to compromise between accuracy and cost.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 16 Aug 2014 14:56:19 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Perl bug ;
Message-Id: <lsnke5$kuu$1@speranza.aioe.org>
El 16/08/14 a las 14:35, Peter J. Holzer escribió:
> But note that while 80 bit fp numbers (almost) always give more precise
> results than 64 bit fp numbers, 128 bit fp numbers would give even more
> precise results. So should we always use 128 bit fp numbers? Or 256 bit
> fp numbers, since those given even better results? Where do we stop?
>
We need to stop where technology stop us. The processor can handle
well a certain amount of length of bits of a fp. Over this amount,
it only can process a number with considerable overhead.
> In the end for any generic solution (such as hardware support in a
> processore or the generic "number" type in a weakly typed language like
> Perl or Javascript) you have to compromise between accuracy and cost.
>
> hp
What? Perl is programmed in C, ergo I don't know a good reason why
it need to be more imprecise added to more slowly. This kind of
reason add another brick in the wall around Perl as a decent lenguage.
And it is a decent one.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Fri, 15 Aug 2014 23:33:08 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: perl6 too much pointless functionality
Message-Id: <slrnlusv4k.hl4.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-14 11:02, G.B. <bauhaus@futureapps.invalid> wrote:
> While there appears to be some concerted work on some
> libraries, the creative people still behind Perl 6 seem to spend
> more energy on mixing more 7 bit ASCII ideographs with the current
> syntax,
Do they? Which ASCII characters have been added to the syntax recently?
The twigils that confused Mpouras have been in Perl6 for a long time.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4268
***************************************
