In a current discussion about a topic from the field of physics,
there are some people who do not realize that I am right.

In computer programming, often, when someone says something
that is wrong, I can demonstrate his error relatively easily
to such an extend, that he must realize that he is wrong.
Of course, this applies especially to trivial matters, and
not to all programming topics.

For example, when someone says, "In C, one cannot print
an asterisk, as this is a so-called 'meta character' that
has a special meaning for the language.", I can go ahead and
write a C program that prints an asterisk. Even if my opponent
does not even understand the program, he can start it and
see that it prints an asterisk.

Of, course, he /could/ say: "Yes, as I said. This program
is not written in C, because it prints an asterisk! This must
be C++.". But often he will see his error. People who do not
like to admit their errors have a hard time in programming,
because the behavior of their program is only controlled by
the technical guidelines of the language specification and
not by their wishful thinking or overconfidence.

When things get more complicated, it becomes more difficult,
to get your opponent to admit that you are right. For example,
you cannot write a program that shows the complexity of an
algorithm in a convincing manner.

Of course, it is also possible that I am the one who is wrong.

On 07/02/2023 7:53 pm, Stefan Ram wrote:

<snip>

> When things get more complicated, it becomes more difficult,
> to get your opponent to admit that you are right. For example,
> you cannot write a program that shows the complexity of an
> algorithm in a convincing manner.
>
> Of course, it is also possible that I am the one who is wrong.

Loop through from 1 to N.

Count c comparisons, say, on each iteration.

print n,c

You now have CSV data you can feed to Libre Office or the
spreadsheet program of your choice to make a nice pretty graph.

With big enough N it should show you most of what you need.

Of course, it is also possible that I am the one who is wrong.
But I think I just showed that not only /can/ you write such a
program, but it isn't even very difficult.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield <rjh@cpax.org.uk> writes:
>Loop through from 1 to N.
>Count c comparisons, say, on each iteration.
>print n,c
>You now have CSV data you can feed to Libre Office or the
>spreadsheet program of your choice to make a nice pretty graph.

Yes, I think this should show the relationship between n and c,
I did not think of this possibility!

On 7 Feb 2023 19:53:17 GMT, Stefan Ram wrote:
> In a current discussion about a topic from the field of physics,
> there are some people who do not realize that I am right.
>
> In computer programming, often, when someone says something
> that is wrong, I can demonstrate his error relatively easily
> to such an extend, that he must realize that he is wrong.
> Of course, this applies especially to trivial matters, and
> not to all programming topics.
>
> For example, when someone says, "In C, one cannot print
> an asterisk, as this is a so-called 'meta character' that
> has a special meaning for the language.", I can go ahead and
> write a C program that prints an asterisk. Even if my opponent
> does not even understand the program, he can start it and
> see that it prints an asterisk.
>
> Of, course, he /could/ say: "Yes, as I said. This program
> is not written in C, because it prints an asterisk! This must
> be C++.". But often he will see his error. People who do not
> like to admit their errors have a hard time in programming,
> because the behavior of their program is only controlled by
> the technical guidelines of the language specification and
> not by their wishful thinking or overconfidence.

If you go to any programming sub in Reddit, or any programming channel in
Discord, you'll realize that some people aren't capable of realizing that
they are wrong.

> When things get more complicated, it becomes more difficult,
> to get your opponent to admit that you are right. For example,
> you cannot write a program that shows the complexity of an
> algorithm in a convincing manner.

It may actually be the opposite. The program which is needed to convince the
opponent, would need to be done at a lower level - which increases the
complexity to understand the code.

Short question or small problem usually need a long answer or complex
solution. While long question or complex problem, usually need a short
answer or simple solution.

> Of course, it is also possible that I am the one who is wrong.

Nah... you're not wrong. Some people don't (yet) understand either the lower
level part of programming, or the concept of programming itself.

Many jump directly into learning how to code, and skip learning the concept
of programming. Including failing to understand the capabilities of a
computer, an OS, a compiler/interpreter, and a software library. Not aware
that they are actually crucial to programming. Because no matter how hard
they tried, if the underlying softwares and hardwares aren't capable of
doing it, it'll never happen. Care to download a RAM?

JJ <jj4public@outlook.com> writes:
>Many jump directly into learning how to code, and skip learning the concept
>of programming.

Requiring students to learn abstract concepts of programming
languages before they have made concrete programming
experiences in some specific languages might actually make it
unnecessarily difficult for them and slow down their learning.

On 07/02/2023 23:18, Stefan Ram wrote:
> JJ <jj4public@outlook.com> writes:
>> Many jump directly into learning how to code, and skip learning the concept
>> of programming.
>
> Requiring students to learn abstract concepts of programming
> languages before they have made concrete programming
> experiences in some specific languages might actually make it
> unnecessarily difficult for them and slow down their learning.
>
>

That is going to depend on what you are trying to teach them, and what
they are trying to learn. "Programming" is a broad field, and includes
software design, coding, algorithm design, testing, maintenance, project
management, code-reuse, libraries, understanding OS's, understanding
hardware, working with customers, documentation, specifications, and a
dozen other things that could be major aspects of work for someone who
calls themselves a "professional programmer".

No one course is ever going to teach it all. No one person is ever
going to be good at it all.

If you are teaching a short language-specific course for people who are
already experienced programmers but need to learn a specific language,
then you focus on that language. It can also be suitable for people who
are never going to be serious programmers but just need to use computers
for convenience (teach them Python), or for those with low ambitions and
low expectations who will be pure coders within a large team (teach them
C# or Java).

But for bigger courses teaching over a longer period, don't bother with
coding in "realistic" languages at the start. Your task is to show them
what's out there, and teach them how to learn. When teaching different
aspects of programming, use different languages. When they are done,
they will see languages as a detail, not the driving force - you'll have
taught people to be /programmers/, not merely Java programmers or C++
programmers.

And who cares if it slows down their learning? Speed of learning is not
a goal - things that are quickly taught are quickly forgotten. It is
what you know at the end of the course that matters.

On 07/02/2023 9:58 pm, JJ wrote:
> On 7 Feb 2023 19:53:17 GMT, Stefan Ram wrote:

<snip>

>
>> When things get more complicated, it becomes more difficult,
>> to get your opponent to admit that you are right. For example,
>> you cannot write a program that shows the complexity of an
>> algorithm in a convincing manner.
>
> It may actually be the opposite. The program which is needed to convince the
> opponent, would need to be done at a lower level - which increases the
> complexity to understand the code.
>
> Short question or small problem usually need a long answer or complex
> solution. While long question or complex problem, usually need a short
> answer or simple solution.

It is not immediately obvious that you know what Stefan means by
"complexity of an algorithm".

See Knuth's "The Art of Computer Programming", Vol I, section
1.2.11.1 for the beginning of an introduction to "big-O"
notation, or failing Knuth you could start here:

https://en.wikipedia.org/wiki/Big_O_notation

<snip>

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

On Tuesday, February 7, 2023 at 9:58:29 PM UTC, JJ wrote:
> If you go to any programming sub in Reddit, or any programming channel in
> Discord, you'll realize that some people aren't capable of realizing that
> they are wrong.

This is even more obvious in comp.theory. There is a poster there who claims to have refuted the Halting Problem proof, and to have a system which can accurately determine whether a program will halt or not. He has a demonstration program, which he claims does not halt and which his detector identifies as non-halting. He does however accept that when said program is run, it halts. He can't accept that his simulation is incorrect, however, and instead argues that this is proof that a program can behave differently when it is "directed executed" from when it is "correctly simulated". He goes on to say that it is correct for his detector to determinate what will happen when the program is correctly simulated, rather than what happens when it is run, and so his detector is correct. Numerous people have pointed the problems out to him, but he keeps posting to say that no-one has ever posted a correct refutation.

On 08/02/2023 3:03 pm, Paul N wrote:
> On Tuesday, February 7, 2023 at 9:58:29 PM UTC, JJ wrote:
>> If you go to any programming sub in Reddit, or any programming channel in
>> Discord, you'll realize that some people aren't capable of realizing that
>> they are wrong.
>
> This is even more obvious in comp.theory. There is a poster there who claims to have refuted the Halting Problem proof,

I refute it too. Bear with me.

> and to have a system which can accurately determine whether a program will halt or not.

I, too, have such a system. Bear with me.

> He has a demonstration program, which he claims does not halt

He is mistaken.

> and which his detector identifies as non-halting.

His detector errs.

> He does however accept that when said program is run, it halts. He can't accept that his simulation is incorrect, however, and instead argues that this is proof that a program can behave differently when it is "directed executed" from when it is "correctly simulated". He goes on to say that it is correct for his detector to determinate what will happen when the program is correctly simulated, rather than what happens when it is run, and so his detector is correct. Numerous people have pointed the problems out to him, but he keeps posting to say that no-one has ever posted a correct refutation.

Here is my refutation. Feed it with any program you like via a pipe.

#include <stdio.h>

int main(void)
{ int ch;
while((ch = getchar()) != EOF)
{
continue;
}
puts("If executed, the specified program will halt.");
return 0;
}

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 08/02/2023 3:03 pm, Paul N wrote:
>> On Tuesday, February 7, 2023 at 9:58:29 PM UTC, JJ wrote:
>>> If you go to any programming sub in Reddit, or any programming channel in
>>> Discord, you'll realize that some people aren't capable of realizing that
>>> they are wrong.

Yes, it's a rather quaint idea. Some subjects might make it easier for
people with open minds to discover their mistakes, but it's very far
from being universal!

>> This is even more obvious in comp.theory. There is a poster there who
>> claims to have refuted the Halting Problem proof,
>
> I refute it too. Bear with me.

OK...

>> and to have a system which can accurately determine whether a program
>> will halt or not.
>
> I, too, have such a system. Bear with me.

This is a rather different claim. The "Halting Problem proof" surely
refers to a proof of a specific mathematical theorem, so it's not clear
in what way any particular C program refutes it.

>> He has a demonstration program, which he claims does not halt

His claims change, but when I last checked in he (the loon in
comp.theory) was still being clear that the program in question halts.
He's posted code, he's posted traces of the simulation, he's stated it
in plain words.

> He is mistaken.

On this point, no.

>> and which his detector identifies as non-halting.
>
> His detector errs.
>
>> He does however accept that when said program is run, it halts.

Just to clear up the nonsense he spouts, he claims that "non-halting" is
the right answer because of what /would/ happen if the program were not
stopped -- that the program in question only halts because it is stopped
"by itself". Yes, it's bonkers, but he maintains he's right because
he's changed what "halting" means.

>> can't accept that his simulation is incorrect, however, and instead
>> argues that this is proof that a program can behave differently when
>> it is "directed executed" from when it is "correctly simulated". He
>> goes on to say that it is correct for his detector to determinate
>> what will happen when the program is correctly simulated, rather than
>> what happens when it is run, and so his detector is correct. Numerous
>> people have pointed the problems out to him, but he keeps posting to
>> say that no-one has ever posted a correct refutation.
>
> Here is my refutation. Feed it with any program you like via a pipe.
>
> #include <stdio.h>
>
> int main(void)
> {
> int ch;
> while((ch = getchar()) != EOF)
> {
> continue;
> }
> puts("If executed, the specified program will halt.");
> return 0;
> }

The proof is of a theorem about Turing machines. More importantly, the
property in question -- halting -- is one which, in the context of
Rice's theorem, is often called an "interesting" property of program
behaviour, i.e. it is possessed by some programs and not others. No
universal property of program behaviour is "interesting" in this sense,
so it's clear that this program can't be about whatever it is the
theorem is about.

OK, /I/ know you are joking, but will everyone? Do we want any more
people confused about what the halting theorem is about?

I think the fact that the term "halting" is so open to interpretation
(as here) is what makes it a magnet for cranks. (I know you are not a
crank, you are just having a bit of fun). No crank has ever stated that
they have a program that can compute the busy-beaver function, solve
Post's correspondence program or determine if a given context-free
grammar is ambiguous or not. Those problems are far too clear. It's
always some take on halting. I suppose that's why I get a bit cranky
myself when it comes up like this.

--
Ben.

On 08/02/2023 9:07 pm, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 08/02/2023 3:03 pm, Paul N wrote:
>>> On Tuesday, February 7, 2023 at 9:58:29 PM UTC, JJ wrote:
>>>> If you go to any programming sub in Reddit, or any programming channel in
>>>> Discord, you'll realize that some people aren't capable of realizing that
>>>> they are wrong.
>
> Yes, it's a rather quaint idea. Some subjects might make it easier for
> people with open minds to discover their mistakes, but it's very far
> from being universal!

Indeed, although computer programs have proven to be singularly
adept at proving their authors wrong!

>>> This is even more obvious in comp.theory. There is a poster there who
>>> claims to have refuted the Halting Problem proof,
>>
>> I refute it too. Bear with me.
>
> OK...

Ta.

>>> and to have a system which can accurately determine whether a program
>>> will halt or not.
>>
>> I, too, have such a system. Bear with me.
>
> This is a rather different claim. The "Halting Problem proof" surely
> refers to a proof of a specific mathematical theorem, so it's not clear
> in what way any particular C program refutes it.

The refutation is in the program's output (which is always correct):

If executed, the specified program will halt.

Which it will. ALL programs halt.

>
>>> He has a demonstration program, which he claims does not halt
>
> His claims change, but when I last checked in he (the loon in
> comp.theory) was still being clear that the program in question halts.
> He's posted code, he's posted traces of the simulation, he's stated it
> in plain words.
>
>> He is mistaken.
>
> On this point, no.

The specific statement I was addressing was: "He has a
demonstration program, which he claims does not halt"

Such a claim would be erroneous.

If he makes the opposite claim: "still being clear that the
program in question halts", then of course he is correct in
making that specific claim.

>
>>> and which his detector identifies as non-halting.
>>
>> His detector errs.
>>
>>> He does however accept that when said program is run, it halts.
>
> Just to clear up the nonsense he spouts, he claims that "non-halting" is
> the right answer because of what /would/ happen if the program were not
> stopped -- that the program in question only halts because it is stopped
> "by itself". Yes, it's bonkers, but he maintains he's right because
> he's changed what "halting" means.

We all know what "halting" means, and we all should know that all
programs halt.

<snip>

> OK, /I/ know you are joking, but will everyone?

No. That's part of the joy of Usenet.

> Do we want any more
> people confused about what the halting theorem is about?

Interesting exercise: attempt to justify a "yes" answer in an
entertaining way. (I came up with three that are far too dull to
post.)

>
> (I know you are not a
> crank, you are just having a bit of fun).

After such kind words, I suppose I had better let go of the handle.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 08/02/2023 9:07 pm, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 08/02/2023 3:03 pm, Paul N wrote:
>>>> On Tuesday, February 7, 2023 at 9:58:29 PM UTC, JJ wrote:
>>>>> If you go to any programming sub in Reddit, or any programming channel in
>>>>> Discord, you'll realize that some people aren't capable of realizing that
>>>>> they are wrong.
>> Yes, it's a rather quaint idea. Some subjects might make it easier for
>> people with open minds to discover their mistakes, but it's very far
>> from being universal!
>
> Indeed, although computer programs have proven to be singularly adept at
> proving their authors wrong!

Yes, that's a good point. Programming is more frequently humbling than
very many other activities, at least for most of us.

>>>> This is even more obvious in comp.theory. There is a poster there who
>>>> claims to have refuted the Halting Problem proof,
>>>
>>> I refute it too. Bear with me.
>> OK...
>
> Ta.
>
>>>> and to have a system which can accurately determine whether a program
>>>> will halt or not.
>>>
>>> I, too, have such a system. Bear with me.
>> This is a rather different claim. The "Halting Problem proof" surely
>> refers to a proof of a specific mathematical theorem, so it's not clear
>> in what way any particular C program refutes it.
>
> The refutation is in the program's output (which is always correct):
>
> If executed, the specified program will halt.
>
> Which it will. ALL programs halt.

Come on! You know I know what that C program does. What I don't know
is in what way that C program refutes a mathematical theorem. One makes
statement about programs, the other makes statements are Turing
machines. Presumably you don't think Turing machines all halt in the
same sense that you think all programs halt?

>>>> He has a demonstration program, which he claims does not halt
>> His claims change, but when I last checked in he (the loon in
>> comp.theory) was still being clear that the program in question halts.
>> He's posted code, he's posted traces of the simulation, he's stated it
>> in plain words.
>>
>>> He is mistaken.
>> On this point, no.
>
> The specific statement I was addressing was: "He has a demonstration
> program, which he claims does not halt"
>
> Such a claim would be erroneous.

OK. I was addressing his claims in the context of his model of
computation, not yours. His is abstract, yours is concrete. The
abstract model is interesting whereas yours is not -- in the technical
sense of interesting (that has been cut).

<cut>
>>>> He does however accept that when said program is run, it halts.
>> Just to clear up the nonsense he spouts, he claims that "non-halting" is
>> the right answer because of what /would/ happen if the program were not
>> stopped -- that the program in question only halts because it is stopped
>> "by itself". Yes, it's bonkers, but he maintains he's right because
>> he's changed what "halting" means.
>
> We all know what "halting" means, and we all should know that all programs
> halt.

Words rarely have unique meanings across all contexts. Halting means
all sorts of things. I'm forever halting my dog during a walk, and then
calling "walk on". I used to use a button to halt a program on a
mainframe when I needed to do certain physical activities with it. It
would then resume from halting.

Yes, we /should/ all know what halting, in the context of a "problem" in
computer science, means and I would imagine that you do too, but I keep
making the mistake of thinking that it's worth making technical replies
to humorous posts.

> <snip>

Oh, OK.

>> OK, /I/ know you are joking, but will everyone?
>
> No. That's part of the joy of Usenet.
>
>> Do we want any more
>> people confused about what the halting theorem is about?
>
> Interesting exercise: attempt to justify a "yes" answer in an entertaining
> way. (I came up with three that are far too dull to post.)

I'm old-school. I liked it more when Usenet was informative rather than
entertaining. I prefer to learn what people know and think and believe
about things. I'll try to reply in a more entertaining way in future!

--
Ben.

On 09/02/2023 1:09 am, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 08/02/2023 9:07 pm, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>>>> On 08/02/2023 3:03 pm, Paul N wrote:
>>>>> On Tuesday, February 7, 2023 at 9:58:29 PM UTC, JJ wrote:
>>>>>> If you go to any programming sub in Reddit, or any programming channel in
>>>>>> Discord, you'll realize that some people aren't capable of realizing that
>>>>>> they are wrong.
>>> Yes, it's a rather quaint idea. Some subjects might make it easier for
>>> people with open minds to discover their mistakes, but it's very far
>>> from being universal!
>>
>> Indeed, although computer programs have proven to be singularly adept at
>> proving their authors wrong!
>
> Yes, that's a good point. Programming is more frequently humbling than
> very many other activities, at least for most of us.
>
>>>>> This is even more obvious in comp.theory. There is a poster there who
>>>>> claims to have refuted the Halting Problem proof,
>>>>
>>>> I refute it too. Bear with me.
>>> OK...
>>
>> Ta.
>>
>>>>> and to have a system which can accurately determine whether a program
>>>>> will halt or not.
>>>>
>>>> I, too, have such a system. Bear with me.
>>> This is a rather different claim. The "Halting Problem proof" surely
>>> refers to a proof of a specific mathematical theorem, so it's not clear
>>> in what way any particular C program refutes it.
>>
>> The refutation is in the program's output (which is always correct):
>>
>> If executed, the specified program will halt.
>>
>> Which it will. ALL programs halt.
>
> Come on! You know I know what that C program does.

Yes, of course.

> What I don't know
> is in what way that C program refutes a mathematical theorem. One makes
> statement about programs,

Yes. That statement refutes the mathematical theorem by pointing
out an obvious fact about all programs.

> the other makes statements are Turing
> machines. Presumably you don't think Turing machines all halt in the
> same sense that you think all programs halt?

Of course all Turing machines halt. You don't seriously think it
is possible for a Turing machine *not* to halt, do you?

>
>>>>> He has a demonstration program, which he claims does not halt
>>> His claims change, but when I last checked in he (the loon in
>>> comp.theory) was still being clear that the program in question halts.
>>> He's posted code, he's posted traces of the simulation, he's stated it
>>> in plain words.
>>>
>>>> He is mistaken.
>>> On this point, no.
>>
>> The specific statement I was addressing was: "He has a demonstration
>> program, which he claims does not halt"
>>
>> Such a claim would be erroneous.
>
> OK. I was addressing his claims in the context of his model of
> computation, not yours. His is abstract, yours is concrete. The
> abstract model is interesting whereas yours is not -- in the technical
> sense of interesting (that has been cut).

I do not demand that you find my claim interesting. False claims
are very often far more interesting than true claims.

<snip>

>> <snip>
>
> Oh, OK.

You sound disappointed. I don't remember what I snipped and I'm
not going to check, but my intent was not to disappoint but to be
briefer.

<snip>

> I'm old-school. I liked it more when Usenet was informative rather than
> entertaining.

I guess that makes me middle-aged school, because I like both.

> I prefer to learn what people know and think and believe
> about things. I'll try to reply in a more entertaining way in future!

That's your decision, not mine. (But I don't think it's written
down anywhere that information has to be dull.)

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

On 09/02/2023 08:18, Richard Heathfield wrote:
> On 09/02/2023 1:09 am, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>

>>> If executed, the specified program will halt.
>>>
>>> Which it will. ALL programs halt.
>>
>> Come on!  You know I know what that C program does.
>
> Yes, of course.
>
>> What I don't know
>> is in what way that C program refutes a mathematical theorem.  One makes
>> statement about programs,
>
> Yes. That statement refutes the mathematical theorem by pointing out an
> obvious fact about all programs.
>
>> the other makes statements are Turing
>> machines.  Presumably you don't think Turing machines all halt in the
>> same sense that you think all programs halt?
>
> Of course all Turing machines halt. You don't seriously think it is
> possible for a Turing machine *not* to halt, do you?
>

You are making up new definitions here for pretty much all of the terms.

In the mathematics of computation and computability, where the halting
problem and associated theorems live, some programs (or Turing machines)
halt and some do not.

/Real-world/ programs always halt. Most of the programs I write have an
"infinite loop" - "while (true) { .... }" in them. But they stop when
someone switches off the board they are running on. Even the last of
the Novel Netware servers will stop with the heat death of the universe.

You /could/ argue that non-halting programs are just mathematical
fantasies. But like the infinite decimal expansion of pi, or the
never-ending list of integers, they are very useful fantasies that let
people reason about all kinds of /real/ things.

So let's please stick to the normal definitions of the terms, and not
add hidden assumptions about real-world limitations to simple
mathematical concepts.

On 2023-02-09 09:42, David Brown wrote:

> /Real-world/ programs always halt.  Most of the programs I write have an
> "infinite loop" - "while (true) { .... }" in them.  But they stop when
> someone switches off the board they are running on.  Even the last of
> the Novel Netware servers will stop with the heat death of the universe.

Here you are talking about a computing system, not the program it runs.
The computing system may halt = stop functioning. However arguably it
does not stop, it ceases to exist as a computing system.

The program does not. Per definition properties of a program are
independent on the computing system. It is like 1+1=2, even if some
beads of the abacus are built out of antimatter so that they annihilate
when touching other beads. Same stupid argument.

> You /could/ argue that non-halting programs are just mathematical
> fantasies.

All programs are mathematical fantasies. After all, they are immaterial.

> So let's please stick to the normal definitions of the terms, and not
> add hidden assumptions about real-world limitations to simple
> mathematical concepts.

Right.

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

On 09/02/2023 8:42 am, David Brown wrote:
> On 09/02/2023 08:18, Richard Heathfield wrote:
>> On 09/02/2023 1:09 am, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>
>>>> If executed, the specified program will halt.
>>>>
>>>> Which it will. ALL programs halt.
>>>
>>> Come on!  You know I know what that C program does.
>>
>> Yes, of course.
>>
>>> What I don't know
>>> is in what way that C program refutes a mathematical theorem.
>>> One makes
>>> statement about programs,
>>
>> Yes. That statement refutes the mathematical theorem by
>> pointing out an obvious fact about all programs.
>>
>>> the other makes statements are Turing
>>> machines.  Presumably you don't think Turing machines all halt
>>> in the
>>> same sense that you think all programs halt?
>>
>> Of course all Turing machines halt. You don't seriously think
>> it is possible for a Turing machine *not* to halt, do you?
>>
>
> You are making up new definitions here for pretty much all of the
> terms.

A very straight bat, very well played.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

On 09/02/2023 11:17, Dmitry A. Kazakov wrote:
> On 2023-02-09 09:42, David Brown wrote:
>
>> /Real-world/ programs always halt.  Most of the programs I write have
>> an "infinite loop" - "while (true) { .... }" in them.  But they stop
>> when someone switches off the board they are running on.  Even the
>> last of the Novel Netware servers will stop with the heat death of the
>> universe.
>
> Here you are talking about a computing system, not the program it runs.
> The computing system may halt = stop functioning. However arguably it
> does not stop, it ceases to exist as a computing system.

Agreed. That's a useful way to describe it.

>
> The program does not. Per definition properties of a program are
> independent on the computing system. It is like 1+1=2, even if some
> beads of the abacus are built out of antimatter so that they annihilate
> when touching other beads. Same stupid argument.
>

Yes.

>> You /could/ argue that non-halting programs are just mathematical
>> fantasies.
>
> All programs are mathematical fantasies. After all, they are immaterial.
>
>> So let's please stick to the normal definitions of the terms, and not
>> add hidden assumptions about real-world limitations to simple
>> mathematical concepts.
>
> Right.
>

On 09/02/2023 12:41, Richard Heathfield wrote:

> A very straight bat, very well played.
>

Is that a cricket metaphor? I'm Scottish, and we don't really do
cricket. What's the point of having a game with sticks if you can't hit
the other players when the ref is looking the other way? :-)

On 09/02/2023 1:20 pm, David Brown wrote:
> On 09/02/2023 12:41, Richard Heathfield wrote:
>
>> A very straight bat, very well played.
>>
>
> Is that a cricket metaphor?  I'm Scottish, and we don't really do
> cricket.

An effective but unimaginative defensive stroke.

>  What's the point of having a game with sticks if you
> can't hit the other players when the ref is looking the other
> way?  :-)

If the ref's looking the other way, I really don't see what's
stopping you.

Or maybe that's why in cricket you have two refs?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 09/02/2023 1:09 am, Ben Bacarisse wrote:

>> What I don't know
>> is in what way that C program refutes a mathematical theorem. One makes
>> statement about programs,
>
> Yes. That statement refutes the mathematical theorem by pointing out an
> obvious fact about all programs.

I'm now not sure if you are still joking. The theorem is about a
particular property not shared by all Turing machines

>> the other makes statements are Turing
>> machines. Presumably you don't think Turing machines all halt in the
>> same sense that you think all programs halt?
>
> Of course all Turing machines halt. You don't seriously think it is possible
> for a Turing machine *not* to halt, do you?

Of course. It seems hard to believe you are joking now, so maybe you
have some unconventional view on infinite and finite mathematical
sequences. Maybe you have your own definition of a Turing machine...

Can I ask what you mean when you say "a Turing machine"?

>>> <snip>
>> Oh, OK.
>
> You sound disappointed. I don't remember what I snipped and I'm not going to
> check, but my intent was not to disappoint but to be briefer.

I thought that part captured the key point. But it seems the
disagreement is about something else altogether -- maybe what an
infinite sequence is, or even what a TM is. I don't think what you cut
is significant any more.

<cut>
>> I prefer to learn what people know and think and believe
>> about things. I'll try to reply in a more entertaining way in future!
>
> That's your decision, not mine. (But I don't think it's written down
> anywhere that information has to be dull.)

Right, both is good, but you appeared to be /only/ joking -- making a
point you knew was not technically relevant but was amusing (nothing
wrong with that though it can be hard to tell the difference in some
corners of Usenet). I had no idea you were also conveying some
information. To be honest, I'm still not 100% sure if you are serious,
half-serious, conveying some genuinely held position or just having fun.

--
Ben.