On 02/12/2021 07:37, David Brown wrote:
>>> [...] 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.

"Additive identity" is meaningless before you have defined
addition; and once you have got to anywhere interesting, "0" is
defined anyway. It's really not important, except when you get to
rationals [when 1-based is better, as you don't have to make a
special case for when the denominator is zero].

> 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.

I don't see "a + 1 == a'" as interestingly harder than
"a + 0 = a". In some ways it's easier; if we abbreviate [eg]
3' [or succ(3)] as 4, in the usual way, then 1-based has [eg]

3+4 = (3+3)' = ((3+2)')' = (((3+1)')')' = 4''' = 5'' = 6' = 7,

whereas 0-based has

3+4 = (3+3)' = ((3+2)')' = (((3+1)')')' = ((((3+0)')')')' =
3'''' = 4''' = 5'' = 6' = 7,

and you have two extra steps with every addition.

> 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.

Fine; as I said, books vary, and it's at the whim of
the lecturer [if any -- it's commonly not taught at all, except
at the level of "if you really want to know how all this stuff
gets defined, look at (some book -- Landau in my case)"].

[...]
>>> 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.

Again, I would repeat that they were an /example/ of the
way that /mathematics/, predominantly 1-based, has /tended/ to
become 0-based. That's not a /purpose/; it just so happens that
some relatively recent maths has found uses where 0-based seems
more natural than 1-based. There are still plenty where 1-based
remains more usual/natural.

> 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.

You're assuming the answer! As above, you can equally
get to integers [and so rationals and reals] from 1.

> 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?)

Knuth wrote /a/ book on them; /the/ book is Conway's "On
Numbers and Games", but a more accessible version is "Winning Ways"
by Berlekamp, Conway and Guy [all three of whom, sadly, died within
a year and two days in 2019-20]; expensive to buy, but there is a
PDF freely available online. What most people don't realise is the
motivation: Conway couldn't see /why/ the step from rationals to
reals is so difficult. We define naturals eg by Peano, then get
by equivalence classes to integers and rationals, and then ...?
The usual constructions of reals seem so artificial, and not at
all related to what happens earlier. So Conway wondered what
would happen if we went the other way -- start from the concept
of a Dedekind section, forget that it relies on knowing about
the rationals, and just build on what we know. Thus we get the
idea of partitioning whatever numbers we know into two sets.
That is how we build the surreals, without exceptions or special
cases. Oh, we also get [combinatorial] games as a side-effect;
which is where it gets interesting to people like me, and to CS
more generally, and why it's not as esoteric as people think.

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

On 03/12/2021 13:24, Andy Walker wrote:
> On 02/12/2021 07:37, David Brown wrote:
>>>> [...] 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.
>
>     "Additive identity" is meaningless before you have defined
> addition;  and once you have got to anywhere interesting, "0" is
> defined anyway.  It's really not important, except when you get to
> rationals [when 1-based is better, as you don't have to make a
> special case for when the denominator is zero].
>

Rationals are easier when you have 0 :

ℚ = { p / q : p, q ∈ ℤ, q > 0 }

vs.

ℚ = { p / q : p, q ∈ ℕ⁺ } ∪ { 0 } ∪ { -p / q : p, q ∈ ℕ⁺ }

>>          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.
>
>     I don't see "a + 1 == a'" as interestingly harder than
> "a + 0 = a".  In some ways it's easier;  if we abbreviate [eg]
> 3' [or succ(3)] as 4, in the usual way, then 1-based has [eg]
>
>   3+4 = (3+3)' = ((3+2)')' = (((3+1)')')' = 4''' = 5'' = 6' = 7,
>
> whereas 0-based has
>
>   3+4 = (3+3)' = ((3+2)')' = (((3+1)')')' = ((((3+0)')')')' =
>     3'''' = 4''' = 5'' = 6' = 7,
>
> and you have two extra steps with every addition.

The number of steps doesn't matter much - we are not looking for an
efficient way of adding up! But calling the additive identity "0" or
"1" /does/ matter, because one choice makes sense and the other choice
is pointlessly confusing. (The definition of addition does not actually
require an identity.)

I can happily agree that you /can/ define Peano numbers starting with 1,
and I am sure some people think that is better. But personally I think
there are good reasons why 0 is the more common starting point (as far
as I could see from a statistically invalid and non-scientific google
search) - the big hint comes from Peano himself who started with 1, then
changed his mind and started 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.
>
>     Fine;  as I said, books vary, and it's at the whim of
> the lecturer [if any -- it's commonly not taught at all, except
> at the level of "if you really want to know how all this stuff
> gets defined, look at (some book -- Landau in my case)"].

We were taught them as 0-based in pure maths. And in computing, we
constructed them from 0 in a Haskell-like functional programming
language as a practical exercise.

>
> [...]
>>>> 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.
>
>     Again, I would repeat that they were an /example/ of the
> way that /mathematics/, predominantly 1-based, has /tended/ to
> become 0-based.  That's not a /purpose/;  it just so happens that
> some relatively recent maths has found uses where 0-based seems
> more natural than 1-based.  There are still plenty where 1-based
> remains more usual/natural.

I was referring to /your/ purpose in picking the surreals as an example.
(It's not that I don't find surreals interesting, it's just that most
people have probably never heard of them. Mind you, this thread has
given me some information about them that I didn't know, so thanks for
that anyway!)

>
>>         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.
>
>     You're assuming the answer!  As above, you can equally
> get to integers [and so rationals and reals] from 1.
>

Of course you can always start from 1. In my experience (as someone
with a degree in mathematics and theoretical computing, but not having
worked in a mathematical profession) it is usually simpler and easier,
and more common, to start from 0.

>> 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?)
>
>     Knuth wrote /a/ book on them;  /the/ book is Conway's "On
> Numbers and Games", but a more accessible version is "Winning Ways"
> by Berlekamp, Conway and Guy [all three of whom, sadly, died within
> a year and two days in 2019-20];  expensive to buy, but there is a
> PDF freely available online. 

I'll have a look for that - thanks.

(It was sad that the inventor of "life" died of Covid.)

> What most people don't realise is the
> motivation:  Conway couldn't see /why/ the step from rationals to
> reals is so difficult.  We define naturals eg by Peano, then get
> by equivalence classes to integers and rationals, and then ...?
> The usual constructions of reals seem so artificial, and not at
> all related to what happens earlier.  So Conway wondered what
> would happen if we went the other way -- start from the concept
> of a Dedekind section, forget that it relies on knowing about
> the rationals, and just build on what we know.  Thus we get the
> idea of partitioning whatever numbers we know into two sets.
> That is how we build the surreals, without exceptions  or special
> cases.

That is interesting. I had thought of surreals as trying to find gaps
and endpoints in the reals and filling them in (though I know the
construction doesn't do that).

I wonder if the lengths in TeX, which have 3 (IIRC) layers of infinities
and infinitesimals, were invented as a kind of computer approximation to
surreals?

>  Oh, we also get [combinatorial] games as a side-effect;
> which is where it gets interesting to people like me, and to CS
> more generally, and why it's not as esoteric as people think.
>

All sorts of maths that is esoteric to most people has some odd
application or two. That is often what makes it interesting.

On 03/12/2021 14:38, David Brown wrote:
> Rationals are easier when you have 0 :
> ℚ = { p / q : p, q ∈ ℤ, q > 0 }
> vs.
> ℚ = { p / q : p, q ∈ ℕ⁺ } ∪ { 0 } ∪ { -p / q : p, q ∈ ℕ⁺ }

Or vs ℚ = { p, q : p ∈ ℤ, q ∈ ℕ }.

> [...] But calling the additive identity "0" or
> "1" /does/ matter, because one choice makes sense and the other choice
> is pointlessly confusing. (The definition of addition does not actually
> require an identity.)

No-one calls the additive identity 1, esp as it's not even
useful until you get to much more advanced maths, by which time you
already have 0 [part of ℤ, defined by equivalence classes of pairs
of members of ℕ].

> [...] In my experience (as someone
> with a degree in mathematics and theoretical computing, [...].

No such thing when I was a student!

> I had thought of surreals as trying to find gaps
> and endpoints in the reals and filling them in (though I know the
> construction doesn't do that).

No, rather that "filling in gaps" [ie, partitioning known
numbers] produces the reals and more. If the partitioning is
ordered, you get numbers; if unordered, you get games [of which
numbers are therefore a subset].

> I wonder if the lengths in TeX, which have 3 (IIRC) layers of infinities
> and infinitesimals, were invented as a kind of computer approximation to
> surreals?

Pass. I've never used [and don't like] TeX; we had real
experts in typography in my dept [consultants for major academic
publishers, exam boards, etc], and some of that rubbed off. They
disliked the "look" of Knuth's books, and even more so that we
kept being told that TeX knows best. They devoted their time to
tweaking Troff, which takes a more pragmatic view [and some of
the tweaks found their way back into "official" Troff]. I also
quite like Lout, FWIW.

[...]
> All sorts of maths that is esoteric to most people has some odd
> application or two. That is often what makes it interesting.

/All/ maths is esoteric to most people! A large majority
don't even know that there is maths beyond arithmetic, apart from
the algebra [etc] that never made any sense at all to them.

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

On 03/12/2021 17:26, Andy Walker wrote:
> On 03/12/2021 14:38, David Brown wrote:
>> Rationals are easier when you have 0 :
>>      ℚ = { p / q : p, q ∈ ℤ, q > 0 }
>> vs.
>>      ℚ = { p / q : p, q ∈ ℕ⁺  } ∪ { 0 } ∪ { -p / q : p, q ∈ ℕ⁺  }
>
>     Or vs ℚ = { p, q : p ∈ ℤ, q ∈ ℕ }.
>

ℕ is ambiguous - you need to write something like ℕ⁺ unless it is clear
from earlier. While it is quite easy to write ℕ⁺, there is no good
argument for suggesting it is noticeably simpler than using ℤ, nor any
special case handling for 0.

>> [...] But calling the additive identity "0" or
>> "1" /does/ matter, because one choice makes sense and the other choice
>> is pointlessly confusing.  (The definition of addition does not actually
>> require an identity.)
>
>     No-one calls the additive identity 1, esp as it's not even
> useful until you get to much more advanced maths, by which time you
> already have 0 [part of ℤ, defined by equivalence classes of pairs
> of members of ℕ].

You wrote:

I don't see "a + 1 == a'" as interestingly harder than
"a + 0 = a". In some ways it's easier;

Presumably then that was a typo. (Fair enough, we all do that.)

>
>> [...] In my experience (as someone
>> with a degree in mathematics and theoretical computing, [...].
>
>     No such thing when I was a student!
>
>> I had thought of surreals as trying to find gaps
>> and endpoints in the reals and filling them in (though I know the
>> construction doesn't do that).
>
>     No, rather that "filling in gaps" [ie, partitioning known
> numbers] produces the reals and more.  If the partitioning is
> ordered, you get numbers;  if unordered, you get games [of which
> numbers are therefore a subset].
>
>> I wonder if the lengths in TeX, which have 3 (IIRC) layers of infinities
>> and infinitesimals, were invented as a kind of computer approximation to
>> surreals?
>
>     Pass.  I've never used [and don't like] TeX;  we had real
> experts in typography in my dept [consultants for major academic
> publishers, exam boards, etc], and some of that rubbed off.  They
> disliked the "look" of Knuth's books, and even more so that we
> kept being told that TeX knows best.  They devoted their time to
> tweaking Troff, which takes a more pragmatic view [and some of
> the tweaks found their way back into "official" Troff].  I also
> quite like Lout, FWIW.

I learned my typography from the TeXBook and the LaTeX Documentation
Preparation System. Knuth's early books had ugly typography - that's
why he made TeX. But of course there's a lot of scope for subjective
choice in the subject, and for picking formats, layouts, etc., that suit
your own needs. LaTeX and friends take a bit of work to use well, but I
find it is worth it. (That is especially for most people that can't
afford in-house typographers, so the alternative is LibreOffice or,
horrors, Word.)

>
> [...]
>> All sorts of maths that is esoteric to most people has some odd
>> application or two.  That is often what makes it interesting.
>
>     /All/ maths is esoteric to most people!  A large majority
> don't even know that there is maths beyond arithmetic, apart from
> the algebra [etc] that never made any sense at all to them.
>

Touché.

On 03/12/2021 17:49, David Brown wrote:
[Definition of rationals:]
> ℕ is ambiguous - you need to write something like ℕ⁺ unless it is clear
> from earlier.

It was clear in context! But ℕ⁺ is still a more primitive
concept than ℤ.

> While it is quite easy to write ℕ⁺, there is no good
> argument for suggesting it is noticeably simpler than using ℤ, nor any
> special case handling for 0.

My version didn't have any special casing for 0. Note that
according to the usual development you need four members of ℕ to
construct two members of ℤ [as two equivalence classes of members
of ℕ], of which one is logically redundant.

> You wrote:
> I don't see "a + 1 == a'" as interestingly harder than
> "a + 0 = a". In some ways it's easier;
> Presumably then that was a typo. (Fair enough, we all do that.)

If it was, I still don't see it. Did you miss the "'"
[usual abbreviation for the successor function]?

Recap:
ANW: ℕ is 1, 1', 1'', ...; "+" is defined by "a + 1 == a'"
and "a + b' = (a+b)'"; "ℤ" by equivalence classes on
pairs of members of "ℕ"; "ℚ" as a triple of members of
"ℕ" [equivalently, a member of "ℤ" and a member of "ℕ"].
DB: ℕ is 0, 0', 0'', ...; "+" is defined by "a + 0 == a"
and "a + b' = (a+b)'"; "ℤ" by equivalence classes on
pairs of members of "ℕ"; "ℚ" as a pair of members of
"ℤ" of which the second is > 0 [equivalently, a member
of "ℤ" and a member of "ℕ⁺"].
I don't see an interesting difference in difficulty, nor any
good reason other than fashion to choose one over the other.

Further recap: this started with whether Bart counted "1, 2,
3, ..." or "0, 1, 2, ...". IRL virtually everyone is first
taught to count "1, 2, 3, ...". Everything else comes later
[if at all].

I doubt whether I have anything further to contribute
to this thread, which is now diverging a long way from CS.

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

On Thursday, December 2, 2021 at 1:37:33 AM UTC-6, David Brown wrote:
> On 02/12/2021 01:11, Andy Walker wrote:

> > [...]
> >> 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.
>

Dang. Y'all giving me ideas.

--
better watch out

On 03/12/2021 23:03, Andy Walker wrote:
> On 03/12/2021 17:49, David Brown wrote:
> [Definition of rationals:]
>> ℕ is ambiguous - you need to write something like ℕ⁺ unless it is clear
>> from earlier.
>
>     It was clear in context!  But ℕ⁺ is still a more primitive
> concept than ℤ.
>

You can't say that your definition of ℕ in your definition of ℚ is clear
in the context - that would be begging the question. Obviously I know
what you meant by ℕ because I know how the rationals are defined. But
if you are giving the definition of something, you can't force readers
to assume the definition you want in order to figure out the meaning of
the things you use in your definition.

I can agree that the naturals - with or without 0 - are more primitive
than the integers. I don't see an advantage in that. Mathematics is
about building up concepts step by step - once you have a concept, you
use it freely for the next step. There is no benefit in going back to
more primitive stages.

>>         While it is quite easy to write ℕ⁺, there is no good
>> argument for suggesting it is noticeably simpler than using ℤ, nor any
>> special case handling for 0.
>
>     My version didn't have any special casing for 0.  Note that
> according to the usual development you need four members of ℕ to
> construct two members of ℤ [as two equivalence classes of members
> of ℕ], of which one is logically redundant.
>
>> You wrote:
>>      I don't see "a + 1 == a'" as interestingly harder than
>> "a + 0 = a".  In some ways it's easier;
>> Presumably then that was a typo.  (Fair enough, we all do that.)
>
>     If it was, I still don't see it.  Did you miss the "'"
> [usual abbreviation for the successor function]?
>

Ah, yes, I /did/ miss that. Sorry. A tick mark as a successor
indicator is fine on paper, but I find it can easily be missed in emails
or Usenet where typography is limited. With that sorted out, I agree
with you - it is entirely possible to start your addition recursive
definition with 1 here. I can't see a benefit from starting with 1, and
the 0 will come in very handy later on, but they are both valid
alternatives.

>
>     I doubt whether I have anything further to contribute
> to this thread, which is now diverging a long way from CS.
>

I enjoy a little side-tracking sometimes, but it is a bit off-topic for
the thread and the group!

On Tue, 30 Nov 2021 08:07:30 +0000
James Harris <james.harris.1@gmail.com> 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.
>

'n'th, 'i'th, 'x'th, ...

Does the letter choice matter?

Why wouldn't you say the 10th or 7th or 1st etc by using an actual
number to specify a specific item? Although I do like variables, this
isn't algebra.

> 'element n'

Chemistry ... Obtuse?

Well, "item" is shorter than "element". So, that's one up vote for
"item" ...

> 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?

IMO, irrelevant.

As, he has his choice of either with 0-based indexing.

If he wants the first ten elements of an array to be indexed by 0 to 9,
he can use 0 to 9.

If he wants the first ten elements of an array to be indexed by 1 to
10, he can use 1 to 10, skip using 0, but he needs to remember
to allocate one additional element.

> [What does Rod prefer?]
> (Let's hope I'm not talking to myself now.)

Oh boy, you didn't ask me that ...
(Oops, it seems that I am talking to myself now.)

Maybe I've been coding in C for too long now, as I prefer zero-based
indexing, even in non-C situations like personal to-do lists.

0-based works really well with C, but I do recall it being somewhat
"unnatural" at first, even though zero was the central starting point of
the signed number line in mathematics. For programming, I strongly
prefer unsigned only. This eliminates many coding errors.

E.g., for C, I know that the address of the 0'th (zeroth) element of an
"array" (&A[0]) is the same as the base address of the said "array"
named A. This can be convenient as no address calculation needs to be
computed because there is no actual indexing into the array when the
index is zero.

E.g., for C, you can do neat 0-based "tricks" like below for loops to
detect loop termination. I.e., the value of 10 below as MAX detects the
end-of-loop of the 10 values of variable "i" with 0..9 being the actual
printed values:

#define MAX 10
for(i=0;i!=MAX;i++)

And, if the language is designed correctly and the variable is declared
with file scope, using zero-based indexing means that variables don't
need to be initialized to zero. They'll be cleared to zero upon
program execution. I.e., the "i=0" above should be optional in a
language for all declared file scope variables, since such variables
should be initialized to or cleared to zero by default. E.g., a C
compiler may warn if "i=0" initialization is missing when "i" is
declared with auto or local scope (within a procedure), but C compilers
will generally not warn when "i" is declared with file or global scope
(or local static) as they are initialized to zero due to BSS.

--
"If Britain were to join the United States, it would be the
second-poorest state, behind Alabama and ahead of Mississippi,"
Hunter Schwarz, Washington Post

On 06/12/2021 10:41, Rod Pemberton wrote:
> On Tue, 30 Nov 2021 08:07:30 +0000
> James Harris <james.harris.1@gmail.com> wrote:

>> [What does Rod prefer?]
>> (Let's hope I'm not talking to myself now.)

> 0-based works really well with C,

Well, C invented it. (If it didn't, then it made it famous.)

but I do recall it being somewhat
> "unnatural" at first, even though zero was the central starting point of
> the signed number line in mathematics.

Yeah, this my fence/fencepost distinction.

If you draw XY axes on squared paper, and start annotating the positive
X axis as 0 (at Y-axis), 1, 2, 3 ..., then those figures will mark the
vertical divisions between the squares.

NOT the squares themselves. The squares are what correspond to C array
elements.

> For programming, I strongly
> prefer unsigned only. This eliminates many coding errors.

OK, so we can forget about that negative X axis!

> E.g., for C, you can do neat 0-based "tricks" like below for loops to
> detect loop termination. I.e., the value of 10 below as MAX detects the
> end-of-loop of the 10 values of variable "i" with 0..9 being the actual
> printed values:
>
> #define MAX 10
> for(i=0;i!=MAX;i++)
>
>
> And, if the language is designed correctly and the variable is declared
> with file scope, using zero-based indexing means that variables don't
> need to be initialized to zero. They'll be cleared to zero upon
> program execution. I.e., the "i=0" above should be optional in a
> language for all declared file scope variables, since such variables
> should be initialized to or cleared to zero by default.

That's great. Until the second time you execute this loop:

for(; i!=MAX; i++)

since now i will have value 10 (or whatever it ended up as after 1000
more lines of code, being a file-scope variable visible from any
function). Or when you execute this separate loop further on:

for(; i<N; i++)

On 06/12/2021 11:41, Rod Pemberton wrote:

>
> Maybe I've been coding in C for too long now, as I prefer zero-based
> indexing, even in non-C situations like personal to-do lists.
>
> 0-based works really well with C, but I do recall it being somewhat
> "unnatural" at first, even though zero was the central starting point of
> the signed number line in mathematics. For programming, I strongly
> prefer unsigned only. This eliminates many coding errors.

Out of curiosity, what kinds of coding errors do you eliminate by using
unsigned types?

>
> E.g., for C, I know that the address of the 0'th (zeroth) element of an
> "array" (&A[0]) is the same as the base address of the said "array"
> named A. This can be convenient as no address calculation needs to be
> computed because there is no actual indexing into the array when the
> index is zero.
>
> E.g., for C, you can do neat 0-based "tricks" like below for loops to
> detect loop termination. I.e., the value of 10 below as MAX detects the
> end-of-loop of the 10 values of variable "i" with 0..9 being the actual
> printed values:
>
> #define MAX 10
> for(i=0;i!=MAX;i++)
>
>
> And, if the language is designed correctly and the variable is declared
> with file scope, using zero-based indexing means that variables don't
> need to be initialized to zero. They'll be cleared to zero upon
> program execution. I.e., the "i=0" above should be optional in a
> language for all declared file scope variables, since such variables
> should be initialized to or cleared to zero by default. E.g., a C
> compiler may warn if "i=0" initialization is missing when "i" is
> declared with auto or local scope (within a procedure), but C compilers
> will generally not warn when "i" is declared with file or global scope
> (or local static) as they are initialized to zero due to BSS.
>

Loop variables are almost always local, rather than file scope (or other
static lifetime). Indeed, they are normally local to the loop itself.
The idiomatic for loop in C is :

for (int i = 0; i < MAX; i++) { ... }

On Mon, 6 Dec 2021 12:24:18 +0000
Bart <bc@freeuk.com> wrote:

> On 06/12/2021 10:41, Rod Pemberton wrote:
> > On Tue, 30 Nov 2021 08:07:30 +0000
> > James Harris <james.harris.1@gmail.com> wrote:
> >> [What does Rod prefer?]
> >> (Let's hope I'm not talking to myself now.)
>
> > 0-based works really well with C,
>
> Well, C invented it. (If it didn't, then it made it famous.)
>
> > but I do recall it being somewhat
> > "unnatural" at first, even though zero was the central starting
> > point of the signed number line in mathematics.
>
> Yeah, this my fence/fencepost distinction.
>
> If you draw XY axes on squared paper, and start annotating the
> positive X axis as 0 (at Y-axis), 1, 2, 3 ..., then those figures
> will mark the vertical divisions between the squares.
>
> NOT the squares themselves. The squares are what correspond to C
> array elements.

Well, they can represent the squares too along a single axis, either X
or Y. I.e., skip zero, use the other values.

This won't work for a 2-dimensional grid, but the same is true of
arrays, e.g., A[2][3]. I.e., what do you call the 3rd square up in
the 2nd column?

> > For programming, I strongly
> > prefer unsigned only. This eliminates many coding errors.
>
> OK, so we can forget about that negative X axis!
>

and that negative Y axis too!

Yeah, we're down to one quadrant instead of four!

> > E.g., for C, you can do neat 0-based "tricks" like below for loops
> > to detect loop termination. I.e., the value of 10 below as MAX
> > detects the end-of-loop of the 10 values of variable "i" with 0..9
> > being the actual printed values:
> >
> > #define MAX 10
> > for(i=0;i!=MAX;i++)
> >
> >
> > And, if the language is designed correctly and the variable is
> > declared with file scope, using zero-based indexing means that
> > variables don't need to be initialized to zero. They'll be cleared
> > to zero upon program execution. I.e., the "i=0" above should be
> > optional in a language for all declared file scope variables, since
> > such variables should be initialized to or cleared to zero by
> > default.
>
> That's great. Until the second time you execute this loop:
>
> for(; i!=MAX; i++)

Why would you execute the loop a second time? ...

I.e., I'd argue that in general, very generally, loops are only
executed once within most C programs. However, obviously, if the loop
is re-used, the programmer must set i to 0, as shown previously, or to
1 in your case, prior to the re-use of i.

> since now i will have value 10 (or whatever it ended up as after 1000
> more lines of code, being a file-scope variable visible from any
> function). Or when you execute this separate loop further on:
>
> for(; i<N; i++)

The paragraph above was about the clearing of file or global scope
variables, not specifically about loops. If numbering and indexing
start with a value of one, then you'll have to "clear" the BSS
variables to a value of "one", except the binary representations for
what "one" is may vary depending on the data type, e.g., integer vs
float. Whereas, the binary representation for "zero" is almost always
all bits clear.

--

On Mon, 6 Dec 2021 14:56:41 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 06/12/2021 11:41, Rod Pemberton wrote:
>
> >
> > Maybe I've been coding in C for too long now, as I prefer zero-based
> > indexing, even in non-C situations like personal to-do lists.
> >
> > 0-based works really well with C, but I do recall it being somewhat
> > "unnatural" at first, even though zero was the central starting
> > point of the signed number line in mathematics. For programming, I
> > strongly prefer unsigned only. This eliminates many coding errors.
>
> Out of curiosity, what kinds of coding errors do you eliminate by
> using unsigned types?

When you expect the variable to function as unsigned, which is common
in C when working with characters, pointers, or binary data, but the
variable was actually declared as signed. If you add the value to
another integer, you'll end up with the "wrong" numeric result, i.e.,
other than what was expected because the variable was signed.

i=1000
x=0xFF (signed 8-bit char)
y=0xFF (unsigned 8-bit char)

i+x = 999 (unexpected)
i+y = 1255 (expected)

> > E.g., for C, I know that the address of the 0'th (zeroth) element
> > of an "array" (&A[0]) is the same as the base address of the said
> > "array" named A. This can be convenient as no address calculation
> > needs to be computed because there is no actual indexing into the
> > array when the index is zero.
> >
> > E.g., for C, you can do neat 0-based "tricks" like below for loops
> > to detect loop termination. I.e., the value of 10 below as MAX
> > detects the end-of-loop of the 10 values of variable "i" with 0..9
> > being the actual printed values:
> >
> > #define MAX 10
> > for(i=0;i!=MAX;i++)
> >
> >
> > And, if the language is designed correctly and the variable is
> > declared with file scope, using zero-based indexing means that
> > variables don't need to be initialized to zero. They'll be cleared
> > to zero upon program execution. I.e., the "i=0" above should be
> > optional in a language for all declared file scope variables, since
> > such variables should be initialized to or cleared to zero by
> > default. E.g., a C compiler may warn if "i=0" initialization is
> > missing when "i" is declared with auto or local scope (within a
> > procedure), but C compilers will generally not warn when "i" is
> > declared with file or global scope (or local static) as they are
> > initialized to zero due to BSS.
> >
>
> Loop variables are almost always local, rather than file scope (or
> other static lifetime). Indeed, they are normally local to the loop
> itself. The idiomatic for loop in C is :
>
> for (int i = 0; i < MAX; i++) { ... }
>

The paragraph on clearing variables, wasn't intended to be specifically
linked with the concept of a loop variable, or even a discussion of C
specifically, but was a generic statement for any file scope or global
variables, for some new language using C as a means to explain.

The other option, per the prior discussion, would require that the file
scope variables in BSS all be "cleared" to a value of one. As you know
from C, the representations for a value of one may be different for
each type of variable, e.g., integer vs float.

As for C, variable declarations within the for() loop is not valid
for ANSI C (C89), i.e., valid for C99 or C11 or later. So, one could
argue, that to ensure backwards code compatibility, hence portability
of C code, that declaring a variable somewhere within a procedure, such
as within a for() loop, should be avoided, yes? Think of C style guide
suggestions.

--

On 07/12/2021 12:52, Rod Pemberton wrote:
> On Mon, 6 Dec 2021 14:56:41 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 06/12/2021 11:41, Rod Pemberton wrote:
>>
>>>
>>> Maybe I've been coding in C for too long now, as I prefer zero-based
>>> indexing, even in non-C situations like personal to-do lists.
>>>
>>> 0-based works really well with C, but I do recall it being somewhat
>>> "unnatural" at first, even though zero was the central starting
>>> point of the signed number line in mathematics. For programming, I
>>> strongly prefer unsigned only. This eliminates many coding errors.
>>
>> Out of curiosity, what kinds of coding errors do you eliminate by
>> using unsigned types?
>
> When you expect the variable to function as unsigned, which is common
> in C when working with characters, pointers, or binary data, but the
> variable was actually declared as signed. If you add the value to
> another integer, you'll end up with the "wrong" numeric result, i.e.,
> other than what was expected because the variable was signed.
>
> i=1000
> x=0xFF (signed 8-bit char)

If x has int8 type then it has the value -1 not +255.

> y=0xFF (unsigned 8-bit char)
>
> i+x = 999 (unexpected)

This is not unexpected, only if you expect int8 to be able to represent
+255.

> i+y = 1255 (expected)

Unsigned has its own problems:

unsigned int i=1000;
unsigned int x=1001;

printf("%u\n",i-x);
printf("%f\n",(double)(i-x));

displsys:

4294967295
4294967295.000000

On 07/12/2021 13:52, Rod Pemberton wrote:
> On Mon, 6 Dec 2021 14:56:41 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 06/12/2021 11:41, Rod Pemberton wrote:
>>
>>>
>>> Maybe I've been coding in C for too long now, as I prefer zero-based
>>> indexing, even in non-C situations like personal to-do lists.
>>>
>>> 0-based works really well with C, but I do recall it being somewhat
>>> "unnatural" at first, even though zero was the central starting
>>> point of the signed number line in mathematics. For programming, I
>>> strongly prefer unsigned only. This eliminates many coding errors.
>>
>> Out of curiosity, what kinds of coding errors do you eliminate by
>> using unsigned types?
>
> When you expect the variable to function as unsigned, which is common
> in C when working with characters, pointers, or binary data, but the
> variable was actually declared as signed.

It's a bad idea ever to use plain "char" and think of it as a number at
all - thus signedness makes no sense. Use "signed char" or "unsigned
char" if you need a signed small type - or, preferably, uint8_t, int8_t,
or one of the other <stdint.h> types if you need maximal portability.

Pointers don't have a concept of signedness.

The only type that is guaranteed to work for general "binary data"
without a proper type, is "unsigned char".

These issues are not solved by "preferring to use unsigned", they are
solved by learning the language.

> If you add the value to
> another integer, you'll end up with the "wrong" numeric result, i.e.,
> other than what was expected because the variable was signed.
>
> i=1000
> x=0xFF (signed 8-bit char)
> y=0xFF (unsigned 8-bit char)
>
> i+x = 999 (unexpected)
> i+y = 1255 (expected)
>

"unsigned" on its own means "unsigned int". You don't have any unsigned
ints here, nor would they help.

Do you mean that you prefer to use a type that can hold the data you put
into it, rather than having it truncated or converted? If so, then I
agree - that is sane practice for all types and all programming languages.

But your "unexpected" result is caused by someone trying to use a
"signed char" or plain "char" (without knowing the signedness) for
values outside its range and for something completely inappropriate. A
much more useful coding rule here is "don't use plain chars for numbers
or arithmetic - use <stdint.h> types", rather than "prefer unsigned".

I agree that people do make mistakes by assuming that plain "char" is
signed - I just disagree that "preferring unsigned" is helpful in
avoiding such mistakes.

(I personally use a lot more unsigned types than most, because types
such as uint8_t, uint16_t and uint32_t are most natural when dealing
with low-level embedded programming.)

>>> E.g., for C, I know that the address of the 0'th (zeroth) element
>>> of an "array" (&A[0]) is the same as the base address of the said
>>> "array" named A. This can be convenient as no address calculation
>>> needs to be computed because there is no actual indexing into the
>>> array when the index is zero.
>>>
>>> E.g., for C, you can do neat 0-based "tricks" like below for loops
>>> to detect loop termination. I.e., the value of 10 below as MAX
>>> detects the end-of-loop of the 10 values of variable "i" with 0..9
>>> being the actual printed values:
>>>
>>> #define MAX 10
>>> for(i=0;i!=MAX;i++)
>>>
>>>
>>> And, if the language is designed correctly and the variable is
>>> declared with file scope, using zero-based indexing means that
>>> variables don't need to be initialized to zero. They'll be cleared
>>> to zero upon program execution. I.e., the "i=0" above should be
>>> optional in a language for all declared file scope variables, since
>>> such variables should be initialized to or cleared to zero by
>>> default. E.g., a C compiler may warn if "i=0" initialization is
>>> missing when "i" is declared with auto or local scope (within a
>>> procedure), but C compilers will generally not warn when "i" is
>>> declared with file or global scope (or local static) as they are
>>> initialized to zero due to BSS.
>>>
>>
>> Loop variables are almost always local, rather than file scope (or
>> other static lifetime). Indeed, they are normally local to the loop
>> itself. The idiomatic for loop in C is :
>>
>> for (int i = 0; i < MAX; i++) { ... }
>>
>
> The paragraph on clearing variables, wasn't intended to be specifically
> linked with the concept of a loop variable, or even a discussion of C
> specifically, but was a generic statement for any file scope or global
> variables, for some new language using C as a means to explain.
>

Eh, okay, I suppose. It's an rather odd example, in that loop variables
(in any language) are perhaps the least likely of any variable uses to
have static lifetime.

> The other option, per the prior discussion, would require that the file
> scope variables in BSS all be "cleared" to a value of one. As you know
> from C, the representations for a value of one may be different for
> each type of variable, e.g., integer vs float.

It would also give a new and exciting meaning to the word "clear", as
well as making every other static-lifetime default initialised variable
wrong.

>
> As for C, variable declarations within the for() loop is not valid
> for ANSI C (C89), i.e., valid for C99 or C11 or later.

C18 is the current standard - without other qualifications, that is what
is meany by "C". If you want to pick an older standard, it is best to
specify it explicitly. (And I don't recommend using the term "ANSI C"
at all - people often use it to mean C89, when in fact it means "the
current ISO C standard" - i.e., C18 at the time of writing.)

Of course you are correct that putting declarations in the "for" loop
was introduced in C99. Rounded to the nearest percentage, 100% of C
code has been written since the introduction of C99, and probably at
least 98% since it became widely supported by common tools. There are a
few very niche situations where it makes sense to use pre-C99 today,
other than for maintaining old programs in the style in which they were
written. Other than that, C99 syntax is standard.

> So, one could
> argue, that to ensure backwards code compatibility, hence portability
> of C code, that declaring a variable somewhere within a procedure, such
> as within a for() loop, should be avoided, yes? Think of C style guide
> suggestions.
>

No.

That's like saying software should be published as printouts in a
magazine, rather than, say, on a web page, for backwards compatibility.

On 07/12/2021 15:05, Bart wrote:
> On 07/12/2021 12:52, Rod Pemberton wrote:
>> On Mon, 6 Dec 2021 14:56:41 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> On 06/12/2021 11:41, Rod Pemberton wrote:
>>>
>>>>
>>>> Maybe I've been coding in C for too long now, as I prefer zero-based
>>>> indexing, even in non-C situations like personal to-do lists.
>>>>
>>>> 0-based works really well with C, but I do recall it being somewhat
>>>> "unnatural" at first, even though zero was the central starting
>>>> point of the signed number line in mathematics.  For programming, I
>>>> strongly prefer unsigned only.  This eliminates many coding errors.
>>>
>>> Out of curiosity, what kinds of coding errors do you eliminate by
>>> using unsigned types?
>>
>> When you expect the variable to function as unsigned, which is common
>> in C when working with characters, pointers, or binary data, but the
>> variable was actually declared as signed.  If you add the value to
>> another integer, you'll end up with the "wrong" numeric result, i.e.,
>> other than what was expected because the variable was signed.
>>
>> i=1000
>> x=0xFF  (signed 8-bit char)
>
> If x has int8 type then it has the value -1 not +255.
>

Correct. "0xff" is interpreted as an integer constant (value 255).
When assigned to "x", it is converted using an implementation-dependent
algorithm (which is invariably modulo reduction, when using a two's
complement system) to the range of the target variable - arriving at -1.

I'd prefer if C had some way of initialising variables that did not have
such implicit conversions (also known as "narrowing conversions"). C++
has a method which works well in practice but is, IMHO, ugly :

int8_t x { 0xff };

instead of :

int8_t x = 0xff;

The first is an error in C++ because of the narrowing conversion, the
second works exactly like C.

A syntax such as :

int8_t x := 0xff;

would have been nicer IMHO, but it's too late for that in C (or C++).

>
>> y=0xFF  (unsigned 8-bit char)
>>
>> i+x = 999   (unexpected)
>
> This is not unexpected, only if you expect int8 to be able to represent
> +255.
>
>> i+y = 1255  (expected)
>
> Unsigned has its own problems:
>
>     unsigned int i=1000;
>     unsigned int x=1001;
>
>     printf("%u\n",i-x);
>     printf("%f\n",(double)(i-x));
>
> displsys:
>
>     4294967295
>     4294967295.000000
>

That is also not unexpected.

(Other languages could reasonably handle this differently - C's
treatment of unsigned int as a modulo type is not the only practical way
to handle things. But if you know the basics of C, it is neither a
problem not a surprise.)

On 07/12/2021 14:55, David Brown wrote:
> On 07/12/2021 15:05, Bart wrote:

>> Unsigned has its own problems:
>>
>>     unsigned int i=1000;
>>     unsigned int x=1001;
>>
>>     printf("%u\n",i-x);
>>     printf("%f\n",(double)(i-x));
>>
>> displsys:
>>
>>     4294967295
>>     4294967295.000000
>>
>
> That is also not unexpected.
>
> (Other languages could reasonably handle this differently - C's
> treatment of unsigned int as a modulo type is not the only practical way
> to handle things. But if you know the basics of C, it is neither a
> problem not a surprise.)

When using signed integers, then you really only get problems with
overflows and such at quite high magnitudes, around +/- 2e9 for int32,
and considerably higher for int64 at +/- 9e18.

But you will normally work with values a long way from those limits,
unless results are stored in narrower types, so such problems are rare.

With unsigned numbers however, one of those problematic limits is zero,
which is really too close for comfort! So you will see problems even
with small, very ordinary calculations, such as 2 - 3, which here
underflows that zero.

On 08/12/2021 01:42, Bart wrote:
> On 07/12/2021 14:55, David Brown wrote:
>> On 07/12/2021 15:05, Bart wrote:
>
>>> Unsigned has its own problems:
>>>
>>>      unsigned int i=1000;
>>>      unsigned int x=1001;
>>>
>>>      printf("%u\n",i-x);
>>>      printf("%f\n",(double)(i-x));
>>>
>>> displsys:
>>>
>>>      4294967295
>>>      4294967295.000000
>>>
>>
>> That is also not unexpected.
>>
>> (Other languages could reasonably handle this differently - C's
>> treatment of unsigned int as a modulo type is not the only practical way
>> to handle things.  But if you know the basics of C, it is neither a
>> problem not a surprise.)
>
> When using signed integers, then you really only get problems with
> overflows and such at quite high magnitudes, around +/- 2e9 for int32,
> and considerably higher for int64 at +/- 9e18.

Yes.

>
> But you will normally work with values a long way from those limits,
> unless results are stored in narrower types, so such problems are rare.
>

Agreed.

> With unsigned numbers however, one of those problematic limits is zero,
> which is really too close for comfort! So you will see problems even
> with small, very ordinary calculations, such as 2 - 3, which here
> underflows that zero.
>

Disagreed.

Whatever kind of numbers you use, you have to apply a few brain cells.
You can't represent 1/3 with an integer, no matter how big it is. You
can't represent negative numbers with unsigned types. It's common
sense, not a "problematic limit". Anyone who finds it surprising that
you can't subtract 3 from 2 without signed numbers should give up their
programming career and go back to primary school. We have to have
/some/ standard of education in this profession!

On 08/12/2021 08:41, David Brown wrote:
> On 08/12/2021 01:42, Bart wrote:
>> On 07/12/2021 14:55, David Brown wrote:
>>> On 07/12/2021 15:05, Bart wrote:
>>
>>>> Unsigned has its own problems:
>>>>
>>>>      unsigned int i=1000;
>>>>      unsigned int x=1001;
>>>>
>>>>      printf("%u\n",i-x);
>>>>      printf("%f\n",(double)(i-x));
>>>>
>>>> displsys:
>>>>
>>>>      4294967295
>>>>      4294967295.000000
>>>>
>>>
>>> That is also not unexpected.
>>>
>>> (Other languages could reasonably handle this differently - C's
>>> treatment of unsigned int as a modulo type is not the only practical way
>>> to handle things.  But if you know the basics of C, it is neither a
>>> problem not a surprise.)
>>
>> When using signed integers, then you really only get problems with
>> overflows and such at quite high magnitudes, around +/- 2e9 for int32,
>> and considerably higher for int64 at +/- 9e18.
>
> Yes.
>
>>
>> But you will normally work with values a long way from those limits,
>> unless results are stored in narrower types, so such problems are rare.
>>
>
> Agreed.
>
>> With unsigned numbers however, one of those problematic limits is zero,
>> which is really too close for comfort! So you will see problems even
>> with small, very ordinary calculations, such as 2 - 3, which here
>> underflows that zero.
>>
>
> Disagreed.
>
> Whatever kind of numbers you use, you have to apply a few brain cells.
> You can't represent 1/3 with an integer, no matter how big it is. You
> can't represent negative numbers with unsigned types. It's common
> sense, not a "problematic limit". Anyone who finds it surprising that
> you can't subtract 3 from 2 without signed numbers should give up their
> programming career and go back to primary school. We have to have
> /some/ standard of education in this profession!

It won't be 2 - 3, it will be A - B.

Can the result be properly represented, or not? Given ordinary (ie.
smallish) signed values, it can. Given ordinary unsigned values, the
chances are 50% that it can't!

This is why I prefer signed types for general use to unsigned types. And
why my mixed arithmetic is performed using signed types.

Imagine working with unsigned float; where would you start with all the
potential problems!

C of course prefers to use unsigned for mixed arithmetic (although the
precise rules are complex). So here:

int a = 2;
unsigned b = 3;
double c = a-b;

printf("%f\n", c);

it prints 4294967295.000000. Same using b-4 instead of a-b.

If I do the same:

int a := 2
word b := 3
real c := a-b

println c

it shows -1.000000, for b-4 too. Fewer surprises.

I actually do all arithmetic using at least i64. Values of types u8, u16
and u32 are converted losslessly to i64 first. It's only when u64 is
involved that you need to start taking care, but my example uses u64
('word'), and that has more sensible behaviour than the C.

On 08/12/2021 10:45, Bart wrote:
> On 08/12/2021 08:41, David Brown wrote:
>> On 08/12/2021 01:42, Bart wrote:
>>> On 07/12/2021 14:55, David Brown wrote:
>>>> On 07/12/2021 15:05, Bart wrote:
>>>
>>>>> Unsigned has its own problems:
>>>>>
>>>>>       unsigned int i=1000;
>>>>>       unsigned int x=1001;
>>>>>
>>>>>       printf("%u\n",i-x);
>>>>>       printf("%f\n",(double)(i-x));
>>>>>
>>>>> displsys:
>>>>>
>>>>>       4294967295
>>>>>       4294967295.000000
>>>>>
>>>>
>>>> That is also not unexpected.
>>>>
>>>> (Other languages could reasonably handle this differently - C's
>>>> treatment of unsigned int as a modulo type is not the only practical
>>>> way
>>>> to handle things.  But if you know the basics of C, it is neither a
>>>> problem not a surprise.)
>>>
>>> When using signed integers, then you really only get problems with
>>> overflows and such at quite high magnitudes, around +/- 2e9 for int32,
>>> and considerably higher for int64 at +/- 9e18.
>>
>> Yes.
>>
>>>
>>> But you will normally work with values a long way from those limits,
>>> unless results are stored in narrower types, so such problems are rare.
>>>
>>
>> Agreed.
>>
>>> With unsigned numbers however, one of those problematic limits is zero,
>>> which is really too close for comfort! So you will see problems even
>>> with small, very ordinary calculations, such as 2 - 3, which here
>>> underflows that zero.
>>>
>>
>> Disagreed.
>>
>> Whatever kind of numbers you use, you have to apply a few brain cells.
>> You can't represent 1/3 with an integer, no matter how big it is.  You
>> can't represent negative numbers with unsigned types.  It's common
>> sense, not a "problematic limit".  Anyone who finds it surprising that
>> you can't subtract 3 from 2 without signed numbers should give up their
>> programming career and go back to primary school.  We have to have
>> /some/ standard of education in this profession!
>
> It won't be 2 - 3, it will be A - B.
>
> Can the result be properly represented, or not? Given ordinary (ie.
> smallish) signed values, it can. Given ordinary unsigned values, the
> chances are 50% that it can't!

Again, it is absolutely no different from A / B.

>
> This is why I prefer signed types for general use to unsigned types. And
> why my mixed arithmetic is performed using signed types.

Most people use signed types for general integer arithmetic - that's
fine, and the ability to subtract them and get negative numbers is one
of the reasons for that.

>
> Imagine working with unsigned float; where would you start with all the
> potential problems!
>
> C of course prefers to use unsigned for mixed arithmetic (although the
> precise rules are complex). So here:

The precise rules are simple, not complex. Pretending they are
difficult does not help. Personally, however, I don't think they are
good - I would have preferred rules that promoted both sides to a common
type that is big enough for all the values involved. Thus "signed int +
unsigned int" should be done as "signed long" (or "signed long long" if
necessary - or the rules for sizes should be changed too). Failing
that, it should be a constraint error (i.e., fail to compile).

C doesn't give me the rules I want here, so I use warnings and errors in
my compilation that flags such mixed arithmetic use as errors. The
result is that I can't get accidents with mixed arithmetic when
developing, and the code is fine for other compilers or flags because it
is just a slightly limited subset of C.

Other programmers make other choices, of course - that's just the way I
choose to handle this.

Please don't mistake my understanding of C's rules, my acceptance of
them, my appreciation that C is used by many people for many purposes
with different preferences and requirements, my working with C and
liking C, as meaning that I think C's rules are the way I personally
would have preferred.

>
>     int a = 2;
>     unsigned b = 3;
>     double c = a-b;
>
>     printf("%f\n", c);
>
> it prints 4294967295.000000. Same using b-4 instead of a-b.

Yes. That is not surprising. In C, the types of expressions are
determined from the inside out (the actual calculations can be done in
any order, as long as the results match the sequence point
requirements). The type used on the left of an assignment operator has
no bearing on the types used on the right hand side (and vice versa).

This is the same in the solid majority of programming languages. It is
a simple and consistent choice that is easy to understand and use.

It is not the only option. In Ada, as I understand it, expressions are
influenced by the type they are assigned to. This is certainly true for
literals and it allows overloading functions based on the return type.
I don't know the full rules here (others here know better - indeed, much
of what /I/ know has come from postings here).

Applying the types from the outside in, so that in "c = a - b;" the type
of "c" is applied to those of "a" and "b" before the subtraction, is an
alternative to applying it from the inside out. It is not /better/, it
is /different/. It has some pros, and some cons. It is not in any
sense more "natural" or more "expected".

>
> If I do the same:
>
>     int a := 2
>     word b := 3
>     real c := a-b
>
>     println c
>
> it shows -1.000000, for b-4 too. Fewer surprises.

Surprises are for people who don't know what they are doing. I can
agree that a result of -1 is more likely to be useful to the programmer,
but not that a reasonably competent C programmer would fine the C
version surprising.

And you are mixing two separate issues here, which does not help your case.

>
> I actually do all arithmetic using at least i64. Values of types u8, u16
> and u32 are converted losslessly to i64 first. It's only when u64 is
> involved that you need to start taking care, but my example uses u64
> ('word'), and that has more sensible behaviour than the C.

As I said above, I would be happiest with a language that when given "a
- b" would first ensure that "a" and "b" are converted to a common type
that covers the whole range of both. If that can't be done, or if the
overflow characteristics of the original types are incompatible and an
overflow is possible, then there should be an error.

This is completely orthogonal as to whether "a - b" should be converted
to "real" before the subtraction, given that the result will be assigned
to a "real", or whether it should be evaluated first in the closest
common type specified by the language ("i64" in your language, "unsigned
int" in the C version) and /then/ converted to "real".

In particular, what does your language give for :

int a := 2
int b := 3
real c := b / a;

println c

Does it print 1, or 1.5 ?

The C version would give 1. Ada, as far as I could see in a quick test
on <https://godbolt.org>, will not accept mixing types in the same
expression or assignment without explicit casts.

On 08/12/2021 11:07, David Brown wrote:
> On 08/12/2021 10:45, Bart wrote:

>> C of course prefers to use unsigned for mixed arithmetic (although the
>> precise rules are complex). So here:
>
> The precise rules are simple, not complex. Pretending they are
> difficult does not help.

Here is the table of rules for C: S means the operation is performed as
signed with a signed result; "." (chosen to make it clearer) means unsigned:

u8 u16 u32 u64 i8 i16 i32 i64

u8 S S . . S S S S
u16 S S . . S S S S
u32 . . . . . . . S
u64 . . . . . . . .

i8 S S . . S S S S
i16 S S . . S S S S
i32 S S . . S S S S
i64 S S S . S S S S

Here is the corresponding table for my language:

u8 u16 u32 u64 i8 i16 i32 i64

u8 . . . . S S S S
u16 . . . . S S S S
u32 . . . . S S S S
u64 . . . . S S S S

i8 S S S S S S S S
i16 S S S S S S S S
i32 S S S S S S S S
i64 S S S S S S S S

I think people can make up their own minds as to which has the simpler
rules!

(My table is missing row/colums for i128/u128, but it's the same
pattern: unsigned/unsigned => unsigned, otherwise signed. I don't know
what C's would look like with 128-bit added.)

> Personally, however, I don't think they are
> good - I would have preferred rules that promoted both sides to a common
> type that is big enough for all the values involved. Thus "signed int +
> unsigned int" should be done as "signed long" (or "signed long long" if
> necessary - or the rules for sizes should be changed too). Failing
> that, it should be a constraint error (i.e., fail to compile).
>
> C doesn't give me the rules I want here,

Yeah, I get that feeling a lot. (Are you still wondering why I prefer my
language?)

>
> In particular, what does your language give for :
>
> int a := 2
> int b := 3
> real c := b / a;
>
> println c
>
>
> Does it print 1, or 1.5 ?

My languages have two divide operators: "/" and "%".

"%" means integer divide. "/" is supposed to be for floating point
divide, but that's only on one language; the static one will still do
integer divide when both operands are integers.

So M will give 1.0, Q will give 1.5.

But in both cases, it is the operator and the operand types that
determine what happens. It can't look beyond that, since I want the same
code to work in dynamic code where that information doesn't exist (c
will not even have a type until assigned to).

You would anyway want a term like A*B, to give the same result in terms
of value and type, no matter which expressions it is part of.

In languages that do it differently, A*B could give different results
even if repeated within the same expression!

> The C version would give 1. Ada, as far as I could see in a quick test
> on <https://godbolt.org>, will not accept mixing types in the same
> expression or assignment without explicit casts.
>

On 08/12/2021 11:55, Bart wrote:
> On 08/12/2021 11:07, David Brown wrote:
>> On 08/12/2021 10:45, Bart wrote:
>
>>> C of course prefers to use unsigned for mixed arithmetic (although the
>>> precise rules are complex). So here:
>>
>> The precise rules are simple, not complex.  Pretending they are
>> difficult does not help.
>
> Here is the table of rules for C: S means the operation is performed as
> signed with a signed result; "." (chosen to make it clearer) means
> unsigned:
>
>        u8  u16 u32 u64  i8  i16 i32 i64
>
>    u8   S   S   .   .    S   S   S   S
>   u16   S   S   .   .    S   S   S   S
>   u32   .   .   .   .    .   .   .   S
>   u64   .   .   .   .    .   .   .   .
>
>    i8   S   S   .   .    S   S   S   S
>   i16   S   S   .   .    S   S   S   S
>   i32   S   S   .   .    S   S   S   S
>   i64   S   S   S   .    S   S   S   S
>
> Here is the corresponding table for my language:
>
>        u8  u16 u32 u64  i8  i16 i32 i64
>
>    u8   .   .   .   .    S   S   S   S
>   u16   .   .   .   .    S   S   S   S
>   u32   .   .   .   .    S   S   S   S
>   u64   .   .   .   .    S   S   S   S
>
>    i8   S   S   S   S    S   S   S   S
>   i16   S   S   S   S    S   S   S   S
>   i32   S   S   S   S    S   S   S   S
>   i64   S   S   S   S    S   S   S   S
>
> I think people can make up their own minds as to which has the simpler
> rules!

Actually my table is not up-to-date. I was going to add a remark about
thinking of tweaking it so that there were more signed operations; I'd
forgotten I'd already done it and was trying it out!

The current table is (arguably even simpler than before):

u8 u16 u32 u64 i8 i16 i32 i64

u8 S S S S S S S S
u16 S S S S S S S S
u32 S S S S S S S S
u64 S S S . S S S S

i8 S S S S S S S S
i16 S S S S S S S S
i32 S S S S S S S S
i64 S S S S S S S S

Everything is done as signed (specifically as i64, not shown), except
for u64/u64.

Any scheme will give incorrect results: inappropriate signedness,
overflow etc on certain combination. This was designed to minimise those
and give the most useful results for the most common values.

Explicit u64 types are not common; but quite common are u8 u16 u32 used
in arrays and structs, which are about saving space.

But this is a demonstration of the benefit:

u8 a:=2, b:=3

println a-b

Under the old chart, this displayed 18446744073709551615 (u8-u8 =>
u64-u64 => u64). Under the new one, it shows -1 (u8-u8 => i64-i64 => i64).

BTW this is the C table showing the operation and result types (both
sides promoted to the type shown):

u8 u16 u32 u64 i8 i16 i32 i64

u8 i32 i32 u32 u64 i32 i32 i32 i64
u16 i32 i32 u32 u64 i32 i32 i32 i64
u32 u32 u32 u32 u64 u32 u32 u32 i64
u64 u64 u64 u64 u64 u64 u64 u64 u64

i8 i32 i32 u32 u64 i32 i32 i32 i64
i16 i32 i32 u32 u64 i32 i32 i32 i64
i32 i32 i32 u32 u64 i32 i32 i32 i64
i64 i64 i64 i64 u64 i64 i64 i64 i64

And this is my own current chart:

u8 u16 u32 u64 i8 i16 i32 i64

u8 i64 i64 i64 i64 i64 i64 i64 i64
u16 i64 i64 i64 i64 i64 i64 i64 i64
u32 i64 i64 i64 i64 i64 i64 i64 i64
u64 i64 i64 i64 u64 i64 i64 i64 i64

i8 i64 i64 i64 i64 i64 i64 i64 i64
i16 i64 i64 i64 i64 i64 i64 i64 i64
i32 i64 i64 i64 i64 i64 i64 i64 i64
i64 i64 i64 i64 i64 i64 i64 i64 i64

Spot the odd-one-out.

On 08/12/2021 12:55, Bart wrote:
> On 08/12/2021 11:07, David Brown wrote:
>> On 08/12/2021 10:45, Bart wrote:
>
>>> C of course prefers to use unsigned for mixed arithmetic (although the
>>> precise rules are complex). So here:
>>
>> The precise rules are simple, not complex.  Pretending they are
>> difficult does not help.
>

What is it with you and your campaign to claim everything C is bad, and
everything in your useless little private language is good? It doesn't
matter what anyone writes - you /always/ twist the facts, move the
goalposts or deliberately misinterpret what others write. (And yes,
your language is useless - no one else will ever use it. You've had
made useful software with it and used it in your work in the past.
That's great, and genuinely praise-worthy. But it is dead now. Move
along.)

So - let's start with some kindergarten logic. Claiming that your rules
are simpler than C's does not make C's rules complex.

In a binary arithmetic expression with integer types, any type smaller
than "int" is first converted to an "int". Then if the two parts have
different types, they are converted to the bigger type with "unsigned"
types being treated as slightly bigger than the signed types.

It is /not/ hard. It is /not/ complex. You might not think it is
ideal, and I'd agree. But it really is not rocket science, and it
doesn't need a complicated table of inappropriate made-up types to make
it look more complicated.

Oh, and your method will screw up too, for some cases. /Any/ method
will in some cases, unless you have unlimited ranges for your integers
(like Python) or point-blank refuse mixed signed expressions (like Ada).
And your language will still screw up on overflows.

(And before you post your knee-jerk response, the fact that C gets
things wrong on overflow does not mean your language is right or better.)

<snip more pointless and annoying drivel>

>> In particular, what does your language give for :
>>
>>       int a := 2
>>       int b := 3
>>       real c := b / a;
>>
>>       println c
>>
>>
>> Does it print 1, or 1.5 ?
>
> My languages have two divide operators: "/" and "%".
>
> "%" means integer divide. "/" is supposed to be for floating point
> divide, but that's only on one language; the static one will still do
> integer divide when both operands are integers.

Genius. Does it also use "and" as a keyword for the remainder after
division? Nothing says "simple" and "intuitive" like picking different
meanings for your operators than all other languages.

>
> So M will give 1.0, Q will give 1.5.
>

That's your two languages that are proudly the same syntax, but handle
expressions in completely different ways?

If you want to keep posting about your own language, please feel free -
only you can tell if you are making things up as you go along. But
/please/ stop posting shite about other languages that you refuse to
understand.

Understand me correctly here - I really don't care if you like C or not.
I don't care if anyone else here likes it or not, uses it or not. I am
not interested in promoting C or any other language - I'll use what I
want to use, and others will use what they want.

But what I /do/ react against is lies, FUD, and misrepresentations. I
am not "pro-C" - I am "anti-FUD", and it just so happens that your
bizarre hatred of C means it is C you post rubbish about. I'd react
against anyone else deliberately and repeatedly writing nonsense about
other topics too.

On 08/12/2021 15:36, David Brown wrote:
> On 08/12/2021 12:55, Bart wrote:

>
> What is it with you and your campaign to claim everything C is bad, and
> everything in your useless little private language is good?

I said the rules are complex. You said they are simple. I disagreed, and
illustrated my point with a chart.

> than "int" is first converted to an "int". Then if the two parts have
> different types, they are converted to the bigger type with "unsigned"
> types being treated as slightly bigger than the signed types.

At least, they are simpler than the rules for type syntax. And not much
simpler than the rules for charting the Mandelbrot Set!

> It is /not/ hard. It is /not/ complex. You might not think it is
> ideal, and I'd agree. But it really is not rocket science, and it
> doesn't need a complicated table of inappropriate made-up types

What made-up types? And why are they inappropriate?

Are you sure you aren't twisting and making up things yourself?

> to make
> it look more complicated.

I think most people would be surprised at how untidy that chart is. /I/ was.

>>> Does it print 1, or 1.5 ?
>>
>> My languages have two divide operators: "/" and "%".
>>
>> "%" means integer divide. "/" is supposed to be for floating point
>> divide, but that's only on one language; the static one will still do
>> integer divide when both operands are integers.
>
> Genius. Does it also use "and" as a keyword for the remainder after
> division? Nothing says "simple" and "intuitive" like picking different
> meanings for your operators than all other languages.

"%" was used for integer divide in Pascal. I adopted it in the 1980s
when I needed distinct operators.

And I use "rem" for integer REMainder instead of "%"; "ixor" instead of
"^"; "ior" instead of "|" and "or" instead of "||". Maybe it's just me,
but I find them more readable.

Why, what do other languages use for integer divide?

>> So M will give 1.0, Q will give 1.5.
>>
>
> That's your two languages that are proudly the same syntax, but handle
> expressions in completely different ways?

Funnily enough, C and Python will also give 1.0 and 1.5 respectively.

But that of course is fine.

On 08/12/2021 17:58, Bart wrote:
> On 08/12/2021 15:36, David Brown wrote:
>> On 08/12/2021 12:55, Bart wrote:
>
>
>>
>> What is it with you and your campaign to claim everything C is bad, and
>> everything in your useless little private language is good?
>
> I said the rules are complex. You said they are simple. I disagreed, and
> illustrated my point with a chart.

A chart designed purely to make the simple rules of C appear complex -
it is FUD. You added those of your own language, which is utterly
irrelevant to C, purely to be able to claim that the rules of your
language are simple. Note that even if your language's rules are
simpler in some way, that does /not/ make C's rules complex!

>
>> than "int" is first converted to an "int".  Then if the two parts have
>> different types, they are converted to the bigger type with "unsigned"
>> types being treated as slightly bigger than the signed types.
>
> At least, they are simpler than the rules for type syntax. And not much
> simpler than the rules for charting the Mandelbrot Set!
>
>> It is /not/ hard.  It is /not/ complex.  You might not think it is
>> ideal, and I'd agree.  But it really is not rocket science, and it
>> doesn't need a complicated table of inappropriate made-up types
>
> What made-up types? And why are they inappropriate?

There are no types of the names you used in C. C has a perfectly good
set of fundamental types (regardless of what you personally might think
of them, or even what /I/ personally might think of them), and the rules
of C are given in terms of those types.

>
> Are you sure you aren't twisting and making up things yourself?
>
>> to make
>> it look more complicated.
>
> I think most people would be surprised at how untidy that chart is. /I/
> was.

You seem to find just about everything in C surprising.

But let's be clear here. Do you think people familiar and experienced
with C programming will find C's rules surprising? Or do you just think
people who have never used C will find them surprising?

>
>
>>>> Does it print 1, or 1.5 ?
>>>
>>> My languages have two divide operators: "/" and "%".
>>>
>>> "%" means integer divide. "/" is supposed to be for floating point
>>> divide, but that's only on one language; the static one will still do
>>> integer divide when both operands are integers.
>>
>> Genius.  Does it also use "and" as a keyword for the remainder after
>> division?  Nothing says "simple" and "intuitive" like picking different
>> meanings for your operators than all other languages.
>
> "%" was used for integer divide in Pascal. I adopted it in the 1980s
> when I needed distinct operators.
>
> And I use "rem" for integer REMainder instead of "%"; "ixor" instead of
> "^"; "ior" instead of "|" and "or" instead of "||". Maybe it's just me,
> but I find them more readable.
>
> Why, what do other languages use for integer divide?

Most use /. And in most languages, if they have % operator for
integers, it means modulus. (Conventions differ regarding rounding and
signs when dividing by negative integers.)

>
>>> So M will give 1.0, Q will give 1.5.
>>>
>>
>> That's your two languages that are proudly the same syntax, but handle
>> expressions in completely different ways?
>
> Funnily enough, C and Python will also give 1.0 and 1.5 respectively.
>
> But that of course is fine.

Yes.

I've no problem with different languages handling these in different
ways - just as I have no problem with different languages handling
integer promotions and implicit conversions in different ways. I merely
have a problem with claims that one method is "surprising" and another
somehow unsurprising, and I would question the benefit of making
languages designed specifically to be as similar in appearance and
syntax as possible while disagreeing on something that fundamental.

So it is /fine/ that your language promotes unsigned types to signed
types in mixed arithmetic. Those are the rules you chose, and if they
are clear and consistent, great. It is /wrong/ to say they are better,
or simpler, than other choices. OK?

On 08/12/2021 17:13, David Brown wrote:
> On 08/12/2021 17:58, Bart wrote:
>> On 08/12/2021 15:36, David Brown wrote:
>>> On 08/12/2021 12:55, Bart wrote:
>>
>>
>>>
>>> What is it with you and your campaign to claim everything C is bad, and
>>> everything in your useless little private language is good?
>>
>> I said the rules are complex. You said they are simple. I disagreed, and
>> illustrated my point with a chart.

> A chart designed purely to make the simple rules of C appear complex -

Does it correctly represent what you get when you apply those rules?
Then there's nothing underhand about it.

> it is FUD. You added those of your own language, which is utterly
> irrelevant to C, purely to be able to claim that the rules of your
> language are simple.

My chart is partly simpler because there isn't a discontinuity in the
type system between 32-bit and 64-bit types as there is in most desktop Cs.

But it also simpler because I made it so.

>> What made-up types? And why are they inappropriate?
>
> There are no types of the names you used in C. C has a perfectly good
> set of fundamental types (regardless of what you personally might think
> of them, or even what /I/ personally might think of them), and the rules
> of C are given in terms of those types.

Oh, right, I should written uint64_t etc. Unfortunately that would have
made for a rather wide and spaced out chart.

(Or maybe I should included char, signed char, unsigned char,
signed/unsigned long etc as well. Then it would really have been big
/and/ complex!)

That is a ludicrous quibble; this is a language-agnostic group, and
everyone here surely can figure out what those types represent.

Besides I wanted two charts for comparison; they need to use the same
annotations.

>>
>> Are you sure you aren't twisting and making up things yourself?
>>
>>> to make
>>> it look more complicated.
>>
>> I think most people would be surprised at how untidy that chart is. /I/
>> was.
>
> You seem to find just about everything in C surprising.
>
> But let's be clear here. Do you think people familiar and experienced
> with C programming will find C's rules surprising

I think so. I thought for a long time that mixed arithmetic in C was
done as unsigned. But according to that chart, only 44% of mixed
combinations are done as unsigned; most are signed.

> Or do you just think
> people who have never used C will find them surprising?

There's a ton of things in C that even those who've used it for many
years, will find surprising.

>> Why, what do other languages use for integer divide?
>
> Most use /.

That's not integer divide. For example, Python uses "/" for floating
point divide, and "//" for integer divide. Although Python and its "//"
came along some years after I chose "%".

So what else is there?

Wikipedia says (https://en.wikipedia.org/wiki/Division_(mathematics)):

"Names and symbols used for integer division include div, /, \, and %"

In my IL, I used DIV, IDIV for float and integer division, and IREM for
integer remainder. (Float remainder uses FMOD.)

I had once reserved "//" for designating rational numbers.

> And in most languages, if they have % operator for
> integers, it means modulus.

And if they don't have "%"? Here:

https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages

it seems to be split between REM, MOD and %. I chose REM.

Some languages use more than one for a choice of behaviour.

I don't think "%" is the most common; where it is used, it's often for a
language with C-style syntax.