Fortran - Integer representation

Author

Integer representation

Gus Gassmann

2004-03-27, 12:17 am

I have some C code that I need to adapt to Fortran 90.
One requirement in one step of the algorithm is that a function
evaluate to an odd integer. Will the following work portably:

i = ior(i,1)

or is it better (more reliable/ more efficient/safer) to say

i = 2*(i/2) + 1

or maybe something else entirely?

Thank very much in advance.

David Ham

2004-03-27, 12:17 am

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

> I have some C code that I need to adapt to Fortran 90.
> One requirement in one step of the algorithm is that a function
> evaluate to an odd integer. Will the following work portably:
>
> i = ior(i,1)
>
> or is it better (more reliable/ more efficient/safer) to say
>
> i = 2*(i/2) + 1
>
> or maybe something else entirely?
>
> Thank very much in advance.

I would say the latter simply because it's easier for me to read and
understand (I had to look up M&R to even know what IOR does). On the
other hand, if your used to C (a language in which bit twiddling seems
much more common), the reverse may be true.

David

Gus Gassmann

2004-03-27, 12:17 am

David Ham wrote:

> Gus Gassmann <hgassman@mgmt.dal.ca> writes:
>
>
> I would say the latter simply because it's easier for me to read and
> understand (I had to look up M&R to even know what IOR does). On the
> other hand, if your used to C (a language in which bit twiddling seems
> much more common), the reverse may be true.

I should have mentioned that this is part of a module on hashing,
which has bit manipulations galore, anyway. So if the bit manipulation
does not cause a performance hit (which I can't imagine) and is
portable, I would go with that one, because it is in the spirit of the
rest of the routine.

Herman D. Knoble

2004-03-27, 12:17 am

I think that you want the Fortran 90 Intrinsic function: IEOR which exclusively
OR's two integer arguments and returns the result.

Good luck with it.
Skip Knoble

On Fri, 19 Mar 2004 14:23:30 GMT, Gus Gassmann <hgassman@mgmt.dal.ca> wrote:

-|I have some C code that I need to adapt to Fortran 90.
-|One requirement in one step of the algorithm is that a function
-|evaluate to an odd integer. Will the following work portably:
-|
-|i = ior(i,1)
-|
-|or is it better (more reliable/ more efficient/safer) to say
-|
-|i = 2*(i/2) + 1
-|
-|or maybe something else entirely?
-|
-|Thank very much in advance.

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

David Ham

2004-03-27, 12:17 am

Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> writes:

> I think that you want the Fortran 90 Intrinsic function: IEOR which exclusively
> OR's two integer arguments and returns the result.
>
> Good luck with it.
> Skip Knoble

No, I think he wants inclusive or (ior). ior(i,1) ensures that the
least significant bit of the result is 1 whereas xor sets it to 0 if i
is even.

David

>
> On Fri, 19 Mar 2004 14:23:30 GMT, Gus Gassmann <hgassman@mgmt.dal.ca> wrote:
>
> -|I have some C code that I need to adapt to Fortran 90.
> -|One requirement in one step of the algorithm is that a function
> -|evaluate to an odd integer. Will the following work portably:
> -|
> -|i = ior(i,1)
> -|
> -|or is it better (more reliable/ more efficient/safer) to say
> -|
> -|i = 2*(i/2) + 1
> -|
> -|or maybe something else entirely?
> -|
> -|Thank very much in advance.
>
>
> 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

Herman D. Knoble

2004-03-27, 12:17 am

Yea, sorry about that; you're right, the normal OR function. IOR is available also as an
an F90 Elemental Intrinsic Function.

Skip

On 19 Mar 2004 16:02:24 +0100, David Ham <D.A.Ham@CiTG.TUDelft.nl> wrote:

-|Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> writes:
-|
-|> I think that you want the Fortran 90 Intrinsic function: IEOR which exclusively
-|> OR's two integer arguments and returns the result.
-|>
-|> Good luck with it.
-|> Skip Knoble
-|
-|No, I think he wants inclusive or (ior). ior(i,1) ensures that the
-|least significant bit of the result is 1 whereas xor sets it to 0 if i
-|is even.
-|
-|David
-|
-|>
-|> On Fri, 19 Mar 2004 14:23:30 GMT, Gus Gassmann <hgassman@mgmt.dal.ca> wrote:
-|>
-|> -|I have some C code that I need to adapt to Fortran 90.
-|> -|One requirement in one step of the algorithm is that a function
-|> -|evaluate to an odd integer. Will the following work portably:
-|> -|
-|> -|i = ior(i,1)
-|> -|
-|> -|or is it better (more reliable/ more efficient/safer) to say
-|> -|
-|> -|i = 2*(i/2) + 1
-|> -|
-|> -|or maybe something else entirely?
-|> -|
-|> -|Thank very much in advance.
-|>
-|>
-|> 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

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

Jugoslav Dujic

2004-03-27, 12:17 am

Gus Gassmann wrote:
| I have some C code that I need to adapt to Fortran 90.
| One requirement in one step of the algorithm is that a function
| evaluate to an odd integer. Will the following work portably:
|
| i = ior(i,1)
|
| or is it better (more reliable/ more efficient/safer) to say
|
| i = 2*(i/2) + 1
|
| or maybe something else entirely?

In addition what other posters said, there are also bit-manipulation
intrinsics:

IBSET, IBCLEAR, BTEST, ISHFT, ISHFTC, MVBITS, IBITS

For the dividability test, I prefer the form

if (MOD(i, 2) == 0) then
!even
else
!odd
end if

purely for readability reasons (byt YMMV/ETHO).

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Gus Gassmann

2004-03-27, 12:17 am

David Ham wrote:

> Herman D. Knoble <SkipKnobleLESS@SPAMpsu.DOT.edu> writes:
>
>
> No, I think he wants inclusive or (ior). ior(i,1) ensures that the
> least significant bit of the result is 1 whereas xor sets it to 0 if i
> is even.

Precisely. I just don't want to get burned by big-endian versus little-endian
or two's-complement versus not or any other non-portabilities. The correct
answer may very well be "If you worry about such things, you're not ready
to use IOR in the first place".

Kevin G. Rhoads

2004-03-27, 12:17 am

>Precisely. I just don't want to get burned by big-endian versus little-endian
>or two's-complement versus not or any other non-portabilities.

But elsewhere you indicated that bit-twiddling was used all over the
code:
>I should have mentioned that this is part of a module on hashing,
>which has bit manipulations galore,

You can NOT have bit twiddling and portability. Bit twiddling
depends on knowing the underlying representation (big-end vs. little-end;
ones complement, twos complement, sign-magnitude or whatever).

Hashes can be 1) good, 2) fast, 3) portable. With some efffort, two
of these are simultaneously achieveable. Three out of three is
close to impossible.

I expect you knew all this, and were just hoping someone could
show you something that you hadn't seen already that would
let you have it all. Unfortunately, I don't think it can be so.

So -- I'd recomment that you use bit twiddling where appropriate,
and comment heavily about portability issues. If you really want
to run on many platforms, you can isolate the platform specific
stuff into a few places. Perhaps having separate subroutines for
these for big and little end machines &c.

James Giles

2004-03-27, 12:17 am

Kevin G. Rhoads wrote:
>
> But elsewhere you indicated that bit-twiddling was used all over the
> code:
>
> You can NOT have bit twiddling and portability. Bit twiddling
> depends on knowing the underlying representation (big-end vs. little-end;
> ones complement, twos complement, sign-magnitude or whatever).

You should read the Bit Model in the standard document (or one
of the Fortran books that cover it). The "endian" issues are all
portably addressed for such "twiddling" *within* the program (but
not for I/O). The others are all irrelevant as long as you don't
"twiddle" the sign-bit. The sign bit is explicitly mentioned as a
non-portable thing to manipulate with the bit intrinsics.

As a practical matter, nothing but two's complement is very common
anymore. So, even "twiddling" the sign bit is usually portably defined.
Anyone actually have a modern platform that doesn't use two's
complement for signed integers in Fortran?

[...]
> So -- I'd recomment that you use bit twiddling where appropriate,
> and comment heavily about portability issues. If you really want
> to run on many platforms, you can isolate the platform specific
> stuff into a few places. Perhaps having separate subroutines for
> these for big and little end machines &c.

That's good advice for anything you do that's off the beaten track.
Even things that are completely portable, if they're uncommon
enough not to be completely familiar to most users, do the above.

--
J. Giles

Gus Gassmann

2004-03-27, 12:17 am

Kevin G. Rhoads wrote:
>
>
> But elsewhere you indicated that bit-twiddling was used all over the
> code:
>
>
>
> You can NOT have bit twiddling and portability. Bit twiddling
> depends on knowing the underlying representation (big-end vs. little-end;
> ones complement, twos complement, sign-magnitude or whatever).
>
> Hashes can be 1) good, 2) fast, 3) portable. With some efffort, two
> of these are simultaneously achieveable. Three out of three is
> close to impossible.

I was never under the illusion that the resulting hash table should
be identical in all environments. (Not even I am _that_ naive...)
The only thing I want is code that will run without crashing.
That, and the confirmation that i = ior(i,1) returns an odd integer
that is positive if i is nonnegative. But I certainly take to heart
the many comments made, especially about the sign bit.

> I expect you knew all this, and were just hoping someone could
> show you something that you hadn't seen already that would
> let you have it all. Unfortunately, I don't think it can be so.
>
> So -- I'd recomment that you use bit twiddling where appropriate,
> and comment heavily about portability issues. If you really want
> to run on many platforms, you can isolate the platform specific
> stuff into a few places. Perhaps having separate subroutines for
> these for big and little end machines &c.

Thank you all for contributing to this thread. I have learned a lot
(as always).

glen herrmannsfeldt

2004-03-27, 12:17 am

James Giles wrote:
> Kevin G. Rhoads wrote:

(snip)
[color=darkred]

Bit twiddling doesn't directly have to do with endianness.
Accessing data as both words (storage units) and bytes, using
any operators, will show endianness. (Almost any access using
two different sizes of memory access will do it.)
[color=darkred]
> You should read the Bit Model in the standard document (or one
> of the Fortran books that cover it). The "endian" issues are all
> portably addressed for such "twiddling" *within* the program (but
> not for I/O). The others are all irrelevant as long as you don't
> "twiddle" the sign-bit. The sign bit is explicitly mentioned as a
> non-portable thing to manipulate with the bit intrinsics.

Well, it shows up for I/O assuming a byte oriented I/O system.

> As a practical matter, nothing but two's complement is very common
> anymore. So, even "twiddling" the sign bit is usually portably defined.
> Anyone actually have a modern platform that doesn't use two's
> complement for signed integers in Fortran?

Stories are that Unisys is still building ones complement machines.
CDC machines were also ones complement, but may be all gone by now.
The last sign magnitude machine I can think of is the 7090.

Assuming that the operators are standard, and proper consideration
is given to the sign bit, I don't see anything non portable.
[color=darkred]
> That's good advice for anything you do that's off the beaten track.
> Even things that are completely portable, if they're uncommon
> enough not to be completely familiar to most users, do the above.

Maybe everyone agrees with this.

-- glen

James Giles

2004-03-27, 12:17 am

glen herrmannsfeldt wrote:
> James Giles wrote:
....
>
> Stories are that Unisys is still building ones complement machines.

So they appear to be!! Wow! 36-bit words! 6- or 9-bit characters!
As seen in http://en.wikipedia.org/wiki/UNIVAC_1100/2200_series:

Data Formats
Fixed-point either integer or fraction
Whole word - 36 bit (one's complement)
Half word - two 18 bit fields per word (unsigned or one's complement)
Third word - three 12 bit fields per word (unsigned)
Quarter word - four 9 bit fields per word (unsigned)
Sixth word - six 6 bit fields per word (unsigned)
Floating point
Single precision - 36 bits: 1 sign bit, 8 bit characteristic, 27 bit
mantisa
Double precision - 72 bits: 1 sign bit, 11 bit characteristic, 60 bit
mantisa
Alphanumeric
Fieldata - 6 bits
ASCII - 9 bits

However, with a (brief) perusal of the Unisys website, I can find no
mention of these characteristics. Anyway, the low-order bits of the
integer and bit models should be portably consistent as long as the
sign bit isn't set - even if you're likely to port to a Unisys platform.
You'll have to worry about differences in wordsize anyway (even
if you don't do bit manipulation).

--
J. Giles

Richard Steiner

2004-03-27, 12:17 am

Here in comp.lang.fortran,
glen herrmannsfeldt <gah@ugcs.caltech.edu> spake unto us, saying:

>Stories are that Unisys is still building ones complement machines.

Absolutely. One should learn to pay homage to Minus Zero. :-)

http://www.fourmilab.ch/documents/univac/minuszero.html

The Unisys Clearpath IX line is essentially a newer Sperry 1100-series
box, and they are still in heavy use at some major airlines.

As is Fortran, I might add <g>.

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) s

ing employment.
See web site above for resume/CV and background.

Richard Steiner

2004-03-27, 12:17 am

Here in comp.lang.fortran,
"James Giles" <jamesgiles@worldnet.att.net> spake unto us, saying:

>So they appear to be!! Wow! 36-bit words! 6- or 9-bit characters!

FIELDATA rules, and CHARACTER variables are for wimps. If it isn't
good enough to store in an INTEGER array, it's simply not useful. :-)

>However, with a (brief) perusal of the Unisys website, I can find no
>mention of these characteristics.

Unisys is not good at disseminating information about their platforms.
They might accidentally SELL something, for gosh sake! :-)

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) s

ing employment.
See web site above for resume/CV and background.

Toon Moene

2004-03-27, 12:17 am

Richard Steiner wrote:

> Here in comp.lang.fortran,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> spake unto us, saying:
>
>
> Absolutely. One should learn to pay homage to Minus Zero. :-)
>
> http://www.fourmilab.ch/documents/univac/minuszero.html

<QUOTE>
As Prof. William C. Lynch remarked in the heyday of minus zero, "give a
programmer a glitch and he'll try to drive a truck through it", and
minus zero was a glitch big enough to roll a whole convoy through, good
buddy. Consider the following UNIVAC assembly code ...
</QUOTE>

Indeed. One of the more funny bug reports against a compiler (UNISYS's
one) runs as follows (paraphrasing the resolution to the error report):

The compiler, after dutifully parsing and translating to an internal
representation your huge subroutine, performed reaching definition
analysis on it. All basic blocks that where reachable were denoted by a
1 in an array of bits. At the end of the analysis, the compiler went
through the array of bits, checking 72 of them at the time against 0
(meaning unreachable). Unfortunately, the instruction used for this
also considers 72 1 bits as zero. Therefore, most of your routine was
declared unreachable and did not appear in the object code.

[Thank you for your continued support of our product]

--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Gary L. Scott

2004-03-27, 12:17 am

Richard Steiner wrote:
>
> Here in comp.lang.fortran,
> "James Giles" <jamesgiles@worldnet.att.net> spake unto us, saying:
>
>
> FIELDATA rules, and CHARACTER variables are for wimps. If it isn't
> good enough to store in an INTEGER array, it's simply not useful. :-)
>
>
> Unisys is not good at disseminating information about their platforms.
> They might accidentally SELL something, for gosh sake! :-)

Some of these stodgy old companies are really horrible at marketing.
How in heck did they get to be "old companies"...

Same for some Fortran compilers. You'd think they could at least put
out some decent packaging. I think that Lahey's is probably best
overall with CVF 6 a strong runner up (DVF 5 was so-so), although CVF's
documentation is tops. The Intel compiler and related product packaging
could use some brushing up as well.

>
> --
> -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
> OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
> Applications analyst/designer/developer (14 yrs) s

ing employment.
> See web site above for resume/CV and background.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

Democracy is two wolves and a sheep, voting on what to eat for dinner...
Liberty is a well armed sheep contesting the vote. - Thomas Jefferson

glen herrmannsfeldt

2004-03-27, 12:17 am

Toon Moene wrote:

(snip regarding ones complement machines)

> Indeed. One of the more funny bug reports against a compiler (UNISYS's
> one) runs as follows (paraphrasing the resolution to the error report):

> The compiler, after dutifully parsing and translating to an internal
> representation your huge subroutine, performed reaching definition
> analysis on it. All basic blocks that where reachable were denoted by a
> 1 in an array of bits. At the end of the analysis, the compiler went
> through the array of bits, checking 72 of them at the time against 0
> (meaning unreachable). Unfortunately, the instruction used for this
> also considers 72 1 bits as zero. Therefore, most of your routine was
> declared unreachable and did not appear in the object code.

Well, that is a side effect of ones complement.

Twos complement has the side effect that applying unary
minus, or IABS to the most negative number returns the
same negative number. I don't know of any bug reports
quite that funny, but there must be some.

-- glen

Richard Steiner

2004-03-27, 12:17 am

Here in comp.lang.fortran,
"Gary L. Scott" <garyscott@ev1.net> spake unto us, saying:

>Richard Steiner wrote:
>
>
>Some of these stodgy old companies are really horrible at marketing.
>How in heck did they get to be "old companies"...

In the case of Unisys, it probably helps somewhat that they still have
a number of long-time customers who were brought into the fold back in
the Sperry (or Burroughs, depending on the architecture) days.

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) s

ing employment.
See web site above for resume/CV and background.

Gordon Sande

2004-03-27, 12:17 am

In article <sgPXApHpvaTP092yn@visi.com>,
rsteiner@visi.com (Richard Steiner) wrote:

>Subject: Re: Integer representation
>From: rsteiner@visi.com (Richard Steiner)
>Reply-To: rsteiner@visi.com
>Organization: FIELDATA FORTRAN ENTHUSIASTS CLUB
>Date: Sat, 20 Mar 2004 20:04:28 -0600
>Newsgroups: comp.lang.fortran
>
>Here in comp.lang.fortran,
>"Gary L. Scott" <garyscott@ev1.net> spake unto us, saying:
>
>
>In the case of Unisys, it probably helps somewhat that they still have
>a number of long-time customers who were brought into the fold back in
>the Sperry (or Burroughs, depending on the architecture) days.

I recall reading a stock analysts assessment of IBM which basically said
"IBM will never have a new customer of a mainframe because everyone who
could possibly want one already has one but the demand for replacement
machines and computing growth will asure that the mainframe segment of IBM
will be profitable for the foreseeable future". Nothing unique about IBM
as the same analysis would seem to apply to the others. One might argue
about
the defintion of mainframe as the analysis seems to be more applicable to
central data processing where I/O and processing are both required than
to number crunching where I/O is relatively less important. There are
various other arguements for large central sources of compute power. I
recall statements to the effect that "the most effective local network
is called UniBus" to make the point that a single central VAX (with a
UniBus backplane aritchure) was often more effetive than a number of
networked PCs. It has long been true that the software running on the
machines is more valuable that the machines.

>--
> -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
> OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
> Applications analyst/designer/developer (14 yrs) s

ing employment.
> See web site above for resume/CV and background.

robin

2004-03-27, 12:17 am

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Toon Moene wrote:
>
> (snip regarding ones complement machines)
>
>
>
> Well, that is a side effect of ones complement.
>
> Twos complement has the side effect that applying unary
> minus, or IABS to the most negative number returns the
> same negative number.

Not in PL/I. That would cause overflow,
and an error message would be printed.

> I don't know of any bug reports
> quite that funny, but there must be some.
>
> -- glen

glen herrmannsfeldt

2004-03-27, 12:17 am

robin wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Toon Moene wrote:

(ones complement snip)

[color=darkred]
[color=darkred]
> Not in PL/I. That would cause overflow,
> and an error message would be printed.

According to
http://publibfp.boulder.ibm.com/cgi...=20020917160741

FIXEDOVERFLOW only works for FIXED DECIMAL data, not FIXED BINARY.

As far as I know, that isn't true of all compilers, but it seems to be
true now. Otherwise, if FIXEDOVERFLOW is disabled, the normal result
should be returned.

I am not sure now if Fortran is allowed to trap fixed point
overflow, but most that I know don't. There have at least
been random number generators that assumed it didn't.

-- glen

Richard Maine

2004-03-27, 12:17 am

(I'm replying only on comp.lang.fortran; I'm sure the pl1 folk
see more than enough Fortran-specific stuff as it is, and my
reply has nothing to do with PL1).

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> I am not sure now if Fortran is allowed to trap fixed point
> overflow,

Yes, it is allowed. Overflow (of any kind) is in the category of
things that put a program outside of the bounds of the standard.
The compiler can then do absolutely anything, including all the
usual ludicrous examples. Catching the overflow and aborting
with a suitable error message is not only allowed, it is a quite
reasonable option.

The IEEE stuff in the TR (and f2003) does add some overflow-related
stuff for floating point. But

1) implementation of that stuff is not mandatory.

2) in any case, the fact that it doesn't cover integer overflow
doesn't mean that compilers aren't allowed to do something
with integer overflow. It just means that it still lies
outside the standard and compilers can do anything they want
with it, just lik ebefore the TR.

> but most that I know don't. There have at least
> been random number generators that assumed it didn't.

Indeed. I've also noticed that most don't (and it has been discussed
here before).

--
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

James J. Weinkam

2004-03-27, 12:17 am

glen herrmannsfeldt wrote:
> robin wrote:
>
>
>
> (ones complement snip)
>
>
>
>
>
>
>
> According to
> http://publibfp.boulder.ibm.com/cgi...=20020917160741
>
>
> FIXEDOVERFLOW only works for FIXED DECIMAL data, not FIXED BINARY.
>
> As far as I know, that isn't true of all compilers, but it seems to be
> true now. Otherwise, if FIXEDOVERFLOW is disabled, the normal result
> should be returned.
>
The page you cited pertains to the Enterprise compiler. For the Personal and
I believe also the VA compilers FIXEDOVERFLOW applies to both DECIMAL and
BINARY fixed point operations except for the AIX implementations.

Every manual I have ever seen says something like, "if FIXEDOVERFLOW occurs
while disabled the program is in error." Nevertheless, in every
implementation I have used, the result was what one would expect so that, say,
the random number generator worked as designed and the overhead of raising the
condition and doing a normal return was avoided.

robin

2004-03-27, 12:17 am

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > robin wrote:
>
>
> (ones complement snip)
>
>
>
>
> According to
> http://publibfp.boulder.ibm.com/cgi...=20020917160741
>
> FIXEDOVERFLOW only works for FIXED DECIMAL data, not FIXED BINARY.

On some of the later compilers, both SIZE AND FIXEDOVERFLOW
will catch such errors.

The point is that it's detected in PL/I, and an error message
would be printed.

> As far as I know, that isn't true of all compilers, but it seems to be
> true now. Otherwise, if FIXEDOVERFLOW is disabled, the normal result
> should be returned.
>
> I am not sure now if Fortran is allowed to trap fixed point
> overflow, but most that I know don't. There have at least
> been random number generators that assumed it didn't.
>
> -- glen
>

robin

2004-03-27, 12:17 am

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>, Comcast Online
Date: Mon, 22 Mar 2004 11:18:13 GMT

| robin wrote:
| > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
| > Toon Moene wrote:
|
| (ones complement snip)
|
| >>Well, that is a side effect of ones complement.
|
| >>Twos complement has the side effect that applying unary
| >>minus, or IABS to the most negative number returns the
| >>same negative number.
|
| > Not in PL/I. That would cause overflow,
| > and an error message would be printed.
|
| According to
| http://publibfp.boulder.ibm.com/cgi...=20020917160741
|
| FIXEDOVERFLOW only works for FIXED DECIMAL data, not FIXED BINARY.
..
That is entirely irrelevant, and is in any case non-standard PL/I.
It applies to certain IBM compilers.
If the FIXEDOVERFLOW condition is not raised, then the SIZE condition is raised.
Either way, an error message is reported, and the program
can do something about it (recover, print message, continue, etc)
..
| As far as I know, that isn't true of all compilers, but it seems to be
| true now. Otherwise, if FIXEDOVERFLOW is disabled, the normal result
| should be returned.
..
There is no "normal" result if FIXEDOVERFLOW or SIZE is disabled.
In such case, the program is in error.
..
| I am not sure now if Fortran is allowed to trap fixed point
| overflow, but most that I know don't. There have at least
| been random number generators that assumed it didn't.
..
Fortran does not trap overflow.
..
|
| -- glen

David Frank

2004-03-27, 12:18 am

"robin" <robin_v@bigpond.mapson.com> wrote in message
news:Zr38c.121642$Wa.110304@news-server.bigpond.net.au...
>
> Fortran does not trap overflow.
>

As I corrected you last year in your alternate disquise as "john"

news:bt7Fb.60063$aT.8592@news-server.bigpond.net.au...[color=darkred]
words).[color=darkred]

[color=darkred]
> My compiler refuses to compile above statement, saying it OVERFLOWS!!

to which "john" aka Robin replied:[color=darkred]

to which I replied:
! -------------------
program test
m = 2147483647
k = m * 12345
write (*,*) k
end program

compiled with switches /traceback /check:overflow
execution creates following diagnostic
"program exception integer overflow line 3 test.f90"

glen herrmannsfeldt

2004-03-27, 12:18 am

David Frank wrote:

(snip)

> to which I replied:
> ! -------------------
> program test
> m = 2147483647
> k = m * 12345
> write (*,*) k
> end program
>
> compiled with switches /traceback /check:overflow
> execution creates following diagnostic
> "program exception integer overflow line 3 test.f90"

OK, usual disclaimer that language comparisons are to
better understand the use of language features.
Any other use is prohibited.

Much more fun is:

ON FIXEDOVERFLOW GOTO OOPS;
M=2147483647;
K=M*12345;
PUT LIST(K);
/* ... */

OOPS: PUT LIST('OOPS, M IS TOO BIG!');
PUT DATA(M,K);
STOP;

Whether it is needed or not, PL/I gives the program the
ability to determine what happens in a variety of
different conditions, and possibly recover. In this
case, printing out the values is sometimes useful.

One thing about ON units though, good or bad, is that
they are global. If you want to do end of file
checking in Fortran you put END= on each READ
statement. Each can be different. If you want
them all the same, then the global form is a little
easier. I have had programs where every READ
had END=99999 (my favorite END= statement).
If you want each READ to have a different
destination for its END= then the PL/I form requires
a separate ON statement for each, possibly with a little
more overhead.

I don't think I every used ERR= on a READ. Will that
allow control for conversion errors, such as non-numeric
characters where numeric ones are expected? PL/I gives
you the ability to find what the actual character was, and
if desired substitute a different character and retry the
conversion. I have known programs that read lists of numbers,
terminating on a non-numeric character, and then go on to
something else depending on what that character was.

I would probably say, though, that the ability to retry the
conversion with a different character is probably more
than necessary.

Oh well,

-- glen

Richard Maine

2004-03-27, 12:18 am

(Again, I'm replying to comp.lang.fortran only)

robin <robin_v@bigpond.mapson.com> writes:

> From: glen herrmannsfeldt <gah@ugcs.caltech.edu>, Comcast Online
> Date: Mon, 22 Mar 2004 11:18:13 GMT

> | I am not sure now if Fortran is allowed to trap fixed point
> | overflow, but most that I know don't. There have at least
> | been random number generators that assumed it didn't.
> .
> Fortran does not trap overflow.

That's too broadly stated to be accurate, and it answers a different
question than Glenn asked.

The Fortran standard, up to and including f95, does not require
trapping of overflow. However, neither does it forbid it. Note the
word "allowed" in Glenn's question. That's a pretty important word,
whithout which the question has a very different answer. The answer
to the question of whether it is allowed is yes. Many compilers do in
fact trap floating point overflow, and the IEEE TR even standardizes
it.

Glenn also was specifically asking about fixed point overflow. The
answer to the question he asked is still yes, that Fortran allows
it. However, in that case, few compilers do it.

--
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

Richard Maine

2004-03-27, 12:18 am

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> I don't think I every used ERR= on a READ. Will that
> allow control for conversion errors, such as non-numeric
> characters where numeric ones are expected?

No. Well, it might, but you can't depend on it. The standard
does not define the set of error conditions. Intuitively,
I'd expect such conversion errors to be errors that would
trigger err=, but the standard doesn't specify that and I've
run into compilers that surprised me. At least one compiler
by default "fixed up" nonnumeric characters for me, though I
later did find out how to disable this "helpful" behavior.

Note also, that reasonably plausible extensions can make
more characters valid as numeric characters. For a very specific
example, some compilers accept Q as a quad precision exponent
indicator.

Oh, and by the way, you mentioned never using err=. ALthough
the standard doesn't specify the set of error conditions, it
does specify what happens if you get one, and part of that
specification is that err= and iostat= are just different
forms of detecting the same errors. If you use iostat= and
check for values>0, that will be triggered for the same conditions
that trigger err= (whatever those conditions are).

--
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

robin

2004-03-27, 12:18 am

From: "David Frank" <dave_frank@hotmail.com>, RoadRunner - Central Florida
Date: Wed, 24 Mar 2004 06:35:36 GMT

| "robin" <robin_v@bigpond.mapson.com> wrote in message news:Zr38c.121642$Wa.110304@news-server.bigpond.net.au...
|
| > Fortran does not trap overflow.
....
| ! -------------------
| program test
| m = 2147483647
| k = m * 12345
| write (*,*) k
| end program
|
| compiled with switches /traceback /check:overflow
| execution creates following diagnostic
| "program exception integer overflow line 3 test.f90"

It's not in the language.

On the other hand, detecting, reportng, and recovering
from, such errors have been part of PL/I since it
was introduced in 1966.

Sponsored Links