forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incorrect evaluation of vector expressions

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1024

PostPosted: Tue Nov 20, 2018 4:48 pm    Post subject: Incorrect evaluation of vector expressions Reply with quote

The bugs reported here are akin to those that I recently reported in the thread http://forums.silverfrost.com/viewtopic.php?t=3892 . Here, I have a drastically simplified and short example code, and am able to shed some light on what the generated code is actually doing, as opposed to what it should have done.

The example source code:
Code:
program xpi
   implicit none
   integer, parameter :: nx = 2
   integer :: i, n = nx*4
   real :: x(4*nx) = (/ (1.0, 2.0, 3.0, 4.0, i=1,nx) /)
   real :: s

   s = sum((x(2:n-2:2)-x(3:n-1:2))**4)

   print *,s,' (expected: 83)'
end

The results that I obtained from FTN95 8.30.279:
Code:
-default-      26.3333
/opt           26.3333
/check         Internal compiler error
/checkmate     Internal compiler error

/64            21.0000
/64 /opt       21.0000
/64 /check      0.0000
/64 /checkmate  0.0000

Inspection of the /exp listings for some of the cases (where there is output and that output is not zero) shows that the 32-bit EXE actually computes
Code:
sum((u-v)**3/v),
and the 64-bit EXE actually computes
Code:
sum(v*(u-v)**3),
where
Code:
u = x(2:n-2:2)
and
Code:
 v = x(3:n-1:2),
instead of computing the requested result
Code:
sum((u-v)**4)
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5584
Location: Salford, UK

PostPosted: Tue Nov 20, 2018 5:01 pm    Post subject: Reply with quote

Many thanks. I will make a note of this.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 959
Location: Aerospace Valley

PostPosted: Wed Nov 21, 2018 2:00 am    Post subject: Reply with quote

don't forget the second espression from the other post quoted above where d (line 12) gave a FP error for 32bit

A mod of this code here with the form:

s = sum ((x(:n-3:2) - x(4:n:2))**4)

would test that too (and presumeably give a FP error)

I noted on the original 'big' probleme code that this expression starts with a ':' in the first term.
I wonder if that could relate to the problem too ?

maybe 1:n-3:2 would work ?

This is a good example of where the 'suck-it-and-see' method of diagnosing the problem (progressively weeding out the source in the 'good-old-fashioned' code elimination way) combines nivýcely with subsequent 'clever' debugging to understand exactly what is hapening.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 959
Location: Aerospace Valley

PostPosted: Wed Nov 21, 2018 2:01 am    Post subject: Reply with quote

mecej4 - in your single lines quoted at top you've pur **3 (twice) in error of **4 !!!
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1873
Location: Yateley, Hants, UK

PostPosted: Wed Nov 21, 2018 10:44 am    Post subject: Reply with quote

I wonder why it has taken so long to find this out?

Perhaps Holmes has the answer: "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."

Could it be that no-one has ever used this form of statement? Or if they did, the result didn't matter? Or perhaps they blithely assumed the wrong answer was correct? Certain predictions in climate science leap instantly to mind.

My own guess is that the first is the real answer. After all, traditionally one would do it with some sort of explicit loop. I would, perhaps in so doing revealing that there are some parts of Fortran 90 et seq. that haven't entered my consciousness, or that within days of writing the statement I wouldn't have a clue what it did! (That is, if I could).

On a serious note, is it the raising to the power where the problem lies? I suspect so, because converting to repeated multiplication gives 83. And there was me, thinking that 42 was the answer to life, the universe and everything ...

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1024

PostPosted: Wed Nov 21, 2018 11:01 am    Post subject: Re: Reply with quote

John-Silver wrote:
mecej4 - in your single lines quoted at top you've put **3 (twice) in error of **4 !!!
Blame not the messenger!

The compiler emits machine code for two loops for Line-8. The first loop calculates the array valued expression to the right of '='. The second loop sums up the elements of the temporary array that the first loop filled in.

Here are the 32-bit assembler instructions in the first loop generated for Line-8 of the source code.
Code:
Label     __N3
      fld       X[ebx*8+4]        # u = X(i+1)
      fsub      X[ebx*8+8]        # v = X(i+2), u - v
      fst       Temp@9            # u-v
      fmul      Temp@9            # (u-v)**2
      fmul      Temp@9            # (u-v)**3
      fdiv      X[ebx*8+8]        # (u-v)**3/v
      fstp      [eax+ebx*4]       # store element of temporary result array
      inc       ebx               # increment i
      cmp       ebx,Temp@7        # loop count reached?
      jle       __N3


If any of the elements of v happen to be zero, doing '/v' with such an element will cause an FP 0-divide exception.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 959
Location: Aerospace Valley

PostPosted: Fri Nov 23, 2018 2:57 am    Post subject: Reply with quote

ooer missus, after reading that and TRYING to understand it ... my cervical functioning is affected

_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group