On 8/27/22 5:13 PM, Thomas Koenig wrote:
> gah4 <gah4@u.washington.edu> schrieb:
>> On Saturday, August 27, 2022 at 2:30:15 AM UTC-7, Thomas Koenig wrote:
>>
>> (snip)
>>
>>>> Now for this case, you want a DO loop to start at zero, which Fortran 66
>>>> didn't allow.
>>
>>> Really? You mean that
>>
>>> DO 10 I=0,1
>>
>>> would not be allowed?
>>
>> Yes, not allowed.
>
> I have the Fortran 66 standard before me, and I find no such
> restriction in 7.1.2.8 (nor would it make sense at all).
>
> Which part of the standard are you referring to?

It is right there in that section in the paragraph that starts with (3).
The three integers m1, m2, and m3 must be greater than zero.

The only justification I can see for this is that they wanted to be able
to implement the loop logic with unsigned integers. Even then I don't
know why zero was not allowed.

$.02 -Ron Shepard

On 8/28/22 9:28 AM, Charlie Roberts wrote:
[...]
> The authors of "Numerical Recipes" started out with F77 and so all the
> code in their first book has arrays starting at 1. When they brought
> out the C version, they resorted to just this trick!

If I remember correctly, the code in the chapters was written in Pascal,
and there was an appendix that had fortran code. Or maybe it was the
other way around? I don't remember what version of fortran they used, bu
the book was published before there were any f77 compilers available, so
I'm guessing that it was f66+extensions. Then they wrote the f77 version
a year or two later.

So the conventions they were mimicking in C were not really f77 (or even
Pascal), they were standard math conventions. C at that time was not
designed to do math. It did not even respect grouping of operands by
parentheses. This frustrating flaw in the C language would be corrected
some 19 years after the first language definition in the ANSI C version
of the language, c89.

When the NR authors did the pointer decrement hack, they took a lot of
criticism for writing nonstandard code. Then when they wrote the c++
version, they adjusted the math notation to fit the limitations of the
language.

$.02 -Ron Shepard

On Monday, August 29, 2022 at 5:07:13 PM UTC+10, Ron Shepard wrote:
> On 8/27/22 5:13 PM, Thomas Koenig wrote:
> > gah4 <ga...@u.washington.edu> schrieb:
> >> On Saturday, August 27, 2022 at 2:30:15 AM UTC-7, Thomas Koenig wrote:
> >>
> >> (snip)
> >>
> >>>> Now for this case, you want a DO loop to start at zero, which Fortran 66
> >>>> didn't allow.
> >>
> >>> Really? You mean that
> >>
> >>> DO 10 I=0,1
> >>
> >>> would not be allowed?
> >>
> >> Yes, not allowed.
> >
> > I have the Fortran 66 standard before me, and I find no such
> > restriction in 7.1.2.8 (nor would it make sense at all).
> >
> > Which part of the standard are you referring to?
> It is right there in that section in the paragraph that starts with (3).
> The three integers m1, m2, and m3 must be greater than zero.
>
> The only justification I can see for this is that they wanted to be able
> to implement the loop logic with unsigned integers.
..
Definitely not.
The control variable at least would be an ordinary signed integer,
because that variable could be used in integer and/or real
expressions.
..
And if m2 and m3 are variables,, then for the same reason,
these would be ordinary signed integers.
..
> Even then I don't know why zero was not allowed.

On Monday, August 29, 2022 at 12:07:13 AM UTC-7, Ron Shepard wrote:

(snip on DO loops)

> It is right there in that section in the paragraph that starts with (3).
> The three integers m1, m2, and m3 must be greater than zero.
> The only justification I can see for this is that they wanted to be able
> to implement the loop logic with unsigned integers. Even then I don't
> know why zero was not allowed.

There are a lot of restrictions in Fortran 66 that aren't at all obvious.

I thought this one went back to Fortran I on the 704, but don't see it there.

Some machines have special hardware registers for loops,
and might have restrictions not obvious today. In any case, the
restriction is there, and was enforced by some compilers for
constants, that otherwise didn't need to be restricted.

In comp.lang.c++ Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> ???Why do arrays start at 0?"
> https://buttondown.email/hillelwayne/archive/why-do-arrays-start-at-0/
>
> "It's not the reason you think. No, it's not that reason either.???
>
> My Fortran starts at one. My C++ starts at zero. This has made my life
> hell.

I don't know if it's the *original* reason, but I would assume that at least
in C one of the main reasons is the principle of maximum efficiency.

In many processor architectures the concept of "array" exists, at least
when it comes to values of the register sizes (ie. usually 1-byte,
2-byte, 4-byte and 8-byte elements, the last one at least on 64-bit
architectures). Prominently the concept of an indexable array exists
in the x86 architecture. (I don't remember now if it also exists in
the ARM architecture, but I would guess so.)

Generally when a processor architecture supports the concept of an "array",
it does so by having instructions that take (at least) two registers as
the input or the output parameter: A base address, and an offset. The
memory location of the element is calculated by adding those two. (The
number of bytes that an offset of 1 jumps depends on the instruction,
and thus multi-byte elements are supported.)

Thus zero-indexing is extraordinarily natural in processor architectures:
The "index" is actually an offset. It's a value you add to the base
address in order to get to the location you want. Thus, the first element
is at index/offset 0.

Since that's the case, the most optimal way to handle low-level arrays is
to have 0-based indexing in the programming language as well. That way
you don't need to be subtracting 1 from the index every time an array is
accessed (or you don't need an extraneous unused element at the beginning
of the array, consuming memory for no reason).

Also, since C supports pointer arithmetic, many operations become simpler.
Such as getting the index of an element when what you have is a pointer to
it (and the pointer to the start of the array).

On 8/29/22 3:30 AM, Robin Vowels wrote:
> On Monday, August 29, 2022 at 5:07:13 PM UTC+10, Ron Shepard wrote:
[...]
>> The only justification I can see for this is that they wanted to be able
>> to implement the loop logic with unsigned integers.
> .
> Definitely not.
> The control variable at least would be an ordinary signed integer,
> because that variable could be used in integer and/or real
> expressions.

Yes, the index variable and all three variables m1, m2, and m3 are
fortran integers. There was no unsigned integer type in fortran then. or
now for that matter, so these variables were all regular fortran signed
integers.

> And if m2 and m3 are variables,, then for the same reason,
> these would be ordinary signed integers.
> .
>> Even then I don't know why zero was not allowed.

Yes, see above. Fortran did not have unsigned integers, then or now. But
as I said before, the only reason I can imagine for having that
limitation in the language is that they wanted to allow the processor to
implement the loop control logic using unsigned integers in whatever
instruction set the compiled code was running.

$.02 -Ron Shepard

On Tuesday, August 30, 2022 at 1:13:37 AM UTC+10, Ron Shepard wrote:
> On 8/29/22 3:30 AM, Robin Vowels wrote:
> > On Monday, August 29, 2022 at 5:07:13 PM UTC+10, Ron Shepard wrote:
> [...]
> >> The only justification I can see for this is that they wanted to be able
> >> to implement the loop logic with unsigned integers.
> > .
> > Definitely not.
> > The control variable at least would be an ordinary signed integer,
> > because that variable could be used in integer and/or real
> > expressions.
> Yes, the index variable and all three variables m1, m2, and m3 are
> fortran integers. There was no unsigned integer type in fortran then. or
> now for that matter, so these variables were all regular fortran signed
> integers.
> > And if m2 and m3 are variables,, then for the same reason,
> > these would be ordinary signed integers.
> > .
> >> Even then I don't know why zero was not allowed..

> Yes, see above. Fortran did not have unsigned integers, then or now. But
> as I said before, the only reason I can imagine for having that
> limitation in the language is that they wanted to allow the processor to
> implement the loop control logic using unsigned integers in whatever
> instruction set the compiled code was running.
..
Some hardware used signed-magnitude form.
The arithmetic for incrementing the control variable
would have been implemented using whatever hardware was normally
used for integer arithmetic anywhere in the machine.
..
Similarly for comparing the loop control variable with m2.

On Monday, August 29, 2022 at 4:16:00 AM UTC-7, Juha Nieminen wrote:

(snip)

> I don't know if it's the *original* reason, but I would assume that at least
> in C one of the main reasons is the principle of maximum efficiency.
> In many processor architectures the concept of "array" exists, at least
> when it comes to values of the register sizes (ie. usually 1-byte,
> 2-byte, 4-byte and 8-byte elements, the last one at least on 64-bit
> architectures). Prominently the concept of an indexable array exists
> in the x86 architecture. (I don't remember now if it also exists in
> the ARM architecture, but I would guess so.)
BCPL, a predecessor of C, was written on a word addressable
machine. Pointer arithmetic was integer arithmetic. It was with
C that variables could be larger than the addressable unit,
and that pointers (addresses) incremented and decremented
in appropriate sized units.

In any case, early C (and B and BCPL) programmers were likely
also assembly programmers, and would have been used
to 0 origin indexing.

> Generally when a processor architecture supports the concept of an "array",
> it does so by having instructions that take (at least) two registers as
> the input or the output parameter: A base address, and an offset. The
> memory location of the element is calculated by adding those two. (The
> number of bytes that an offset of 1 jumps depends on the instruction,
> and thus multi-byte elements are supported.)

For many machines, you have to multiply by the element size,
but yes some do it for you. C pointer arithmetic is defined in terms
of the size of the pointed-to object, and array indexing is defined
in terms of pointer arithmetic.
> Thus zero-indexing is extraordinarily natural in processor architectures:
> The "index" is actually an offset. It's a value you add to the base
> address in order to get to the location you want. Thus, the first element
> is at index/offset 0.
> Since that's the case, the most optimal way to handle low-level arrays is
> to have 0-based indexing in the programming language as well. That way
> you don't need to be subtracting 1 from the index every time an array is
> accessed (or you don't need an extraneous unused element at the beginning
> of the array, consuming memory for no reason).

In the case of Fortran, starting with static arrays, the compiler can subtract
before generating the address constant, such that the subtract is done
at compile time. No run-time cost.

For allocatable arrays, it can adjust the offset once, and use that.

For automatic variables on the stack, the stack pointer offset is
computed once.

The way C pointers are defined, that would not be quite as
easy to do. Or, C pointers are defined the way they are to make it easier.

Fortran was originally Formula Translation, and mathematicians did,
and still do, use 1 based indexing for matrices and vectors.

> Also, since C supports pointer arithmetic, many operations become simpler.
> Such as getting the index of an element when what you have is a pointer to
> it (and the pointer to the start of the array).

Note that it gets more interesting for Fortran. When you pass an array
as an argument to a subroutine, it loses the original origin.
(Well, most of the time. Remembering when it does and doesn't is
probably harder than figuring out 0 vs.1 origin.)

One that C programmers like to do, and I suspect was faster on
many early machines, is index through arrays with a pointer to an array,
indexing it as it goes. That means no subscript calculation in the loop.
Many early C processors didn't have multiply, or had slow multiply.

However, one of the favorite optimizations for Fortran compilers
is strength reduction, converting multiply inside a loop into addition
as the loop increments. The result is pretty much the same.

Ron Shepard <nospam@nowhere.org> schrieb:
> On 8/28/22 9:28 AM, Charlie Roberts wrote:
> [...]
>> The authors of "Numerical Recipes" started out with F77 and so all the
>> code in their first book has arrays starting at 1. When they brought
>> out the C version, they resorted to just this trick!
>
> If I remember correctly, the code in the chapters was written in Pascal,
> and there was an appendix that had fortran code. Or maybe it was the
> other way around?

The first edition was released in 1986, for Fortran, see the
Wikipedia article.

> I don't remember what version of fortran they used, bu
> the book was published before there were any f77 compilers available,

This is not the case. I have a version of a manual for VS Fortran,
from February 1981, which describes a Fortran 77 compiler.

> so
> I'm guessing that it was f66+extensions. Then they wrote the f77 version
> a year or two later.

I have the first edition, it is definitely Fortran 77.

On Tuesday, August 30, 2022 at 10:18:08 AM UTC-7, Thomas Koenig wrote:

(snip)

> This is not the case. I have a version of a manual for VS Fortran,
> from February 1981, which describes a Fortran 77 compiler.

WATFIV had most of the Fortran 77 features in 1973, but we
didn't know it at the time.

As well as I know, it was testing them out before the standard
was done. Much more fun at the time, though, than Fortran IV.