Intel Fortran Manual Error

[prop_design]

hi,

i just noticed there is an error in the intel fortran manual. on page 102 it says:

DO loop index variable 9,223,372,036,854,775,807= 2**(63-1)

That can't be right. The number shown equates to 2**(64-1)

I wonder if some other entries are also wrong. You have 2**(31-1) and 2**(63-1) in the same section, where you would expect 2**(32-1) and 2**(64-1). These are off by exactly half of what 32 and 64bit binary numbers would be.

ps; i'm not sure what the version number of the manual is. i don't see it listed. it's a fairly recent version though. there is a line that says the following:

This document is for version 2021.8 of Intel® Fortran Compiler Classic (ifort) and version 2023.0 of Intel®Fortran Compiler (ifx).

Another line says; Notice revision #20201201

[mecej4]

---

@prop_design wrote:

i just noticed there is an error in the intel fortran manual. on page 102 it says:

DO loop index variable 9,223,372,036,854,775,807= 2**63-1

That can't be right. The number shown equates to 2**64-1

I wonder if some other entries are also wrong. You have 2**31-1 and 2**63-1 in the same section, where you would expect 2**32-1 and 2**64-1. These are off by exactly half of what 32 and 64bit binary numbers would be.

Sorry, you are wrong on many counts. If you click on this WolframAlpha link, you can easily check that "9,223,372,036,854,775,807= 2**63-1" is correct. Perhaps you overlook the fact that n-bit signed integers cover the range -m to +(m-1), where m = 2^(n-1).

Here is a page with a copy of an older Intel Fortran manual, with the ranges of different integer types displayed in a convenient-to-view format:

     https://www.cita.utoronto.ca/~merz/intel_f10b/main_for/mergedProjects/bldaps_for/common/bldaps_datarepov.htm

Here is an alternative proof that your contention "The number shown equates to 2**64-1" is wrong, without doing long multiplications.

Your claim "The number shown equates to 2**64-1" is equivalent to "9,223,372,036,854,775,807 + 1 = 2**64".

The sum on the left, i.e., 9,223,372,036,854,775,807 + 1, ends with the decimal digit 8.

The number on the right, 2⁶⁴, equals (2⁴)¹⁶ = 16¹⁶.

Any decimal number whose least significant digit is 6, when raised to any positive integer power, gives a result that also has 6 as its least significant digit. The result on left of the claimed equality (after adding +1 to both sides), however, ends with 8, as stated earlier. The equality claim is refuted.

---

Here is a short program that may help you explore the issues using 1-byte signed integers instead of 8-byte integers.

program doloop
   implicit none
   integer*1 ilo,ihi
   integer i
   ilo=-huge(ilo)-1
   ihi=+huge(ihi)
   print *,ilo,ihi
   i = ilo
   do while (i <= ihi)
      print '(3i6)',i,i*i,2*i-1
      i = i+1
   end do
end

After running and noting the behavior of the program, change the variable i to a 1-byte integer and see what that does to the running of the program.

[prop_design]

thanks for this info. i will study it. what your saying is weird though, because i did the calculations in Mathcad (about a month or two ago) and it shows what I posted. so i'm not sure what is going on. also, the microsoft help shows the difference for signed and unsigned and it's not a big difference. the difference from the intel manual is 50%.

[mecej4]

---

@prop_design wrote:

... the microsoft help shows the difference for signed and unsigned and it's not a big difference. the difference from the intel manual is 50%"

---

Sorry, I do not understand what differences you are writing about, and which Microsoft help you are referring to.

In these discussions, one needs to keep in mind that finite-precision computer arithmetic does not always obey the rules of mathematics. As a consequence, when arguments are stated, one has to make it clear whether some associated calculations were made using classical mathematics or computer arithmetic.

[prop_design]

hi,

unfortunately, it's not very clear to me. i attached a document with calculations i did awhile ago. in an attempt to figure out what was going on. it seems to be a dead end. however, it did make me realize there seems to be an error in the intel manual. unless of course, i'm just hopelessly lost.

the document looks at various definitions I found of the supposed limit. none of which even come close to the limit I'm experiencing. however, that topic is in a different thread. i made this thread just to point out an issue with the intel user manual.

[prop_design]

maybe i confused you. i added brackets to my original post. the number you showed in your link wasn't the number i meant. i can see where my original post wasn't clear. i literally copied that from the intel manual though. in any event, maybe the updated post explains what i mean better.

[JohnNichols]

The beauty of using LISP is you learn that the brackets are really important.  Fortran tends to get sloppy and not use them and rely on the standard rules of math conventions.  You half used brackets which is dangerous in long Fortran equations. 

Here is a Fortran output for the equation 

The equation is Y = ((X**N)-1) in and in LISP FORM  (setq Y  (- (** X N) 1)) of course you can place any X and N within reason, but you need double precision to hold the output.  The number you seek is 2 to the 63rd power and for some reason you subtract one.  Both are sort of randomish numbers.  

It is always best to check your math with Fortran first.  EXCEL and other programs are number limited as @mecej4 kindly explained. 

[mecej4]

Sorry, you made things worse by adding misplaced parentheses to your original post.

      2**(63-1) means 2^63-1 = 2⁶²

The number 2 raised to any integer exponent > 1 is an even number, so its decimal representation cannot end with the digit 7.

Here is the corresponding page of the online version of the latest (2023-1) compiler reference manual, which you have an older PDF version of:

https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2023-1/compiler-limits.html

There is a table shortly after the title, and a row in the table that says:

DO loop index variable           9,223,372,036,854,775,807= 2**63-1

 Do you think that there is something wrong with this entry in the table? Do you recognize that this is the upper limit on the loop count, and that DO loop index variables can start with a large negative number as the starting value, as I illustrated with the short program in my earlier reply?

The exact nature of the computations that are performed for a DO loop with a loop-control triplet of integers is specified by the standard. There is a further "guard-rail" that the program source is invalid if during the course of those calculations an integer overflow occurs.

[prop_design]

i think there is a lot of confusion. i didn't program this in fortran. i was just trying to understand what the limit is. i used Mathcad. In Mathcad, there is no problem calculating 2^(63-1). the pdf file that I attached is a copy of the Mathcad file. it also has the references etc. plus a bunch of comparisons. i still think the intel manual doesn't make sense. their statement that:

9,223,372,036,854,775,807= 2**63-1

if you correct it, 9,223,372,036,854,775,807= 2**(63-1), for clarity. however, that number equals half of what they are saying. that's why i say i think there is an error. they probably meant 2**(64-1). as that equals 9,223,372,036,854,775,807. i think the other parts where they say 2**31-1 really should be 2**(32-1) as well. basically, a lot of the numbers in the manual seem to be off by half.

[mecej4 · Accepted solution]

---

@prop_design wrote:

...i still think the intel manual doesn't make sense. their statement that:

9,223,372,036,854,775,807= 2**63-1

if you correct it, 9,223,372,036,854,775,807= 2**(63-1), for clarity.

---

 Still wrong. That line needs no correction, and is perfectly clear as it is, because the ** operator has higher priority than the - operator.

Let me try another way to persuade you. For now, let us ignore Fortran, DO loops, etc., and examine that single line of the manual.

Open the Windows Calculator program, and put it in "scientific" mode. Press "2", then "x^y", then "63", then "-", then "1", then "=". You will see the number 9,223,372,036,854,775,807, which proves that the line from the Intel manual is fine. Any other calculator with the capability to handle that range of integers will do, as well.

Next, open the Windows Calculator program again, and put it in "programmer mode".  Press "HEX", then enter "7FFF FFFF FFFF FFFF" (don't type in the blanks, which I have inserted to help you count the number of "F's). This is the largest positive integer that can be represented with 64 bits . What does the "DEC" line show?

Perhaps you can find someone who agrees with your claim and can state arguments in support, which you can report here. The chances of that happening are, in my opinion, close to zero.

[Steve_Lionel]

@prop_design , I am baffled that you continue to make this error. @mecej4 is correct. 2**63 is 9,223,372,036,854,775,808. Subtract one from that and you get 9,223,372,036,854,775,807. This is the largest positive 64-bit integer. While I have found other numerical errors in the Intel documentation, this isn't one of them. The only thing I can think of is that you are assuming unsigned integers, but since Fortran doesn't have those, and a DO loop iteration count can be computed to be negative, 2**63-1 (or (2**63)-1) is the correct value.

[prop_design]

thanks guys,

really weird. i put what you said into mathcad and it gives the right answer. so the intel manual is 2^63-1. mathcad gives 2^63 as the same number. whether i subtract one or not. the confusion started from other documents online. i get what you are saying though. thanks for clarifying

[mecej4]

Searching the web turned up this link about Mathcad from the year 2008, which discusses something quite similar with integers near the limit of what can be represented in 32 bits. Specifically, the complaint was that the version of Mathcad in use at that time gave a negative value for 2³¹. We seem to be experiencing a redux of the same problem near the limit of 64 bits, fifteen years later.

[prop_design]

the version i have of mathcad is old and hasn't changed much. mathcad prime is the new stuff. however, from what i've read, and the licensing, i'm not interested in it. however, i don't think this was mathcad's fault. i just got confused from the get go and happened to be getting numbers that looked right (that aspect may be mathcad's fault though). i am updating the files with the correct formula (that you explained).

as for what i've been seeing in testing. i think there might be several things going on. i basically can run 1.0d5 on any code and it's fast. i've been using that for decades. i have 16gb of memory and that seems to be pretty close to 1.0d5 (maybe just a coincidence, but I'm starting to wonder if that's significant). depending on the code, the  limit i'm hitting is 1.0d6, 1.0d7, or 2.0d8. I think the last one might be with allocatable arrays. not 100% sure, at the moment. in any event, they are all below the 32gb limit. i tried increasing the page file but it didn't seem to do anything. i'm wondering if i actually had 64gb of memory, maybe all this would be a lot different. as it stands, 1.0d5 runs as expected. if i do nothing but switch to allocatable arrays it slows down. so the gflops are lower than they should be. that's all i know at the moment. i'll post more on the other thread, if i find out anything useful.