From: Peter J. Holzer on 22 May 2010 05:58 On 20100520 14:58, Ilya Zakharevich <nospamabuse(a)ilyaz.org> wrote: > On 20100519, Ben Morrow <ben(a)morrow.me.uk> wrote: >> Can you give an example of things not behaving as expected? > > I was presuming that such things happens left and right, so I did not > try to remember the problems people were reporting. But I may try to guess... > > And: I do not have Perl with 64bit IV AND 64bit 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)? An integer? Then it doesn't make sense to round it. 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. > $x + 0.5 >= $x Again, this is already "broken" (i.e., a false assumption) on large numbers, making IVs 64 bit doesn't change that. A better example would be where something like $large_even_integer/2 where the result is exact in integer arithmetic but must be rounded in FP arithmetic. However, perl (at least since 5.8.8) does the right thing here: The result is an IV with the exact result. (how does it do this?) hp
From: Ben Morrow on 22 May 2010 10:09 Quoth "Peter J. Holzer" <hjpusenet2(a)hjp.at>: > > A better example would be where something like > > $large_even_integer/2 > > where the result is exact in integer arithmetic but must be rounded in > FP arithmetic. However, perl (at least since 5.8.8) does the right thing > here: The result is an IV with the exact result. (how does it do this?) The code is in pp_divide in pp.c. Basically, if there is a chance the division will produce an exact integer result that can't be represented as a float, the code will  make both numbers positive  do the division in unsigned ints  if the result was exact (checked with an unsignedint multiply)  return an unsigned int if the result should be positive,  return a (negated) signed int if the result should be negative and it fits,  otherwise cast the int to a float and return the negation of that (which may be inaccurate, but that can't be helped);  else  do a floatingpoint division Ben
From: sln on 22 May 2010 14:38 On Sat, 22 May 2010 10:57:53 +0200, "Peter J. Holzer" <hjpusenet2(a)hjp.at> wrote: >On 20100521 16:24, sln(a)netherlands.com <sln(a)netherlands.com> wrote: >> On Thu, 20 May 2010 13:02:08 +0200, "Peter J. Holzer" <hjpusenet2(a)hjp.at> wrote: >>>On 20100519 23:56, sln(a)netherlands.com <sln(a)netherlands.com> wrote: >>>> On Wed, 19 May 2010 23:44:50 +0100, Ben Morrow <ben(a)morrow.me.uk> wrote: >>>>>and a C program the does the same operations on a signed 32bit integer >>>> ^^ .........^^ >>>> This is redundant. There is only unsigned and int. >>> >>>Wrong. "integer" is not the same as "int". The C standard knows five >>>standard signed integer types and six standard unsigned integer types. >>>And "int" and "unsigned" are just abbreviations of "signed int" and >>>"unsigned int", respectively. >> >> Technically there are no "integer types", they are integral types. > >Please read the standard. > Integer is what it is, a single whole number from the set of all whole numbers. There is no type of integer. There are subsets, they are called integral types in computing science. If the phrase is loosely used, thats a shame. C/C++ standard and all references to it use integral types as classifier of the subsets. sln
From: Ilya Zakharevich on 23 May 2010 19:08 On 20100522, Peter J. Holzer <hjpusenet2(a)hjp.at> wrote: >> And: I do not have Perl with 64bit IV AND 64bit 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. > An integer? Then it doesn't make sense to round it. Why? I can round 3 without any problem here... > 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. perldoc perlnumber >> $x + 0.5 >= $x > Again, this is already "broken" (i.e., a false assumption) on large > numbers, making IVs 64 bit doesn't change that. ??? Are you sure you know what you are talking about? Yours, Ilya
From: Peter J. Holzer on 24 May 2010 05:44 On 20100523 23:08, Ilya Zakharevich <nospamabuse(a)ilyaz.org> wrote: > On 20100522, Peter J. Holzer <hjpusenet2(a)hjp.at> wrote: >>> And: I do not have Perl with 64bit IV AND 64bit 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. >> 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). >> 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. > > perldoc perlnumber Please be more specific. >>> $x + 0.5 >= $x > >> Again, this is already "broken" (i.e., a false assumption) on large >> numbers, making IVs 64 bit doesn't change that. > > ??? Are you sure you know what you are talking about? Sorry, I misread the ">=" as ">". 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. That, however, does lead to a result which may surprise the unwary: #!/usr/bin/perl use warnings; use strict; no warnings 'portable'; use Devel::Peek; my $x1 = 18014398509481728.000000; # exact FP value my $x2 = 18014398509481729; # exact 64 bit int value if ($x1 >= $x2) { print "surprise!\n"; } hp
First

Prev

Next

Last
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? 