From Newsgroup: comp.programming

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.


--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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!


--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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?
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.


--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.



--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

On 09/02/2023 2:05 pm, Ben Bacarisse wrote:

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.

"You make too much of a trifle", as Watson said to Holmes.
--
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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

I hate programming.



On Tuesday, February 7, 2023 at 10:53:15 PM UTC+2, Richard Heathfield wrote:

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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

On 09/02/2023 2:05 pm, Ben Bacarisse wrote:

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.

"You make too much of a trifle", as Watson said to Holmes.

Might I urge you to follow the excellent device of Flora Poste and to
mark with one or more asterisks those passages which you consider not to
be mere trifles and about which you consider it appropriate that
something might be made?
--
Ben.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

On 10/02/2023 11:46 am, Ben Bacarisse wrote:

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

On 09/02/2023 2:05 pm, Ben Bacarisse wrote:

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.

"You make too much of a trifle", as Watson said to Holmes.

Might I urge you to follow the excellent device of Flora Poste and to
mark with one or more asterisks those passages which you consider not to
be mere trifles and about which you consider it appropriate that
something might be made?

Indeed you might, but I give my readers the credit for being able
to tell the difference without their having to waste precious
computrons deciphering asterisks that are already overloaded with
*far too many* meanings.

Still, let me lay my somewhat arid sense of humour aside for a
moment and take one serious crack at explaining the rationale
that lies beneath my previous 'contributions' to this thread.

To argue for a mathematical model (such as a Turing machine) that
never halts necessarily and /obviously/ entails the claim that a
mathematical model can exist in perpetuity, for if the model
ceases to exist, so does the Turung machine. But such models
themselves exist only in the minds, writings and inventions of
mathematicians and scientists, and all the artifices and devices
of thinking creatures will end with the heat death of the
universe and the consequent inability for devices to do work.
Therefore, to argue that an unending program and its encompassing
mathematical model can exist necessarily requires one to argue,
in essence, for a non-corporeal and /intelligent/ life force to
persist after death not only of the individual but of the entire
universe. I don't know of many computer scientists who would be
prepared to argue for such persistence (because most computer
scientists I know are atheists). I conclude that a computer
scientist who argues that an unending Turing machine is possible
is very likely to be suffering from cognitive dissonance.

If you choose to reply, I will of course read your reply with
interest, but I may well not reply in turn because I intend to at
least attempt to refrain from contributing further to this
thread, as I, too, am making too much of a trifle.
--
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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

To argue for a mathematical model (such as a Turing machine) that
never halts necessarily and /obviously/ entails the claim that a >mathematical model can exist in perpetuity, for if the model
ceases to exist, so does the Turung machine.

In mathematics, words have meanings given to them
by definitions of a /theory/.

For example, this is a simple mathematical theory:

|Theory A
|
|This theory is based on set theory, so it takes
|the notions from set theory for granted.
|
|Definition 1:
|In this theory, any set is also called a /Turing
|machine/.
|
|Definition 2:
|We say that a Turing machine /never halts/ if it's
|not finite.
|
|Theorem 1:
|The Turing machine N (the set of all natural numbers)
|never halts. (The proof is obvious from the definitions.)

In theory A, N is a Turing machine that never halts.

The mathematical model of the theory A does not have
a physical existence in time. So it never started to
exist in this sence nor can it ever cease to exist.


--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

ram@zedat.fu-berlin.de (Stefan Ram) writes:

In mathematics, words have meanings given to them
by definitions of a /theory/.

Attributed to A. Einstein:

|As far as the laws of mathematics refer to reality,
|they are not certain; and as far as they are certain,
|they do not refer to reality.
attributed to A. Einstein.

Laws of mathematics never refer to reality; once you start to give
concepts a metrological or operational meaning, you're doing physics.


--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

Have You visited: http://meetupplaceforeveryone.atwebpages.com/a.php

and others:

https://groups.google.com/g/airplane/c/dNQxZmPVkbk


?





On Friday, February 10, 2023 at 2:49:12 PM UTC+2, Richard Heathfield wrote:

On 10/02/2023 11:46 am, Ben Bacarisse wrote:

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

On 09/02/2023 2:05 pm, Ben Bacarisse wrote:

Richard Heathfield <r...@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.

"You make too much of a trifle", as Watson said to Holmes.

Might I urge you to follow the excellent device of Flora Poste and to
mark with one or more asterisks those passages which you consider not to be mere trifles and about which you consider it appropriate that
something might be made?

Indeed you might, but I give my readers the credit for being able
to tell the difference without their having to waste precious
computrons deciphering asterisks that are already overloaded with
*far too many* meanings.

Still, let me lay my somewhat arid sense of humour aside for a
moment and take one serious crack at explaining the rationale
that lies beneath my previous 'contributions' to this thread.

To argue for a mathematical model (such as a Turing machine) that
never halts necessarily and /obviously/ entails the claim that a mathematical model can exist in perpetuity, for if the model
ceases to exist, so does the Turung machine. But such models
themselves exist only in the minds, writings and inventions of mathematicians and scientists, and all the artifices and devices
of thinking creatures will end with the heat death of the
universe and the consequent inability for devices to do work.
Therefore, to argue that an unending program and its encompassing mathematical model can exist necessarily requires one to argue,
in essence, for a non-corporeal and /intelligent/ life force to
persist after death not only of the individual but of the entire
universe. I don't know of many computer scientists who would be
prepared to argue for such persistence (because most computer
scientists I know are atheists). I conclude that a computer
scientist who argues that an unending Turing machine is possible
is very likely to be suffering from cognitive dissonance.

If you choose to reply, I will of course read your reply with
interest, but I may well not reply in turn because I intend to at
least attempt to refrain from contributing further to this
thread, as I, too, am making too much of a trifle.
--
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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

Still, let me lay my somewhat arid sense of humour aside for a moment and take one serious crack at explaining the rationale that lies beneath my previous 'contributions' to this thread.

To argue for a mathematical model (such as a Turing machine) that never
halts necessarily and /obviously/ entails the claim that a mathematical
model can exist in perpetuity, for if the model ceases to exist, so does the Turung machine.

That is not at all obvious. In fact, it seems like a deliberately
perverse interpretation of what a mathematician means by a theorem. The
TM model exists at the moment, and theorems about TMs are about what we
know about that model now. The TM that just "writes blank and goes
right" can be proved to "not halt" right now.

Aside: I use "scare quotes" because I don't like metaphors that can be
taken too literally. I'd write out the model, and give the state
transition function, but that would add too much bulk. Just note that
when I say "not halt" I mean that the sequence of configurations arising
from the state transition function is not finite (i.e. can proved to map
onto to a proper subset of itself).

But such models themselves exist only in the minds, writings and
inventions of mathematicians and scientists, and all the artifices and devices of thinking creatures will end with the heat death of the
universe and the consequent inability for devices to do
work.

But the statement, made now, that "this TM right here: <squiggle,
squiggle, squiggle> does not halt" is not a statement about what will be
known and understood for all time. It is simply a statement about what
we know now. 2+2=4 is a reasonable thing to assert now, given our
current shared agreement about the symbols and basic arithmetic. To
challenge it on the basis that there will one day be no minds to know
any arithmetic is to misinterpret what the claim is.

Therefore, to argue that an unending program and its
encompassing mathematical model can exist necessarily requires one to
argue, in essence, for a non-corporeal and /intelligent/ life force to persist after death not only of the individual but of the entire
universe.

I've never heard anyone else claim that a model needs to "exist" for any
more time than it takes to make statements using it and have them
understood by whoever we are talking to. You appeared to dispute a
claim made about some model we could reasonably be assumed to share.

We might all suffer profound mathematical amnesia tomorrow, but I was
still correct to claim, yesterday, that not all TMs halt, just as you
were wrong, yesterday, to dispute it. We won't know, tomorrow, what on
earth we were talking about, much less the right and the wrong of it,
but at the time we made our contradictory claims, we did.

I don't know of many computer scientists who would be
prepared to argue for such persistence (because most computer
scientists I know are atheists). I conclude that a computer scientist
who argues that an unending Turing machine is possible is very likely
to be suffering from cognitive dissonance.

In my experience, religious people are not very good an understanding
what's going on in the minds of atheists. And while the reverse is also
true, most atheists have stopped trying.

Very specifically: I don't argue for an unending Turing machine! The
notion need only exist for as long as it takes for a few theorems to be
proved about that notion -- about the same times it takes for a number
of people to pop up on Usenet to say that they have a refuted those
theorems.

I see mathematics as an exploration of rules: set up some rules and see
what can and can't be the case about the things named in the rules. If
we play chess, and you win, that fact remains a fact that we can talk
about (and even pass into history) as long as the words and rules remain understood. That not all TMs halt was a game that was concluded last
century, but we both still know the rules.

If you choose to reply, I will of course read your reply with interest, but
I may well not reply in turn because I intend to at least attempt to refrain from contributing further to this thread, as I, too, am making too much of a trifle.

Well I thought this part of the was interesting. I find it curious,
though, that you see the whole meaning of mathematical truth as a
trifle.
--
Ben.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

On 10/02/2023 11:16 pm, Ben Bacarisse wrote:

I don't argue for an unending Turing machine!

Fine; then we agree after all.
--
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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

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

On 10/02/2023 11:16 pm, Ben Bacarisse wrote:

I don't argue for an unending Turing machine!

Fine; then we agree after all.

This has been a very useful learning experience. Thank you.
--
Ben.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

On 11/02/2023 9:12 pm, Ben Bacarisse wrote:

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

On 10/02/2023 11:16 pm, Ben Bacarisse wrote:

I don't argue for an unending Turing machine!

Fine; then we agree after all.

This has been a very useful learning experience. Thank you.

I can't help reading a subtext into those words, perhaps
unjustly. Either way, I agree with you (again).
--
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

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.programming

Alright, but what does he not like in this ?




On Tuesday, February 7, 2023 at 10:53:15 PM UTC+2, Richard Heathfield wrote:

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

--- Synchronet 3.20a-Linux NewsLink 1.113