Symmetric Integer Ranges
Scott Robert Ladd
Section 13.7.1 of ISO/IEC 15390-1 sets forth a symmetrical model for
integers of a given bit size -- i.e, for every negative integer, there is
a corresponding positive integer. An 8-bit integer, for example, would
have the range [-127,127] under this model.
Two's complement representation allows an 8-bit integer to have a value in
the range [-128,127].
Naturally, this leads to a problem with functions such as ABS, given that
ABS(-128) equals 128, which is outside the range of representable numbers
in 8 bits.
As it stands now, gfortran strictly enforces the model, rejecting the
constant value -128 for an 8-bit integer. Intel Fortran 8.0 and Lahey
Fortran 6.1, however, accept -128 as a valid 8-bit constant. As an
interesting note, Intel and Lahey both define ABS(-128) as -128 (the
answer also given by C).
The debate might seem a bit pedantic until you consider interoperability.
The problem arose in two pieces of my code, one of which interacts with a
C program that uses -2147483648 as a flag value for 32-bit integers.
Consider a program (written in any arbitrary languages) that stores
-2147483648 in a file or pipe; while it is certainly a valid two's
complement number, it also falls outside the Fortran Standard's model.
My suggested solution was to add a flag to gfortran that allows
asymmetrical, two's complement integers. However, I'm curious as to what
the rest of the community thinks. What is the intent of 13.7.1 (or 13.4 in
the new standard)?
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing
Eric K.
> An interesting debate has arisen in the development of GNU Fortran 95.
>
> Section 13.7.1 of ISO/IEC 15390-1 sets forth a symmetrical model for
> integers of a given bit size -- i.e, for every negative integer, there is
> a corresponding positive integer. An 8-bit integer, for example, would
> have the range [-127,127] under this model.
>
> Two's complement representation allows an 8-bit integer to have a value in
> the range [-128,127].
>
> Naturally, this leads to a problem with functions such as ABS, given that
> ABS(-128) equals 128, which is outside the range of representable numbers
> in 8 bits.
> The debate might seem a bit pedantic until you consider interoperability.
Any program which requires that plus and/or minus 2**(B-1) be representable in a
B-bit signed integer type IMHO has inherent portability and interoperability
problems. Whether such a program functions at all depends on whether the
compiler uses unsigned integer instructions for signed integer arithmetic
and whether the processor traps on signed integer overflow. Take MIPS
for instance: SGI's compilers use unsigned instructions although the
architecture implements signed arithmetic instructions that trap on overflow.
Whether one can store -128 into a signed 8-bit integer is completely
compiler dependent.
Even the C standard does not assure that values less than
-127 are representable in signed char types (typically 8-bit integers)
and similarly for other signed integer types.
> My suggested solution was to add a flag to gfortran that allows
> asymmetrical, two's complement integers.
I think this is a bad idea. Besides the problems outlined above, additional
questions arise: what is the value of HUGE(1)? -HUGE(1)? Such a flag
fosters the development of programs that assume that -(-HUGE(1)) is a
negative number and that ABS(-HUGE(1)).ne.HUGE(1). I don't see the
technical merit of this.
--Eric
Richard Maine
> Section 13.7.1 of ISO/IEC 15390-1 sets forth a symmetrical model for
> integers of a given bit size -- i.e, for every negative integer, there is
> a corresponding positive integer. An 8-bit integer, for example, would
> have the range [-127,127] under this model.
...
> As it stands now, gfortran strictly enforces the model, rejecting the
> constant value -128 for an 8-bit integer.
I think you are confusing model numbers and representable numbers.
I don't think there is anything in the standard that requires the
range of representable numbers to be symmetric (I'd hope not).
If you can represent down to -128 and up to +127, then HUGE just needs
to return 127, saying that you can represent numbers to at least +127
and -127. I don't think there is any problem with being able to
represent some values outside of the tange -huge to +huge.
Of course abs(n) is going to have a problem if n is -128; this
we know. A more annoying problem is the difficulty of writing
a literal constant for -128. The problem there is that the
syntax of the standard parses -128 as a unary minus operation
acting on 128. If you can't have a 128, this is a problem.
> My suggested solution was to add a flag to gfortran that allows
> asymmetrical, two's complement integers.
I don't think you need a flag.
--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net
Steven G. Kargl
Richard Maine <nos...@see.signature> writes:
> Scott Robert Ladd <sc...@coyotegulch.com> writes:
>
>> Section 13.7.1 of ISO/IEC 15390-1 sets forth a symmetrical model for
>> integers of a given bit size -- i.e, for every negative integer, there is
>> a corresponding positive integer. An 8-bit integer, for example, would
>> have the range [-127,127] under this model.
> ...
>> As it stands now, gfortran strictly enforces the model, rejecting the
>> constant value -128 for an 8-bit integer.
>
> I think you are confusing model numbers and representable numbers.
> I don't think there is anything in the standard that requires the
> range of representable numbers to be symmetric (I'd hope not).
The model numbers for integers must be symmetric. The definition
in section 13.4 of the draft standard is clearly symmetric. The
problem is caused by the bit model in section 13.3, which does not
have a sign (bit). In the 8-bit integer type that Scott has
introduce, we have Z'FF' in the bit model, but no corresponding
integer in the integer model. Unfortunately, there is no bit type
or unsigned integer type in Fortran.
> If you can represent down to -128 and up to +127, then HUGE just needs
> to return 127, saying that you can represent numbers to at least +127
My version of draft standard does indicate "at least" for the
return value of HUGE. Indeed, one coudl interpret the draft standard
to mean "at most".
> and -127. I don't think there is any problem with being able to
> represent some values outside of the tange -huge to +huge.
>
> Of course abs(n) is going to have a problem if n is -128; this
> we know. A more annoying problem is the difficulty of writing
> a literal constant for -128. The problem there is that the
> syntax of the standard parses -128 as a unary minus operation
> acting on 128. If you can't have a 128, this is a problem.
What about BOZ?
--
Steve
Richard Maine
> I think you are confusing model numbers and representable numbers.
> I don't think there is anything in the standard that requires the
> range of representable numbers to be symmetric (I'd hope not).
ka...@x1-6-00-00-c5-b3-45-24.client.attbi.com (Steven G. Kargl) writes:
> The model numbers for integers must be symmetric.
Yes. That was exactly my point - model numbers, not representable
ones.
> What about BOZ?
The standard only defines positive BOZ literals. If it defined negative
ones, then there would be dependencies on bit size and representation
(unless it did something like use a minus sign for a literal of the
negative, which wouldn't be very bit-pattern-like).
glen herrmannsfeldt
> In article <m24qvnd...@vega.dsl.att.net>, I wrote:
(snip)
> ka...@x1-6-00-00-c5-b3-45-24.client.attbi.com (Steven G. Kargl) writes:
>>The model numbers for integers must be symmetric.
> Yes. That was exactly my point - model numbers,
> not representable ones.
>>What about BOZ?
> The standard only defines positive BOZ literals. If it defined negative
> ones, then there would be dependencies on bit size and representation
> (unless it did something like use a minus sign for a literal of the
> negative, which wouldn't be very bit-pattern-like).
Well, in many places the standard only allows positive numbers, though
the unary negation operator will fix that.
One of the few places that traditionally allowed signed constants was
in DATA statements, and related constructs, also convenient places
for BOZ literals.
I presume Fortran, like C, allows ones complement and sign magnitude
representations, which are symmetric. (A discussion of this comes
up often in comp.lang.c, much more often than people actually running
on such machines.
Users of BOZ constants should know the number representation on their
machine. I am told that Unisys still sells ones complement machines.
-- glen