Prev: Don't understand: when('foo' and/or 'bar')
Next: FAQ 9.15 How do I parse a mail header?
From: Ilya Zakharevich on 24 May 2010 06:50
On 2010-05-24, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
>>>> And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
>>>> this is just a conjecture: I expect the the following things to break:

>>>> rounding by int($n + 0.t);

>>> what is $n here (conceptually)?

>> A number.

> Not specific enough.

Specific enough for me. What part of

perldoc perlnumber

do you not agree with?

>>> An integer? Then it doesn't make sense to round it.

>> Why? I can round 3 without any problem here...

> Because it is already an integer. Rounding it is useless since it is
> guarantueed to give you the same value (unless you want to round to the
> nearest integer representable as an FP value, then the expression does
> what you want).

I do not see how a correct answer may be deemed "useless". Do you
want to allow sqrt(1) to be 75 since "it does not make sense to apply
sqrt() to 1"?

> But from what I see, ($x + 0.5 >= $x) actually seems to be true for all
> numbers, because the comparison is done on the NVs.

So one moved dust to be under a different carpet. This comparison
"looks" true, but only due to another problem...

> my $x1 = 18014398509481728.000000; # exact FP value
> my $x2 = 18014398509481729; # exact 64 bit int value
> if ($x1 >= $x2) {
> print "surprise!\n";
> }

Yes, this is what I meant by "looking true..."...

Yours,
Ilya
From: Peter J. Holzer on 24 May 2010 11:23
On 2010-05-24 10:50, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> On 2010-05-24, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
>>>>> And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
>>>>> this is just a conjecture: I expect the the following things to break:
>
>>>>> rounding by int($n + 0.t);
>
>>>> what is $n here (conceptually)?
>
>>> A number.
>
>> Not specific enough.
>
> Specific enough for me.

Not for me. A number in a program isn't just a number. It represents
something. To determine which operations on that number make sense you
need to know what it represents, how accurate that represention is (and
needs to be), what properties it has. Then you can say whether a given
representation in a progrem (e.g. as a 64-bit FP number) is adequate and
whether computing int($n + 0.5) makes sense or not.

> What part of
>
> perldoc perlnumber
>
> do you not agree with?

Who says I don't agree with it? You were vaguely referring to it in
response to a very specific claim:

>>>> A floating point value? Then adding 0.5 doesn't change the
>>>> type and whether IVs are 32 bit or 64 bit doesn't matter.

I don't know why you referred to it, or which part of perldoc perlnumber
is supposed to proof that my claim is wrong, and I won't guess. Either
you refer to the specific part of perldoc perlnumber which is applicable
here or you let it rest.


>>>> An integer? Then it doesn't make sense to round it.
>
>>> Why? I can round 3 without any problem here...
>
>> Because it is already an integer. Rounding it is useless since it is
>> guarantueed to give you the same value (unless you want to round to the
>> nearest integer representable as an FP value, then the expression does
>> what you want).
>
> I do not see how a correct answer may be deemed "useless".

Not the answer is useless, but the operation. If I have a variable $x in
my program which at some point contains an integral value, why would I
write

$y = int($x + 0.5);

instead of simply

$y = $x;

at this point? I could just as well write

$y = $x * 1;

or

$y = $x + 0;

or

$y = $x + 1E300 - 1E300;

which are similarly useless (unless executed specifically for the
side-effects caused by the representation).


> Do you want to allow sqrt(1) to be 75 since "it does not make sense to
> apply sqrt() to 1"?

No, but I do want to allow sin(1E100) to return an (more or less) random
number between -1 and +1, because ε(1E100) ≫ 2π. The input to the
function is useless, so I must expect the output to be useless, too.
Similarly ($n + 0.5) is only useful if the result can actually be
represented in an FP number with adequate precision. Perl doesn't save
you from thinking about stuff like that. Actually, you have to think
more than in statically typed languages: A typeless language gives you
more freedom but demands more discipline.

hp

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Don't understand: when('foo' and/or 'bar')
Next: FAQ 9.15 How do I parse a mail header?