forums.silverfrost.com

PaulLaidler · 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@.

Sebastian · Joined: 20 Feb 2008 Posts: 177

mask_underflow is not an option since it affects numerical results (discussed in this thread or elsewhere in this forum).

DanRRight · Posted: Tue Mar 10, 2015 3:37 pm Post subject: Re:

PaulLaidler · Posted: Tue Mar 10, 2015 7:19 pm Post subject:

PaulLaidler · 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...

Sebastian · Joined: 20 Feb 2008 Posts: 177

DanRRight · 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.

Sebastian · Joined: 20 Feb 2008 Posts: 177

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.

DanRRight · 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.

Sebastian · Joined: 20 Feb 2008 Posts: 177

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.

DanRRight · 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.

Sebastian · Joined: 20 Feb 2008 Posts: 177

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.

DanRRight · 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.

Sebastian · Joined: 20 Feb 2008 Posts: 177

That would be awesome, though any constructive help for the problem is appreciated from anybody.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

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