View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Fri Mar 06, 2015 9:07 am Post subject: |
|
|
This problem is "fixed" if you call mask_underflow@() as the first executable statement in the main program. In the light of all the discussion about masking underflows, I am not sure that this is a good fix but it may serve your purpose.
Basically, Windows API calls (from ClearWin+) sometimes require a clean floating point stack (when underflows are unmasked which is the default).
A better solution might be to do the masking only for the Windows API dlls but this would require some tricky programming (for us and may not be possible for you). However, in theory you can handle the underflows and denormals yourself by using TRAP_EXCEPTION@ and CLEAR_FLOAT_UNDERFLOW@. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Tue Mar 10, 2015 3:12 pm Post subject: |
|
|
mask_underflow is not an option since it affects numerical results (discussed in this thread or elsewhere in this forum).
Quote: | Basically, Windows API calls (from ClearWin+) sometimes require a clean floating point stack (when underflows are unmasked which is the default). |
We've tried various clears already (FCLEX...) inside the callback, but there does not seem to be a problem inside the callback routine except for the generated underflow triggering a "bad" exception handler that crashes the program. It strangely seems related to the %og control (which doesn't have any real functionality in the test case).
Any chance this and similar probmels are fixed for the next release?
Thanks for the help! |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Mar 10, 2015 3:37 pm Post subject: Re: |
|
|
Sebastian wrote: |
Any numerical calculation, any gui-to-data conversion, anything that expects numbers to pass a "equal to zero" test with a non-denormal boundary will not work as it did before. This is unacceptable.
|
Not quite got the real dangers. Can you elaborate that on real example? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Tue Mar 10, 2015 7:19 pm Post subject: |
|
|
Quote: | Any chance this and similar problems are fixed for the next release |
I will log this for investigation but a fix before the next release seems unlikely. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Wed Mar 11, 2015 8:55 am Post subject: |
|
|
There is an undocumented function that may be useful in this context.
It resets the floating point stack (includes emitting finit and fround) and clears the exception record. It does not emit the fclex instruction.
This is how it is declared and called...
Code: | c_external FPRESET@ '_fpreset'
call FPRESET@()
|
|
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Thu Mar 12, 2015 11:37 am Post subject: Re: |
|
|
PaulLaidler wrote: | There is an undocumented function that may be useful in this context. |
Thanks, though I could not get it to avoid the crash. The fpu stack/cw/sw seems just fine in itself when looking at the registers and disassembler, it's the exception handler (which is outside of user code/availability) that crashes the application, and which seems to behave differently whether there's an %og control or not (the latter case doesn't crash at all...).
Quote: | Not quite got the real dangers. Can you elaborate that on real example? |
As I said you can construct any example where multiplying two small numbers results in a different value depending on the mask setting. Changing the behaviour of tested code in that way may or may not be a "danger" to you. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Thu Mar 12, 2015 1:04 pm Post subject: |
|
|
Well, i can not construct such example which would be considered as a valid Fortran and not a programmer's fault intentionally touching gray area of denormals and asking for trouble, why i am asking for example. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Fri Mar 13, 2015 11:03 am Post subject: |
|
|
Gradual underflow is beneficial or crucial for some types of algorithms.
Feel free to read on
http://www.cs.berkeley.edu/~wkahan/ARITH_17U.pdf
and similar. This may or may not be an obvious or hidden problem in your code when changing the underflow mechanics. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Mon Mar 16, 2015 10:09 pm Post subject: |
|
|
It just confirmed my point. All the examples supplied there had some (very small, completely negligible) value in the past when single and double precision arithmetics was way different in CPU speed. Last thing - double requirement for the memory size of double precision values - will die soon too when Silverfrost makes 64 bit compiler with its eventually 4 billion times larger memory limits. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Tue Mar 17, 2015 12:19 pm Post subject: |
|
|
The relevance is not regarding speed or memory consumption but numerical precision. As I said if it's not a problem in your code then that's fine, I can't state the same for huge amounts of legacy code that may be even ever-unnoticedly use the properties of denormals' precision.
Either way if you really want to continue the discussion please open a new thread and try not to derail this one which is about a pretty obvious and reproducable bug with default compiler settings that we'd really like to get fixed rather than worked around since it hits us every now and then pretty hard. Thanks. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Mar 17, 2015 1:23 pm Post subject: |
|
|
And what I was talking about? You get precision and don't lose speed while memory is not an issue to you if you move your stuff to double or extra precision and the problem is solved while the bug is investigated. I am also interested in solving all sorts if crashes and slowdowns associated with underflows. I pulled my hairs due to that for first time 20 years back with exp(-x) while x-->100. And 2 years back with multithreading. And as recent as a month ago. But in my recent case crash took place when I incorrectly used real*4, real*8 and real*10
Interesting if compile crashing code with Intel compiler and Clearwin. Does it crash? Can anyone with Intel IVF confirm? If not then why don't take Intel's solution, Paul? Is it possible to disassemble Intel's code? If underflows is design issue of FTN95 then default has to be changed to the one like in Intel, i.e. to ignore the underflows. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Tue Mar 17, 2015 5:54 pm Post subject: |
|
|
This is *not* limited to single precision, and speed is not an issue anyways. And it's not a bug. Really would appreciate not hijacking this thread again though. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Mar 17, 2015 6:33 pm Post subject: |
|
|
ROTFL. Whatever. But is this your OWN personal thread? With your over-demanding attitude I'd better put you on ignore. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Wed Mar 18, 2015 7:22 am Post subject: |
|
|
That would be awesome, though any constructive help for the problem is appreciated from anybody. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Mar 18, 2015 11:37 am Post subject: |
|
|
Sebastian and Dan,
I think it is often good to have comments that don't agree with the main part of the thread. They can identify a different way of looking at the problem, which could prompt an alternative path for solving it.
While I don't agree with Dan on a number of issues, I do find his different approach to be helpful in understanding the problem and giving it some context.
I look forward to the diversity of views form all users of the forum.
John |
|
Back to top |
|
|
|