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 

MASK_UNDERFLOW@

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Jan 12, 2019 9:14 am    Post subject: MASK_UNDERFLOW@ Reply with quote

Was it implemented in 64bits? Somewhere in my code happening underflow and there is no easy way to find this place, large code, lot of data, long execution time, hard to find when and how code starts producing semi-reasonable garbage.

Worst of all the underflow may happen in very distant place and this place will not reveal itself. The affected place hence will confuse you being absolutely legit code but it will generate crazy results. Hard to find this bug, it is rarely happening, you always forget about it and as a result you lose a lot of time.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Jan 12, 2019 10:17 am    Post subject: Reply with quote

MASK_UNDERFLOW@ has not been implemented for 64 bits (maybe it does not have the same meaning).

You can call PERMIT_UNDERFLOW@(0_2) in order to treat underflows as an error...

SUBROUTINE PERMIT_UNDERFLOW@(opt)
INTEGER(2) opt

opt = 0 treat underflows as an error otherwise use hardware to convert unerflows to zero.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Jan 13, 2019 10:28 am    Post subject: Reply with quote

Oh my...This revealed amount of roaches i can not believe! I will probably die before cleaning all of them. Thanks, Paul

Somebody probably can get great job using FTN95 by giving ad like this:

"Revealing your programming bugs in Fortran codes. 10 bugs per 1000 lines of code GUARANTEED or your money back" Smile
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Jan 14, 2019 8:29 am    Post subject: Reply with quote

Dan

I would be interested to know the context in which an underflow is regarded as an error.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Jan 14, 2019 3:07 pm    Post subject: Reply with quote

I have no tools to reveal such content. Looks like even PERMIT_UNDERFLOW@(0_2) does not catch everything.

By experience, the problems before happened when i ran the code with a lot of EXP(-A) when if A>70-80. These EXPs produce the numbers less then 1.e-38. To fix that i restrict A<70 and the errors disappear.

Currently i search for the bug which is causing similar problem but what causing it is unclear because all EXPonents are restricted as above. The call to PERMIT_UNDERFLOW@(0_2) stops debugger with the underflow error on the line which has legit code like this

Code:
   
          A = F * A + FF * B


with
A=1.3e-35 - real*4
B=2.d-37 - real*8
F =0.999 - real*8
FF=0.001 - real*8

Fun here is that A is far from being off range to become underflow. The F*A - too, and additionally the result of multiplication is real*8 so its range is 1.d-308 - way far from becoming the underflow number

The FF*B is 2.d-40 but also not underflow number because FF and B are real*8, this could be a problem only if they were real*4

The compiler confuses real*8 with real*4?

Such strange devilry bugs are sucking my time periodically
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Jan 14, 2019 5:16 pm    Post subject: Reply with quote

The following code runs without error and outputs a value of about 1e-35.

The REAL*4 value is converted to REAL*8 before multiplication and the result of the right hand side is converted from REAL*8 to REAL*4 for the assignment. You can observe this by using /EXPLIST when compiling.

Code:
IMPLICIT NONE
REAL*4 A
REAL*8 B,F,FF
CALL PERMIT_UNDERFLOW@(0_2)
A=1.3e-35
B=2.d-37
F =0.999d0
FF=0.001d0
A = F * A + FF * B
print*,A
end
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Jan 14, 2019 11:58 pm    Post subject: Reply with quote

No doubts that this extract works ok, I will not even check it myself. The trick is that something else in the code causing change of the state of FPU or some kind of corruption (debugger incorrectly displays results of logical functions for example, though this is still 6 months older version of compiler, will download newer today) and after that the code becomes crazy in the arbitrary place. The suspect #1 is some kind of underflow, isolating all possible such places helped before but I am still not successful.

Is just one call to PERMIT_UNDERFLOW@(0_2) at the beginning of the main program enough to trap underflows everywhere else?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jan 15, 2019 8:17 am    Post subject: Reply with quote

Dan

Yes one call at the beginning is enough.

I was thinking that in a large majority of computations, underflows are common and not a problem. They are just particular instances of round-off error and round-off error can rarely be avoided.

Certainly one can guard against unnecessary loss of precision as in the case of your example where a REAL*4 variable has been assigned to the result of a REAL*8 calculation and might later be used in another REAL*8 calculation.

If the program that you are working with contains an unwise mix of REAL*4 and REAL*8 variables then a quick fix is to use /DREAL on the FTN95 command line.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Jan 15, 2019 9:49 am    Post subject: Reply with quote

I am also surprised how and why underflow causes havoc in the code. This is very old problem. In /32 the call mask_underflow@() solved this problem. Here with /64 the PERMIT_UNDERFLOW@(.TRUE.) does not change anything

I can not use /dreal because already limited in RAM despite /64. This specific variable i still can afford making real*8. Will search further why this underflow error occurs, looking at 8.40 first
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Jan 15, 2019 1:36 pm    Post subject: Reply with quote

Got 8_40. Found no difference in my code diagnostics.

Trying other options, found that the /CHECK compiler option still does not work in /64. During run compiler finds the out of bound error but points on the line number which is the END statement. This will need me to scale back to 32 bits which is not always easy.

This could be still some my own error (like request of too much memory etc) as 32bit version works OK
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jan 15, 2019 6:08 pm    Post subject: Reply with quote

Is it possible to send me the code? I would like to see the /64 /CHECK failure.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Wed Jan 16, 2019 4:42 am    Post subject: Re: Reply with quote

DanRRight wrote:
... During run compiler finds the out of bound error but points on the line number which is the END statement. This will need me to scale back to 32 bits which is not always easy.

Given this slight uncertainty w.r.t. the exact line where an error occurs and the line highlighted in the debugger at an error breakpoint, which I have noticed myself occasionally, perhaps Dan can revisit the issue of which statement caused the underflow.

It would help if, when an underflow break occurs, F11 is pressed and the instructions surrounding the breakpoint and the register values are recorded.


Last edited by mecej4 on Wed Jan 16, 2019 11:32 am; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Jan 16, 2019 5:44 am    Post subject: Reply with quote

Paul, I'd love to prepare the simplest possible variant for you to look as I also have another problems with the code. Hope I will do that quick.

Mecej4 - yes, good idea, forgot about this issue which happened in the past very often
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 -> 64-bit 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