Fortran - Processor-dependent constants

Author

Processor-dependent constants

Gus Gassmann

2004-05-12, 9:09 pm

I am working on an old f77 routine that sets a bunch of processor-
dependent constants, trying to convert it (portably) to f90. Most of
the stuff has intrinsics, such as EPSILON, HUGE and TINY, but
there is one that has me stumped: machpar(9) = 0 if underflow is
non-fatal, 1 if fatal. Is there a way to test for this condition without

crashing the program? Or, even better, is there mandated behaviour
in f90 one way or the other?

Thanks!

David Ham

2004-05-12, 9:09 pm

On Wed, 12 May 2004 11:07:45 GMT
Gus Gassmann <hgassman@mgmt.dal.ca> wrote:

> I am working on an old f77 routine that sets a bunch of processor-
> dependent constants, trying to convert it (portably) to f90. Most of
> the stuff has intrinsics, such as EPSILON, HUGE and TINY, but
> there is one that has me stumped: machpar(9) = 0 if underflow is
> non-fatal, 1 if fatal. Is there a way to test for this condition
> without
>
> crashing the program? Or, even better, is there mandated behaviour
> in f90 one way or the other?

Fortran does not specify by default any response to any floating point
exception (including overflow) or any way to deal with them. However,
there is a Technical Report (a sort of standardised extenstion to
Fortran 95) which has been incorporated in Fortran 2003 which implements
functionality related to the ieee-754 floating point standard.

On compilers which support this (try "use ieee_exceptions") then the
ieee_exceptions module provides the subroutine ieee_get_halting_mode. In
addition, if the platform supports changing the halting behaviour (which
you can check with the function ieee_support_halting) then you can use
the subroutine ieee_set_halting_mode to specify the overflow behaviour.

David

Richard Maine

2004-05-12, 9:09 pm

Gus Gassmann <hgassman@mgmt.dal.ca> writes:

> I am working on an old f77 routine that sets a bunch of processor-
> dependent constants, trying to convert it (portably) to f90. Most of
> the stuff has intrinsics, such as EPSILON, HUGE and TINY, but
> there is one that has me stumped: machpar(9) = 0 if underflow is
> non-fatal, 1 if fatal. Is there a way to test for this condition without
>
> crashing the program? Or, even better, is there mandated behaviour
> in f90 one way or the other?

David gave you the formal answers (about f90/f95 not specifying, and the
TR optionally providing ways to query and control it - though the option
is the proceessors.).

But for the case of underflow in particular, I'll note that processors
that make it fatal by default are pretty unusual. As in I can't
recall one off the top of my head. So, although not guaranteed,
I'd say that non-fatal is a pretty darned good guess on this one.
I doubt you will go wrong by guessing that.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Gerry Thomas

2004-05-12, 9:21 pm

"Gus Gassmann" <hgassman@mgmt.dal.ca> wrote in message
news:40A20559.1699FCCD@mgmt.dal.ca...
> I am working on an old f77 routine that sets a bunch of processor-
> dependent constants, trying to convert it (portably) to f90. Most of
> the stuff has intrinsics, such as EPSILON, HUGE and TINY, but
> there is one that has me stumped: machpar(9) = 0 if underflow is
> non-fatal, 1 if fatal. Is there a way to test for this condition without
>
> crashing the program? Or, even better, is there mandated behaviour
> in f90 one way or the other?
>
> Thanks!
>

I'd look here for good discussions of how to respond to underflows in
floating point arithmetic:
Coonen, J. T. 1981. Underflow and the denormalized numbers. Computer 14, 3
(Mar.), 75-87

Demmel, J. 1984. Underflow and the reliability of numerical software. SIAM
J. Sci. Stat. Com-

put. 5, 4 (Dec.), 887-919

Hauser, J.R. 1996. Handling Floating-Point Exceptions in Numeric Programs.
ACM Trans.Prog. Langs. & Sys. 18, 3 (Mar), 139-174

--
E&OE

Ciao,
Gerry T.
______
"Competent engineers rightly distrust all numerical computations and s

corroboration from alternative numerical methods, from scale models, from
prototypes, from experience... ." -- William V. Kahan.

Herman D. Knoble

2004-05-13, 10:32 am

Gus: Several people have answered with respect to the underflow
part of your question.

Here's and an example where ignoring an underflow (with underflow results
set to zero) will cause a wrong answer on a PC platform:

real :: x, y, z
x=1.1E-38
y=1.1E+38
z=(((x*x)*y)*y)*123456.0
print *, "z=",z
end

The result, z, may be displayed as zero because of the underflow (x*x), but should
be 123456.0

Skip Knoble

On Wed, 12 May 2004 11:07:45 GMT, Gus Gassmann <hgassman@mgmt.dal.ca> wrote:

-|I am working on an old f77 routine that sets a bunch of processor-
-|dependent constants, trying to convert it (portably) to f90. Most of
-|the stuff has intrinsics, such as EPSILON, HUGE and TINY, but
-|there is one that has me stumped: machpar(9) = 0 if underflow is
-|non-fatal, 1 if fatal. Is there a way to test for this condition without
-|
-|crashing the program? Or, even better, is there mandated behaviour
-|in f90 one way or the other?
-|
-|Thanks!

Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818 Fax:+1 814 863-7049

Gerry Thomas

2004-05-13, 12:40 pm

"Herman D. Knoble" <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote in message
news:1ut6a0ttu8elqsqscr0thpbl76ktc48j48@
4ax.com...
> Gus: Several people have answered with respect to the underflow
> part of your question.
>
> Here's and an example where ignoring an underflow (with underflow results
> set to zero) will cause a wrong answer on a PC platform:
>
> real :: x, y, z
> x=1.1E-38
> y=1.1E+38
> z=(((x*x)*y)*y)*123456.0
> print *, "z=",z
> end
>
> The result, z, may be displayed as zero because of the underflow (x*x),
but should
> be 123456.0

All this shows is that the programmer (you excepted) fails to appreciate
that:
1. Valid programs are not guaranteed to produce valid answers
2. In fp arithmetic both summation and multiplication are commutative and
nonassociative, Infinities and NaNs excepted.

So while z=(((x*x)*y)*y)*123456.0 might underflow, z=(x*x)*(y*y)*123456.0
might overflow, and z=(x*y)**2*123456.0 might be valid., etc.
--
E&OE

Ciao,
Gerry T.

James Giles

2004-05-13, 12:40 pm

Herman D. Knoble wrote:
> Gus: Several people have answered with respect to the underflow
> part of your question.
>
> Here's and an example where ignoring an underflow (with underflow results
> set to zero) will cause a wrong answer on a PC platform:
>
> real :: x, y, z
> x=1.1E-38
> y=1.1E+38
> z=(((x*x)*y)*y)*123456.0
> print *, "z=",z
> end
>
> The result, z, may be displayed as zero because of the underflow (x*x),
> but should be 123456.0

Well, the correct answer is not 123456.0, the correct answer is
about 180751.9. Mathematically, the expression is the same as
1.1^4 * 123456.0. Interestingly, many implementations get the
right answer even though they do underflow silently to zero.
This is because they perform the intermediate calculations
in double-extended, which has a much wider exponent range.
The output of the above program run with CVF and the default
floating-point options results with:

z= 180751.9

--
J. Giles

Gus Gassmann

2004-05-13, 2:33 pm

"Herman D. Knoble" wrote:

> Gus: Several people have answered with respect to the underflow
> part of your question.
>
> Here's and an example where ignoring an underflow (with underflow results
> set to zero) will cause a wrong answer on a PC platform:
>
> real :: x, y, z
> x=1.1E-38
> y=1.1E+38
> z=(((x*x)*y)*y)*123456.0
> print *, "z=",z
> end
>
> The result, z, may be displayed as zero because of the underflow (x*x), but should
> be 123456.0

Understood.

I am not worried about getting zero instead of 180751.9.
(Really! I expect the routines to be constructed with enough
care that this does not happen.)

What I am worried about is getting no answer at all
because the program crashed. The reason why this is
important is that I compute row residuals that ought
to be zero, but due to rounding may be slightly off.
Underflow is kind of expected, crashes aren't...

Gerry Thomas

2004-05-13, 2:33 pm

"Gus Gassmann" <hgassman@mgmt.dal.ca> wrote in message
news:40A3AC91.DCFDA4B8@mgmt.dal.ca...
[...]

> I am not worried about getting zero instead of 180751.9.
> (Really! I expect the routines to be constructed with enough
> care that this does not happen.)
>
> What I am worried about is getting no answer at all
> because the program crashed. The reason why this is
> important is that I compute row residuals that ought
> to be zero, but due to rounding may be slightly off.
> Underflow is kind of expected, crashes aren't...
>
>

So mask underflow on your processors control word. It's simple to do.

--
E&OE

Ciao,
Gerry T.

Richard Maine

2004-05-13, 3:32 pm

"Gerry Thomas" <gfthomas@sympatico.ca> writes:

> So mask underflow on your processors control word.

From the original post in the thread, Gus Gassman wrote:
[color=darkred]

I leave any deductions about the relationship of these two
quotes as an exercise for the reader.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

beliavsky@aol.com

2004-05-13, 3:32 pm

Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
>Gus: Several people have answered with respect to the underflow
>part of your question.
>
>Here's and an example where ignoring an underflow (with underflow results
>set to zero) will cause a wrong answer on a PC platform:
>
>real :: x, y, z
>x=1.1E-38
>y=1.1E+38
>z=(((x*x)*y)*y)*123456.0
>print *, "z=",z
>end
>
>The result, z, may be displayed as zero because of the underflow (x*x),
but should
>be 123456.0

Only if you replace the "1.1" with "1.0" above, which is what
I think you intended.

Gerry Thomas

2004-05-13, 3:32 pm

"Richard Maine" <nospam@see.signature> wrote in message
news:m1hduk9p64.fsf@macfortran.local...
> "Gerry Thomas" <gfthomas@sympatico.ca> writes:
>
>
> From the original post in the thread, Gus Gassman wrote:
>
>
> I leave any deductions about the relationship of these two
> quotes as an exercise for the reader.
>

The thread relates to processor-dependent parameters, and what he has to do
is nonportably processor dependent and beyond Fortran.

--
E&OE

HTH,
Gerry T.

Gerry Thomas

2004-05-13, 3:32 pm

"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> wrote in message
news:40a3be81$1_1@news.binaries.net...
>
> Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
results[color=darkred]
> but should
>
> Only if you replace the "1.1" with "1.0" above, which is what
> I think you intended.
>

I agree, Skip is a lot more interested in helping than the petty
one-upmanship of this burlesque.

--
E&OE

Ciao,
Gerry T.

Richard Maine

2004-05-13, 3:32 pm

"Gerry Thomas" <gfthomas@sympatico.ca> writes:

> The thread relates to processor-dependent parameters, and what he has to do
> is nonportably processor dependent and beyond Fortran.

See the numeric inquiry intrinsics added in f90. Their sole purpose
is to allow Fortran programs to portably determine several
processor-dependent parameter values while staying within the
Fortran standard. Portable numerics is important to some of us
in the standards business. It is also processor-dependent
what machine instructions are used to multiply two floating
point numbers, but that doesn't mean that the Fortran standard
can't provide a portable way of denoting such multiplication.

Indeed, the OP did use several of the intrinsics for some of the
processor-dependent parameters, as noted in his original post.
However, he was unable to find a corresponding intrinsic for the one
parameter he asked about.

As other posters have pointed out, the IEEE TR, which is part of
Fortran in the f2003 DIS, has ways to portably address that
(though as I pointed out, it is a bit of overkill in practice
for underflow - I think some of the posters got

and
thought that the request was about overflow.)

If Fortran is defined as f77, then I guess I'd agree that this
is all beyond Fortran. Fortunately for the OP, he specifically
mentioned porting to f90, which provides more portability in
such things than f77 did (and the IEEE TR adds yet a bit
more - I'd mention "continual improvement", but I dislike that
management jargon. :-))

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Gene Wagenbreth

2004-05-13, 4:32 pm

10 years ago, on a Sun workstation, got horrible performance from a
program, but good answers. Ended up that underflow was being trapped
and then ignored. Masking underflow made the program go 1000 times
faster. It was frustrating, because there was no indication what was
going on, no errors or wrnings, just horrible performance.

G

Gerry Thomas

2004-05-13, 7:32 pm

"Richard Maine" <nospam@see.signature> wrote in message
news:m1d6589n0h.fsf@macfortran.local...
> "Gerry Thomas" <gfthomas@sympatico.ca> writes:
>
to do[color=darkred]
>
> See the numeric inquiry intrinsics added in f90. Their sole purpose
> is to allow Fortran programs to portably determine several
> processor-dependent parameter values while staying within the
> Fortran standard. Portable numerics is important to some of us
> in the standards business. It is also processor-dependent
> what machine instructions are used to multiply two floating
> point numbers, but that doesn't mean that the Fortran standard
> can't provide a portable way of denoting such multiplication.
>
> Indeed, the OP did use several of the intrinsics for some of the
> processor-dependent parameters, as noted in his original post.
> However, he was unable to find a corresponding intrinsic for the one
> parameter he asked about.
>
> As other posters have pointed out, the IEEE TR, which is part of
> Fortran in the f2003 DIS, has ways to portably address that
> (though as I pointed out, it is a bit of overkill in practice
> for underflow - I think some of the posters got

and
> thought that the request was about overflow.)
>
> If Fortran is defined as f77, then I guess I'd agree that this
> is all beyond Fortran. Fortunately for the OP, he specifically
> mentioned porting to f90, which provides more portability in
> such things than f77 did (and the IEEE TR adds yet a bit
> more - I'd mention "continual improvement", but I dislike that
> management jargon. :-))
>

I'm more than familiar with the numeric intrinsics of f90 and I haven't
misconstrued the OP's message. The IEEE TR isn't part of f90, the OP's
specified target. The OP's objective is nonportably processor dependent and
beyond f90.

--
E&OE

Ciao,
Gerry T.
______
"Don't play dumb! You're not as good at it as I am!" -- Col Sam Flagg,
ICORPS dropin to the 4077th M*A*S*H

> --
> Richard Maine | Good judgment comes from
experience;
> email: my first.last at org.domain | experience comes from bad
judgment.
> org: nasa, domain: gov | -- Mark Twain

Gerry Thomas

2004-05-13, 8:31 pm

"Gene Wagenbreth" <genew@isi.edu> wrote in message
news:c80ev0$q0f@venera.isi.edu...
> 10 years ago, on a Sun workstation, got horrible performance from a
> program, but good answers. Ended up that underflow was being trapped
> and then ignored. Masking underflow made the program go 1000 times
> faster. It was frustrating, because there was no indication what was
> going on, no errors or wrnings, just horrible performance.
>
> G
>

Denormals, inexacts, and underflows are the lowest in the x87 exception
precedence. Masked denormals can be accompanied by a lower-priority
exception (underflow or inexact); under/overflows can also trigger
inexacts; only the lowest-ranked inexacts occur in isolation. It's little
wonder that underflows are generally masked by default. I've no idea why
the OP's app appears to trap them.

--
Ciao,
Gerry T.
______
"Things are not what they seem; or, to be more accurate, they are not only
what they seem, but very much else besides." -- Aldous Huxley.

Jan Vorbrüggen

2004-05-14, 4:31 am

> 10 years ago, on a Sun workstation, got horrible performance from a
> program, but good answers. Ended up that underflow was being trapped
> and then ignored. Masking underflow made the program go 1000 times
> faster. It was frustrating, because there was no indication what was
> going on, no errors or wrnings, just horrible performance.

I believe that's not quite correct. The standard setting was to precisely
calculate with IEEE denormals according to the standard - in software
emulation, however. The Sun compilers used with -fast would turn that into
hardware-based underflow-to-zero, which for many cases is just as well and
substantially faster. As we were using g++, we ended up calling a routine
from the RTL that set the other mode, and got fast and consistent performance.

Jan

Herman D. Knoble

2004-05-14, 12:32 pm

You are indeed correct. Thanks.
Skip

On 13 May 2004 13:29:21 -0500, "beliavsky@aol.com" <beliavsky@127.0.0.1:7501> wrote:

-|
-|Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote:
-|>Gus: Several people have answered with respect to the underflow
-|>part of your question.
-|>
-|>Here's and an example where ignoring an underflow (with underflow results
-|>set to zero) will cause a wrong answer on a PC platform:
-|>
-|>real :: x, y, z
-|>x=1.1E-38
-|>y=1.1E+38
-|>z=(((x*x)*y)*y)*123456.0
-|>print *, "z=",z
-|>end
-|>
-|>The result, z, may be displayed as zero because of the underflow (x*x),
-|but should
-|>be 123456.0
-|
-|Only if you replace the "1.1" with "1.0" above, which is what
-|I think you intended.

Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818 Fax:+1 814 863-7049

keith bierman

2004-05-14, 2:31 pm

Jan Vorbrüggen wrote:

As far as I can recall, there was always a warning printed at the end of
such runs. Something along the lines of:
[color=darkred]
> Note: IEEE floating-point exception flags raised:
> Underflow, Inexact;
> See the Numerical Computation Guide, ieee_flags(3M)

I recall it was a frequently complained about warning ...

Some application writers went to some lengths to supress it (not by
changing the program to not suffer underflow, of course) so if you
didn't write the application yourself, perhaps someone did it for you
and wasn't kind enough to give you a clue as to what was going on.

Richard Maine

2004-05-14, 3:31 pm

keith bierman <keith.bierman@sun.com> writes:

>
> I recall it was a frequently complained about warning ...
>
> Some application writers went to some lengths to supress it

I'm one of those application writers. I assure you that the
application writers suppressed it because the application users
demanded that. While it is possible for underflow to be a problem, in
many applications it is perfectly normal. And it is next to
impossible to do a nontrivial scientific application without
triggering inexact. The result is that this message (or occasionally
just the inexact part of it) appeared after every run of almost every
application.

A message that appears that often isn't useful. It suffers from
the crying wolf syndrome in that it is so often of no consequence
that it will be ignored when it does have something real to say.

When I left this stuff in, pretty much every user came and asked what
was wrong when they first ran the applications. (And several of them
would forget and come ask again on subsequent uses.) The exceptions
were mostly such things as users who, on concluding that the program
didn't work, didn't bother to ask why, but went looking for some other
program that did work (on occasion, even a version of my code that
someone else had patched to suppress the warning). It didn't take me
long to get that message.

Heck, the "Fortran 90 stop" messages that some compilers liked to
print out were bad enough. I'd occasionally have users ask me what
went wrong to cause it to stop and I'd have to explain to them that
this was a normal termination rather than an error.

The complaints about the IEEE messages weren't occasional and it was a
lot harder to get users to believe it was "normal". A line such as
"it is just the Sun compiler being weird" was more convincing. :-(

Maybe my users were uniformly more clueless than the average, but I
don't think so. Several of them were rocket scientists. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Jan Vorbrüggen

2004-05-17, 10:31 am

>> Note: IEEE floating-point exception flags raised:[color=darkred]

I don't think the denormal emulation should trigger an inexact or underflow
flag, or should it?

Jan

keith bierman

2004-05-17, 7:32 pm

Jan Vorbrüggen wrote:
>
>
> I don't think the denormal emulation should trigger an inexact or underflow
> flag, or should it?
>
> Jan

Even where it's done in hw (e.g. SuperSPARC), the IEEE standard defines
it such that the flag is "raised".

Richard said it annoyed his users (I'm sure that's true). However, when
both inexact and underflow have occured, there is a loss of accuracy
(either one alone isn't as problematic).

Most users just don't expect much from the quality of their results (or
don't understand that there's an issue). Which is why the Sun f90
compiler changed the default behavior.

But recall that orginal poster complained that there was a significant
performance slowdown without warning.

The system tried to give a warning. Either this was ignored, or the
application supressed it. The platform can't do more than try to report ;>

Jan Vorbrüggen

2004-05-19, 6:31 am

> Even where it's done in hw (e.g. SuperSPARC), the IEEE standard defines
> it such that the flag is "raised".

Hmmm, then it might have been an RTL issue. I sure never saw this with g++,
and I always used -fast on the Sun compilers 8-).

> Richard said it annoyed his users (I'm sure that's true). However, when
> both inexact and underflow have occured, there is a loss of accuracy
> (either one alone isn't as problematic).

For that one computation, yes, but not necessarily for the computation as
a whole.

> Most users just don't expect much from the quality of their results (or
> don't understand that there's an issue).

Oh nonsense. When doing FFTs, there is not even an LSB difference with or
without correctly computed denormals.

> The system tried to give a warning. Either this was ignored, or the
> application supressed it. The platform can't do more than try to report ;>

But the warning is incomprehensible in this context. It tells you something
about inexact and underflow, when it should be telling you, "you're hitting
the software denormal emulation way too often for your own good".

Jan

Sponsored Links