Prev: Don't understand: when('foo' and/or 'bar')
Next: FAQ 9.15 How do I parse a mail header?
From: Ben Morrow on 19 May 2010 09:28

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-05-18, Ben Morrow <ben(a)morrow.me.uk> wrote:
> >
> > Depending on what you're doing, promotion to double *should* safely give
> > you 53 bits of integer precision, but you may want to consider
> > rebuilding your perl with -Duse64bitint to avoid type conversion all
> > over the place. The standard FreeBSD build has been built with this
> > option for a while now, and there is some talk of using it for the
> > Debian builds of 5.12.
>
> Having int wider than float type is a VERY large can of worms (well,
> at least it was the last time I was looking; did things change
> recently?).

That's all been fixed, I think by Nick Clark during 5.8. A whole lot of
code in {pp,sv}.c is now conditional on NV_PRESERVES_UV, which is
determined by Configure.

Ben

From: Ilya Zakharevich on 19 May 2010 14:46
On 2010-05-19, Ben Morrow <ben(a)morrow.me.uk> wrote:
>
> Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
>> On 2010-05-18, Ben Morrow <ben(a)morrow.me.uk> wrote:
>> >
>> > Depending on what you're doing, promotion to double *should* safely give
>> > you 53 bits of integer precision, but you may want to consider
>> > rebuilding your perl with -Duse64bitint to avoid type conversion all
>> > over the place. The standard FreeBSD build has been built with this
>> > option for a while now, and there is some talk of using it for the
>> > Debian builds of 5.12.
>>
>> Having int wider than float type is a VERY large can of worms (well,
>> at least it was the last time I was looking; did things change
>> recently?).
>
> That's all been fixed, I think by Nick Clark during 5.8. A whole lot of
> code in {pp,sv}.c is now conditional on NV_PRESERVES_UV, which is
> determined by Configure.

Looks like I might have been not very specific. The can of worms I
meant is with the semantic, not implementation - things "not behaving
as expected" vs things behaving "obviously wrong".

This thread is one example of the "first category" - if one forgets
what happens with `use integer', which is obviously a bug (BTW, is it
reported yet?).

Yours,
Ilya
From: Ben Morrow on 19 May 2010 18:44

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-05-19, Ben Morrow <ben(a)morrow.me.uk> wrote:
> >
> > Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> >> On 2010-05-18, Ben Morrow <ben(a)morrow.me.uk> wrote:
> >> >
> >> > Depending on what you're doing, promotion to double *should* safely give
> >> > you 53 bits of integer precision, but you may want to consider
> >> > rebuilding your perl with -Duse64bitint to avoid type conversion all
> >> > over the place. The standard FreeBSD build has been built with this
> >> > option for a while now, and there is some talk of using it for the
> >> > Debian builds of 5.12.
> >>
> >> Having int wider than float type is a VERY large can of worms (well,
> >> at least it was the last time I was looking; did things change
> >> recently?).
> >
> > That's all been fixed, I think by Nick Clark during 5.8. A whole lot of
> > code in {pp,sv}.c is now conditional on NV_PRESERVES_UV, which is
> > determined by Configure.
>
> Looks like I might have been not very specific. The can of worms I
> meant is with the semantic, not implementation - things "not behaving
> as expected" vs things behaving "obviously wrong".

Can you give an example of things not behaving as expected? AFAICS using
long integers makes numeric semantics *more* predictable, by avoiding
conversion to floats for longer.

In any case, this has been an issue ever since perl started building on
64bit platforms with only a 53bit double type.

> This thread is one example of the "first category" - if one forgets
> what happens with `use integer', which is obviously a bug (BTW, is it
> reported yet?).

Not by me. With a perl with 32bit IVs I get

~% perl -E'
my $x = (1<<30); say $x;
$x <<= 1; say $x;
$x <<= 1; say $x;'
1073741824
-2147483648
0

I presume it's the final '0' you consider a bug, not the negative value?
I'm not sure I agree that's a bug, since perldoc integer says

| Finally, "use integer;" also has an additional affect on the bitwise
| operators. Normally, the operands and results are treated as
| unsigned integers, but with "use integer;" the operands and results
| are signed. This means, among other things, that ~0 is -1, and -2 &
| -5 is 6.
|
| Internally, native integer arithmetic (as provided by your C
| compiler) is used. This means that Perl's own semantics for
| arithmetic operations may not be preserved.

and a C program the does the same operations on a signed 32bit integer
gives the same results.

Ben

From: sln on 19 May 2010 19:56
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.

-sln
From: Peter J. Holzer on 20 May 2010 07:02
On 2010-05-19 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.

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?