Fortran - implementing UNSIGNED

Author

implementing UNSIGNED

robert.corbett@sun.com

2007-06-18, 4:15 am

On Jun 17, 1:15 am, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
wrote:

> Interesting. I'm unaware of any requests for unsigned integers in
> gfortran (though that may not be especially conclusive). Perhaps it's
> not a major Fortran implementation yet. :)

Perhaps people have not asked for UNSIGNED in gfortran,
but if you do a search for the word "unsigned" in this
group, you will find several requests for support for
unsigned integers in Fortran.

> I do find it an interesting choice to add feature this
> by extending the language with an UNSIGNED data type,
> rather than adding it within the existing language
> structure by defining unsigned kinds for INTEGER values.
> Personally, I would have gone with the latter.

I don't think you would hold on to that position long were
you to begin an implementation. First, there is the nasty
fact that the Fortran standard requires the model set for
any INTEGER type to include the value -1, which is hard to
represent as an unsigned integer. J3 has repeatedly ruled
that the model set of a type need only be a "best fit," but
the inquiry functions tend to be useful only when the values
in the model set are representable. I know members of J3 who
are uncomfortable with the "best fit" wording.

Then, there is the question of what values to use for the
kind type parameter values, the horrible promotion rules that
result, what to do about *-typing, etc.

> On the other hand, I suppose that defining it as a different
> data type means that one can easily define different
> semantics for it -- for instance, defining that overflow
> results in wraparound, as is done for unsigned types in C.
> That's philosophically a good bit cleaner than defining it
> as an extension for certain INTEGER kinds, I think.

One important difference between the way C handles unsigned
integers and the way Sun f90/f95 handles unsigned integers
is that Sun f90/f95 imposes severe restrictions on mixing
signed and unsigned integers in expressions. Sun f90/f95
does not allow the expression "I + U" where I and U are
signed and unsigned integer variables, respectively.
Explicit conversions are required in such cases. I have seen
too many C programmers get in trouble using such expressions
to allow them.

Bob Corbett

Brooks Moses

2007-06-18, 4:15 am

robert.corbett@sun.com wrote:
> On Jun 17, 1:15 am, Brooks Moses <bmoses-nos...@cits1.stanford.edu>
> wrote:
>
> Perhaps people have not asked for UNSIGNED in gfortran,
> but if you do a search for the word "unsigned" in this
> group, you will find several requests for support for
> unsigned integers in Fortran.

Oh, definitely -- I even remember some of the conversations here. And,
to be clear, I didn't mean to imply that I was doubting that this was a
common request for Sun's fortran; I just found it a curious difference
in our users.

Meanwhile, thanks for the comments on why Sun added an UNSIGNED type to
do this, rather than extending the INTEGER framework. The aspect of
restricting its interactions with signed integers, in particular, seems
like a good idea but wouldn't have initially occurred to me as a feature.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Kevin G. Rhoads

2007-06-18, 10:08 pm

>Then, there is the question of what values to use for the
>kind type parameter values,

Wouldn't using NEGATIVE kind values to select unsigned integers
be most in keeping with existing practice ;-)

glen herrmannsfeldt

2007-06-18, 10:08 pm

Kevin G. Rhoads wrote:
(someone wrote)
[color=darkred]
> Wouldn't using NEGATIVE kind values to select unsigned integers
> be most in keeping with existing practice ;-)

In that case, it would have been convenient to use negative
KIND for the appropriate COMPLEX type from its corresponding
REAL type. An imaginary KIND would have been more interesting,
but KIND is supposed to be integer. In either case, one could
use ABS to find the base KIND.

-- glen

Gary Scott

2007-06-18, 10:08 pm

Kevin G. Rhoads wrote:
>
>
> Wouldn't using NEGATIVE kind values to select unsigned integers
> be most in keeping with existing practice ;-)
Possibly, but kind seems to me to wrap too many possible attributes
related to kind into a single number. You may as well make it a bit
field. You could do that most likely without damaging existing value
choices.

--

Gary Scott
mailto:garylscott@sbcglobal dot 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

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Sponsored Links