perlop and integer docs are inconsistent about use integer

[p5pRT]

Migrated from rt.perl.org#22193 (status was 'resolved')

Searchable as RT22193$

[p5pRT]

From perlbug.amc+0@nicemice.net

I want to perform integer division. According to perldoc integer\, 4/3 is guaranteed to be 1 in the scope of use integer. But according to perldoc perlop\, "this doesn't mean everything is only an integer\, merely that Perl may use integer operations if it is so inclined".

One of those documents needs to be fixed. Which one? (The inconsistency exists in both 5.6.1 and 5.8.)

If use integer does not guarantee that 4/3 is 1\, then my next thought would be int(4/3). But I can't find any guarantees about the precision of floating-point division. Is 2121212121 exactly representable? Even if I knew that it were\, I see no guarantee that int(2121212121/707070707) is 3; maybe on some platforms it could come out as 2.99999... and get truncated to 2.

If use integer does not guarantee integer division\, then I guess my only hope for predictable integer division is Math​::BigInt. I don't need the bigness\, I just need predictable results for integers within a known range. I don't even need to know the range when I write the code\, if I can discover it at runtime. If the range is too small\, at least I can fail explicitly\, rather than risk getting silently wrong answers.

---

Flags​:   category=docs   severity=low

---

[p5pRT]

From @cwest

It was Wednesday\, May 14\, 2003 when Adam M. Costello took the soap box\, saying​: : I want to perform integer division. According to perldoc integer\, 4/3 : is guaranteed to be 1 in the scope of use integer. But according to : perldoc perlop\, "this doesn't mean everything is only an integer\, merely : that Perl may use integer operations if it is so inclined". : : One of those documents needs to be fixed. Which one? (The : inconsistency exists in both 5.6.1 and 5.8.)

Actually\, within the docs for the integer pragma you'll find consistent viewpoints with perlop.

  Note that this only affects how most of the arithmetic and   relational operators handle their operands and results\,   and not how all numbers everywhere are treated. Specifi-   cally\, "use integer;" has the effect that before computing   the results of the arithmetic operators (+\, -\, *\, /\, %\,   +=\, -=\, *=\, /=\, %=\, and unary minus)\, the comparison oper-   ators (\<\, \<=\, >\, >=\, ==\, !=\, \<=>)\, and the bitwise opera-   tors (|\, &\, ^\, \<\<\, >>\, |=\, &=\, ^=\, \<\<=\, >>=)\, the operands   have their fractional portions truncated (or floored)\, and   the result will have its fractional portion truncated as   well. In addition\, the range of operands and results is   restricted to that of familiar two's complement integers\,   i.e.\, -(2**31) .. (2**31-1) on 32-bit architectures\, and   -(2**63) .. (2**63-1) on 64-bit architectures. For exam-   ple\, this code

: If use integer does not guarantee that 4/3 is 1\, then my next : thought would be int(4/3). But I can't find any guarantees about : the precision of floating-point division. Is 2121212121 exactly : representable? Even if I knew that it were\, I see no guarantee that : int(2121212121/707070707) is 3; maybe on some platforms it could come : out as 2.99999... and get truncated to 2.

You need to always use the int() function if you intent to have every single number be an integer\, even in the face of the integer pragma.

  my $x = int 5.8;   my $x = int sqrt 2;

: If use integer does not guarantee integer division\, then I guess my only : hope for predictable integer division is Math​::BigInt. I don't need the : bigness\, I just need predictable results for integers within a known : range. I don't even need to know the range when I write the code\, if I : can discover it at runtime. If the range is too small\, at least I can : fail explicitly\, rather than risk getting silently wrong answers.

Well\, since the integer pragma is known to work expectedly with the division operator\, I think you're fine here.

  Casey West

-- Usenet is like a herd of performing elephants with diarrhea -- massive\, difficult to redirect\, awe-inspiring\, entertaining\, and a source of mind-boggling amounts of excrement when you least expect it. -- Gene Spafford

[p5pRT]

@cwest - Status changed from 'new' to 'resolved'

[p5pRT]

From @cwest

It was Wednesday\, May 14\, 2003 when Casey West took the soap box\, saying​: : It was Wednesday\, May 14\, 2003 when Adam M. Costello took the soap box\, saying​: : : I want to perform integer division. According to perldoc integer\, 4/3 : : is guaranteed to be 1 in the scope of use integer. But according to : : perldoc perlop\, "this doesn't mean everything is only an integer\, merely : : that Perl may use integer operations if it is so inclined". : : : : One of those documents needs to be fixed. Which one? (The : : inconsistency exists in both 5.6.1 and 5.8.) : : Actually\, within the docs for the integer pragma you'll find : consistent viewpoints with perlop.

On second thought\, perlop could be just a tad more helpful. Patch below.

  Casey West

-- Shooting yourself in the foot with BASIC (interpreted) You shoot yourself in the foot with a water pistol until your leg is waterlogged and rots off.

Inline Patch

```diff --- perl-current.orig/pod/perlop.pod Sun May 11 16:27:03 2003 +++ perl-current/pod/perlop.pod Wed May 14 16:45:58 2003 @@ -2030,8 +2030,8 @@ use integer; you may tell the compiler that it's okay to use integer operations -(if it feels like it) from here to the end of the enclosing BLOCK. -An inner BLOCK may countermand this by saying +(see L for a detailed explanation) from here to the end of +the enclosing BLOCK. An inner BLOCK may countermand this by saying no integer; ```

[p5pRT]

From amc+bxxcce@nicemice.net

Casey West \perlbug\-followup@&#8203;perl\.org wrote​:

you may tell the compiler that it's okay to use integer operations -(if it feels like it) from here to the end of the enclosing BLOCK. -An inner BLOCK may countermand this by saying +(see L\ for a detailed explanation) from here to the end of +the enclosing BLOCK. An inner BLOCK may countermand this by saying

Thanks! You might also want to remove the words "that it's okay"\, leaving the first sentence as​:

  you may tell the compiler to use integer operations (see L\   for a detailed explanation) from here to the end of the enclosing   BLOCK.

That seems more in line with the integer document.

You might also want to make a similar change a few lines later\, where it says​:

  Note that this doesn't mean everything is only an integer\, merely   that Perl may use integer operations if it is so inclined. For   example...

You might want to remove the second half of that sentence\, which I think is more misleading than helpful\, leaving​:

  Note that this doesn't mean everything is only an integer. For   example\, even under "use integer"\, if you take the sqrt(2)\, you'll   still get 1.4142135623731 or so.

Alternatively\, the second half of the first sentence could be reworded to be more in line with the integer document\, something like​:

  Note that this doesn't mean everything is only an integer\, merely   that Perl will use integer operations for most arithmetic operators.   For example...

Of course\, before making any of these changes\, you need to be sure that the integer doc\, and not the perlop doc\, is the authority on this matter.

AMC

[p5pRT]

From @cwest

It was Thursday\, May 15\, 2003 when Adam M. Costello took the soap box\, saying​: : Casey West \perlbug\-followup@&#8203;perl\.org wrote​: : : > you may tell the compiler that it's okay to use integer operations : > -(if it feels like it) from here to the end of the enclosing BLOCK. : > -An inner BLOCK may countermand this by saying : > +(see L\ for a detailed explanation) from here to the end of : > +the enclosing BLOCK. An inner BLOCK may countermand this by saying : : Thanks! You might also want to remove the words "that it's okay"\, : leaving the first sentence as​: : : you may tell the compiler to use integer operations (see L\ : for a detailed explanation) from here to the end of the enclosing : BLOCK. : : That seems more in line with the integer document.

True.

: You might also want to make a similar change a few lines later\, where it : says​: : : Note that this doesn't mean everything is only an integer\, merely : that Perl may use integer operations if it is so inclined. For : example... : : You might want to remove the second half of that sentence\, which I think : is more misleading than helpful\, leaving​: : : Note that this doesn't mean everything is only an integer. For : example\, even under "use integer"\, if you take the sqrt(2)\, you'll : still get 1.4142135623731 or so. : : Alternatively\, the second half of the first sentence could be reworded : to be more in line with the integer document\, something like​: : : Note that this doesn't mean everything is only an integer\, merely : that Perl will use integer operations for most arithmetic operators. : For example...

I like the second.

: Of course\, before making any of these changes\, you need to be sure : that the integer doc\, and not the perlop doc\, is the authority on this : matter.

Yes\, it is. :-)

  Casey West

-- "Windows NT addresses 2 Gigabytes of RAM which is more than any application will ever need." -- Microsoft\, 1992\, on the development of Windows NT

Inline Patch

```diff --- perl-current.orig/pod/perlop.pod Sun May 11 16:27:03 2003 +++ perl-current/pod/perlop.pod Thu May 15 10:44:14 2003 @@ -2029,17 +2029,17 @@ use integer; -you may tell the compiler that it's okay to use integer operations -(if it feels like it) from here to the end of the enclosing BLOCK. -An inner BLOCK may countermand this by saying +you may tell the compiler to use integer operations +(see L for a detailed explanation) from here to the end of +the enclosing BLOCK. An inner BLOCK may countermand this by saying no integer; which lasts until the end of that BLOCK. Note that this doesn't -mean everything is only an integer, merely that Perl may use integer -operations if it is so inclined. For example, even under C, if you take the C, you'll still get C<1.4142135623731> -or so. +mean everything is an integer, merely that Perl may use integer +operations for most operators. arithmetic, comparison, bitwise, +and range operators. For example, even under C, if you take +the C, you'll still get C<1.4142135623731> or so. Used on numbers, the bitwise operators ("&", "|", "^", "~", "<<", and ">>") always produce integral results. (But see also ```

[p5pRT]

From amc+6xuwwu@nicemice.net

Casey West \perlbug\-followup@&#8203;perl\.org wrote​:

+mean everything is an integer\, merely that Perl may use integer +operations for most operators. arithmetic\, comparison\, bitwise\, +and range operators. For example\, even under C\\, if you take

There appears to be a typo in there. In any case\, my main concern is to remove the language that suggests that the behavior is unpredictable (like "may use") and replace it with firm language (like "will use"). As long as it's clear that the behavior is predictable\, I don't care whether any of the details are summarized here in perlop\, since we now have a cross-reference to perldoc integer.

AMC

[p5pRT]

From @cpansprout

On Thu May 15 07​:51​:55 2003\, cwest wrote​:

[...]

Thank you. I’ve applied this\, without the typos\, as 3eab78e37a32aa79c954c0d957e1e37964cc9cc4.

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'