On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
The question is whether a universal termination analyser can be
constructed, and the answer is that it can't.
Aren't you kind of putting the cart before the horse with such an
assertion? Maybe the prior art you are basing that assertion on is
wrong?
You're speaking from ignorance of mathematics. The halting problem has
been unequivocally proven. It is a simple theorem, only slightly more
complicated than 2 + 2 = 4.
We're not talking about "prior art", or anything like that. We're
talking rigorous mathematics. We're talking about absolute truth,
something that Peter Olcott does not understand. You don't need to join
him.
/Flibble
Moronically stupid "rigorous mathematics" that is far
too stupid to know that unless the finite string input
input is transformed by finite string transformation
operations into outputs that you are doing the computer
science stupidly incorrectly.
All of logic, reasoning and computation boils down to
finite string transformations on inputs deriving outputs.
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
The question is whether a universal termination analyser can be
constructed, and the answer is that it can't.
Aren't you kind of putting the cart before the horse with such an
assertion? Maybe the prior art you are basing that assertion on is wrong?
You're speaking from ignorance of mathematics. The halting problem has
been unequivocally proven. It is a simple theorem, only slightly more
complicated than 2 + 2 = 4.
We're not talking about "prior art", or anything like that. We're
talking rigorous mathematics. We're talking about absolute truth,
something that Peter Olcott does not understand. You don't need to join
him.
/Flibble
Moronically stupid "rigorous mathematics" that is far
too stupid to know that unless the finite string input
input is transformed by finite string transformation
operations into outputs that you are doing the computer
science stupidly incorrectly.
All of logic, reasoning and computation boils down to
finite string transformations on inputs deriving outputs.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
All of logic, reasoning and computation boils down to finite string
transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't
prove, even were it true, since you don't understand the concept of
proof.
When a categorically exhaustive search is made it is self-evident that
all computation, logic, and human reasoning has as its barest possible essence transforming input finite strings into outputs via finite
string transformations.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
The question is whether a universal termination analyser can be
constructed, and the answer is that it can't.
Aren't you kind of putting the cart before the horse with such an
assertion? Maybe the prior art you are basing that assertion on is >>>>> wrong?
You're speaking from ignorance of mathematics. The halting problem has >>>> been unequivocally proven. It is a simple theorem, only slightly more >>>> complicated than 2 + 2 = 4.
We're not talking about "prior art", or anything like that. We're
talking rigorous mathematics. We're talking about absolute truth,
something that Peter Olcott does not understand. You don't need to
join
him.
/Flibble
Moronically stupid "rigorous mathematics" that is far
too stupid to know that unless the finite string input
input is transformed by finite string transformation
operations into outputs that you are doing the computer
science stupidly incorrectly.
That isn't even a well formed sentence.
All of logic, reasoning and computation boils down to
finite string transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't
prove, even were it true, since you don't understand the concept of
proof.
When a categorically exhaustive search is made it is
self-evident that all computation, logic, and human
reasoning has as its barest possible essence transforming input
finite strings into outputs via finite string transformations.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
The question is whether a universal termination analyser can be
constructed, and the answer is that it can't.
Aren't you kind of putting the cart before the horse with such an
assertion? Maybe the prior art you are basing that assertion on is wrong?
You're speaking from ignorance of mathematics. The halting problem has >>>> been unequivocally proven. It is a simple theorem, only slightly more >>>> complicated than 2 + 2 = 4.
We're not talking about "prior art", or anything like that. We're
talking rigorous mathematics. We're talking about absolute truth,
something that Peter Olcott does not understand. You don't need to join >>>> him.
/Flibble
Moronically stupid "rigorous mathematics" that is far
too stupid to know that unless the finite string input
input is transformed by finite string transformation
operations into outputs that you are doing the computer
science stupidly incorrectly.
That isn't even a well formed sentence.
All of logic, reasoning and computation boils down to
finite string transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't
prove, even were it true, since you don't understand the concept of
proof.
When a categorically exhaustive search is made it is
self-evident that all computation, logic, and human
reasoning has as its barest possible essence transforming input
finite strings into outputs via finite string transformations.
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite string
transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't
prove, even were it true, since you don't understand the concept of
proof.
When a categorically exhaustive search is made it is self-evident that
all computation, logic, and human reasoning has as its barest possible
essence transforming input finite strings into outputs via finite
string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite string >>>>>>> transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't >>>>>> prove, even were it true, since you don't understand the concept of >>>>>> proof.
When a categorically exhaustive search is made it is self-evident that >>>>> all computation, logic, and human reasoning has as its barest possible >>>>> essence transforming input finite strings into outputs via finite
string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite string >>>>>>> transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't >>>>>> prove, even were it true, since you don't understand the concept of >>>>>> proof.
When a categorically exhaustive search is made it is self-evident that >>>>> all computation, logic, and human reasoning has as its barest possible >>>>> essence transforming input finite strings into outputs via finite
string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite string >>>>>>>>> transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>> can't prove, even were it true, since you don't understand the >>>>>>>> concept of proof.
When a categorically exhaustive search is made it is self-evident >>>>>>> that all computation, logic, and human reasoning has as its
barest possible essence transforming input finite strings into
outputs via finite string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-existence of counter-examples is not a proof. In particular
mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:[ .... ]
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote: >>>>>>
All of logic, reasoning and computation boils down to finite >>>>>>>>> string
transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>> can't
prove, even were it true, since you don't understand the concept of >>>>>>>> proof.
When a categorically exhaustive search is made it is self-evident >>>>>>> that
all computation, logic, and human reasoning has as its barest
possible
essence transforming input finite strings into outputs via finite >>>>>>> string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-exitence of counter-examples is not a proof. In particular
mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
On 4/21/2025 4:33 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite >>>>>>>>>>> string
transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>>>> can't prove, even were it true, since you don't understand the >>>>>>>>>> concept of proof.
When a categorically exhaustive search is made it is self-evident >>>>>>>>> that all computation, logic, and human reasoning has as its
barest possible essence transforming input finite strings into >>>>>>>>> outputs via finite string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is >>>>>> not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-existence of counter-examples is not a proof. In
particular
mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
You're being stupid. Just because you can't think up a counterexample
doesn't mean other more intelligent people can't.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
It's self evident only to the arrogantly stupid.
All computation is isomorphic to:
Finite string transformations to finite strings.
An example of computation not based on string transformation is the
differential analyser. In this device, rotating disks engage with wheels >> by friction, these wheels being at varying distances from the centre of
the disk. The amount of rotation of the wheel was an integral (do you
even know what this means?) of one quantity with respect to another. The >> output from one wheel could be fed as an input to another disk, and so
on.
Another example is the slide rule.
There have been several/many types of analogue computers over the decades
and centuries, though these have now largely been superseded by digital
computers. Analog computations don't involve string manipulation.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:[ .... ]
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote: >>>>>>
All of logic, reasoning and computation boils down to finite string >>>>>>>>> transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you can't >>>>>>>> prove, even were it true, since you don't understand the concept of >>>>>>>> proof.
When a categorically exhaustive search is made it is self-evident that >>>>>>> all computation, logic, and human reasoning has as its barest possible >>>>>>> essence transforming input finite strings into outputs via finite >>>>>>> string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-exitence of counter-examples is not a proof. In particular
mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
On 4/21/2025 4:33 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite string >>>>>>>>>>> transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>>>> can't prove, even were it true, since you don't understand the >>>>>>>>>> concept of proof.
When a categorically exhaustive search is made it is self-evident >>>>>>>>> that all computation, logic, and human reasoning has as its
barest possible essence transforming input finite strings into >>>>>>>>> outputs via finite string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is >>>>>> not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-existence of counter-examples is not a proof. In particular >>>> mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
You're being stupid. Just because you can't think up a counterexample
doesn't mean other more intelligent people can't.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
It's self evident only to the arrogantly stupid.
All computation is isomorphic to:
Finite string transformations to finite strings.
On 4/21/2025 4:33 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite >>>>>>>>>>> string transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>>>> can't prove, even were it true, since you don't understand the >>>>>>>>>> concept of proof.
When a categorically exhaustive search is made it is self-evident >>>>>>>>> that all computation, logic, and human reasoning has as its
barest possible essence transforming input finite strings into >>>>>>>>> outputs via finite string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But it is >>>>>> not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-existence of counter-examples is not a proof. In particular >>>> mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
You're being stupid. Just because you can't think up a counterexample
doesn't mean other more intelligent people can't.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
It's self evident only to the arrogantly stupid.
All computation is isomorphic to:
Finite string transformations to finite strings.
An example of computation not based on string transformation is the
differential analyser. In this device, rotating disks engage with wheels
by friction, these wheels being at varying distances from the centre of
the disk. The amount of rotation of the wheel was an integral (do you
even know what this means?) of one quantity with respect to another. The
output from one wheel could be fed as an input to another disk, and so
on.
Another example is the slide rule.
There have been several/many types of analogue computers over the decades
and centuries, though these have now largely been superseded by digital
computers. Analog computations don't involve string manipulation.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 4/22/2025 10:27 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 4:33 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield >>>>>>>>>>>>>>> wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite >>>>>>>>>>>>> string transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>>>>>> can't prove, even were it true, since you don't understand the >>>>>>>>>>>> concept of proof.
When a categorically exhaustive search is made it is self- >>>>>>>>>>> evident
that all computation, logic, and human reasoning has as its >>>>>>>>>>> barest possible essence transforming input finite strings into >>>>>>>>>>> outputs via finite string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But >>>>>>>> it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-existence of counter-examples is not a proof. In
particular
mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
You're being stupid. Just because you can't think up a counterexample >>>> doesn't mean other more intelligent people can't.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
It's self evident only to the arrogantly stupid.
All computation is isomorphic to:
Finite string transformations to finite strings.
Is that really the best you can manage? Simply repeat discredited
falsehood, ignoring the argument which discredits it?
All computation is defined to be represented as finite
string transformations to finite strings.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
possible that report the halting behaviour for all inputs that specify
a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
On 4/22/2025 10:27 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 4:33 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/21/2025 3:57 AM, Mikko wrote:
On 2025-04-20 05:18:56 +0000, olcott said:
On 4/19/2025 2:48 AM, Mikko wrote:
On 2025-04-17 19:57:30 +0000, olcott said:
On 4/17/2025 2:19 PM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/17/2025 6:49 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
On 4/16/2025 1:09 PM, Alan Mackenzie wrote:
Mr Flibble <[email protected]> wrote:
On Wed, 16 Apr 2025 13:29:18 +0100, Richard Heathfield >>>>>>>>>>>>>>> wrote:
[ .... ]
All of logic, reasoning and computation boils down to finite >>>>>>>>>>>>> string transformations on inputs deriving outputs.
That's a big assertion, one you have not proved. It is one you >>>>>>>>>>>> can't prove, even were it true, since you don't understand the >>>>>>>>>>>> concept of proof.
When a categorically exhaustive search is made it is self- >>>>>>>>>>> evident
that all computation, logic, and human reasoning has as its >>>>>>>>>>> barest possible essence transforming input finite strings into >>>>>>>>>>> outputs via finite string transformations.
It is not at all self-evident.
It is self-evident that there are no exceptions to the rule
the all truth that is entirely anchored in fully formalized
semantics an be expressed as finite string transformations
from input finite strings.
It seems that there is an error above as I can't parse it. But >>>>>>>> it is
not clear how that should be corrected.
All mental, computational or logical reasoning
boils down to finite string transformation rules
applied to finite strings deriving finite string
outputs.
That no counter-example to this rule exists is its proof.
Unproven non-existence of counter-examples is not a proof. In
particular
mental reasoning is too poorly understood to be sure about anything.
In other words you cannot find a counter-example.
I claim that the entire category of counter-example
to the above statement is the empty set.
You're being stupid. Just because you can't think up a counterexample >>>> doesn't mean other more intelligent people can't.
When you try and find any computation that is not
essentially finite string transformations to finite
strings it is self-evident that none can possibly exist.
It's self evident only to the arrogantly stupid.
All computation is isomorphic to:
Finite string transformations to finite strings.
Is that really the best you can manage? Simply repeat discredited
falsehood, ignoring the argument which discredits it?
All computation is defined to be represented as finite
string transformations to finite strings.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
People here stupidly assume that the outputs are not
required to correspond to the inputs. That comes from
learn-by-rote with zero depth of understanding.
By the way, falsehoods don't become truths by continual repetition.
Misunderstood truths become understood with additional
elaboration.
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
possible that report the halting behaviour for all inputs that
specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
that describes a halting program. Not on the hypothetical input that
does not halt, because it is based on a hypothetical HHH that does not
abort.
Why do you maintain that HHH should process the hypothetical input
instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Where do they diverge? The directly executed DD also calls a HHH that
Op 22.apr.2025 om 18:38 schreef olcott:
On Turing Machines inputs <are> finite strings, and finite stringAnd it has been proven that no finite string transformations are
transformation rules <are> applied to these finite strings to derive
corresponding outputs.
possible that report the halting behaviour for all inputs that specify
a correct program.
The directly executed DD and DD emulated by HHH according to the
semantics of the x86 language have had provably different set of state changes for several years now.
HHH is only accountable for the behavior that its input actuallyOn the contrary, it is required to report on the behaviour of the
specifies and strictly NOT ALLOWED to report on anything else. HHH IS
NOT ALLOWED TO REPORT ON THE BEHAVIOR OF THE DIRECTLY EXECUTED DD. This breaks the computable function requirement that OUTPUTS MUST CORRESPOND
TO INPUTS.
Outputs are forced to correspond to inputs when finite stringThere are many behaviours you could compute from the description of
transformation rules are applied to inputs to derive outputs.
Agreed. Agreed?There is no algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed.
Agreed?
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming many years without any logic.
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string that describes a halting
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are possible that report the
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
halting behaviour for all inputs that specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
program. Not on the hypothetical input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
You failed to show the first state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach the end of the simulation of a
halting program.
On 4/23/2025 4:02 AM, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
possible that report the halting behaviour for all inputs that
specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
that describes a halting program. Not on the hypothetical input that
does not halt, because it is based on a hypothetical HHH that does
not abort.
Why do you maintain that HHH should process the hypothetical input
instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
many years without any logic. You failed to show the first state
change where the direct execution is different from the simulation.
You only showed an erroneous HHH that fails to reach the end of the
simulation of a halting program.
I have showed this hundreds of times.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Anyone that is an expert on the x86 language can directly
see that DD emulated by HHH cannot possibly reach its final
halt state by the finite string transformation rules of the
x86 language.
On 4/23/2025 10:28 AM, Mike Terry wrote:If so, show the first state change where the simulation is different
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are >>>>>>> possible that report the halting behaviour for all inputs that
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
that describes a halting program. Not on the hypothetical input
that does not halt, because it is based on a hypothetical HHH that
does not abort.
Why do you maintain that HHH should process the hypothetical input
instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
many years without any logic. You failed to show the first state
change where the direct execution is different from the simulation.
You only showed an erroneous HHH that fails to reach the end of the
simulation of a halting program.
Worse than this, on more than one occasion I've actually posted traces
of computation DDD(DDD) executed directly and simulated by HHH side by
side. Both traces were of course /identical/, up to the point where
HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
On 4/23/2025 4:02 AM, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
possible that report the halting behaviour for all inputs that
specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
that describes a halting program. Not on the hypothetical input that
does not halt, because it is based on a hypothetical HHH that does
not abort.
Why do you maintain that HHH should process the hypothetical input
instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
many years without any logic. You failed to show the first state
change where the direct execution is different from the simulation.
You only showed an erroneous HHH that fails to reach the end of the
simulation of a halting program.
I have showed this hundreds of times.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Anyone that is an expert on the x86 language can directly
see that DD emulated by HHH cannot possibly reach its final
halt state by the finite string transformation rules of the
x86 language.
Liars and ignorant people may disagree.
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming many years without any
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string that describes a halting
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are possible that report the
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
halting behaviour for all inputs that specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
program. Not on the hypothetical input that does not halt, because it is based on a
hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
logic. You failed to show the first state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach the end of the simulation of a
halting program.
Worse than this, on more than one occasion I've actually posted traces of computation DDD(DDD)
executed directly and simulated by HHH side by side.� Both traces were of course /identical/, up
to the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the first
state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach
the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to the
point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the first
state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach
the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to the
point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
This call immediately from the directly executed DD and
cannot possibility return from DD emulated by HHH according
to the finite string transformation rules of the x86 language.
HHH doesn't stop simulating DD until one recursive emulation
later on.
On 4/23/2025 10:34 PM, olcott wrote:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>>> input that does not halt, because it is based on a hypothetical >>>>>>>> HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things) >>>> The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
This call immediately from the directly executed DD and
cannot possibility return from DD emulated by HHH according
to the finite string transformation rules of the x86 language.
According to the finite string transformation rules of the x86 language.
The call from the directly executed DD to HHH(DD) immediately returns.
The call from DD emulated by HHH to HHH(DD) cannot possibility return.
HHH doesn't stop simulating DD until one recursive emulation
later on.
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are dreaming
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite string
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations are >>>>>>> possible that report the halting behaviour for all inputs that
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
specify a correct program.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
that describes a halting program. Not on the hypothetical input
that does not halt, because it is based on a hypothetical HHH that
does not abort.
Why do you maintain that HHH should process the hypothetical input
instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
many years without any logic. You failed to show the first state
change where the direct execution is different from the simulation.
You only showed an erroneous HHH that fails to reach the end of the
simulation of a halting program.
Worse than this, on more than one occasion I've actually posted traces
of computation DDD(DDD) executed directly and simulated by HHH side by
side. Both traces were of course /identical/, up to the point where
HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:Again a lot of words, which hide that you cannot show where the traces
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:That is exactly the same point. If not, show the difference in the
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the
hypothetical input that does not halt, because it is based on a >>>>>>>>> hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
traces before that point.
As soon as the directly executed DD calls HHH(DD) this
call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates
DD and also emulates itself emulating DD. This is one
whole recursive emulation than the directly executed
DD can possibly get to.
On 4/24/2025 2:15 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 19:46 schreef olcott:
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:That is exactly the same point. If not, show the difference in the
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
traces before that point.
As soon as the directly executed DD calls HHH(DD) this
call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates
DD and also emulates itself emulating DD. This is one
whole recursive emulation than the directly executed
DD can possibly get to.
Again a lot of words, which hide that you cannot show where the traces
differ up to that point.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
On 4/24/2025 2:15 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 19:46 schreef olcott:
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:Again a lot of words, which hide that you cannot show where the traces
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:That is exactly the same point. If not, show the difference in the
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are >>>>>>>>> dreaming many years without any logic. You failed to show the >>>>>>>>> first state change where the direct execution is different from >>>>>>>>> the simulation. You only showed an erroneous HHH that fails to >>>>>>>>> reach the end of the simulation of a halting program.
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite >>>>>>>>>>> string that describes a halting program. Not on the
Op 22.apr.2025 om 18:38 schreef olcott:int sum(int x, int y) { return x + y; }
And it has been proven that no finite string
a function is computable if there exists an algorithm >>>>>>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>>>>>> of the function domain it can return the corresponding >>>>>>>>>>>>>> output.
https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and >>>>>>>>>>>>>> finite string transformation rules <are> applied to >>>>>>>>>>>>>> these finite strings to derive corresponding outputs. >>>>>>>>>>>>>>
transformations are possible that report the halting >>>>>>>>>>>>> behaviour for all inputs that specify a correct program. >>>>>>>>>>>>
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
hypothetical input that does not halt, because it is based on >>>>>>>>>>> a hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
Worse than this, on more than one occasion I've actually posted >>>>>>>> traces of computation DDD(DDD) executed directly and simulated >>>>>>>> by HHH side by side. Both traces were of course /identical/, up >>>>>>>> to the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return. >>>>>>>
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
traces before that point.
As soon as the directly executed DD calls HHH(DD) this
call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates
DD and also emulates itself emulating DD. This is one
whole recursive emulation than the directly executed
DD can possibly get to.
differ up to that point.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
On 4/24/2025 6:22 AM, Richard Damon wrote:
On 4/23/25 11:38 AM, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the first
state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach
the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to the
point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
The call to HHH(DD) from the DD emulated by HHH, when correctly
emulated returns, just after the point that HHH gives up.
Factually Incorrect.
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the first
state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach
the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to the
point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
On 4/24/2025 3:03 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 21:45 schreef olcott:
On 4/24/2025 2:15 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 19:46 schreef olcott:
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:Again a lot of words, which hide that you cannot show where the
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:That is exactly the same point. If not, show the difference in the >>>>>> traces before that point.
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:Worse than this, on more than one occasion I've actually
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are >>>>>>>>>>> dreaming many years without any logic. You failed to show the >>>>>>>>>>> first state change where the direct execution is different >>>>>>>>>>> from the simulation. You only showed an erroneous HHH that >>>>>>>>>>> fails to reach the end of the simulation of a halting program. >>>>>>>>>>
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite >>>>>>>>>>>>> string that describes a halting program. Not on the
Op 22.apr.2025 om 18:38 schreef olcott:int sum(int x, int y) { return x + y; }
And it has been proven that no finite string
a function is computable if there exists an algorithm >>>>>>>>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>>>>>>>> of the function domain it can return the corresponding >>>>>>>>>>>>>>>> output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>>>>>>>
On Turing Machines inputs <are> finite strings, and >>>>>>>>>>>>>>>> finite string transformation rules <are> applied to >>>>>>>>>>>>>>>> these finite strings to derive corresponding outputs. >>>>>>>>>>>>>>>>
transformations are possible that report the halting >>>>>>>>>>>>>>> behaviour for all inputs that specify a correct program. >>>>>>>>>>>>>>
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
hypothetical input that does not halt, because it is based >>>>>>>>>>>>> on a hypothetical HHH that does not abort.
Why do you maintain that HHH should process the
hypothetical input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
posted traces of computation DDD(DDD) executed directly and >>>>>>>>>> simulated by HHH side by side. Both traces were of course / >>>>>>>>>> identical/, up to the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these >>>>>>>>> things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly
return.
...because HHH stops simulating before reaching that step in the >>>>>>>> computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
As soon as the directly executed DD calls HHH(DD) this
call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates
DD and also emulates itself emulating DD. This is one
whole recursive emulation than the directly executed
DD can possibly get to.
traces differ up to that point.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
That is not visible in the trace up to that point.
Not at all you are totally clueless about this.
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:That is exactly the same point. If not, show the difference in the
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the
hypothetical input that does not halt, because it is based on a >>>>>>>>> hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
traces before that point.
As soon as the directly executed DD calls HHH(DD) this
call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates
DD and also emulates itself emulating DD. This is one
whole recursive emulation than the directly executed
DD can possibly get to.
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the first
state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach
the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to the
point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
On 4/24/2025 6:22 AM, Richard Damon wrote:
On 4/23/25 11:38 AM, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>> input that does not halt, because it is based on a hypothetical
HHH that does not abort.
Why do you maintain that HHH should process the hypothetical
input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the first
state change where the direct execution is different from the
simulation. You only showed an erroneous HHH that fails to reach
the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to the
point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
The call to HHH(DD) from the DD emulated by HHH, when correctly
emulated returns, just after the point that HHH gives up.
Factually Incorrect.
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
On 4/24/2025 3:09 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 21:49 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the
hypothetical input that does not halt, because it is based on a >>>>>>>>> hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
It is only a finite recursion.
TOTALLY INCORRECT --- Please pay better attention.
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
not even after an infinite number of emulated steps.
not even after an infinite number of emulated steps.
not even after an infinite number of emulated steps.
On 4/24/2025 3:11 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 21:53 schreef olcott:
On 4/24/2025 6:22 AM, Richard Damon wrote:Factually incorrect, both the direct execution and the simulation have
On 4/23/25 11:38 AM, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the
hypothetical input that does not halt, because it is based on a >>>>>>>>> hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
The call to HHH(DD) from the DD emulated by HHH, when correctly
emulated returns, just after the point that HHH gives up.
Factually Incorrect.
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
a finite recursion.
You are stupidly wrong about this.
On 4/24/2025 5:53 AM, Richard Damon wrote:
On 4/23/25 11:40 PM, olcott wrote:
On 4/23/2025 10:34 PM, olcott wrote:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite >>>>>>>>>> string that describes a halting program. Not on the
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>>> are possible that report the halting behaviour for all >>>>>>>>>>>> inputs that specify a correct program.
a function is computable if there exists an algorithm >>>>>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs. >>>>>>>>>>>>>
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
hypothetical input that does not halt, because it is based on >>>>>>>>>> a hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from >>>>>>>> the simulation. You only showed an erroneous HHH that fails to >>>>>>>> reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by >>>>>>> HHH side by side. Both traces were of course /identical/, up to >>>>>>> the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return. >>>>>>
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
This call immediately from the directly executed DD and
cannot possibility return from DD emulated by HHH according
to the finite string transformation rules of the x86 language.
According to the finite string transformation rules of the x86 language. >>> The call from the directly executed DD to HHH(DD) immediately returns.
The call from DD emulated by HHH to HHH(DD) cannot possibility return.
According to the rules of the x86 language, your provided input is
invalid as it references code outside the input. PERIOD.
*Repetition seems to help you overcome your ADD*
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
On 4/24/2025 6:26 PM, Richard Damon wrote:
On 4/24/25 5:19 PM, olcott wrote:
On 4/24/2025 5:53 AM, Richard Damon wrote:
On 4/23/25 11:40 PM, olcott wrote:
On 4/23/2025 10:34 PM, olcott wrote:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:Worse than this, on more than one occasion I've actually posted >>>>>>>>> traces of computation DDD(DDD) executed directly and simulated >>>>>>>>> by HHH side by side. Both traces were of course /identical/, >>>>>>>>> up to the point where HHH stops simulating.
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are >>>>>>>>>> dreaming many years without any logic. You failed to show the >>>>>>>>>> first state change where the direct execution is different >>>>>>>>>> from the simulation. You only showed an erroneous HHH that >>>>>>>>>> fails to reach the end of the simulation of a halting program. >>>>>>>>>
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite >>>>>>>>>>>> string that describes a halting program. Not on the
Op 22.apr.2025 om 18:38 schreef olcott:int sum(int x, int y) { return x + y; }
And it has been proven that no finite string
a function is computable if there exists an algorithm >>>>>>>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>>>>>>> of the function domain it can return the corresponding >>>>>>>>>>>>>>> output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>>>>>>
On Turing Machines inputs <are> finite strings, and >>>>>>>>>>>>>>> finite string transformation rules <are> applied to >>>>>>>>>>>>>>> these finite strings to derive corresponding outputs. >>>>>>>>>>>>>>>
transformations are possible that report the halting >>>>>>>>>>>>>> behaviour for all inputs that specify a correct program. >>>>>>>>>>>>>
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
hypothetical input that does not halt, because it is based >>>>>>>>>>>> on a hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
*Factually incorrect* (You are usually very careful about these >>>>>>>> things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return. >>>>>>>>
...because HHH stops simulating before reaching that step in the >>>>>>> computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
This call immediately from the directly executed DD and
cannot possibility return from DD emulated by HHH according
to the finite string transformation rules of the x86 language.
According to the finite string transformation rules of the x86
language.
The call from the directly executed DD to HHH(DD) immediately returns. >>>>> The call from DD emulated by HHH to HHH(DD) cannot possibility return. >>>>
According to the rules of the x86 language, your provided input is
invalid as it references code outside the input. PERIOD.
*Repetition seems to help you overcome your ADD*
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
And thus there is only every that ONE HHH, so HHH *NEVER* correctly
emulates it input,
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
On 4/24/2025 6:56 PM, Richard Damon wrote:
On 4/24/25 7:52 PM, olcott wrote:
On 4/24/2025 6:26 PM, Richard Damon wrote:
On 4/24/25 5:19 PM, olcott wrote:
On 4/24/2025 5:53 AM, Richard Damon wrote:
On 4/23/25 11:40 PM, olcott wrote:
On 4/23/2025 10:34 PM, olcott wrote:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are >>>>>>>>>>>> dreaming many years without any logic. You failed to show >>>>>>>>>>>> the first state change where the direct execution is
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the >>>>>>>>>>>>>> finite string that describes a halting program. Not on the >>>>>>>>>>>>>> hypothetical input that does not halt, because it is based >>>>>>>>>>>>>> on a hypothetical HHH that does not abort.
Op 22.apr.2025 om 18:38 schreef olcott:int sum(int x, int y) { return x + y; }
And it has been proven that no finite string
a function is computable if there exists an algorithm >>>>>>>>>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>>>>>>>>> of the function domain it can return the corresponding >>>>>>>>>>>>>>>>> output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>>>>>>>>
On Turing Machines inputs <are> finite strings, and >>>>>>>>>>>>>>>>> finite string transformation rules <are> applied to >>>>>>>>>>>>>>>>> these finite strings to derive corresponding outputs. >>>>>>>>>>>>>>>>>
transformations are possible that report the halting >>>>>>>>>>>>>>>> behaviour for all inputs that specify a correct program. >>>>>>>>>>>>>>>
Only when people stupid assume the same thing as >>>>>>>>>>>>>>> sum(3,2) should return the sum of 5 + 3.
Why do you maintain that HHH should process the
hypothetical input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
different from the simulation. You only showed an erroneous >>>>>>>>>>>> HHH that fails to reach the end of the simulation of a >>>>>>>>>>>> halting program.
Worse than this, on more than one occasion I've actually >>>>>>>>>>> posted traces of computation DDD(DDD) executed directly and >>>>>>>>>>> simulated by HHH side by side. Both traces were of course / >>>>>>>>>>> identical/, up to the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about
these things)
The call to HHH(DD) from the directly executed DD returns. >>>>>>>>>> The call to HHH(DD) from DD emulated by HHH cannot possibly >>>>>>>>>> return.
...because HHH stops simulating before reaching that step in >>>>>>>>> the computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
This call immediately from the directly executed DD and
cannot possibility return from DD emulated by HHH according
to the finite string transformation rules of the x86 language. >>>>>>>>
According to the finite string transformation rules of the x86
language.
The call from the directly executed DD to HHH(DD) immediately
returns.
The call from DD emulated by HHH to HHH(DD) cannot possibility
return.
According to the rules of the x86 language, your provided input is >>>>>> invalid as it references code outside the input. PERIOD.
*Repetition seems to help you overcome your ADD*
I have told you that the whole Halt.obj is in scope
for every function in Halt.c several times now.
And thus there is only every that ONE HHH, so HHH *NEVER* correctly
emulates it input,
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
*At least you will quit STUPIDLY saying that HHH is undefined*
And you are stuck having to lie about what HHH does,
I am not the one that stupid repeats that HHH is undefined.
On 4/24/2025 3:09 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 21:49 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the
hypothetical input that does not halt, because it is based on a >>>>>>>>> hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
...because HHH stops simulating before reaching that step in the
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
It is only a finite recursion.
TOTALLY INCORRECT --- Please pay better attention.
On 4/24/2025 3:11 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 21:53 schreef olcott:
On 4/24/2025 6:22 AM, Richard Damon wrote:Factually incorrect, both the direct execution and the simulation have
On 4/23/25 11:38 AM, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input >>>>>>>>>>>> of the function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
string that describes a halting program. Not on the
hypothetical input that does not halt, because it is based on a >>>>>>>>> hypothetical HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
The call to HHH(DD) from the DD emulated by HHH, when correctly
emulated returns, just after the point that HHH gives up.
Factually Incorrect.
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
a finite recursion.
You are stupidly wrong about this.
On 4/24/2025 3:03 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 21:45 schreef olcott:
On 4/24/2025 2:15 PM, Fred. Zwarts wrote:
Op 24.apr.2025 om 19:46 schreef olcott:
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:Again a lot of words, which hide that you cannot show where the
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:That is exactly the same point. If not, show the difference in the >>>>>> traces before that point.
On 23/04/2025 16:38, olcott wrote:
On 4/23/2025 10:28 AM, Mike Terry wrote:
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:Worse than this, on more than one occasion I've actually
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are >>>>>>>>>>> dreaming many years without any logic. You failed to show the >>>>>>>>>>> first state change where the direct execution is different >>>>>>>>>>> from the simulation. You only showed an erroneous HHH that >>>>>>>>>>> fails to reach the end of the simulation of a halting program. >>>>>>>>>>
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite >>>>>>>>>>>>> string that describes a halting program. Not on the
Op 22.apr.2025 om 18:38 schreef olcott:int sum(int x, int y) { return x + y; }
And it has been proven that no finite string
a function is computable if there exists an algorithm >>>>>>>>>>>>>>>> that can do the job of the function, i.e. given an input >>>>>>>>>>>>>>>> of the function domain it can return the corresponding >>>>>>>>>>>>>>>> output.
https://en.wikipedia.org/wiki/Computable_function >>>>>>>>>>>>>>>>
On Turing Machines inputs <are> finite strings, and >>>>>>>>>>>>>>>> finite string transformation rules <are> applied to >>>>>>>>>>>>>>>> these finite strings to derive corresponding outputs. >>>>>>>>>>>>>>>>
transformations are possible that report the halting >>>>>>>>>>>>>>> behaviour for all inputs that specify a correct program. >>>>>>>>>>>>>>
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
hypothetical input that does not halt, because it is based >>>>>>>>>>>>> on a hypothetical HHH that does not abort.
Why do you maintain that HHH should process the
hypothetical input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.
posted traces of computation DDD(DDD) executed directly and >>>>>>>>>> simulated by HHH side by side. Both traces were of course / >>>>>>>>>> identical/, up to the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these >>>>>>>>> things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly
return.
...because HHH stops simulating before reaching that step in the >>>>>>>> computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
Mike.
It *is not* up to the point where HHH stops simulating.
It is up to the point where the simulated versus directly
executed calls HHH(DD).
As soon as the directly executed DD calls HHH(DD) this
call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates
DD and also emulates itself emulating DD. This is one
whole recursive emulation than the directly executed
DD can possibly get to.
traces differ up to that point.
THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.
That is not visible in the trace up to that point.
Not at all you are totally clueless about this.
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:Does HHH abort after or before the call to itself?
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:It *is not* up to the point where HHH stops simulating.
On 4/23/2025 10:28 AM, Mike Terry wrote:...because HHH stops simulating before reaching that step in the
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm that >>>>>>>>>>>> can do the job of the function, i.e. given an input of the >>>>>>>>>>>> function domain it can return the corresponding output. >>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and finite >>>>>>>>>>>> string transformation rules <are> applied to these finite >>>>>>>>>>>> strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as sum(3,2)
should return the sum of 5 + 3.
string that describes a halting program. Not on the hypothetical >>>>>>>>> input that does not halt, because it is based on a hypothetical >>>>>>>>> HHH that does not abort.
Why do you maintain that HHH should process the hypothetical >>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD emulated by >>>>>>>> HHH according to the semantics of the x86 language have a
different set of state changes many hundreds of times for several >>>>>>>> years.
dreaming many years without any logic. You failed to show the
first state change where the direct execution is different from
the simulation. You only showed an erroneous HHH that fails to
reach the end of the simulation of a halting program.
Worse than this, on more than one occasion I've actually posted
traces of computation DDD(DDD) executed directly and simulated by
HHH side by side. Both traces were of course /identical/, up to
the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
It is up to the point where the simulated versus directly executed
calls HHH(DD).
Why doesn't it return when simulated? Why doesn't the direct callThat is exactly the same point. If not, show the difference in the
traces before that point.
As soon as the directly executed DD calls HHH(DD) this call immediately returns.
When DD emulated by HHH calls HHH(DD) then HHH emulates DD and also--
emulates itself emulating DD. This is one whole recursive emulation than
the directly executed DD can possibly get to.
On 4/25/2025 9:06 AM, joes wrote:
Am Thu, 24 Apr 2025 12:46:14 -0500 schrieb olcott:
On 4/24/2025 3:11 AM, Fred. Zwarts wrote:Does HHH abort after or before the call to itself?
Op 24.apr.2025 om 05:34 schreef olcott:
On 4/23/2025 7:31 PM, Mike Terry wrote:
On 23/04/2025 16:38, olcott wrote:It *is not* up to the point where HHH stops simulating.
On 4/23/2025 10:28 AM, Mike Terry wrote:...because HHH stops simulating before reaching that step in the
On 23/04/2025 10:02, Fred. Zwarts wrote:
Op 22.apr.2025 om 21:50 schreef olcott:
On 4/22/2025 2:30 PM, Fred. Zwarts wrote:You never showed a proof. You only repeated a dream. You are >>>>>>>>> dreaming many years without any logic. You failed to show the >>>>>>>>> first state change where the direct execution is different from >>>>>>>>> the simulation. You only showed an erroneous HHH that fails to >>>>>>>>> reach the end of the simulation of a halting program.
Op 22.apr.2025 om 21:14 schreef olcott:
On 4/22/2025 1:10 PM, Fred. Zwarts wrote:Therefore HHH should report on the actual input, the finite >>>>>>>>>>> string that describes a halting program. Not on the hypothetical >>>>>>>>>>> input that does not halt, because it is based on a hypothetical >>>>>>>>>>> HHH that does not abort.
Op 22.apr.2025 om 18:38 schreef olcott:
And it has been proven that no finite string transformations >>>>>>>>>>>>> are possible that report the halting behaviour for all inputs >>>>>>>>>>>>> that specify a correct program.
a function is computable if there exists an algorithm that >>>>>>>>>>>>>> can do the job of the function, i.e. given an input of the >>>>>>>>>>>>>> function domain it can return the corresponding output. >>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
On Turing Machines inputs <are> finite strings, and finite >>>>>>>>>>>>>> string transformation rules <are> applied to these finite >>>>>>>>>>>>>> strings to derive corresponding outputs.
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as sum(3,2) >>>>>>>>>>>> should return the sum of 5 + 3.
Why do you maintain that HHH should process the hypothetical >>>>>>>>>>> input instead of the actual input.
Do you really believe that 3+2 equals 5+3?
I have proven that the directly executed DD and DD emulated by >>>>>>>>>> HHH according to the semantics of the x86 language have a
different set of state changes many hundreds of times for several >>>>>>>>>> years.
Worse than this, on more than one occasion I've actually posted >>>>>>>> traces of computation DDD(DDD) executed directly and simulated by >>>>>>>> HHH side by side. Both traces were of course /identical/, up to >>>>>>>> the point where HHH stops simulating.
*Factually incorrect* (You are usually very careful about these
things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return. >>>>>>>
computation. Note that I said
MT: Both traces were of course /identical/,
*up to the point where HHH stops simulating*
So I was factually correct.
It is up to the point where the simulated versus directly executed
calls HHH(DD).
Why doesn't it return when simulated?That is exactly the same point. If not, show the difference in the
traces before that point.
As soon as the directly executed DD calls HHH(DD) this call immediately
returns.
Because this is logically impossible.
Why are squares not round?
Because this is logically impossible.
Why doesn't the direct call
simulate DD calling HHH(DD)?
When DD emulated by HHH calls HHH(DD) then HHH emulates DD and also
emulates itself emulating DD. This is one whole recursive emulation than >>> the directly executed DD can possibly get to.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 168:39:58 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,823 |