From another thread, discussion between David and Bart:

D> But if you have just one starting point, 0 is the sensible one.
D> You might not like the way C handles arrays (and I'm not going to
D> argue about it - it certainly has its cons as well as its pros),
D> but even you would have to agree that defining "A[i]" to be the
D> element at "address of A + i * the size of the elements" is neater
D> and clearer than one-based indexing.

B> That's a crude way of defining arrays. A[i] is simply the i'th
B> element of N slots, you don't need to bring offsets into it.

Why call it 'i'th? I know people do but wouldn't it be easier to call it
'element n' where n is its index? Then that would work with any basing.

B> With 0-based, there's a disconnect between the ordinal number of
B> the element you want, and the index that needs to be used. So A[2]
B> for the 3rd element.

Why not call A[2] element 2?

BTW, Bart, do you consider the first ten numbers as 1 to 10 rather than
0 to 9? If so, presumably you count the hundreds as starting at 111.
That's not the most logical viewpoint.

Similarly, on the day a child is born do you say that he is one year old?

--
James Harris

On 2021-11-30 09:07, James Harris wrote:
> From another thread, discussion between David and Bart:
>
> D> But if you have just one starting point, 0 is the sensible one.
> D> You might not like the way C handles arrays (and I'm not going to
> D> argue about it - it certainly has its cons as well as its pros),
> D> but even you would have to agree that defining "A[i]" to be the
> D> element at "address of A + i * the size of the elements" is neater
> D> and clearer than one-based indexing.
>
> B> That's a crude way of defining arrays. A[i] is simply the i'th
> B> element of N slots, you don't need to bring offsets into it.
>
> Why call it 'i'th? I know people do but wouldn't it be easier to call it
> 'element n' where n is its index? Then that would work with any basing.

You are confusing position with index. Index can be of any ordered type.
Position is an ordinal number: first, second, third element from the
array beginning.

> B> With 0-based, there's a disconnect between the ordinal number of
> B> the element you want, and the index that needs to be used. So A[2]
> B> for the 3rd element.
>
> Why not call A[2] element 2?

Because it would be wrong. In most languages A[2] means the array
element corresponding to the index 2.

Remember, array is a mapping:

array : index -> element

In well-designed languages it is also spelt as a mapping:

A(2)

> BTW, Bart, do you consider the first ten numbers as 1 to 10 rather than
> 0 to 9? If so, presumably you count the hundreds as starting at 111.
> That's not the most logical viewpoint.
>
> Similarly, on the day a child is born do you say that he is one year old?

Similar confusion here. There is date and duration. Date is absolute
like index. Duration is relative like position.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 30/11/2021 08:07, James Harris wrote:
> From another thread, discussion between David and Bart:
>
> D> But if you have just one starting point, 0 is the sensible one.
> D> You might not like the way C handles arrays (and I'm not going to
> D> argue about it - it certainly has its cons as well as its pros),
> D> but even you would have to agree that defining "A[i]" to be the
> D> element at "address of A + i * the size of the elements" is neater
> D> and clearer than one-based indexing.
>
> B> That's a crude way of defining arrays. A[i] is simply the i'th
> B> element of N slots, you don't need to bring offsets into it.
>
> Why call it 'i'th? I know people do but wouldn't it be easier to call it
> 'element n' where n is its index? Then that would work with any basing.

The most common base I use is 1 (about 2/3 of the time). You have a
3-element array, the 1st is numbered 1, the last is 3, the 3rd is 3 too.
All very intuitive and user-friendly.

But this is that 3-element array as 3 adjoining cells:

mmmmmmmmmmmmmmmmmmmmmmmmm
m m m m
m 1 m 2 m 3 m Normal indexing
m +0 m +1 m +2 m Offsets
m m m m
mmmmmmmmmmmmmmmmmmmmmmmmm

0 1 2 3 Distance from start point

The numbering is 1, 2, 3 as I prefer when /counting/. Or you can choose
to use offsets from the first element as C does, shown as +0, +1, +2.

There is also /measuring/, which applies more when each cell has some
physical dimension, such as 3 adjoining square pixels. Or maybe these
are three fence panels, and the vertical columns are the posts.

Here, offsets are again used, but notionally considered to be measured
from the first 'post'.

In this case, an 'index' of 2.4 is meaningful, being 2.4 units from the
left, and 40% along that 3rd cell.

Measurement can also apply when the cells represent other units, like
time as DAK touched on: how many days from Monday to Wednesday? That is
not that meaningful when a day is considered an indivisible unit like an
array cell.

You can say the difference is +2 days. In real life, it depends on what
time Monday, and what time Wednesday, so it can vary from 24 to 72 hours
(24:00 Mon to 00:00 Wed, or 00:00 Mon to 24:00 Wed).

>
> B> With 0-based, there's a disconnect between the ordinal number of
> B> the element you want, and the index that needs to be used. So A[2]
> B> for the 3rd element.
>
> Why not call A[2] element 2?

See N-based below.

>
> BTW, Bart, do you consider the first ten numbers as 1 to 10 rather than
> 0 to 9? If so, presumably you count the hundreds as starting at 111.
> That's not the most logical viewpoint.

It's not always logical; I celebrated the millennium on 1-1-2000 like
everyone else. It's a big deal when the '19' year prefix in use for 100
years, suddenly changes to '20'.

> Similarly, on the day a child is born do you say that he is one year old?

This is 'measurement'; see above. However my dad always liked to round
his age up to the next whole year; most people round down! So the child
would be 0 years, but in its first year.

However there is not enough resolution using years to accurately measure
ages of very young children, so people also use days, weeks and months.

So, when do I use 0-based:

(a) When porting zero-based algorithms from elsewhere. This works more
reliably than porting one-based code to C.

[N]int A # 1-based (also [1:N] or [1..N]
[0:N]int A # 0-based (also [0..N-1])

(b) When I have a regular array normally index from 1, but that index
can have 0 as an escape value, meaning not set or not valid:

global tabledata() [0:]ichar opndnames =
(no_opnd=0, $),
(mem_opnd, $),
(memaddr_opnd, $),
....

(c) When the value used as index naturally includes zero.

When do I use N-based: this is much less common. An example might be:

['A'..'Z']int counts

Here, it becomes less meaningful to use the ordinal position index: the
first element has index 65! So this kind of array has more in common
with a hash or dict type, when the index is a key that can anything.

But for the special case of the keys being consecutive integers over a
small range, then a regular, fixed-size array indexed by that range is
far more efficient.

However, the slice counts['D'..'F] will have elements indexed from 1..3,
not 'D'..'F'. There are some pros and cons, but overall the way I've
done it is simpler (slices have a lower bound known at compile-time, not
runtime).

On 30/11/2021 08:07, James Harris wrote:
> BTW, Bart, do you consider the first ten numbers as 1 to 10 rather
> than 0 to 9?

Until quite recently, Bart and almost everyone else would
certainly have done exactly that. Zero, as a number, was invented
in modern times [FSVO "modern"!]. "You have ten sheep and you sell
ten of them. How many sheep do you now have?" "??? I don't have
/any/ sheep left." Or, worse, "You have ten sheep and you sell
eleven of them. How many sheep do you now have?" "??? You can't
do that, it would be fraud." Or the Peano axioms for the natural
numbers: 1 is a natural number; for every n in the set, there
is a successor n' in the set; every n in the set /except/ 1 is
the successor of a unique member; .... Or look at any book;
only in a handful of rather weird books trying to make a point
is there a page 0. When you first learned to count, you almost
certainly started with a picture of a ball [or whatever] and
the caption "1 ball", then "2 cats", "3 trees", "4 cakes", ...
up to "12 candles"; not with an otherwise blank page showing
"0 children". [Note that 0 as a number in its own right is
different from the symbol 0 as a placeholder in the middle or at
the end of a number in Arabic numerals.]

Maths, inc numbers, counting, and science generally, got
along quite happily with only positive numbers from antiquity up
to around 1700, when the usefulness of the rest of the number
line became apparent, at least in maths and science if not to
the general public.

/Now/ the influence of computing has made zero-based
indexing more relevant. So have constructive arguments more
generally; eg, the surreal numbers -- a surreal number is two
sets of surreal numbers [with some conditions], so that the
natural starting point is there the two sets are empty, giving
the "empty" number, naturally identified with zero. So it was
only around 1970 that people started taking seriously the idea
of counting from zero. Of course, once you do that, then you
can contemplate not counting "from" anywhere at all; eg the
idea [which I first saw espoused by vd Meulen] that arrays
could be thought of as embedded in [-infinity..+infinity],
treated therefore always in practice as "sparse" arrays, with
almost all elements being "virtual".

> If so, presumably you count the hundreds as starting at
> 111. That's not the most logical viewpoint.

Note that we normally read that number as "one hundred
/and/ eleven", suggesting that it's eleven into the second
hundred. It's not illogical to suggest that the "hundreds"
start immediately after 100, nor to suggest that they start
/at/ 100. Dates are a special case, as there was [of course]
no year zero, so centuries "definitely" end on the "hundred"
years, not start on them. But, as Bart pointed out, there is
still an interest in the number clicking over from 1999 to
2000, and therefore the chance to get two parties.

> Similarly, on the day a child is born do you say that he is one year
> old?

Is this child your first-born? Would you call your
eighth-born child "Septimus"?

Slightly more seriously, there are of course legal
questions surrounding this [esp when they concern the age
of majority and such-like], and they are resolved by the
law and by conventions [which may well differ around the
world] rather than by maths and logic.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Bendel

On 01/12/2021 01:50, Andy Walker wrote:
> On 30/11/2021 08:07, James Harris wrote:
>> BTW, Bart, do you consider the first ten numbers as 1 to 10 rather
>> than 0 to 9?
>
>     Until quite recently, Bart and almost everyone else would
> certainly have done exactly that.

Remember Bart, and some others, think it is "natural" to count from
32767 on to -32767 (or larger type equivalents - 16-bit numbers are
easier to write) in the context of programming. Clearly they would not
think that way when counting sheep. So why apply sheep counting to
other aspects of programming? Personally I prefer to think you can't
add 1 to 32767 (or larger type equivalents), which is of course almost
equally silly in terms of sheep.

>  Zero, as a number, was invented
> in modern times [FSVO "modern"!].

(Historical note:

It reached Europe around 1200, but had been around in India, amongst
other countries, for a good while before that. The Mayans also had a
number zero earlier on. It is difficult to be precise about times,
however, because "zero" is used for many different purposes and ideas
changed and evolved over time.)

>  "You have ten sheep and you sell
> ten of them.  How many sheep do you now have?"  "??? I don't have
> /any/ sheep left."  Or, worse, "You have ten sheep and you sell
> eleven of them.  How many sheep do you now have?" "??? You can't
> do that, it would be fraud."  Or the Peano axioms for the natural
> numbers:  1 is a natural number;  for every n in the set, there
> is a successor n' in the set;  every n in the set /except/ 1 is
> the successor of a unique member; ....  Or look at any book;
> only in a handful of rather weird books trying to make a point
> is there a page 0.  When you first learned to count, you almost
> certainly started with a picture of a ball [or whatever] and
> the caption "1 ball", then "2 cats", "3 trees", "4 cakes", ...
> up to "12 candles";  not with an otherwise blank page showing
> "0 children".  [Note that 0 as a number in its own right is
> different from the symbol 0 as a placeholder in the middle or at
> the end of a number in Arabic numerals.]
>

The first Peano axiom is "0 is a natural number". They start counting
at zero, not at one.

There is no mathematical consensus as to whether the set of natural
numbers ℕ starts with 0 or 1. But there is no doubt that the numbers
generated by the Peano axioms start at 0.

Other than that, we can simply say that different types of number are
useful for different purposes.

>     Maths, inc numbers, counting, and science generally, got
> along quite happily with only positive numbers from antiquity up
> to around 1700, when the usefulness of the rest of the number
> line became apparent, at least in maths and science if not to
> the general public.
>

Negative numbers long pre-date the general acceptance of 0 as a
"number". They were used in accountancy, as well as by a few
mathematicians. But there general use, especially in Europe, came a lot
later.

>     /Now/ the influence of computing has made zero-based
> indexing more relevant.  So have constructive arguments more
> generally;  eg, the surreal numbers -- a surreal number is two
> sets of surreal numbers [with some conditions], so that the
> natural starting point is there the two sets are empty, giving
> the "empty" number, naturally identified with zero.  So it was
> only around 1970 that people started taking seriously the idea
> of counting from zero.  Of course, once you do that, then you
> can contemplate not counting "from" anywhere at all;  eg the
> idea [which I first saw espoused by vd Meulen] that arrays
> could be thought of as embedded in [-infinity..+infinity],
> treated therefore always in practice as "sparse" arrays, with
> almost all elements being "virtual".
>

I am quite confident that the idea of starting array indexes from 0 had
nothing to do with surreals. Surreal numbers are rather esoteric, and
very far from useful in array indexing in programming (which always
boils down to some kind of finite integer).

On 01/12/2021 08:43, David Brown wrote:
> On 01/12/2021 01:50, Andy Walker wrote:
>> On 30/11/2021 08:07, James Harris wrote:
>>> BTW, Bart, do you consider the first ten numbers as 1 to 10 rather
>>> than 0 to 9?
>>
>>     Until quite recently, Bart and almost everyone else would
>> certainly have done exactly that.
>
> Remember Bart, and some others, think it is "natural" to count from
> 32767 on to -32767 (or larger type equivalents - 16-bit numbers are
> easier to write) in the context of programming.

Remember David think's it's natural to count from 65535 onto 0.

I simply acknowledge that that is how most hardware works. Otherwise how
do you explain that the upper limit of some value is (to ordinary
people) the arbitrary figure of 32,767 or 65,535 instead of 99,999?

> Clearly they would not
> think that way when counting sheep. So why apply sheep counting to
> other aspects of programming? Personally I prefer to think you can't
> add 1 to 32767 (or larger type equivalents), which is of course almost
> equally silly in terms of sheep.

It might be silly, but you'd still be stuck if you had 33,000 sheep to
count; what are you going to do?

> I am quite confident that the idea of starting array indexes from 0 had
> nothing to do with surreals.

More to do with conflating them with offsets.

> Surreal numbers are rather esoteric, and
> very far from useful in array indexing in programming (which always
> boils down to some kind of finite integer).
>

a:=[:]

a{infinity} := 100
a{-infinity} := 200

println a # [Infinity:100, -Infinity:200]

On 01/12/2021 12:13, Bart wrote:
> On 01/12/2021 08:43, David Brown wrote:
>> On 01/12/2021 01:50, Andy Walker wrote:
>>> On 30/11/2021 08:07, James Harris wrote:
>>>> BTW, Bart, do you consider the first ten numbers as 1 to 10 rather
>>>> than 0 to 9?
>>>
>>>      Until quite recently, Bart and almost everyone else would
>>> certainly have done exactly that.
>>
>> Remember Bart, and some others, think it is "natural" to count from
>> 32767 on to -32767 (or larger type equivalents - 16-bit numbers are
>> easier to write) in the context of programming.
>
> Remember David think's it's natural to count from 65535 onto 0.

No, I don't - as you would know if you read my posts.

>
> I simply acknowledge that that is how most hardware works. Otherwise how
> do you explain that the upper limit of some value is (to ordinary
> people) the arbitrary figure of 32,767 or 65,535 instead of 99,999?
>

You say the limit is 32767, or whatever - explaining it in terms of the
hardware if you like. People can understand that perfectly well.
Limits are quite natural in counting and measuring - wrapping is much
rarer (though it does occur, such as with times and angles).

>
>
>> Clearly they would not
>> think that way when counting sheep.  So why apply sheep counting to
>> other aspects of programming?  Personally I prefer to think you can't
>> add 1 to 32767 (or larger type equivalents), which is of course almost
>> equally silly in terms of sheep.
>
> It might be silly, but you'd still be stuck if you had 33,000 sheep to
> count; what are you going to do?
>

Buy a bigger pen to put them in.

It is perfectly reasonable to say that you are counting sheep by putting
them in a pen, and if the pen only holds 20 sheep then you can't count
beyond 20.

>
>
>> I am quite confident that the idea of starting array indexes from 0 had
>> nothing to do with surreals.
>
> More to do with conflating them with offsets.

Having indexes of low-level arrays correlate to offsets is simple,
clear, obvious and efficient. (And again, I like having higher-level
array handling where index types can be more flexible - such as integer
subranges or enumeration types.)

>
>>  Surreal numbers are rather esoteric, and
>> very far from useful in array indexing in programming (which always
>> boils down to some kind of finite integer).
>>
>
>     a:=[:]
>
>     a{infinity}  := 100
>     a{-infinity} := 200
>
>     println a               # [Infinity:100, -Infinity:200]
>
>

General hashmaps or dictionaries are a different concept from contiguous
arrays (though some languages combine them). They are suitable (and
very useful) in higher level languages, but should not be part of the
core language for low-level languages. Libraries can then offer a range
of different variations on the theme, letting programmers pick the
version that fits their needs.

(Oh, and there is no such surreal as "infinity" - most surreals are
non-finite. But that's really getting off-topic!)

On 01/12/2021 08:43, David Brown wrote:
> [I wrote:]
>>   Zero, as a number, was invented
>> in modern times [FSVO "modern"!].
> (Historical note:
> It reached Europe around 1200, but had been around in India, amongst
> other countries, for a good while before that.

Yes, but that's nearly always zero as a placeholder, not
as a number in its own right. [I'm not convinced by many of the
claimed exceptions, which often smack of flag-waving.]

[...]
> The first Peano axiom is "0 is a natural number". They start counting
> at zero, not at one.
> There is no mathematical consensus as to whether the set of natural
> numbers ℕ starts with 0 or 1. But there is no doubt that the numbers
> generated by the Peano axioms start at 0.

When Peano first wrote his axioms, he started at 1. Later
he wrote a version starting at 0. The foundational maths books on
my shelves, even modern ones, are split; it really matters very
little.

[...]
> Negative numbers long pre-date the general acceptance of 0 as a
> "number". They were used in accountancy, as well as by a few
> mathematicians. But there general use, especially in Europe, came a
> lot later.

My impression is that accountants used red ink rather than
negative numbers. As late as the 1970s, hand/electric calculators
still used red numerals rather than a minus sign.

>>     /Now/ the influence of computing has made zero-based
>> indexing more relevant.  So have constructive arguments more
>> generally;  eg, the surreal numbers [...].
> I am quite confident that the idea of starting array indexes from 0 had
> nothing to do with surreals. [...]

Surreal numbers were an example; they are part of the
explanation for mathematics also tending to become zero-based.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Ketterer

On 02/12/2021 01:11, Andy Walker wrote:
> On 01/12/2021 08:43, David Brown wrote:
>> [I wrote:]
>>>    Zero, as a number, was invented
>>> in modern times [FSVO "modern"!].
>> (Historical note:
>> It reached Europe around 1200, but had been around in India, amongst
>> other countries, for a good while before that.
>
>     Yes, but that's nearly always zero as a placeholder, not
> as a number in its own right.  [I'm not convinced by many of the
> claimed exceptions, which often smack of flag-waving.]
>

Certainly zero as a placeholder was much more common. As a number -
well, since there was not even a consensus as to what a "number" is
until more rigorous mathematics of the past few centuries, it is very
difficult to tell. And of course we don't exactly have complete records
of all mathematics in all cultures for the last few millennium. So
there is definitely place for interpretation, opinions and hypotheses in
the history here, with no good way to judge the accuracy.

> [...]
>> The first Peano axiom is "0 is a natural number".  They start counting
>> at zero, not at one.
>> There is no mathematical consensus as to whether the set of natural
>> numbers ℕ starts with 0 or 1.  But there is no doubt that the numbers
>> generated by the Peano axioms start at 0.
>
>     When Peano first wrote his axioms, he started at 1.  Later
> he wrote a version starting at 0.  The foundational maths books on
> my shelves, even modern ones, are split;  it really matters very
> little.

It matters a lot once you get into the arithmetic - 0 is the additive
identity. I suppose you /could/ define addition with the starting point
"a + 1 = succ(a)" rather than "a + 0 = a", but it is all much easier and
neater when you start with 0. That is certainly how I learned it at
university, and how I have seen it a few other places - but while I
think I have a couple of books covering them, they are buried in the
attic somewhere.

>
> [...]
>> Negative numbers long pre-date the general acceptance of 0 as a
>> "number".  They were used in accountancy, as well as by a few
>> mathematicians.  But there general use, especially in Europe, came a
>> lot later.
>
>     My impression is that accountants used red ink rather than
> negative numbers.  As late as the 1970s, hand/electric calculators
> still used red numerals rather than a minus sign.
>

Many conventions have been used, in different countries, times, and
cultures. "Red ink" is certainly a well-known phrase in modern
English-speaking countries. But brackets, minus signs, and other
methods are used. Go far enough back and people didn't write with ink
at all.

But again, it is difficult to decide when something was considered "a
negative number" rather than "a number to be subtracted rather than added".

>>>      /Now/ the influence of computing has made zero-based
>>> indexing more relevant.  So have constructive arguments more
>>> generally;  eg, the surreal numbers [...].
>> I am quite confident that the idea of starting array indexes from 0 had
>> nothing to do with surreals. [...]
>
>     Surreal numbers were an example;  they are part of the
> explanation for mathematics also tending to become zero-based.
>

Really? Again, I would suggest that they are far too esoteric for the
purpose. Constructions of surreal numbers will normally start with 0 -
but so will constructions of other more familiar types, such as
integers, reals, ordinals, cardinals, and almost any other numbers.
Maybe it is just that with surreals, few people ever have much idea of
what they are, or get beyond reading how they are constructed! (Some
day I must get the book on them - it was Conway that developed them, and
Knuth that wrote the book, right?)

On 01/12/2021 12:25, David Brown wrote:
> On 01/12/2021 12:13, Bart wrote:
>> On 01/12/2021 08:43, David Brown wrote:

>>> Remember Bart, and some others, think it is "natural" to count from
>>> 32767 on to -32767 (or larger type equivalents - 16-bit numbers are
>>> easier to write) in the context of programming.
>>
>> Remember David think's it's natural to count from 65535 onto 0.
>
> No, I don't - as you would know if you read my posts.
>
>>
>> I simply acknowledge that that is how most hardware works. Otherwise how
>> do you explain that the upper limit of some value is (to ordinary
>> people) the arbitrary figure of 32,767 or 65,535 instead of 99,999?
>>
>
> You say the limit is 32767, or whatever - explaining it in terms of the
> hardware if you like. People can understand that perfectly well.
> Limits are quite natural in counting and measuring - wrapping is much
> rarer (though it does occur, such as with times and angles).

Yes, exactly. You travel east but when you hit 180E, it suddenly turns
into 180W, and the next degree along will be 179W not 181E.

The integer values represented by N bits can be thought of as being
arranged in a circle, here shown for N=3 as either unsigned, two's
complement or signed magnitude:

u3 i3 s3

000 0 000 0 000 +0 Origin
001 +1 001 +1 001 +1
010 +2 010 +2 010 +2
011 +3 011 +3 011 +3
100 +4 100 -4 100 -0
101 +5 101 -3 101 -1
110 +6 110 -2 110 -2
111 +7 111 -1 111 -3
000 0 000 0 000 +0 Origin
001 +1 001 +1 001 +1
...

Degrees of longtitude, if they were whole numbers rather than
continuous, would correspond most closely with the middle column (but
there would be 179E then 180W; no 180E).

Whatever column is chosen, wrapping behaviour is well-defined, even if
it may not be meaningful if your prefered result would need 6 bits to
represent; you don't want just the bottom 3.

But if you're in an aircraft flying along the equator, travelling 10
degrees east then 10 degrees west would normally get to you back to the
same longitude, whatever the start point, even when you cross the 180th
meridian.

On 30/11/2021 10:28, Bart wrote:
> On 30/11/2021 08:07, James Harris wrote:
>>  From another thread, discussion between David and Bart:

....

>> B> That's a crude way of defining arrays. A[i] is simply the i'th
>> B> element of N slots, you don't need to bring offsets into it.

I disagree. A[i] is not necessarily or even naturally the ith element.
See below about cardinal and ordinal numbers.

>>
>> Why call it 'i'th? I know people do but wouldn't it be easier to call
>> it 'element n' where n is its index? Then that would work with any
>> basing.
>
> The most common base I use is 1 (about 2/3 of the time). You have a
> 3-element array, the 1st is numbered 1, the last is 3, the 3rd is 3 too.
> All very intuitive and user-friendly.
>
> But this is that 3-element array as 3 adjoining cells:
>
>    mmmmmmmmmmmmmmmmmmmmmmmmm
>    m       m       m       m
>    m   1   m   2   m   3   m     Normal indexing
>    m  +0   m  +1   m  +2   m     Offsets
>    m       m       m       m
>    mmmmmmmmmmmmmmmmmmmmmmmmm
>
>    0       1       2       3     Distance from start point
>
>
> The numbering is 1, 2, 3 as I prefer when /counting/. Or you can choose
> to use offsets from the first element as C does, shown as +0, +1, +2.
>
> There is also /measuring/, which applies more when each cell has some
> physical dimension, such as 3 adjoining square pixels. Or maybe these
> are three fence panels, and the vertical columns are the posts.

Rather that 'counting' and 'measuring' here's another way to look at it:
The natural place to count an element - any element - is when it is
complete; however, where I think the conflict appears is that if an
element is known to be indivisible then its can never be partially
present so we know when we see the start of it that it is complete. That
'trick' works for whole elements but does not work in the general case.

To explain, consider a decimal number and take the units. You may see
them as

1, 2, 3, etc

but now take the tens position. In those numbers the tens position is
zero so they can be seen as (in normal notation, not in C-form octal!)

01, 02, 03, etc

Similarly, the number of hundreds in those numbers is also zero, i.e.
with three digits they are

001, 002, 003, etc

The tens and the hundreds are each subdivided (into smaller elements
1/10th of their value). We have to wait for the units to tick past 9
before we add 1 to the tens column, and for the tens column to tick past
9 before we add another hundred. So the mathematically natural indexing
for tens and hundreds and all higher digit positions more is from zero.
It's more consistent, then, to number the units from zero, too, but we
often find it natural to count them from 1. Here's an idea as to why:

Perhaps we think of counting units from 1 because we normally count
/whole/ objects. We don't need to wait for them to complete; since they
are indivisible we know they are complete when we first see them.

But that's a special case. The more general case is to start from zero.

>
> Here, offsets are again used, but notionally considered to be measured
> from the first 'post'.
>
> In this case, an 'index' of 2.4 is meaningful, being 2.4 units from the
> left, and 40% along that 3rd cell.

As above, that's (correctly) seeing an object as partial.

....

>> Similarly, on the day a child is born do you say that he is one year old?
>
>
> This is 'measurement'; see above. However my dad always liked to round
> his age up to the next whole year; most people round down! So the child
> would be 0 years, but in its first year.
>
> However there is not enough resolution using years to accurately measure
> ages of very young children, so people also use days, weeks and months.

Partials, again. A person doesn't become 1 year old until he reaches 12
months, for example.

Cardinals and ordinals

Going back to your point at the beginning, as above the ordinal of
something is naturally one more than its cardinal number. Our /first/
year is when we are age zero whole years. In the 20th century the
century portion of the date was 19. Etc.

So in a zero-based array it would be inconsistent to refer to

A[1]

as the first element even though lots of people do it. It is, in fact,
the second. It's probably easiest to refer to it as

element 1

then the bounds don't matter.

--
James Harris

On 30/11/2021 09:18, Dmitry A. Kazakov wrote:
> On 2021-11-30 09:07, James Harris wrote:
>>  From another thread, discussion between David and Bart:

....

>> B> That's a crude way of defining arrays. A[i] is simply the i'th
>> B> element of N slots, you don't need to bring offsets into it.
>>
>> Why call it 'i'th? I know people do but wouldn't it be easier to call
>> it 'element n' where n is its index? Then that would work with any
>> basing.
>
> You are confusing position with index. Index can be of any ordered type.
> Position is an ordinal number: first, second, third element from the
> array beginning.

You are confusing a question to Bart with an opinion. :-)

....

>> Why not call A[2] element 2?
>
> Because it would be wrong. In most languages A[2] means the array
> element corresponding to the index 2.

"Element 2" doesn't mean "second element" so why is A[2] not "element 2"
just as A["XX"] would be element "XX"?

>
> Remember, array is a mapping:
>
>    array : index -> element
>
> In well-designed languages it is also spelt as a mapping:
>
>    A(2)

This is something I want to come back to elsewhere but since you mention
it I'm curious, Dmitry, as to whether you would accept such a mapping
returning the address of, as in

A(2) = A(2) + 1

--
James Harris

On 2021-12-02 18:39, James Harris wrote:
> On 30/11/2021 09:18, Dmitry A. Kazakov wrote:
>> On 2021-11-30 09:07, James Harris wrote:

>>> Why not call A[2] element 2?
>>
>> Because it would be wrong. In most languages A[2] means the array
>> element corresponding to the index 2.
>
> "Element 2" doesn't mean "second element"

Again, A[2] is the element corresponding to the index 2. Not "element
2," not "second element," just an element denoted by the index value 2.

> so why is A[2] not "element 2"

Because "element 2" is undefined, so far.

> just as A["XX"] would be element "XX"?

Nope. It is the element corresponding to the index "XX".

>> Remember, array is a mapping:
>>
>>     array : index -> element
>>
>> In well-designed languages it is also spelt as a mapping:
>>
>>     A(2)
>
> This is something I want to come back to elsewhere but since you mention
> it I'm curious, Dmitry, as to whether you would accept such a mapping
> returning the address of, as in
>
>   A(2) = A(2) + 1

It does not return address. A(2) denotes the array element corresponding
to the index 2 on both sides. No any addresses. A is a mapping, mutable
in this case. It does not return anything.

You as always confuse implementation with semantics. There is an
uncountable number of valid implementations of a mapping. The programmer
does not care most of the time, because he presumes the compiler vendors
are sane people, until proven otherwise.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

James Harris <james.harris.1@gmail.com> writes:
>Why call it 'i'th? I know people do but wouldn't it be easier to call it
>'element n' where n is its index? Then that would work with any basing.

See also:

https://www.purl.org/stefan_ram/pub/zero

.

On 02/12/2021 17:29, James Harris wrote:
> On 30/11/2021 10:28, Bart wrote:

> To explain, consider a decimal number and take the units. You may see
> them as
>
>   1, 2, 3, etc
>
> but now take the tens position. In those numbers the tens position is
> zero so they can be seen as (in normal notation, not in C-form octal!)
>
>   01, 02, 03, etc
>
> Similarly, the number of hundreds in those numbers is also zero, i.e.
> with three digits they are
>
>   001, 002, 003, etc
>
> The tens and the hundreds are each subdivided (into smaller elements
> 1/10th of their value). We have to wait for the units to tick past 9
> before we add 1 to the tens column, and for the tens column to tick past
> 9 before we add another hundred. So the mathematically natural indexing
> for tens and hundreds and all higher digit positions more is from zero.
> It's more consistent, then, to number the units from zero, too, but we
> often find it natural to count them from 1.

They're not really numbered, they're counted, and the number of tens go
from 0 to 9 in total.

Most people do count from zero, in that the start point when you have
nothing is zero; the next is designated 1; the next 2, and so on. The
last in your collection is designated N, and you have N things in all.

Except the tens in your example are not ordered nor individually
numbered, you just need the total.

I guess if you had two cars in your household, you would agree there
were '2' cars and not '1' (which would confuse everyone, and would mean
that anyone without a car would have, what, -1 cars? If doesn't work!).

But if you had to number the cars, with a number on the roof, or on the
keytags, you can choose to number them 0 and 1, or 1 and 2, or 5000 and
5001, if you needed a sequential order.

The number of tens digit in that column however, must correspond to the
number of cars in a household, and not to the highest value of whatever
numbering scheme you favour.

>> This is 'measurement'; see above. However my dad always liked to round
>> his age up to the next whole year; most people round down! So the
>> child would be 0 years, but in its first year.
>>
>> However there is not enough resolution using years to accurately
>> measure ages of very young children, so people also use days, weeks
>> and months.
>
> Partials, again. A person doesn't become 1 year old until he reaches 12
> months, for example.

I think it's a mistake to conflate discrete, abstract units with
physical measurement.

If you go back to my fence and fenceposts example, you have N panels and
N+1 posts for a straight fence.

If you number the /posts/ from 0 to N, then the number gives you the
physical distance from the start (in fence panel units).

You wouldn't number the panels to get that information, because it would
be inaccurate; the panels are too wide.

The panels however do correspond to the elements of an array. This is
where I'd number them from 1 (since there is no reason to use 0 or
anything else); you'd probably use 0 for misguided reasons (perhaps too
much time spent coding in C or Python).

> Going back to your point at the beginning, as above the ordinal of
> something is naturally one more than its cardinal number. Our /first/
> year is when we are age zero whole years.

Our age in years is a continuous measure. Usually you specify it as
whole years when it has floor() applied to round it down.

> In the 20th century the
> century portion of the date was 19. Etc.

Yeah, that confuses a lot of people, but not us, right?

>
>   A[1]
>
> as the first element even though lots of people do it. It is, in fact,
> the second. It's probably easiest to refer to it as
>
>   element 1
>
> then the bounds don't matter.

Very often you do need to refer to the first or the last. In a strictly
1-based scheme, they would be A[1] and A[N]; 0-based is A[0] and A[N-1].

X-based (since N is the length) gets ugly, eg. A.[A.lwb] and A.[A.upb]
or A[$].

However it looks you're itching to start your arrays from 0; then just
do so. You don't need an excuse.

I happen to think that 1-based is better:

* It's more intuitive and easier to understand

* It corresponds to how most discrete things are numbered in real life

* If there are N elements, the first is 1, and the last N; there is no
dis-connect are there is with 0-based

* It plays well with the rest of a language, so for-loops can go from
1 to N instead of 0 to N-1.

* In N-way select (n | a,b,c |z), then n=1/2/3 selects 1st/2nd/3rd

* If you have a list indexed 1..N, then a search function can return
1..N for success, and 0 for failure. How would it work for 0-based
since 0 could be a valid return value?

* Such a return code will also be True in conditional (if x in A then...)

But despite the advantages, I still use 0-based too; it's just not the
primary choice.

On 02/12/2021 18:05, Dmitry A. Kazakov wrote:
> On 2021-12-02 18:39, James Harris wrote:
>> On 30/11/2021 09:18, Dmitry A. Kazakov wrote:
>>> On 2021-11-30 09:07, James Harris wrote:
>
>>>> Why not call A[2] element 2?
>>>
>>> Because it would be wrong. In most languages A[2] means the array
>>> element corresponding to the index 2.
>>
>> "Element 2" doesn't mean "second element"
>
> Again, A[2] is the element corresponding to the index 2. Not "element
> 2," not "second element," just an element denoted by the index value 2.
>
>> so why is A[2] not "element 2"
>
> Because "element 2" is undefined, so far.
>
>> just as A["XX"] would be element "XX"?
>
> Nope. It is the element corresponding to the index "XX".

Just as the house corresponding with the number 48a is commonly called
house 48a, then. I am suggesting referring to elements of arrays by
their labels rather than by their positions.

>
>>> Remember, array is a mapping:
>>>
>>>     array : index -> element
>>>
>>> In well-designed languages it is also spelt as a mapping:
>>>
>>>     A(2)
>>
>> This is something I want to come back to elsewhere but since you
>> mention it I'm curious, Dmitry, as to whether you would accept such a
>> mapping returning the address of, as in
>>
>>    A(2) = A(2) + 1
>
> It does not return address. A(2) denotes the array element corresponding
> to the index 2 on both sides. No any addresses. A is a mapping, mutable
> in this case. It does not return anything.
>
> You as always confuse implementation with semantics. There is an
> uncountable number of valid implementations of a mapping. The programmer
> does not care most of the time, because he presumes the compiler vendors
> are sane people, until proven otherwise.

Strange. I think it's you who too often conflates implementations with
semantics. But in this case I certainly was referring at least to a
reference or ideal implentation from which information (and other
potential implementations with the same semantics) can be inferred.

But to the point, are you comfortable with the idea of the A(2) in

x = A(2) + 0

meaning the same mapping result as the A(2) in

A(2) = 0

?

--
James Harris

On 2021-12-02 21:31, James Harris wrote:
> On 02/12/2021 18:05, Dmitry A. Kazakov wrote:
>> On 2021-12-02 18:39, James Harris wrote:
>>> On 30/11/2021 09:18, Dmitry A. Kazakov wrote:
>>>> On 2021-11-30 09:07, James Harris wrote:

>>>> Remember, array is a mapping:
>>>>
>>>>     array : index -> element
>>>>
>>>> In well-designed languages it is also spelt as a mapping:
>>>>
>>>>     A(2)
>>>
>>> This is something I want to come back to elsewhere but since you
>>> mention it I'm curious, Dmitry, as to whether you would accept such a
>>> mapping returning the address of, as in
>>>
>>>    A(2) = A(2) + 1
>>
>> It does not return address. A(2) denotes the array element
>> corresponding to the index 2 on both sides. No any addresses. A is a
>> mapping, mutable in this case. It does not return anything.
>>
>> You as always confuse implementation with semantics. There is an
>> uncountable number of valid implementations of a mapping. The
>> programmer does not care most of the time, because he presumes the
>> compiler vendors are sane people, until proven otherwise.
>
> Strange. I think it's you who too often conflates implementations with
> semantics. But in this case I certainly was referring at least to a
> reference or ideal implentation from which information (and other
> potential implementations with the same semantics) can be inferred.
>
> But to the point, are you comfortable with the idea of the A(2) in
>
>   x = A(2) + 0
>
> meaning the same mapping result as the A(2) in
>
>   A(2) = 0
>
> ?

Yes, in both cases the result is the array element corresponding to the
index 2. That is the semantics of A(2).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 02/12/2021 20:11, Bart wrote:
> On 02/12/2021 17:29, James Harris wrote:
>> On 30/11/2021 10:28, Bart wrote:
>
>
>> To explain, consider a decimal number and take the units. You may see
>> them as
>>
>>    1, 2, 3, etc
>>
>> but now take the tens position. In those numbers the tens position is
>> zero so they can be seen as (in normal notation, not in C-form octal!)
>>
>>    01, 02, 03, etc
>>
>> Similarly, the number of hundreds in those numbers is also zero, i.e.
>> with three digits they are
>>
>>    001, 002, 003, etc
>>
>> The tens and the hundreds are each subdivided (into smaller elements
>> 1/10th of their value). We have to wait for the units to tick past 9
>> before we add 1 to the tens column, and for the tens column to tick
>> past 9 before we add another hundred. So the mathematically natural
>> indexing for tens and hundreds and all higher digit positions more is
>> from zero. It's more consistent, then, to number the units from zero,
>> too, but we often find it natural to count them from 1.
>
> They're not really numbered, they're counted, and the number of tens go
> from 0 to 9 in total.

So (whatever you prefer to call it) do you agree that the number line
has the tens, hundreds, and above starting at zero and increasing to 9?
If so why not apply that to the units digit, too and say the natural
first number is zero?

....

> I guess if you had two cars in your household, you would agree there
> were '2' cars and not '1' (which would confuse everyone, and would mean
> that anyone without a car would have, what, -1 cars? If doesn't work!).
>
> But if you had to number the cars, with a number on the roof, or on the
> keytags, you can choose to number them 0 and 1, or 1 and 2, or 5000 and
> 5001, if you needed a sequential order.

As I said, whole units do not have partial, incomplete phases, and the
cars are whole units.

But if you were putting petrol in one of the cars would you count
yourself as having received a tankful when the first drop went in? No,
where elements are partial we don't count the whole until it is complete.

Similarly, if you sold one of the cars to a friend who was to pay you
£100 a month for it would you count yourself as having received the
payment after the first month? No, this is also partial so you'd count
it at the end.

Ergo it's only for indivisible units that 1-based can possibly be seen
as natural. It's more general, though, to begin counting from zero -
even if it is less familiar.

....

> The panels however do correspond to the elements of an array. This is
> where I'd number them from 1 (since there is no reason to use 0 or
> anything else); you'd probably use 0 for misguided reasons (perhaps too
> much time spent coding in C or Python).

No, I use 0 because it scales better. BTW, it sounds like the posts are
also an array.

....

>> In the 20th century the century portion of the date was 19. Etc.
>
> Yeah, that confuses a lot of people, but not us, right?

But do you see the point of it? The first century /naturally/ had
century number zero, not one, and the N'th century has century number

N - 1

IOW the numbering begins at zero.

That's not a convention, by the way, but how all numbering works: things
with partial phases begin at zero.

>
>>
>>    A[1]
>>
>> as the first element even though lots of people do it. It is, in fact,
>> the second. It's probably easiest to refer to it as
>>
>>    element 1
>>
>> then the bounds don't matter.
>
> Very often you do need to refer to the first or the last. In a strictly
> 1-based scheme, they would be A[1] and A[N]; 0-based is A[0] and A[N-1].
>
> X-based (since N is the length) gets ugly, eg. A.[A.lwb] and A.[A.upb]
> or A[$].
>
> However it looks you're itching to start your arrays from 0; then just
> do so. You don't need an excuse.

I wasn't looking for advice but I thought I'd have a go at challenging
your position and see where the argument led me.

>
> I happen to think that 1-based is better:
>
> * It's more intuitive and easier to understand

It's easier on indivisible elements. That's fine if you only have a
single, simple array. But if you have arrays being processed in nested
loops then it might be best if you didn't count the outer one as
complete until the first set of iterations of the inner one have
finished. That's why I asked you before if you start numbering your
three-digit numbers at 111...!

>
> * It corresponds to how most discrete things are numbered in real life
>
> * If there are N elements, the first is 1, and the last N; there is no
>   dis-connect are there is with 0-based

Yes, you are talking about discreet units which are not made of parts.

>
> * It plays well with the rest of a language, so for-loops can go from
>   1 to N instead of 0 to N-1.
>
> * In N-way select (n | a,b,c |z), then n=1/2/3 selects 1st/2nd/3rd

My version of that selects phrases from zero:

n of (a, b)

If n is zero it will pick a; if one, b. If you treat integers as
booleans (as you do below) then it doubles as a boolean test in the
order false, true - the opposite of C's ?: operator.

>
> * If you have a list indexed 1..N, then a search function can return
>   1..N for success, and 0 for failure. How would it work for 0-based
>   since 0 could be a valid return value?

That's convenient, for sure, but then so is treating the return from
strcmp as a boolean when it is typically a signum or a difference.

As for the alternative, some options: -1, N, exception, designated
default value, boolean instead of index.

>
> * Such a return code will also be True in conditional (if x in A then...)
>
> But despite the advantages, I still use 0-based too; it's just not the
> primary choice.

Sure. For discrete units either will do - and if our programming is
mainly in discrete units then we can become accustomed to thinking
1-based. Yet that begins to run out of steam when processing hierarchies.

--
James Harris

On 02/12/2021 20:49, Dmitry A. Kazakov wrote:
> On 2021-12-02 21:31, James Harris wrote:

....

>> But to the point, are you comfortable with the idea of the A(2) in
>>
>>    x = A(2) + 0
>>
>> meaning the same mapping result as the A(2) in
>>
>>    A(2) = 0
>>
>> ?
>
> Yes, in both cases the result is the array element corresponding to the
> index 2. That is the semantics of A(2).

Cool. If A were, instead, a function that, say, ended with

return v

then what would you want those A(2)s to mean and should they still mean
the same as each other? The latter expression would look strange to many.

I've been meaning to reply to Charles about the same issue but what you
said reminded me of it.

--
James Harris

On 02/12/2021 21:25, James Harris wrote:
> On 02/12/2021 20:11, Bart wrote:

> As I said, whole units do not have partial, incomplete phases, and the
> cars are whole units.
>
> But if you were putting petrol in one of the cars would you count
> yourself as having received a tankful when the first drop went in? No,
> where elements are partial we don't count the whole until it is complete.
>
> Similarly, if you sold one of the cars to a friend who was to pay you
> £100 a month for it would you count yourself as having received the
> payment after the first month? No, this is also partial so you'd count
> it at the end.
>
> Ergo it's only for indivisible units that 1-based can possibly be seen
> as natural. It's more general, though, to begin counting from zero -
> even if it is less familiar.

Continuous measurements need to start from 0.0.

Discrete entities are counted, starting at 0 for none, then 1 for 1 (see
Xs below).

Some are in-between, where continuous quantities are represented as lots
of small steps. (Example: money in steps of £0.01, or time measured in
whole seconds.)

> ...
>
>> The panels however do correspond to the elements of an array. This is
>> where I'd number them from 1 (since there is no reason to use 0 or
>> anything else); you'd probably use 0 for misguided reasons (perhaps
>> too much time spent coding in C or Python).
>
> No, I use 0 because it scales better. BTW, it sounds like the posts are
> also an array.

The posts don't have a dimension, not abstract ones anyway, and can't
store data. If you were draw a diagram of bits or bytes or array
elements in memory, they would be the lines separate those elements.

> But do you see the point of it? The first century /naturally/ had
> century number zero, not one, and the N'th century has century number
>
>   N - 1
>
> IOW the numbering begins at zero.

Define what you mean by numbering first.

For me it means assigning sequential integers to a series of entities.
But you need an entity to hang a number from. With no entities, where
are you going to stick that zero?

>>
>> I happen to think that 1-based is better:
>>
>> * It's more intuitive and easier to understand
>
> It's easier on indivisible elements. That's fine if you only have a
> single, simple array. But if you have arrays being processed in nested
> loops then it might be best if you didn't count the outer one as
> complete until the first set of iterations of the inner one have
> finished. That's why I asked you before if you start numbering your
> three-digit numbers at 111...!

If you write a number with the usual decimal notation then a number like:

abc

has the value a*10^2 + b*10^1 + c*10^0.

The value of each of a,b,c is in the range 0..9 exclusive. That's just
how decimal notation works. Each digit represents as count as I said.

I'm not sure what you're trying to argue here; that because 0 is used to
mean nothing, then that must be the start point for everything?

Here are some sets of Xs increasing in size:

How many X's? Numbered as? Number of the Last?
--------
- 0 - -
--------
X 1 1 1
--------
X X 2 1 2 2
--------
X X X 3 1 2 3 3
--------

How would /you/ fill in those columns? I'd guess my '1 2 3' becomes '0 1
2', and that that last '3' becomes '2'.

But what about the first '3' on that last line; don't tell me it becomes
'2'! (Because then what happens to the '0'?)

Using you scheme (as I assume it will be); there is too much disconnect:
a '0' in the first row, and two 0s the second; a '1' in the second, and
two 1s in the third. Everything is out of step!

> Yes, you are talking about discreet units which are not made of parts.

Yes, arrays of elements that are computer data with no physical dimensions.

>> But despite the advantages, I still use 0-based too; it's just not the
>> primary choice.
>
> Sure. For discrete units either will do - and if our programming is
> mainly in discrete units then we can become accustomed to thinking
> 1-based. Yet that begins to run out of steam when processing hierarchies.

My arrays have a general declaration that looks like this:

[A..B]T X # or [A:N] where N is the length (B=A+N-1)

So, an array X of T, indexed from A to B inclusive. Here, whether A is
0, 1 or anything else doesn't come into it.

I just need to be aware of it so that I don't assume a specific lower
bound. (But usually I will know when A is 1 so I can take advantage.)

On 02/12/2021 22:25, James Harris wrote:
> On 02/12/2021 20:11, Bart wrote:
>> On 02/12/2021 17:29, James Harris wrote:

>>> In the 20th century the century portion of the date was 19. Etc.
>>
>> Yeah, that confuses a lot of people, but not us, right?
>
> But do you see the point of it? The first century /naturally/ had
> century number zero, not one, and the N'th century has century number
>
>   N - 1
>
> IOW the numbering begins at zero.
>
> That's not a convention, by the way, but how all numbering works: things
> with partial phases begin at zero.
>
Note, however, that the first century began with year 1 AD (or 1 CE, if
you prefer). The preceding year was 1 BC. There was no year 0. This
means the first century was the years 1 to 100 inclusive.

It really annoyed me that everyone wanted to celebrate the new
millennium on 01.01.2000, when in fact it did not begin until 01.01.2001.

It would have been so much simpler, and fitted people's expectations
better, if years have been numbered from 0 onwards instead of starting
counting at 1.

On 03/12/2021 00:08, David Brown wrote:
> On 02/12/2021 22:25, James Harris wrote:
>> On 02/12/2021 20:11, Bart wrote:
>>> On 02/12/2021 17:29, James Harris wrote:
>
>>>> In the 20th century the century portion of the date was 19. Etc.
>>>
>>> Yeah, that confuses a lot of people, but not us, right?
>>
>> But do you see the point of it? The first century /naturally/ had
>> century number zero, not one, and the N'th century has century number
>>
>>   N - 1
>>
>> IOW the numbering begins at zero.
>>
>> That's not a convention, by the way, but how all numbering works: things
>> with partial phases begin at zero.
>>
> Note, however, that the first century began with year 1 AD (or 1 CE, if
> you prefer). The preceding year was 1 BC. There was no year 0. This
> means the first century was the years 1 to 100 inclusive.

So -1 was followed by +1?

> It really annoyed me that everyone wanted to celebrate the new
> millennium on 01.01.2000, when in fact it did not begin until 01.01.2001.

> It would have been so much simpler, and fitted people's expectations
> better, if years have been numbered from 0 onwards instead of starting
> counting at 1.

I'm sure we can all pretend that the start point was the year before 1
AD, which can be an honorary year 0.

It must have been a big deal on 24:00 on 31-12-999 when not only a new
century began, from the 10th to the 11th, and the century year changed
not only from 9 to 10, but from 1 digit to 2 digits.

Then probably some spoilsport came along and said it didn't count, they
were still in the same century really, despite that '10' in the year,
and they'd have to wait until midnight on 31-12-1000.

On 03/12/2021 02:42, Bart wrote:
> On 03/12/2021 00:08, David Brown wrote:
>> On 02/12/2021 22:25, James Harris wrote:
>>> On 02/12/2021 20:11, Bart wrote:
>>>> On 02/12/2021 17:29, James Harris wrote:
>>
>>>>> In the 20th century the century portion of the date was 19. Etc.
>>>>
>>>> Yeah, that confuses a lot of people, but not us, right?
>>>
>>> But do you see the point of it? The first century /naturally/ had
>>> century number zero, not one, and the N'th century has century number
>>>
>>>    N - 1
>>>
>>> IOW the numbering begins at zero.
>>>
>>> That's not a convention, by the way, but how all numbering works: things
>>> with partial phases begin at zero.
>>>
>> Note, however, that the first century began with year 1 AD (or 1 CE, if
>> you prefer).  The preceding year was 1 BC.  There was no year 0.  This
>> means the first century was the years 1 to 100 inclusive.
>
> So -1 was followed by +1?

Yes. Although of course the idea of AD and BC numbering was developed
long afterwards. The people living in 1 BC didn't know their year was
called 1 BC :-)

>
>
>> It really annoyed me that everyone wanted to celebrate the new
>> millennium on 01.01.2000, when in fact it did not begin until 01.01.2001.
>
>> It would have been so much simpler, and fitted people's expectations
>> better, if years have been numbered from 0 onwards instead of starting
>> counting at 1.
>
> I'm sure we can all pretend that the start point was the year before 1
> AD, which can be an honorary year 0.

It's difficult to change that now. But it rarely makes a big
difference, since many BC dates are only known approximately anyway.

>
> It must have been a big deal on 24:00 on 31-12-999 when not only a new
> century began, from the 10th to the 11th, and the century year changed
> not only from 9 to 10, but from 1 digit to 2 digits.
>

The new century didn't begin until 1001, but the year number got an
extra digit.

And at that time, day was from the first hour starting about dawn - what
we call 06:00 - until the twelfth hour about sunset - what we call
18:00. The length of hours in the day and the night depended on the
time of year. They were really only tracked by monasteries, where they
had their obsession about prayers and masses at different times. For
example, they needed to know when the ninth hour was (about 15:00 modern
timing) for their "noon" prayers.

It's easy to assume that people saw the change to year 1000 (or 1001) as
a big thing or perhaps the time for the "second coming" or apocalypse,
but from the records we have, it does not seem to be the case. (I'm
talking about the UK and Europe here - folks like the Mayans and Chinese
always loved a really big party at calender rollovers.) We have banking
records of people taking out 10 year loans in 998, for example, without
any indication that it was unusual.

> Then probably some spoilsport came along and said it didn't count, they
> were still in the same century really, despite that '10' in the year,
> and they'd have to wait until midnight on 31-12-1000.
>

I doubt if anyone listened to them. No one listened to me at 01.01.2000 :-(

On 2021-12-02 22:42, James Harris wrote:
> On 02/12/2021 20:49, Dmitry A. Kazakov wrote:
>> On 2021-12-02 21:31, James Harris wrote:
>
> ...
>
>>> But to the point, are you comfortable with the idea of the A(2) in
>>>
>>>    x = A(2) + 0
>>>
>>> meaning the same mapping result as the A(2) in
>>>
>>>    A(2) = 0
>>>
>>> ?
>>
>> Yes, in both cases the result is the array element corresponding to
>> the index 2. That is the semantics of A(2).
>
> Cool. If A were, instead, a function that, say, ended with
>
>   return v

PL/1 had those, if I correctly remember. But no, it is not a function.
If you want to go for fully abstract array types, it is a procedure (and
a method):

procedure Setter (A : in out Array; I : Index; E : Element)

So

A(2) = 0

must compile into

Setter (A, 2, 0) or A.Setter (2, 0)

whatever notation you prefer.

The other one is a Getter:

function Getter (A : Array; I : Index) return Element;

> then what would you want those A(2)s to mean and should they still mean
> the same as each other?

Yes, they always mean same.

In a language that does not have abstract arrays a programmer might
implement that using helper types decomposing it in the [wrong way] you
suggested. That would involve all sorts of helper types having
referential semantics, smart pointers etc. Unfortunately such
abstractions leak producing quite a mess of unreadable error messages.
You asked about methods and free functions. One of the leakage points is
that these helper types are unrelated and the operations on them might
get not fully visible in some context etc. This is why it is better to
provide abstract arrays on the language level.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 02/12/2021 22:42, James Harris wrote:
> On 02/12/2021 20:49, Dmitry A. Kazakov wrote:
>> On 2021-12-02 21:31, James Harris wrote:
>
> ...
>
>>> But to the point, are you comfortable with the idea of the A(2) in
>>>
>>>    x = A(2) + 0
>>>
>>> meaning the same mapping result as the A(2) in
>>>
>>>    A(2) = 0
>>>
>>> ?
>>
>> Yes, in both cases the result is the array element corresponding to
>> the index 2. That is the semantics of A(2).
>
> Cool. If A were, instead, a function that, say, ended with
>
>   return v
>
> then what would you want those A(2)s to mean and should they still mean
> the same as each other? The latter expression would look strange to many.
>

Do you mean like returning a reference in C++ style?

int a[10];

void foo1(int i, int x) {
a[i] = x;
}

int& A(int i) {
return a[i];
}

void foo2(int i, int x) {
A(i) = x;
}

foo1 and foo2 do the same thing, and have the same code. Of course,
foo2 could add range checking, or offsets (for 1-based array), or have
multiple parameters for multi-dimensional arrays, etc. And in practice
you'd make such functions methods of a class so that the class owns the
data, rather than having a single global source of the data.