View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Jan 12, 2019 9:14 am Post subject: MASK_UNDERFLOW@ |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Sat Jan 12, 2019 10:17 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Jan 13, 2019 10:28 am Post subject: |
|
|
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" |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon Jan 14, 2019 8:29 am Post subject: |
|
|
Dan
I would be interested to know the context in which an underflow is regarded as an error. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Jan 14, 2019 3:07 pm Post subject: |
|
|
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
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon Jan 14, 2019 5:16 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Jan 14, 2019 11:58 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Tue Jan 15, 2019 8:17 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Jan 15, 2019 9:49 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Jan 15, 2019 1:36 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Tue Jan 15, 2019 6:08 pm Post subject: |
|
|
Is it possible to send me the code? I would like to see the /64 /CHECK failure. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Wed Jan 16, 2019 4:42 am Post subject: Re: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Wed Jan 16, 2019 5:44 am Post subject: |
|
|
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 |
|
|
|