Fortran - F2k8 BITS

Author

F2k8 BITS

gary.l.scott@lmco.com

2007-03-16, 7:07 pm

>"29 4.4.7 Bits type
>30 The bits type has a set of values composed of ordered >sequences of bits. The number of bits in
>31 the sequence is specified by the kind type parameter, which >shall be greater than or equal to zero.
>32 The processor shall provide representation methods with kind >type parameter values equal to every
>33 nonnegative integer less than or equal to a processor-determined >limit. This limit shall be at least as
>34 large as the storage size, expressed in bits, of every supported >kind of type integer, real, complex, and
>35 logical. Additional representation methods may be provided."

I'm now semi-happy with this implementation, but prefer that the
processor minimum limit to be supported be set at some value >= 2048.
Perhaps 32768 or 65535 is reasonable. Size of a default integer does
not meet my usual needs.

Brooks Moses

2007-03-16, 7:07 pm

gary.l.scott@lmco.com wrote:
>
> I'm now semi-happy with this implementation, but prefer that the
> processor minimum limit to be supported be set at some value >= 2048.
> Perhaps 32768 or 65535 is reasonable. Size of a default integer does
> not meet my usual needs.

One could argue that the number of bits should be a LENGTH type
parameter, not a KIND type parameter. At first glance, it _is_ pretty
clearly a LENGTH, not a KIND, though there may be other reasons why a
KIND is preferred. (I'm curious what they are, though.)

It's possible to write functions that take types with arbitrary LENGTH
parameters, but not ones with arbitrary KIND parameters, and it seems to
me rather a loss to exclude this with BITS variables.

On the other hand, perhaps the thought is that having this a KIND
parameter allows compilers to more easily use optimized processor
instructions for specific bit counts.

- Brooks

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

Gary Scott

2007-03-16, 7:07 pm

Brooks Moses wrote:
> gary.l.scott@lmco.com wrote:
>
>
>
> One could argue that the number of bits should be a LENGTH type
> parameter, not a KIND type parameter. At first glance, it _is_ pretty
> clearly a LENGTH, not a KIND, though there may be other reasons why a
> KIND is preferred. (I'm curious what they are, though.)
>
> It's possible to write functions that take types with arbitrary LENGTH
> parameters, but not ones with arbitrary KIND parameters, and it seems to
> me rather a loss to exclude this with BITS variables.
>
> On the other hand, perhaps the thought is that having this a KIND
> parameter allows compilers to more easily use optimized processor
> instructions for specific bit counts.
>

I guess I tend to agree there. You might want kind=onescomplement or
twoscomplement or ... in the future.

> - Brooks
>
>

--

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

Richard Maine

2007-03-16, 10:05 pm

Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:

> One could argue that the number of bits should be a LENGTH type
> parameter, not a KIND type parameter. At first glance, it _is_ pretty
> clearly a LENGTH, not a KIND, though there may be other reasons why a
> KIND is preferred. (I'm curious what they are, though.)

Don't focus too much on the English meaning of length. That is not the
basic definition of a length type parameter. The term is perhaps
unfortunate. It comes from character, which was the first type with such
a type parameter. For character, it is a length (English meaning).

You can have kind type parameters that represent lengths (English
meaning). You can have length type parameters that don't.

> It's possible to write functions that take types with arbitrary LENGTH
> parameters, but not ones with arbitrary KIND parameters, and it seems to
> me rather a loss to exclude this with BITS variables.

Ah. Now that's an essential difference. But you are looking at only one
side of it. It is possible to disambiguate generics based on kind type
parameters, but not length ones. That's very much a direct consequence
of the same distinction. You can't both allow a ingle function to accept
multiple values and also use those same values to disambiguate.

Fundamentally, what Gary is looking for is the "other" sort (took me a
few seconds to come up with a suitable word other than type/class/kind,
which have "overloaded" meanings here). of bit string. They are really 2
distinctly different things. You can't really do both sorts with the
same facility - not well anyway.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Sponsored Links