Re: Math
- From: Ilya Zakharevich <nospam-abuse@xxxxxxxxx>
- Date: Wed, 25 Jul 2007 20:17:14 +0000 (UTC)
[A complimentary Cc of this posting was sent to
Brian Blackmore
<blb8@xxxxxxxxxxx>], who wrote in article <f86uje$3mf$1@xxxxxxxxxxxxxxxxxxxxxxx>:
For some unfathomable reasons, Perl uses non-invertible transformations
between strings and numbers. So if your handling of numbers involves
converting them to strings, then back, the precision will be lost.
Yes, but I would question which programming languages don't suffer
from this behavior?
What other programming languages with multi-representation numbers do
you know?
I thought we were talking about the classic `type conversion' issue.
If you mean *explicit* conversion from binary representation to string
and back, then ANY language I know can do it losslessly.
Nope, by C RT libraries. And the for these libraries, they do it
following instructions from perl.
Following your advice, and checking perlnumber, what I found was what
I said up above:
"RESTRICTION: The conversions marked with "(*)" above
involve steps performed by the C compiler. In particular,
bugs/features of the compiler used may lead to breakage of
some of the above rules."
I wonder whether it is the original text (written by me); might be so.
It does not make any sense; the intent is clear, but the wording is
very bad... I tried to "keep things simple", but this error is not in
that category...
Since "native floating_point --> decimal string (*)" and
"decimal string --> native floating point (*)" are so marked, I
interpret that to mean that perl is at the whim of whatever C compiler
was used.
Yes - in the sense, that usually C compiler determines which CRTL is used.
What you are missing however, that even if Perl uses CRTL functions,
they take a lot of "options". And it is the options which Perl uses
which lead to precision loss.
AND, as I said, Perl could have used some specialized functions tuned
up to its problem domain (multi-representation).
whence Perl is at the mercy of the system on which it was compiled.
And this the CHOICE made by perl. It could have done the conversion
itself.
True, but that's a bit like saying that it's output could be based on
the TeX typesetting engine, that it's input stream should be entirely
XMLized and should natively handle images and gestured input, and that
it should natively translated any symbol set into the appropriate
characters necessary to create code.
Sorry, I have no idea what was it you wanted to express here.
Lacking a programming language where float->string conversion is
invertible,
??? See above.
converting to strings in any language creates a loss of
precision, which is no difficulty to imagine given a base ten
representation in a string in comparison to a base two representation
for a float.
Indeed, I was also thinking of something simple like 1/3, but have
you an example of a language where "1/3"=1/3? Or are there so many
that I'm just being dim?
Yes. E.g., see
perl -MMath::Pari=:int
So perl has the ability after all, and doesn't use non-invertible
transforms, so there are no unfathomable reasons.
Again, the way I can parse this, it makes no sense.
Hope this helps,
Ilya
.
- Follow-Ups:
- Re: Math
- From: Robert Hicks
- Re: Math
- References:
- Prev by Date: Re: match string by re using some pattern
- Next by Date: Re: match string by re using some pattern
- Previous by thread: Re: Math
- Next by thread: Re: Math
- Index(es):
Relevant Pages
|
