forums.silverfrost.com

sparge · Joined: 11 Apr 2005 Posts: 371

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

brucebowler · Guest

I've just run it 100 times with no failure of either loop...

Win XP, Plato 4.3.0, Ftn95 6.00.0

LitusSaxonicum · Posted: Wed May 11, 2011 10:04 pm Post subject:

Sparge,

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

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

Eddie

sparge · Joined: 11 Apr 2005 Posts: 371

@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

brucebowler · Guest

LitusSaxonicum · Posted: Thu May 12, 2011 3:35 pm Post subject:

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? REAL**REAL uses logarithms (I think) REAL**INTEGER does something else. I suspect that repeated multiplication would give a better result than REAL**REAL, but worse than REAL**INTEGER .... but this is pure guess.

Eddie

brucebowler · Guest

LitusSaxonicum · Posted: Thu May 12, 2011 11:12 pm Post subject:

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

PaulLaidler · Posted: Fri May 13, 2011 6:38 am Post subject:

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.