IEEE support
Frank
The only mention they have of IEEE is that in C99, IEEE support is
optional.
In § 14 of _The F2003 Handbook_, the fortran equivalent is discussed.
Rightly or wrongly, I think of Dick Hendickson as the author of this
chapter, as it "sounds like" him. Anyways, right from the git-go, it
says that modules are optional. On the bottom of p. 521, it further
ratchets down expectations for its utility to implementations.
So, what good are is having IEEE support? Thanks for your comment.
Dan Nagle
On 2009-09-05 17:45:55 -0400, Frank <mer...@lomas-assault.net> said:
> So, what good are is having IEEE support? Thanks for your comment.
Don't thank me until you read it. ;-) ;-)
I think the purpose of IEEE support in standard languages
is to support whatever the hardware supports in a standard way.
Short answer: programming language standards do not dictate
to hardware engineers how the arithmetic will work.
Not all hardware supports all of 754 because some
of the less-used corners take a lot of transistors to implement,
are slow to execute, are infrequently used by most applications,
and don't have all that great a demand from applications programmers.
Do you really care about denorms?
Have you ever tested for unordered? (Do you really want to?)
Do you want more expensive chips with slower arithmetic?
HTH
--
Cheers!
Dan Nagle
Ron Shepard
Dan Nagle <dann...@verizon.net> wrote:
> Hello,
>
> On 2009-09-05 17:45:55 -0400, Frank <mer...@lomas-assault.net> said:
>
> > So, what good are is having IEEE support? Thanks for your comment.
>
> Don't thank me until you read it. ;-) ;-)
>
> I think the purpose of IEEE support in standard languages
> is to support whatever the hardware supports in a standard way.
IMO, I think that the fortran standard took the right approach regarding
IEEE arithmetic, optional but with standardized syntax if it is
supported. There have been many many features over the years that
SHOULD have been treated this way, but weren't.
Arbitrary-length bit strings and asynchronous I/O are two things like
this that come to mind. We application programmers have used these
things in nonstandard, nonportable, ways since the 60's (in my case
since the 70's). But because some vendors did not want to support them,
they were not included in the standard. If they had been included in an
optional way (like IEEE/f2003 arithmetic), then the vendors who had a
market for those features could have implemented them in a standard way
and provided them for their users, and those who did not have that
market could have ignored them.
$.02 -Ron Shepard
Dick Hendrickson
> I'm reading Harbison and Steele V right now, which is a C reference.
> The only mention they have of IEEE is that in C99, IEEE support is
> optional.
>
> In � 14 of _The F2003 Handbook_, the fortran equivalent is discussed.
> Rightly or wrongly, I think of Dick Hendickson as the author of this
> chapter, as it "sounds like" him. Anyways, right from the git-go, it
> says that modules are optional. On the bottom of p. 521, it further
> ratchets down expectations for its utility to implementations.
>
> So, what good are is having IEEE support? Thanks for your comment.
The simple answer is that if you require some feature of the IEEE
class of floating point stuff, your program will fail at compile
time if the processor doesn't support that feature
Dan's comments are pretty good. Also, remember that when IEEE support
was being designed (mid to late 90s) there were more hardware options
available, and not all of them supported IEEE in the same way. In
particular, the DEC Alpha, generally speaking, had the modes (rounding,
interrupt, etc.) hard coded into the op-codes when it compiled in
fast execute mode. It was much slower when it had to go and look
at a run-time changeable status register to decide how to do an
operation. Many vendors (more than 1) said adamantly that they
couldn't support full IEEE and reasonable optimization. The three
modules were a compromise that lets vendors support well what they
can support well, support poorly what is hard to do, and abort when
you ask them to do something they can't reasonably do. In that sense,
it's a little bit like the various selected_*_kind intrinsics. You
can ask for whatever precision you think is necessary and your program
will fail in a predictable way if that precision isn't available.
The IEEE modules are more general (or more complicated (or more
confusing)), but they let you get predictable results when you
require the unusual end cases and don't force compilers to
treat every simple thing as if it were really hard to do.
At least in the 90s, you could find very smart people who didn't
think that IEEE arithmetic was actually the best answer to a
problem. Making IEEE support "optional" allowed for the development
of other ways of doing things. It turns out that "the other ways"
have either been bought out or not materialized, but the standard
generally tries not to force reliance on specific hardware features.
Dick Hendrickson
Frank
Ok. Thanks all for responses. I was curious how it seems to be a
much bigger topic in fortran as opposed to C.
It doesn't have much bearing on whatever I do on a computer, as my
floats just seem to work magicly without me having to do much. It is
interesting to see how this material is treated by the standard.
nm...@cam.ac.uk
>
>> So, what good are is having IEEE support? Thanks for your comment.
>
>Don't thank me until you read it. ;-) ;-)
>
>I think the purpose of IEEE support in standard languages
>is to support whatever the hardware supports in a standard way.
Unfortunately, that isn't feasible :-( As people have been pointing
out since IEEE 754 was promulgated, its basic arithmetic model is
fundamentally incompatible with the basic arithmetic model of almost
every "high level" programming language since Fortran onwards. This
was raised in the context of IEEE 754R by several people who said
that IEEE 754 would need to change if it were ever to be taken up
by programming languages. Unfortunately, that did not happen.
For example, the IEEE 754 model is flatly incompatible with Fortran
2003 section 7.1.8. Even worse, its dynamic modes are incompatible
with static scoping of semantics. The situation is similar in almost
all other languages, definitely including C and C++.
>Short answer: programming language standards do not dictate
>to hardware engineers how the arithmetic will work.
Yup. Unfortunately, IEEE 754 attempts to dictate to programming
language standards how their arithmetic will work.
>Not all hardware supports all of 754 because some
>of the less-used corners take a lot of transistors to implement,
>are slow to execute, are infrequently used by most applications,
>and don't have all that great a demand from applications programmers.
At one stage, IEEE 754R attempted to address that, but my reading
of the final draft is that they backed off from doing so.
>Do you really care about denorms?
>Have you ever tested for unordered? (Do you really want to?)
>Do you want more expensive chips with slower arithmetic?
Plus:
Are you capable or writing code that can make use of signed zeroes
or NaNs, with any realistic hope of getting it correct?
Do you know EXACTLY what IEEE 754 specifies for sign handling, flag
setting and exceptional value handling?
>>Ok. Thanks all for responses. I was curious how it seems to be a
>>much bigger topic in fortran as opposed to C.
That is because you (Frank) haven't looked at the shambles that is
IEEE 754 support in C99. I recommend that you don't. If Harbison
and Steele skipped over it with one sentence, they were quite right
to do so. I am extremely experienced in both C and numerics, and
regard it as unusable if you care about either portability or
reliability.
I don't recommend using Fortran IEEE support, either, incidentally.
It's VASTLY better than C's, because it provides just a syntactic
framework for a compiler to provide suitable semantics, and doesn't
attempt to define the semantics in detail. So it can't be used
portably, because its semantics are inherently processor dependent.
Regards,
Nick Maclaren.
Steve Lionel
> So, what good are is having IEEE support? Thanks for your comment.
Over the years/decades, I have seen, and continue to see, customers who
want more control over floating point exceptional behavior. In the
past, we and other vendors have offered various non-standard methods for
such things. Each time we refined the control, customers asked for more.
The IEEE support in F2003 is hard to get your head around, especially if
you are not already well-versed in the possibilities, but it offers a
standard syntax for both querying and modifying the floating point
environment in a way that does not prevent optimization for programs
that don't want the detailed control. I think that the increase in
portability and flexibility these modules offer is wonderful, and I try
to encourage our customers to make use of them. (Unfortunately, many
keep asking for new command line switches to make global changes...)
I guess the response I have is, "If you don't know you need it, you
probably don't." But perhaps someday you'll encounter a situation where
you'll be glad it's there.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
Tim Prince
> I don't recommend using Fortran IEEE support, either, incidentally.
> It's VASTLY better than C's, because it provides just a syntactic
> framework for a compiler to provide suitable semantics, and doesn't
> attempt to define the semantics in detail. So it can't be used
> portably, because its semantics are inherently processor dependent.
>
I suppose the IEEE support could be more useful if examples were
available showing how it works with compilers which have implemented it,
or how to test whether some of the obscure bits work in an expected way
on a given platform.
Although gfortran doesn't supply any part of ieee_arithmetic,
gfortran build tests whether <fenv.h> (the relevant bit of C99) appears
to be present. So it seems there is precedent for attempting a degree
of consistency between Fortran and C99.
The rounding_mode functions are easily implemented with C99 and
iso_c_interop. However, <fenv.h> is not widely available, for example
not on Windows, even with gcc. For Windows, rounding modes, as well as
underflow modes, can be implemented ieee_arithmetic style by use of
<xmmintrin.h> (a common C extension).
http://sites.google.com/site/tprincesite/Home/gfortran-ieee-arithmetic
Compilers aren't consistent in the underflow mode settings which are
often coupled with optimization flags. For example, gfortran for linux
sets abrupt underflow with the -ffast-math option, but the same effect
is not present on Windows. I wanted ieee_set_underflow_mode so as to
overcome this inconsistency.
Fortunately, design of new CPUs shows a trend toward less severe
performance implications for gradual underflow (as claimed by the
originators of IEEE-754 decades ago).
nm...@cam.ac.uk
Tim Prince <tpr...@nospamcomputer.org> wrote:
>
>> I don't recommend using Fortran IEEE support, either, incidentally.
>> It's VASTLY better than C's, because it provides just a syntactic
>> framework for a compiler to provide suitable semantics, and doesn't
>> attempt to define the semantics in detail. So it can't be used
>> portably, because its semantics are inherently processor dependent.
>
>I suppose the IEEE support could be more useful if examples were
>available showing how it works with compilers which have implemented it,
>or how to test whether some of the obscure bits work in an expected way
>on a given platform.
If the latter were even theoretically possible, things would be a
lot better than they are.
>Although gfortran doesn't supply any part of ieee_arithmetic,
>gfortran build tests whether <fenv.h> (the relevant bit of C99) appears
>to be present. So it seems there is precedent for attempting a degree
>of consistency between Fortran and C99.
!!!!! NO chance! Have you looked at the two specifications, even
briefly? There isn't the chance of a flea in a furnace of getting
significant consistency between them. Just to start, Fortran has
adopted a scope-based model, and C a global model.
>The rounding_mode functions are easily implemented with C99 and
>iso_c_interop. However, <fenv.h> is not widely available, for example
>not on Windows, even with gcc. For Windows, rounding modes, as well as
>underflow modes, can be implemented ieee_arithmetic style by use of
><xmmintrin.h> (a common C extension).
Don't bet on it. REALLY don't bet on it. I haven't studied this
aspect of x86 closely, nor <xmmintrin.h>, but will bet a guinea to
a groat that it is solid with gotchas. Such as the exact details
depending on whether raw, XMM, SSE, coprocessor or library call
code is generated for a specific Fortran construct.
>Compilers aren't consistent in the underflow mode settings which are
>often coupled with optimization flags. For example, gfortran for linux
>sets abrupt underflow with the -ffast-math option, but the same effect
>is not present on Windows. I wanted ieee_set_underflow_mode so as to
>overcome this inconsistency.
That's the least of the problems :-(
>Fortunately, design of new CPUs shows a trend toward less severe
>performance implications for gradual underflow (as claimed by the
>originators of IEEE-754 decades ago).
Hmm. "Fortunately"? There are many experts who believe that
denormalised numbers are a serious mistake, in numerical as well as
performance terms.
Regards,
Nick Maclaren.
Dan Nagle
On 2009-09-06 10:05:32 -0400, Tim Prince <tpr...@nospamcomputer.org> said:
> The rounding_mode functions are easily implemented with C99 and iso_c_interop.
I take it you meant iso_c_binding here.
Else, I'm lost. :-(
--
Cheers!
Dan Nagle
Tim Prince
Tim Prince
Frank
> Not all hardware supports all of 754 because some
> of the less-used corners take a lot of transistors to implement,
> are slow to execute, are infrequently used by most applications,
> and don't have all that great a demand from applications programmers.
You frequently provide terms that allow me to search.
http://en.wikipedia.org/wiki/IEEE_754-2008
It seems to have changed names along the way. This is a good link to
have bookmarked:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
Annex F
(normative)
IEC 60559 floating-point arithmetic
Apparently IEEE is now IEC.
> Do you really care about denorms?
> Have you ever tested for unordered? (Do you really want to?)
> Do you want more expensive chips with slower arithmetic?
What are denorms and unordered?
nm...@cam.ac.uk
Frank <mer...@lomas-assault.net> wrote:
>
>It seems to have changed names along the way. This is a good link to
>have bookmarked:
>
>http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
Er, no. If you think that you understand what that implies, you
don't. As I have posted, my recommendation is not even to THINK
of going NEAR that! I kept a watching eye on the NCEG and (like
many other people) relaxed when that decided that it was not suitable
for inclusion in the C standard, and should be left in TR form. That
was a BAD mistake :-(
>> Do you really care about denorms?
>> Have you ever tested for unordered? =A0(Do you really want to?)
>> Do you want more expensive chips with slower arithmetic?
>
>What are denorms and unordered?
Subnormals, in Wikipedia's terms, and things like NaN, which are
neither greater than or less than each other and other numbers.
There are lots of references telling you how to use the IEEE 754
facilities, but damn few warning you of the evil "gotchas". One
of my courses (please ask) does, briefly. This is a great pity,
because fairly minor changes would remove 99% of the gotchas, and
make it a great aid to reliable numerical programming.
However, as things are at present, you need to learn a LOT more
before you can use those facilities correctly. Like Dan, I advise
not wasting your time.
One of the many projects on my task list is to write some test code
that will check Fortran IEEE support for sanity (C is beyond hope),
at least in rough draft. Coupled with that, I could write something
on how to use the features correctly - i.e. what to do and, more
importantly, what NOT to do. It is possible that someone has done
that, and I should appreciate hearing if so.
Regards,
Nick Maclaren.
robin
news:ron-shepard-EE0C...@news60.forteinc.com...
> IMO, I think that the fortran standard took the right approach regarding
> IEEE arithmetic, optional but with standardized syntax if it is
> supported. There have been many many features over the years that
> SHOULD have been treated this way, but weren't.
>
> Arbitrary-length bit strings and asynchronous I/O are two things like
> this that come to mind.
> We application programmers have used these
> things in nonstandard, nonportable, ways since the 60's (in my case
> since the 70's).
Those were available in PL/I since the mod-1960s.
No need for anything non-standard.
glen herrmannsfeldt
(snip, someone wrote))
<>Short answer: programming language standards do not dictate
<>to hardware engineers how the arithmetic will work.
< Yup. Unfortunately, IEEE 754 attempts to dictate to programming
< language standards how their arithmetic will work.
variabilities of hardware. Allowing for differing representation
of signed numbers and, one of my favorite, C's restriction on
shifts greater than or equal to the length of the value being shifted.
Floating point is one that tended to be more open, from the days
when there was no standard for floating point.
-- glen
glen herrmannsfeldt
(snip, someone wrote)
<>Fortunately, design of new CPUs shows a trend toward less severe
<>performance implications for gradual underflow (as claimed by the
<>originators of IEEE-754 decades ago).
< Hmm. "Fortunately"? There are many experts who believe that
< denormalised numbers are a serious mistake, in numerical as well as
< performance terms.
I don't know about the numerical part, but it seems a large
amount of work for a small gain. If you need more exponent
range, then add an exponent bit and double the range.
Gradual underflow gives you slightly larger exponent range,
and big complications in the ALU.
If the exponent range isn't big enough, then software tricks
like prenormalization should be used.
-- glen
glen herrmannsfeldt
< On Sep 5, 3:28?pm, Dan Nagle <danna...@verizon.net> wrote:
<> Not all hardware supports all of 754 because some
<> of the less-used corners take a lot of transistors to implement,
<> are slow to execute, are infrequently used by most applications,
<> and don't have all that great a demand from applications programmers.
< You frequently provide terms that allow me to search.
< http://en.wikipedia.org/wiki/IEEE_754-2008
< It seems to have changed names along the way.
It seems that since 2008 is now the current standard, the
http://en.wikipedia.org/wiki/IEEE_754
page now describes the 2008 version.
The title for the page is IEEE 754-2008
It seems that the link
http://en.wikipedia.org/wiki/IEEE754
also works.
-- glen
glen herrmannsfeldt
(snip)
<? Dan's comments are pretty good. Also, remember that when IEEE support
<? was being designed (mid to late 90s)
IEEE 754-1985 was published in 1985, so the designing must have
been done earlier. The 8087 data sheet was available around 1982
when the IBM PC was released. I don't know how easy they were
to find, though.
<? there were more hardware options
<? available, and not all of them supported IEEE in the same way. In
<? particular, the DEC Alpha, generally speaking, had the modes (rounding,
<? interrupt, etc.) hard coded into the op-codes when it compiled in
<? fast execute mode. It was much slower when it had to go and look
<? at a run-time changeable status register to decide how to do an
<? operation.
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
><>Short answer: programming language standards do not dictate
><>to hardware engineers how the arithmetic will work.
>
>< Yup. Unfortunately, IEEE 754 attempts to dictate to programming
>< language standards how their arithmetic will work.
>
>In many places, programming languages leave room for the
>variabilities of hardware. Allowing for differing representation
>of signed numbers and, one of my favorite, C's restriction on
>shifts greater than or equal to the length of the value being shifted.
From a course that I give:
More on Shifts
Hardware and languages mess these up
I know the history/excuses, from 40 years back
%deity alone knows why no improvement
Shifts often unsigned only in hardware
Involving the sign bit can have weird effects
Usually, only some bits of the count used
Typically, the bottom 5/6/8 bits of count
Why? The ICL 1904 (c.1965) did it properly
What Languages Do
Shifts >= bits in word usually undefined
Java defined, but uses only 5/6 bits of shift
Usually undefined if signed shifts overflow
I.e. left shift a one into or out of sign bit
Right shifts on negatives usually unspecified
As mentioned earlier, Python gets these right
Why don't other languages do the same?
For the youngsters reading this group (anyone with no experience
of discrete-logic machines!), valves and transistors were a limit,
and it was easier and quicker to read just a few bits than compare
values and return zero if out of range. And we have that restriction
in the hardware and software of today. I kid you not!
>Floating point is one that tended to be more open, from the days
>when there was no standard for floating point.
Indeed, but my real point was about the incompatibility of the
MODELS, not that of the DETAILS. It's a subtle difference, but
a very important one.
Regards,
Nick Maclaren.
Kevin G. Rhoads
>much bigger topic in fortran as opposed to C.
Because for decades if you needed heavy floating point Fortran
was the way to go and not C
Dick Hendrickson
> Dick Hendrickson <dick.hen...@att.net> wrote:
> (snip)
>
> <? Dan's comments are pretty good. Also, remember that when IEEE support
> <? was being designed (mid to late 90s)
>
> IEEE 754-1985 was published in 1985, so the designing must have
> been done earlier. The 8087 data sheet was available around 1982
> when the IBM PC was released. I don't know how easy they were
> to find, though.
>
Sorry, I meant the IEEE support modules in Fortran, not IEEE arithmetic
in general.
Dick Hendrickson
Frank
> In article <7c83507b-2210-45f2-8960-eeab43829...@h40g2000prf.googlegroups.com>,
>
> Frank <merr...@lomas-assault.net> wrote:
>
> >It seems to have changed names along the way. This is a good link to
> >have bookmarked:
>
> >http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
>
> Er, no. If you think that you understand what that implies, you
> don't. As I have posted, my recommendation is not even to THINK
> of going NEAR that! I kept a watching eye on the NCEG and (like
> many other people) relaxed when that decided that it was not suitable
> for inclusion in the C standard, and should be left in TR form. That
> was a BAD mistake :-(
I'm certain that you don't mean to say "stay away from C," because if
you're in fortran, it's right under the hood. The link is the one
that Keith Thompson in clc posts more than any other. n1256.pdf is
their version of 04-007.pdf.
Annex F is the IEEE part, which they call IEC 6***9. I think you're
telling me not to waste my time forcing strict enforcement to this
protocol.
>
> >> Do you really care about denorms?
> >> Have you ever tested for unordered? =A0(Do you really want to?)
> >> Do you want more expensive chips with slower arithmetic?
>
> >What are denorms and unordered?
>
> Subnormals, in Wikipedia's terms, and things like NaN, which are
> neither greater than or less than each other and other numbers.
>
> There are lots of references telling you how to use the IEEE 754
> facilities, but damn few warning you of the evil "gotchas". One
> of my courses (please ask) does, briefly. This is a great pity,
> because fairly minor changes would remove 99% of the gotchas, and
> make it a great aid to reliable numerical programming.
>
> However, as things are at present, you need to learn a LOT more
> before you can use those facilities correctly. Like Dan, I advise
> not wasting your time.
>
> One of the many projects on my task list is to write some test code
> that will check Fortran IEEE support for sanity (C is beyond hope),
> at least in rough draft. Coupled with that, I could write something
> on how to use the features correctly - i.e. what to do and, more
> importantly, what NOT to do. It is possible that someone has done
> that, and I should appreciate hearing if so.
Thanks, Nick, I don't think I have a compiler to inform an opinion the
IEEE stuff in fortran. This stuff is therefore implementation-
specific, and your instruction would fall on a person unable to
produce a float if not with g95 or gfortran. Without a computer to
calculate the floats you talk about, I could do just as well do a
forum search for Gordon Sande.
> (please ask)
Can you describe robust floating-point operations in either g95 or
gfortran?
Frank
> Frank wrote:
> > So, what good is having IEEE support?
> I guess the response I have is, "If you don't know you need it, you
> probably don't." But perhaps someday you'll encounter a situation where
> you'll be glad it's there.
There's a lot of things I don't know :)
Frank
I guess I knew that part of it.
nm...@cam.ac.uk
Frank <mer...@lomas-assault.net> wrote:
>>
>> Er, no. =A0If you think that you understand what that implies, you
>> don't. =A0As I have posted, my recommendation is not even to THINK
>> of going NEAR that! =A0I kept a watching eye on the NCEG and (like
>> many other people) relaxed when that decided that it was not suitable
>> was a BAD mistake :-(
>
>I'm certain that you don't mean to say "stay away from C," because if
>you're in fortran, it's right under the hood. The link is the one
>that Keith Thompson in clc posts more than any other. n1256.pdf is
>their version of 04-007.pdf.
You should automatically distrust everything you read in comp.lang.c,
on the grounds that the bullshit to information ratio is huge. Keith
Thompson (the OTHER one) is one of the sanest, but I wouldn't class
him as an expert in this area.
And, yes, I DO say "stay away from C", because my assertion is that
anyone who needs any assistance doing so is incapable of using it
reliably, at least where portability or error handling are concerned.
And that statement is based on a LOT of experience. To write
reliable and portable C, it helps a great deal if you have extensive
experience writing serious applications in assembler, plus significant
compiler and language run-time system implementation experience.
No, I am not joking.
>Annex F is the IEEE part, which they call IEC 6***9. I think you're
>telling me not to waste my time forcing strict enforcement to this
>protocol.
I am telling you not to waste your time even looking at at, nor in
attempting to fix code that attempts to use it. Rewrite it not to
do so; if will be more portable, more reliable and easier. I know
as much about that area as anyone, and know of almost nothing to
say about it that is both polite and accurate.
>> One of the many projects on my task list is to write some test code
>> that will check Fortran IEEE support for sanity (C is beyond hope),
>> at least in rough draft. =A0Coupled with that, I could write something
>> on how to use the features correctly - i.e. what to do and, more
>> importantly, what NOT to do. =A0It is possible that someone has done
>> that, and I should appreciate hearing if so.
>
>Thanks, Nick, I don't think I have a compiler to inform an opinion the
>IEEE stuff in fortran. This stuff is therefore implementation-
>specific, and your instruction would fall on a person unable to
>produce a float if not with g95 or gfortran. Without a computer to
>calculate the floats you talk about, I could do just as well do a
>forum search for Gordon Sande.
Grrk. Sorry, but you really don't understand even the basics of this
incredibly arcane area. The problem isn't in producing the IEEE
numbers (g95 and gfortran do that), but in the details of exception
handling. Signed zero handling is beyond redemption.
>Can you describe robust floating-point operations in either g95 or
>gfortran?
Not concisely. You may be interested in:
http://www-uxsup.csx.cam.ac.uk/courses/Arithmetic/
Regards,
Nick Maclaren.
Frank
> In article <5f4c9642-3e36-4c48-9f3e-ae499a6b7...@g1g2000pra.googlegroups.com>,
I'll respectfully disagree with you on the merits of reading 1256.pdf.
>
> I am telling you not to waste your time even looking at at, nor in
> attempting to fix code that attempts to use it. Rewrite it not to
> do so; if will be more portable, more reliable and easier. I know
> as much about that area as anyone, and know of almost nothing to
> say about it that is both polite and accurate.
>
> >> One of the many projects on my task list is to write some test code
> >> that will check Fortran IEEE support for sanity (C is beyond hope),
> >> at least in rough draft. =A0Coupled with that, I could write something
> >> on how to use the features correctly - i.e. what to do and, more
> >> importantly, what NOT to do. =A0It is possible that someone has done
> >> that, and I should appreciate hearing if so.
>
> >Thanks, Nick, I don't think I have a compiler to inform an opinion the
> >IEEE stuff in fortran. This stuff is therefore implementation-
> >specific, and your instruction would fall on a person unable to
> >produce a float if not with g95 or gfortran. Without a computer to
> >calculate the floats you talk about, I could do just as well do a
> >forum search for Gordon Sande.
>
> Grrk. Sorry, but you really don't understand even the basics of this
> incredibly arcane area. The problem isn't in producing the IEEE
> numbers (g95 and gfortran do that), but in the details of exception
> handling. Signed zero handling is beyond redemption.
I know I don't know this area. Numerical analysis was at 7:30 am for
me, while I worked till 3 am. I was a sleep for the times I showed
up, and the prof let me drop it midway.
>
> >Can you describe robust floating-point operations in either g95 or
> >gfortran?
>
> Not concisely. You may be interested in:
>
> http://www-uxsup.csx.cam.ac.uk/courses/Arithmetic/
This looks great:
nm...@cam.ac.uk
Frank <mer...@lomas-assault.net> wrote:
>>
>> And, yes, I DO say "stay away from C", because my assertion is that
>> anyone who needs any assistance doing so is incapable of using it
>> reliably, at least where portability or error handling are concerned.
>> reliable and portable C, it helps a great deal if you have extensive
>> experience writing serious applications in assembler, plus significant
>> compiler and language run-time system implementation experience.
>> No, I am not joking.
>>
>> >telling me not to waste my time forcing strict enforcement to this
>> >protocol.
>
>I'll respectfully disagree with you on the merits of reading 1256.pdf.
That's not what I said. My only further comment is that, if you think
that you know what <fenv.h>, Annex F and the other __STDC_IEC_559__
stuff actually means, you don't. Nobody does.
At least Fortran has specified the syntax, what constitutes a conforming
program and the intent, fairly unambiguously. God alone knows exactly
what is required to happen when executing code like the following,
when array x has all sorts of 'interesting' values, however:
DO i = 1,N
x(i) = x(i)*x(i)/x(i)
END DO
But specifying that precisely involves not starting from here, for
reasons that all experts in the relevant fields will recognise.
Regards,
Nick Maclaren.
Frank
> In article <b6a0db47-6ed4-4eb0-8465-4652fc16b...@i18g2000pro.googlegroups.com>,
>
>
>
> Frank <merr...@lomas-assault.net> wrote:
>
> >> And, yes, I DO say "stay away from C", because my assertion is that
> >> anyone who needs any assistance doing so is incapable of using it
> >> reliably, at least where portability or error handling are concerned.
> >> And that statement is based on a LOT of experience. =A0To write
> >> reliable and portable C, it helps a great deal if you have extensive
> >> experience writing serious applications in assembler, plus significant
> >> compiler and language run-time system implementation experience.
> >> No, I am not joking.
>
> >> >Annex F is the IEEE part, which they call IEC 6***9. =A0I think you're
> >> >telling me not to waste my time forcing strict enforcement to this
> >> >protocol.
>
> >I'll respectfully disagree with you on the merits of reading 1256.pdf.
>
> That's not what I said. My only further comment is that, if you think
> that you know what <fenv.h>, Annex F and the other __STDC_IEC_559__
> stuff actually means, you don't. Nobody does.
Again I will disagree with you.
#ifndef _FENV_H_
#define _FENV_H_
#include <_mingw.h>
/* FPU status word exception flags */
#define FE_INVALID 0x01
#define FE_DENORMAL 0x02
#define FE_DIVBYZERO 0x04
#define FE_OVERFLOW 0x08
#define FE_UNDERFLOW 0x10
#define FE_INEXACT 0x20
#define FE_ALL_EXCEPT (FE_INVALID | FE_DENORMAL | FE_DIVBYZERO \
| FE_OVERFLOW | FE_UNDERFLOW | FE_INEXACT)
/* FPU control word rounding flags */
#define FE_TONEAREST 0x0000
#define FE_DOWNWARD 0x0400
#define FE_UPWARD 0x0800
#define FE_TOWARDZERO 0x0c00
/* The MXCSR exception flags are the same as the
FE flags. */
#define __MXCSR_EXCEPT_FLAG_SHIFT 0
/* How much to shift FE status word exception flags
to get the MXCSR exeptions masks, */
#define __MXCSR_EXCEPT_MASK_SHIFT 7
/* How much to shift FE control word rounding flags
to get MXCSR rounding flags, */
#define __MXCSR_ROUND_FLAG_SHIFT 3
#ifndef RC_INVOKED
/*
For now, support only for the basic abstraction of flags that are
either set or clear. fexcept_t could be structure that holds more
info about the fp environment.
*/
typedef unsigned short fexcept_t;
/* This 32-byte struct represents the entire floating point
environment as stored by fnstenv or fstenv, augmented by
the contents of the MXCSR register, as stored by stmxcsr
(if CPU supports it). */
typedef struct
{
unsigned short __control_word;
unsigned short __unused0;
unsigned short __status_word;
unsigned short __unused1;
unsigned short __tag_word;
unsigned short __unused2;
unsigned int __ip_offset; /* instruction pointer offset */
unsigned short __ip_selector;
unsigned short __opcode;
unsigned int __data_offset;
unsigned short __data_selector;
unsigned short __unused3;
unsigned int __mxcsr; /* contents of the MXCSR register */
} fenv_t;
/*The C99 standard (7.6.9) allows us to define implementation-specific
macros for
different fp environments */
/* The default Intel x87 floating point environment (64-bit mantissa)
*/
#define FE_PC64_ENV ((const fenv_t *)-1)
/* The floating point environment set by MSVCRT _fpreset (53-bit
mantissa) */
#define FE_PC53_ENV ((const fenv_t *)-2)
/* The FE_DFL_ENV macro is required by standard.
fesetenv will use the environment set at app startup.*/
#define FE_DFL_ENV ((const fenv_t *) 0)
#ifdef __cplusplus
extern "C" {
#endif
/*TODO: Some of these could be inlined */
/* 7.6.2 Exception */
extern int __cdecl __MINGW_NOTHROW feclearexcept (int);
extern int __cdecl __MINGW_NOTHROW fegetexceptflag (fexcept_t * flagp,
int excepts);
extern int __cdecl __MINGW_NOTHROW feraiseexcept (int excepts );
extern int __cdecl __MINGW_NOTHROW fesetexceptflag (const fexcept_t *,
int);
extern int __cdecl __MINGW_NOTHROW fetestexcept (int excepts);
/* 7.6.3 Rounding */
extern int __cdecl __MINGW_NOTHROW fegetround (void);
extern int __cdecl __MINGW_NOTHROW fesetround (int mode);
/* 7.6.4 Environment */
extern int __cdecl __MINGW_NOTHROW fegetenv (fenv_t * envp);
extern int __cdecl __MINGW_NOTHROW fesetenv (const fenv_t * );
extern int __cdecl __MINGW_NOTHROW feupdateenv (const fenv_t *);
extern int __cdecl __MINGW_NOTHROW feholdexcept (fenv_t *);
#ifdef __cplusplus
}
#endif
#endif /* Not RC_INVOKED */
#endif /* ndef _FENV_H */
>
> At least Fortran has specified the syntax, what constitutes a conforming
> program and the intent, fairly unambiguously. God alone knows exactly
> what is required to happen when executing code like the following,
> when array x has all sorts of 'interesting' values, however:
>
> DO i = 1,N
> x(i) = x(i)*x(i)/x(i)
> END DO
>
> But specifying that precisely involves not starting from here, for
> reasons that all experts in the relevant fields will recognise.
One can recondtion this expreddion.