When is a number less than itself?

Hi folks,

Can I invite you to have a quick play with the code below and offer an opinion as to why the second loop always works, and the first one fails as often as it works. Seems to me both should always work. RELEASE, DEBUG and CHECKMATE builds all (mis)behave the same way.

I have occasionally had trouble with computations in logical tests before, if I remember correctly. Looks like a compiler bug to me.

Andy

        program descbound
        use calculator
        integer i
        pow = 0
        pow1 = 0
        pow2 = 0
        i = winio@ ('%2.3ob&')
        i = winio@ ('Enter an integer power of 10%cb%rd%cb&', pow)
        i = winio@ ('(Bogus) next highest power of 10%cb%`rd%cb&', pow1)
        i = winio@ ('(Correct) next highest power of 10%cb%`rd%cb&', pow2)
        i = winio@ ('%ff%nl%cn%^bt[Calculate]', calculate)
        stop
        end program descbound

        module calculator
        double precision, parameter :: ten = 1.0d+1
        integer pow, pow1, pow2
        double precision deciman, decimax
        contains
        integer function calculate ()
        calculate = 2
        deciman = ten** pow
        pow1 = 0
        do
          pow1 = pow1 + 1
          if (deciman .lt. ten** dble (pow1)) exit
        end do
        pow2 = 0
        do
          pow2 = pow2 + 1
          decimax = ten** dble (pow2)
          if (deciman .lt. decimax) exit
        end do
        call window_update@ (pow1)
        call window_update@ (pow2)
        return
        end function calculate
        end module calculator

Sparge,

Works better if you don't DBLE - it is legal to raise a DOUBLE PRECISION to an INTEGER power ....

(calculation of REALREAL is different to REALINTEGER ... the latter is better (at least as far as I understand it) and more precise).

Eddie

@Bruce: I shouldn't have said 'fail', sorry. I mean that the two numbers output in the main window should always be a) the same as each other and b) correct. What numbers did you enter for your hundred trials? And are you saing your two outputs were always the same?

(I'm Win XP SP3, Plato 4.4.0, FTN95 6.10.0)

@Eddie: interesting you should say that. The real code was using DBLE** INTEGER originally, and failing, so I changed it to DBLE** DBLE and it still failed. The only reason I tried taking the computation out of the logical test was so I could inspect the result!

Andy

Ran it again without DBLE, and it works for Bruce's fail cases - and I checked, original Sparge code fails for Bruce's list, but works for (some) other cases.

My I respectfully suggest that originally it was failing for some other reason, and when you went to DBLE, you corrected that reason inadvertently but introduced a new reason to fail? REALREAL uses logarithms (I think) REALINTEGER does something else. I suspect that repeated multiplication would give a better result than REALREAL, but worse than REALINTEGER .... but this is pure guess.

Eddie

Hi Bruce,

I'm not sure that REAL**(4000000) would be carried out by repeated multiplication, but I'm prepared to believe that FTN95 does it if the INTEGER power is small enough.

Is an INTEGER always exactly representable in floating point form? Certainly 1 is, and so is any even number that is an exact power of 2, such as 2, 4, 8 etc. Hence, in your list of (3,5,6,10,11,12,13) it's no coincidence that 1, 2, 4, 8 (and later 16, 32 etc) ought to work properly. Presumably, odd numbers and evens not a power of 2 may or may not work depending whether the approximation is lower or higher than the exact value. Missing from your list that would make 7, 9, 14 and 15 into 'lucky strikes', and the ones explicitly in your list 'strike outs' (apologies if I misused the term - I've only seen baseball once!). This assumes that the actual raising to the power is roundoff-error-free, which of course it isn't, but if the index is rounded, then the result cannot be exact.

Presumably when the power gets high enough, repeated multiplies are uneconomic, and the system goes into logarithm mode, although I wouldn't exclude the possibility that there is some other clever math at work. That would then result in some round ups, and some round downs, with some working and some not. Perhaps Paul or one of his colleagues can enlighten us!

Eddie

I don't have the time to comment on this right now but if you have the time and patience you can work out what FTN95 does with this by looking at the /explist.