Sujet : Re: Cray style vectors
De : tkoenig (at) *nospam* netcologne.de (Thomas Koenig)
Groupes : comp.archDate : 11. Mar 2024, 22:43:19
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <usnttn$3re5t$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : slrn/1.0.3 (Linux)
On 2024-03-11, Michael S <
already5chosen@yahoo.com> wrote:
On Mon, 11 Mar 2024 18:19:19 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
>
On 2024-03-11, Michael S <already5chosen@yahoo.com> wrote:
On Mon, 11 Mar 2024 18:01:31 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Thomas Koenig <tkoenig@netcologne.de> schrieb:
David Brown <david.brown@hesbynett.no> schrieb:
On 20/02/2024 07:31, Thomas Koenig wrote:
Even further on the side: I wrote up a proposal for finally
introducing a wrapping UNSIGNED type to Fortran, which
hopefully will be considered in the next J3 meeting, it can be
found at https://j3-fortran.org/doc/year/24/24-102.txt .
In this proposal, I intended to forbid UNSIGNED variables in
DO loops, especially for this sort of reason.
(Testing a new news server, my old one was decomissioned...)
I was quite delighted, but also a little bit surprised that the
proposal (somewhat modified) actually passed.
Now, what's left is the people who do not want modular arithmetic,
for a reason that I am unable to fathom. I guess they don't like
multiplicative hashes...
>
What do they like?
To declare unsigned overflow UB? Or implementation defined? Or
trapping?
Illegal, hence an implementation would be free to trap or start
World War III (with a bit of an expectation that compilers would
trap when supplied with the right options).
>
So, speaking in C Standard language, UB.
Yes, that would be the translation. In Fortran terms, it would
violate a "shall" directive.
>
>
My expecation is different: It would then be treated like signed
overflow, which is also illegal in Fortran. So, everybody will
implement it as if it were modular 2^n anyway, plus start optimizing
on the assumption that overflow cannot happen.
>
>
Yes, I'd expect the same.
>
And, since in Fortran, arrays can start at arbitrary lower bounds
(and array can have a lower bound of -42 and an upper bound of -21,
for example), the use of unsigned integers for array indices is
somewhat less than in programming languages such as C or (I believe)
Rust where they always start at zero.
>
As discussed here just recently, there are good reason to avoid
'unsigned' array indices in performance-oriented programs running under
IL32P64 or I32LP64 C environments. Everything else is preferable -
int, ptrdiff_t, size_t. Now, opinions on which of the 3 is most
preferable, tend to vary.
>
What is the size of Fortran's default UNSIGNED ?
It is not yet in the language; a paper has been passed by J3,
but it needs to be put to WG5, and WG5 has to agree that J3 should
put it into the standard proper for Fortran 202y (202x just
came out as Fortran 2023).
But if it does go in, it is likely that it will have the same
size as INTEGER, which is usually 32 bits.
However, what I did put in the paper (and what the subsequent
revision by a J3 subcommittee left in) is a prohibition against
using unsigneds in a DO loop. The reason is semantics of
negative strides.
Currently, in Fortran, the number of iterations of the loop
do i=m1,m2,m3
...
end do
is (m2-m1+m3)/m3 unless that value is negative, in which case it
is zero (m3 defaults to 1 if it is not present).
So,
do i=1,3,-1
will be executed zero times, as will
do i=3,1
Translating that into arithmetic with unsigned integers makes
little sense, how many times should
do i=1,3,4294967295
be executed?