typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
*This algorithm is used by the simulating termination analyzers*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Simulating termination analyzer HHH aborts its emulation of DDD
as soon as it correctly detects any non-halting behavior pattern.
At this point it aborts its emulation and returns 0 indicating
that it rejected this input as non-halting.
Proving that the simulation is incorrect. Because a correct simulation
would not abort a halting program halfway its simulation.
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
The instance of main() can't possibly halt HHH correctly
aborts and rejects as non-halting. The entirely different
instance of main() that calls HHH only halts because HHH
was correct to abort its simulated instance.
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a finite time.
So, it depends whether we can call it a correct simulation, when it does
not abort. But, for some meaning of 'correct', indeed, a simulator
should not abort a non-halting program either.
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
The instance of main() can't possibly halt HHH correctly
aborts and rejects as non-halting. The entirely different
instance of main() that calls HHH only halts because HHH
was correct to abort its simulated instance.
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation >>>>> would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a finite time.
So, it depends whether we can call it a correct simulation, when it does >>> not abort. But, for some meaning of 'correct', indeed, a simulator
should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation >>>>> would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a finite time.
So, it depends whether we can call it a correct simulation, when it does >>> not abort. But, for some meaning of 'correct', indeed, a simulator
should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
On 7/10/2024 3:49 PM, olcott wrote:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct
simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a finite time.
So, it depends whether we can call it a correct simulation, when it
does
not abort. But, for some meaning of 'correct', indeed, a simulator
should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
In other words he is using deceitful weasel wording to
try to escape a truism.
We stipulate that the only measure of a correct emulation is the
semantics of the x86 programming language. By this measure when 1 to ∞ steps of DDD are correctly emulated by each pure function x86 emulator
HHH (of the infinite set of every HHH that can possibly exist) then DDD cannot possibly reach past its own machine address of 0000216b and halt.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
But H determines (correctly) that D would not halt
if it were not halted. That much is a truism.
On 7/10/2024 1:12 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
Welcome back.
I stipulate that I am referring to 1 to ∞ steps of correct
emulation according to the semantics of the x86 language.
This means that when HHH does correctly emulate 1 step
that *it is a correct emulation* of this 1 step, thus
making everyone that disagrees disagree with a tautology
making them look foolish.
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language.
By this
measure when 1 to ∞ steps of DDD are correctly emulated
by each pure function x86 emulator HHH (of the infinite
set of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
On 7/10/2024 1:12 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting
program either, would it? Or have I misunderstood this correctness?
[ .... ]
Welcome back.
I stipulate that I am referring to 1 to ∞ steps of correct
emulation according to the semantics of the x86 language.
This means that when HHH does correctly emulate 1 step
that *it is a correct emulation* of this 1 step,
thus
making everyone that disagrees disagree with a tautology
making them look foolish.
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated
by each pure function x86 emulator HHH (of the infinite
set of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
On 7/11/2024 1:25 AM, Mikko wrote:Contradicting yourself? "Counterfactual" usually means "if it were
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
*That is counter-factual*Every time any HHH correctly emulates DDD it calls the x86utmvoid DDD()Unneeded complexity. It is equivalent to:
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
int main()
{
return HHH(main);
}
operating system to create a separate process context with its own
memory virtual registers and stack, thus each recursively emulated DDD
is a different instance.
However, each of those instances has the same sequence of instructions
that the x86 language specifies the same operational meaning.
When DDD is correctly emulated by HHH according to the semantics of theIf the recursive call to HHH from DDD halts, the outer HHH doesn't need
x86 programming language HHH must abort its emulation of DDD or both HHH
and DDD never halt.
When DDD is correctly emulated by HHH1 according to the semantics of theWhere does HHH figure into this? It is not the simulator here.
x86 programming language HHH1 need not abort its emulation of DDD
because HHH has already done this.
The behavior of DDD emulated by HHH1 is identical to the behavior of the directly executed DDD().At last!
On 7/11/2024 9:25 AM, joes wrote:Do you mean that HHH doesn't halt?
Am Thu, 11 Jul 2024 09:10:24 -0500 schrieb olcott:Sure and when squares are round you can measure the radius of a square.
On 7/11/2024 1:25 AM, Mikko wrote:Contradicting yourself? "Counterfactual" usually means "if it were
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
*That is counter-factual*However, each of those instances has the same sequence ofUnneeded complexity. It is equivalent to:Every time any HHH correctly emulates DDD it calls the x86utm
int main()
{
return HHH(main);
}
operating system to create a separate process context with its own
memory virtual registers and stack, thus each recursively emulated
DDD is a different instance.
instructions that the x86 language specifies the same operational
meaning.
different".
When DDD is correctly emulated by HHH according to the semantics ofIf the recursive call to HHH from DDD halts, the outer HHH doesn't need
the x86 programming language HHH must abort its emulation of DDD or
both HHH and DDD never halt.
to abort.
What does HHH do after it aborts?DDD depends totally on HHH; it halts exactly when HHH does.Halting means reaching its own last instruction and terminating
Which it does, because it aborts.
normally.
No, HHH1 doesn't need to because DDD is just a regular program to it,HHH must abort its simulation. HHH1 does not need to do that because HHHWhen DDD is correctly emulated by HHH1 according to the semantics ofWhere does HHH figure into this? It is not the simulator here.
the x86 programming language HHH1 need not abort its emulation of DDD
because HHH has already done this.
The behavior of DDD emulated by HHH1 is identical to the behavior ofAt last!
the directly executed DDD().
has already done this.
DDD correctly simulated by HHH has provably different behavior than DDD correctly simulated by HHH1.Which means that HHH is not doing the simulation correctly.
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language
specifies an unambiguous meaning, leaving no room for "can".
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
then no DDD instance of each HHH/DDD pair reaches
past its own machine address of 0000216b and halts.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
(1) I am referring to an infinite set of HHH/DDD pairs each
HHH having different behavior.
(2) No DDD of this infinite set reaches past its
own machine address of 0000216b.
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of instructions
that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
When DDD is correctly emulated by HHH1 according to the
semantics of the x86 programming language HHH1 need not
abort its emulation of DDD because HHH has already done this.
The behavior of DDD emulated by HHH1 is identical to the
behavior of the directly executed DDD().
On 7/11/2024 3:19 PM, joes wrote:This.
Am Thu, 11 Jul 2024 10:05:58 -0500 schrieb olcott:
On 7/11/2024 9:25 AM, joes wrote:
Am Thu, 11 Jul 2024 09:10:24 -0500 schrieb olcott:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
Do you mean that HHH doesn't halt?When DDD is correctly emulated by HHH according to the semantics ofIf the recursive call to HHH from DDD halts, the outer HHH doesn't
the x86 programming language HHH must abort its emulation of DDD or
both HHH and DDD never halt.
need to abort.
And this one.What does HHH do after it aborts?DDD depends totally on HHH; it halts exactly when HHH does.
Which it does, because it aborts.
Aborting is not a correct simulation.When HHH simulates DDD according to the semantics of the x86 languageDDD correctly simulated by HHH has provably different behavior thanWhich means that HHH is not doing the simulation correctly.
DDD correctly simulated by HHH1.
then HHH is simulating correctly. When people disagree with the
semantics of the x86 language THEY ARE WRONG !!!
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of instructions
that the x86 language specifies the same operational meaning.
*That is counter-factual*
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language
specifies an unambiguous meaning, leaving no room for "can".
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
On 7/11/2024 1:28 AM, Mikko wrote:
On 2024-07-10 18:58:14 +0000, olcott said:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation >>>>>>> would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting >>>>>> program either, would it? Or have I misunderstood this correctness? >>>>
[ .... ]
A non-halting program cannot be simulated correctly in a finite time. >>>>> So, it depends whether we can call it a correct simulation, when it does >>>>> not abort. But, for some meaning of 'correct', indeed, a simulator
should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
That is possible as "correctly" has different meaning when talking
about steps from when talking about simulations.
*No that is always false*
When you did one anythings correctly then you did
more than zero anythings correctly.
On 7/12/2024 3:08 AM, joes wrote:Yes, which makes it not a simulator.
Am Thu, 11 Jul 2024 15:56:09 -0500 schrieb olcott:
On 7/11/2024 3:19 PM, joes wrote:
Am Thu, 11 Jul 2024 10:05:58 -0500 schrieb olcott:
On 7/11/2024 9:25 AM, joes wrote:
Am Thu, 11 Jul 2024 09:10:24 -0500 schrieb olcott:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
Do you mean that HHH doesn't halt?When DDD is correctly emulated by HHH according to the semantics >>>>>>> of the x86 programming language HHH must abort its emulation ofIf the recursive call to HHH from DDD halts, the outer HHH doesn't >>>>>> need to abort.
DDD or both HHH and DDD never halt.
What does HHH do after it aborts?DDD depends totally on HHH; it halts exactly when HHH does.
Which it does, because it aborts.
Aborting is what a simulating termination analyzer must do for any inputAborting is not a correct simulation.When HHH simulates DDD according to the semantics of the x86 languageDDD correctly simulated by HHH has provably different behavior thanWhich means that HHH is not doing the simulation correctly.
DDD correctly simulated by HHH1.
then HHH is simulating correctly. When people disagree with the
semantics of the x86 language THEY ARE WRONG !!!
Please answer the other questions above.
that cannot possibly otherwise stop running.
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of instructions >>>> that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
There is not "must" anywhere in the semantics of the programming
language.
The semantics of the language specifies the behavior of
the machine code thus deriving the must.
When DDD is correctly emulated by HHH1 according to the
semantics of the x86 programming language HHH1 need not
abort its emulation of DDD because HHH has already done this.
However, the program DDD is the same in both cases and therefore the
its behavioral meaning per x86 semantics is also the same.
HHH1(DDD) only halts because HHH(DDD) aborts its emulation
thus proving the the behaviors are different.
The behavior of DDD emulated by HHH1 is identical to the
behavior of the directly executed DDD().
Which is the behaviour of DDD accordint to the semantics of x86 language.
If you stupidly ignore that DDD does call HHH in recursive
emulation it might superfically seem that way.
On 7/12/2024 3:15 AM, Mikko wrote:
On 2024-07-11 14:12:15 +0000, olcott said:
On 7/11/2024 1:28 AM, Mikko wrote:
On 2024-07-10 18:58:14 +0000, olcott said:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct
simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting >>>>>>>> program either, would it? Or have I misunderstood this
correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a finite
time.
So, it depends whether we can call it a correct simulation, when >>>>>>> it does
not abort. But, for some meaning of 'correct', indeed, a simulator >>>>>>> should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
That is possible as "correctly" has different meaning when talking
about steps from when talking about simulations.
*No that is always false*
When you did one anythings correctly then you did
more than zero anythings correctly.
If I only correcly do one thing that is not a part of my routine then
I don't do my routine correctly. If I do correctly every part of my
routine
but do them in a wrong order I don't do my routine correctly.
Fred was trying to get away with saying that when 1
step of DDD is correctly emulated by HHH that 0 steps
were emulated correctly.
Op 12.jul.2024 om 15:25 schreef olcott:
On 7/12/2024 3:15 AM, Mikko wrote:
On 2024-07-11 14:12:15 +0000, olcott said:
On 7/11/2024 1:28 AM, Mikko wrote:
On 2024-07-10 18:58:14 +0000, olcott said:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulation
would not abort a halting program halfway its simulation.
Just for clarity, a correct simulation wouldn't abort a non-halting >>>>>>>>> program either, would it? Or have I misunderstood this correctness? >>>>>>>
[ .... ]
A non-halting program cannot be simulated correctly in a finite time. >>>>>>>> So, it depends whether we can call it a correct simulation, when it does
not abort. But, for some meaning of 'correct', indeed, a simulator >>>>>>>> should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
That is possible as "correctly" has different meaning when talking
about steps from when talking about simulations.
*No that is always false*
When you did one anythings correctly then you did
more than zero anythings correctly.
If I only correcly do one thing that is not a part of my routine then
I don't do my routine correctly. If I do correctly every part of my routine >>> but do them in a wrong order I don't do my routine correctly.
Fred was trying to get away with saying that when 1
step of DDD is correctly emulated by HHH that 0 steps
were emulated correctly.
Olcott has a problem with the English language.
I said that when a program needs 2 cycles of simulation, it is
incorrect to abort after 1 cycle and decide it is non-halting.
His problem seems to be that he thinks that skipping x86 instructions
in the simulation does not change the behaviour of a program.
There are more situations where he seems to have a problem with the
English language. He thinks that everything greater than 2 equals
infinity. When a program has more than two recursions, he thinks it is non-halting.
It is very difficult to discuss with someone with such a poor
understanding of the English language, because he continuously twists
the meaning of words, both his own words as well as the words of his opponents.
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language
specifies an unambiguous meaning, leaving no room for "can".
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is
no room for "cannot", either. The x86 semantics of the unshown code
determines unambigously what happens.
Of an infinite set behavior X exists for at least one element
or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of instructions >>>> that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
There is not "must" anywhere in the semantics of the programming language. >>
The semantics of the language specifies the behavior of
the machine code thus deriving the must.
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language >>>>>> specifies an unambiguous meaning, leaving no room for "can".
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is
no room for "cannot", either. The x86 semantics of the unshown code
determines unambigously what happens.
Of an infinite set behavior X exists for at least one element
or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
That is so far from the Common Language that I can't parse.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b
On 7/13/2024 3:00 AM, Mikko wrote:
On 2024-07-12 13:20:53 +0000, olcott said:
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of
instructions
that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
There is not "must" anywhere in the semantics of the programming
language.
The semantics of the language specifies the behavior of
the machine code thus deriving the must.
How can one derive "must" from the semantics of the machine code?
Deciders are required to (thus must) halt.
On 7/13/2024 2:53 AM, Mikko wrote:
On 2024-07-12 14:32:28 +0000, Fred. Zwarts said:
Op 12.jul.2024 om 15:25 schreef olcott:
On 7/12/2024 3:15 AM, Mikko wrote:
On 2024-07-11 14:12:15 +0000, olcott said:
On 7/11/2024 1:28 AM, Mikko wrote:
On 2024-07-10 18:58:14 +0000, olcott said:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct >>>>>>>>>>>> simulationJust for clarity, a correct simulation wouldn't abort a
would not abort a halting program halfway its simulation. >>>>>>>>>
non-halting
program either, would it? Or have I misunderstood this >>>>>>>>>>> correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a
finite time.
So, it depends whether we can call it a correct simulation, >>>>>>>>>> when it does
not abort. But, for some meaning of 'correct', indeed, a
simulator
should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
That is possible as "correctly" has different meaning when talking >>>>>>> about steps from when talking about simulations.
*No that is always false*
When you did one anythings correctly then you did
more than zero anythings correctly.
If I only correcly do one thing that is not a part of my routine then >>>>> I don't do my routine correctly. If I do correctly every part of my
routine
but do them in a wrong order I don't do my routine correctly.
Fred was trying to get away with saying that when 1
step of DDD is correctly emulated by HHH that 0 steps
were emulated correctly.
Olcott has a problem with the English language.
I said that when a program needs 2 cycles of simulation, it is
incorrect to abort after 1 cycle and decide it is non-halting.
His problem seems to be that he thinks that skipping x86 instructions
in the simulation does not change the behaviour of a program.
There are more situations where he seems to have a problem with the
English language. He thinks that everything greater than 2 equals
infinity. When a program has more than two recursions, he thinks it
is non-halting.
It is very difficult to discuss with someone with such a poor
understanding of the English language, because he continuously twists
the meaning of words, both his own words as well as the words of his
opponents.
I think he is less harmful that way. His lack of clarity and obvious
twisting
of the meaning of words reduce the risk that anyone would believe what he
tries to say.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
People disagree with this on the basis they they believe
that they can disagree with the x86 language. That is the
same as disagreeing with arithmetic, not allowed.
On 7/12/2024 3:03 AM, Mikko wrote:The assembly is not concerned with aborting or halting.
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
However, each of those instances has the same sequence of*That is counter-factual*
instructions that the x86 language specifies the same operational
meaning.
When DDD is correctly emulated by HHH according to the semantics of
the x86 programming language HHH must abort its emulation of DDD or
both HHH and DDD never halt.
The simple fact remains that if the behaviour of a program dependsHHH1(DDD) only halts because HHH(DDD) aborts its emulation thus provingWhen DDD is correctly emulated by HHH1 according to the semantics ofHowever, the program DDD is the same in both cases and therefore the
the x86 programming language HHH1 need not abort its emulation of DDD
because HHH has already done this.
its behavioral meaning per x86 semantics is also the same.
the the behaviors are different.
It does that in every (non-)simulation, no change there.If you stupidly ignore that DDD does call HHH in recursive emulation itThe behavior of DDD emulated by HHH1 is identical to the behavior ofWhich is the behaviour of DDD accordint to the semantics of x86
the directly executed DDD().
language.
might superfically seem that way.
On 7/13/2024 5:57 PM, joes wrote:
Am Fri, 12 Jul 2024 08:20:53 -0500 schrieb olcott:
On 7/12/2024 3:03 AM, Mikko wrote:The assembly is not concerned with aborting or halting.
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
However, each of those instances has the same sequence of*That is counter-factual*
instructions that the x86 language specifies the same operational
meaning.
When DDD is correctly emulated by HHH according to the semantics of
the x86 programming language HHH must abort its emulation of DDD or
both HHH and DDD never halt.
The simple fact remains that if the behaviour of a program dependsHHH1(DDD) only halts because HHH(DDD) aborts its emulation thus provingWhen DDD is correctly emulated by HHH1 according to the semantics of >>>>> the x86 programming language HHH1 need not abort its emulation of DDD >>>>> because HHH has already done this.However, the program DDD is the same in both cases and therefore the
its behavioral meaning per x86 semantics is also the same.
the the behaviors are different.
on what is simulating it, that simulator is faulty.
If you stupidly ignore that DDD does call HHH in recursive emulation itThe behavior of DDD emulated by HHH1 is identical to the behavior of >>>>> the directly executed DDD().Which is the behaviour of DDD accordint to the semantics of x86
language.
might superfically seem that way.
It does that in every (non-)simulation, no change there.
DDD cannot call HHH in recursive emulation WITHOUT EMULATION.
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by
each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language >>>>>> specifies an unambiguous meaning, leaving no room for "can".
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is
no room for "cannot", either. The x86 semantics of the unshown code
determines unambigously what happens.
Of an infinite set behavior X exists for at least one element
or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
That is so far from the Common Language that I can't parse.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
On 7/13/2024 3:00 AM, Mikko wrote:
On 2024-07-12 13:20:53 +0000, olcott said:
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of instructions >>>>>> that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
There is not "must" anywhere in the semantics of the programming language. >>>>
The semantics of the language specifies the behavior of
the machine code thus deriving the must.
How can one derive "must" from the semantics of the machine code?
Deciders are required to (thus must) halt.
On 7/13/2024 2:53 AM, Mikko wrote:
On 2024-07-12 14:32:28 +0000, Fred. Zwarts said:
Op 12.jul.2024 om 15:25 schreef olcott:
On 7/12/2024 3:15 AM, Mikko wrote:
On 2024-07-11 14:12:15 +0000, olcott said:
On 7/11/2024 1:28 AM, Mikko wrote:
On 2024-07-10 18:58:14 +0000, olcott said:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
[ .... ]
Proving that the simulation is incorrect. Because a correct simulationJust for clarity, a correct simulation wouldn't abort a non-halting >>>>>>>>>>> program either, would it? Or have I misunderstood this correctness?
would not abort a halting program halfway its simulation. >>>>>>>>>
[ .... ]
A non-halting program cannot be simulated correctly in a finite time.
So, it depends whether we can call it a correct simulation, when it does
not abort. But, for some meaning of 'correct', indeed, a simulator >>>>>>>>>> should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
That is possible as "correctly" has different meaning when talking >>>>>>> about steps from when talking about simulations.
*No that is always false*
When you did one anythings correctly then you did
more than zero anythings correctly.
If I only correcly do one thing that is not a part of my routine then >>>>> I don't do my routine correctly. If I do correctly every part of my routine
but do them in a wrong order I don't do my routine correctly.
Fred was trying to get away with saying that when 1
step of DDD is correctly emulated by HHH that 0 steps
were emulated correctly.
Olcott has a problem with the English language.
I said that when a program needs 2 cycles of simulation, it is
incorrect to abort after 1 cycle and decide it is non-halting.
His problem seems to be that he thinks that skipping x86 instructions
in the simulation does not change the behaviour of a program.
There are more situations where he seems to have a problem with the
English language. He thinks that everything greater than 2 equals
infinity. When a program has more than two recursions, he thinks it is
non-halting.
It is very difficult to discuss with someone with such a poor
understanding of the English language, because he continuously twists
the meaning of words, both his own words as well as the words of his
opponents.
I think he is less harmful that way. His lack of clarity and obvious twisting
of the meaning of words reduce the risk that anyone would believe what he
tries to say.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
People disagree with this on the basis they they believe
that they can disagree with the x86 language. That is the
same as disagreeing with arithmetic, not allowed.
On 7/14/2024 3:40 AM, Mikko wrote:DDD nor HHH however are non-halting inputs and do not need to be aborted.
On 2024-07-13 12:22:24 +0000, olcott said:
On 7/13/2024 3:00 AM, Mikko wrote:
On 2024-07-12 13:20:53 +0000, olcott said:
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
The subject our our conversion is a simulating termination analyzer AKA partial halt decider that accepts a finite string of x86 code asThe semantics of the x86 language does not require that, nor that anyDeciders are required to (thus must) halt.How can one derive "must" from the semantics of the machine code?The semantics of the language specifies the behavior of the machineThere is not "must" anywhere in the semantics of the programmingHowever, each of those instances has the same sequence of*That is counter-factual*
instructions that the x86 language specifies the same operational >>>>>>>> meaning.
When DDD is correctly emulated by HHH according to the semantics >>>>>>> of the x86 programming language HHH must abort its emulation of
DDD or both HHH and DDD never halt.
language.
code thus deriving the must.
of the programs is a decider.
specifying halting behavior or rejects this finite string. Deciders are required to halt thus must abort the emulation of any input that would prevent this.
Any input that must be aborted to prevent the non termination of HHH necessarily specifies non-halting behavior or it would never need to be aborted.
On 7/14/2024 3:40 AM, Mikko wrote:
On 2024-07-13 12:22:24 +0000, olcott said:
On 7/13/2024 3:00 AM, Mikko wrote:
On 2024-07-12 13:20:53 +0000, olcott said:
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of instructions >>>>>>>> that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
There is not "must" anywhere in the semantics of the programming language.
The semantics of the language specifies the behavior of
the machine code thus deriving the must.
How can one derive "must" from the semantics of the machine code?
Deciders are required to (thus must) halt.
The semantics of the x86 language does not require that, nor that any of
the programs is a decider.
The subject our our conversion is a simulating termination
analyzer
AKA partial halt decider
that accepts a finite string of x86 code as specifying halting behavior
or rejects this finite string. Deciders are required to halt thus must
abort the emulation of any input that would prevent this.
On 7/14/2024 3:48 AM, Mikko wrote:
On 2024-07-13 12:19:36 +0000, olcott said:
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language. By this
measure when 1 to ∞ steps of DDD are correctly emulated by >>>>>>>>> each pure function x86 emulator HHH (of the infinite set
of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language >>>>>>>> specifies an unambiguous meaning, leaving no room for "can".
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is >>>>>> no room for "cannot", either. The x86 semantics of the unshown code >>>>>> determines unambigously what happens.
Of an infinite set behavior X exists for at least one element
or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
That is so far from the Common Language that I can't parse.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
Here you attempt to use the same name for a constant programs and univesally >> quantifed variable with a poorly specified range. That is a form of a well >> known mistake called the "fallacy of equivocation".
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.
When we examine the infinite set of every HHH/DDD pair such that:
HHH₁ one step of DDD is correctly emulated by HHH.
HHH₂ two steps of DDD are correctly emulated by HHH.
HHH₃ three steps of DDD are correctly emulated by HHH.
...
HHH∞ The emulation of DDD by HHH never stops running.
On 7/14/2024 3:49 AM, Mikko wrote:
On 2024-07-13 12:18:27 +0000, olcott said:
On 7/13/2024 2:53 AM, Mikko wrote:
On 2024-07-12 14:32:28 +0000, Fred. Zwarts said:
Op 12.jul.2024 om 15:25 schreef olcott:
On 7/12/2024 3:15 AM, Mikko wrote:
On 2024-07-11 14:12:15 +0000, olcott said:
On 7/11/2024 1:28 AM, Mikko wrote:
On 2024-07-10 18:58:14 +0000, olcott said:
On 7/10/2024 1:55 PM, Alan Mackenzie wrote:
Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:
Op 10.jul.2024 om 20:12 schreef Alan Mackenzie:
[ Followup-To: set ]
In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote: >>>>>>>>>>>
[ .... ]
Proving that the simulation is incorrect. Because a correct simulationJust for clarity, a correct simulation wouldn't abort a non-halting
would not abort a halting program halfway its simulation. >>>>>>>>>>>
program either, would it? Or have I misunderstood this correctness?
[ .... ]
A non-halting program cannot be simulated correctly in a finite time.
So, it depends whether we can call it a correct simulation, when it does
not abort. But, for some meaning of 'correct', indeed, a simulator >>>>>>>>>>>> should not abort a non-halting program either.
OK, thanks!
In other words he is saying that when you do
1 step correctly you did 0 steps correctly.
That is possible as "correctly" has different meaning when talking >>>>>>>>> about steps from when talking about simulations.
*No that is always false*
When you did one anythings correctly then you did
more than zero anythings correctly.
If I only correcly do one thing that is not a part of my routine then >>>>>>> I don't do my routine correctly. If I do correctly every part of my routine
but do them in a wrong order I don't do my routine correctly.
Fred was trying to get away with saying that when 1
step of DDD is correctly emulated by HHH that 0 steps
were emulated correctly.
Olcott has a problem with the English language.
I said that when a program needs 2 cycles of simulation, it is
incorrect to abort after 1 cycle and decide it is non-halting.
His problem seems to be that he thinks that skipping x86 instructions >>>>> in the simulation does not change the behaviour of a program.
There are more situations where he seems to have a problem with the
English language. He thinks that everything greater than 2 equals
infinity. When a program has more than two recursions, he thinks it is >>>>> non-halting.
It is very difficult to discuss with someone with such a poor
understanding of the English language, because he continuously twists >>>>> the meaning of words, both his own words as well as the words of his >>>>> opponents.
I think he is less harmful that way. His lack of clarity and obvious twisting
of the meaning of words reduce the risk that anyone would believe what he >>>> tries to say.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
People disagree with this on the basis they they believe
that they can disagree with the x86 language. That is the
same as disagreeing with arithmetic, not allowed.
See, not very convincing, is it?
Likewise for people that do not know how to count to
five can disagree that 2 + 3 = 5.
When the source of your disagreement is your own ignorance
then your disagreement has no actual basis.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Disagreeing with the above is analogous to disagreeing
with arithmetic.
On 7/15/2024 2:41 AM, Mikko wrote:
On 2024-07-14 14:13:41 +0000, olcott said:
On 7/14/2024 3:40 AM, Mikko wrote:
On 2024-07-13 12:22:24 +0000, olcott said:
Deciders are required to (thus must) halt.
The semantics of the x86 language does not require that, nor that any of >>>> the programs is a decider.
The subject our our conversion is a simulating termination
analyzer
No, it is not. As stated on the Subject line, the subject is correctness of >> the rejection of DDD as non-halting.
AKA partial halt decider
That "AKA" is incorrect. The term "termination analyzer" means a program
of a certain kind and the term "partial halt decider" means a program of
a different kind.
Not for the subset of inputs that we are examining.
On 7/15/2024 2:52 AM, Mikko wrote:
On 2024-07-14 14:44:27 +0000, olcott said:
On 7/14/2024 3:48 AM, Mikko wrote:
On 2024-07-13 12:19:36 +0000, olcott said:
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation >>>>>>>>>>> is the semantics of the x86 programming language. By this >>>>>>>>>>> measure when 1 to ∞ steps of DDD are correctly emulated by >>>>>>>>>>> each pure function x86 emulator HHH (of the infinite set >>>>>>>>>>> of every HHH that can possibly exist) then DDD cannot
possibly reach past its own machine address of 0000216b
and halt.
For every instruction that the C compiler generates the x86 language >>>>>>>>>> specifies an unambiguous meaning, leaving no room for "can". >>>>>>>>>>
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is >>>>>>>> no room for "cannot", either. The x86 semantics of the unshown code >>>>>>>> determines unambigously what happens.
Of an infinite set behavior X exists for at least one element
or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
That is so far from the Common Language that I can't parse.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
Here you attempt to use the same name for a constant programs and univesally
quantifed variable with a poorly specified range. That is a form of a well >>>> known mistake called the "fallacy of equivocation".
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.
That does not make sense. Which HHH does that DDD call? Which HHH
is at that fixed machine address?
HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
infinite set of HHH/DDD pairs.
On 7/15/2024 2:57 AM, Mikko wrote:
On 2024-07-14 14:48:05 +0000, olcott said:
On 7/14/2024 3:49 AM, Mikko wrote:
On 2024-07-13 12:18:27 +0000, olcott said:
When the source of your disagreement is your own ignorance
then your disagreement has no actual basis.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Disagreeing with the above is analogous to disagreeing
with arithmetic.
A lame analogy. A better one is: 2 + 3 = 5 is a proven theorem just
like the uncomputability of halting is.
The uncomputability of halting is only proven when the problem
is framed this way: HHH is required to report on the behavior
of an input that was defined to do exactly the opposite of
whatever DDD reports.
When HHH is defined such that an input that was defined to
do the opposite of whatever HHH reports can never reach this
point in its execution trace then the prior halting problem
proof has been defeated.
On 7/16/2024 2:10 AM, Mikko wrote:
On 2024-07-15 13:21:35 +0000, olcott said:
On 7/15/2024 2:52 AM, Mikko wrote:
On 2024-07-14 14:44:27 +0000, olcott said:
On 7/14/2024 3:48 AM, Mikko wrote:
On 2024-07-13 12:19:36 +0000, olcott said:
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation >>>>>>>>>>>>> is the semantics of the x86 programming language. By this >>>>>>>>>>>>> measure when 1 to ∞ steps of DDD are correctly emulated by >>>>>>>>>>>>> each pure function x86 emulator HHH (of the infinite set >>>>>>>>>>>>> of every HHH that can possibly exist) then DDD cannot >>>>>>>>>>>>> possibly reach past its own machine address of 0000216b >>>>>>>>>>>>> and halt.
For every instruction that the C compiler generates the x86 >>>>>>>>>>>> language
specifies an unambiguous meaning, leaving no room for "can". >>>>>>>>>>>>
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means >>>>>>>>>> there is
no room for "cannot", either. The x86 semantics of the unshown >>>>>>>>>> code
determines unambigously what happens.
Of an infinite set behavior X exists for at least one element >>>>>>>>> or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
That is so far from the Common Language that I can't parse.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
Here you attempt to use the same name for a constant programs and
univesally
quantifed variable with a poorly specified range. That is a form
of a well
known mistake called the "fallacy of equivocation".
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.
That does not make sense. Which HHH does that DDD call? Which HHH
is at that fixed machine address?
HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
infinite set of HHH/DDD pairs.
You should not say "another way" before you have one way. What you
presented earlier is not a way as it did not make sense.
DDD itself is a single immutable finite string have the exactly
same instructions at the exact same machine addresses.
If you want at look at DDD less literally and more figuratively
then we can classify DDD as one member of a set of HHH/DDD pairs.
There is no reason to do this because each DDD has the same behavior
and each HHH is called at the same fixed constant machine address.
The only reason that I have DDD/HHH pairs is because deceitful
reviewers were trying to get away with saying tha some DDD have
different behavior.
It you
mean what you say now that is the way to say it. But you still must
specify avout each DDD which HHH it calls.
*I have done that at least 1000 time in the last two years*
No DDD of the infinite set of HHH/DDD pairs where DDD
is emulated by HHH according to the semantics of the
x86 language ever reaches past its own machine address
0000216b.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
On 7/16/2024 2:06 AM, Mikko wrote:
On 2024-07-15 13:15:29 +0000, olcott said:
On 7/15/2024 2:41 AM, Mikko wrote:
On 2024-07-14 14:13:41 +0000, olcott said:
On 7/14/2024 3:40 AM, Mikko wrote:
On 2024-07-13 12:22:24 +0000, olcott said:
Deciders are required to (thus must) halt.
The semantics of the x86 language does not require that, nor that any of >>>>>> the programs is a decider.
The subject our our conversion is a simulating termination
analyzer
No, it is not. As stated on the Subject line, the subject is correctness of
the rejection of DDD as non-halting.
AKA partial halt decider
That "AKA" is incorrect. The term "termination analyzer" means a program >>>> of a certain kind and the term "partial halt decider" means a program of >>>> a different kind.
Not for the subset of inputs that we are examining.
Yes with all inputs. Their input spaces are distinct and they are required >> to answer a different question.
A partial halt decider is a termination analyzer for
any input that has no inputs.
On 7/16/2024 2:18 AM, Mikko wrote:
On 2024-07-15 13:32:27 +0000, olcott said:
On 7/15/2024 2:57 AM, Mikko wrote:
On 2024-07-14 14:48:05 +0000, olcott said:
On 7/14/2024 3:49 AM, Mikko wrote:
On 2024-07-13 12:18:27 +0000, olcott said:
When the source of your disagreement is your own ignorance
then your disagreement has no actual basis.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Disagreeing with the above is analogous to disagreeing
with arithmetic.
A lame analogy. A better one is: 2 + 3 = 5 is a proven theorem just
like the uncomputability of halting is.
The uncomputability of halting is only proven when the problem
is framed this way: HHH is required to report on the behavior
of an input that was defined to do exactly the opposite of
whatever DDD reports.
No, it is proven about the halting problem as that problem is.
Which is simply a logical impossibility
thus no actual limit to computation more that this logical impossibility: What time is it (yes or no)?
*This is isomorphic the HP decider/input pair*
Can Carol correctly answer “no” to this (yes/no) question? (Hehner:2018:2)
On 7/16/2024 2:10 AM, Mikko wrote:
On 2024-07-15 13:21:35 +0000, olcott said:
On 7/15/2024 2:52 AM, Mikko wrote:
On 2024-07-14 14:44:27 +0000, olcott said:
On 7/14/2024 3:48 AM, Mikko wrote:
On 2024-07-13 12:19:36 +0000, olcott said:
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation >>>>>>>>>>>>> is the semantics of the x86 programming language. By this >>>>>>>>>>>>> measure when 1 to ∞ steps of DDD are correctly emulated by >>>>>>>>>>>>> each pure function x86 emulator HHH (of the infinite set >>>>>>>>>>>>> of every HHH that can possibly exist) then DDD cannot >>>>>>>>>>>>> possibly reach past its own machine address of 0000216b >>>>>>>>>>>>> and halt.
For every instruction that the C compiler generates the x86 language
specifies an unambiguous meaning, leaving no room for "can". >>>>>>>>>>>>
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is >>>>>>>>>> no room for "cannot", either. The x86 semantics of the unshown code >>>>>>>>>> determines unambigously what happens.
Of an infinite set behavior X exists for at least one element >>>>>>>>> or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt.
That is so far from the Common Language that I can't parse.
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of
0000216b and halts thus proving that every HHH is correct to
reject its input DDD as non-halting.
Here you attempt to use the same name for a constant programs and univesally
quantifed variable with a poorly specified range. That is a form of a well
known mistake called the "fallacy of equivocation".
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.
That does not make sense. Which HHH does that DDD call? Which HHH
is at that fixed machine address?
HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
infinite set of HHH/DDD pairs.
You should not say "another way" before you have one way. What you
presented earlier is not a way as it did not make sense.
DDD itself is a single immutable finite string have the exactly
same instructions at the exact same machine addresses.
On 7/17/2024 3:03 AM, Mikko wrote:
On 2024-07-16 14:34:19 +0000, olcott said:
On 7/16/2024 2:10 AM, Mikko wrote:
On 2024-07-15 13:21:35 +0000, olcott said:
On 7/15/2024 2:52 AM, Mikko wrote:
On 2024-07-14 14:44:27 +0000, olcott said:
On 7/14/2024 3:48 AM, Mikko wrote:
On 2024-07-13 12:19:36 +0000, olcott said:
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:That is so far from the Common Language that I can't parse. >>>>>>>>>>
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation >>>>>>>>>>>>>>> is the semantics of the x86 programming language. By this >>>>>>>>>>>>>>> measure when 1 to ∞ steps of DDD are correctly emulated by >>>>>>>>>>>>>>> each pure function x86 emulator HHH (of the infinite set >>>>>>>>>>>>>>> of every HHH that can possibly exist) then DDD cannot >>>>>>>>>>>>>>> possibly reach past its own machine address of 0000216b >>>>>>>>>>>>>>> and halt.
For every instruction that the C compiler generates the >>>>>>>>>>>>>> x86 language
specifies an unambiguous meaning, leaving no room for "can". >>>>>>>>>>>>>>
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means >>>>>>>>>>>> there is
no room for "cannot", either. The x86 semantics of the >>>>>>>>>>>> unshown code
determines unambigously what happens.
Of an infinite set behavior X exists for at least one element >>>>>>>>>>> or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt. >>>>>>>>>>
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of >>>>>>>>> 0000216b and halts thus proving that every HHH is correct to >>>>>>>>> reject its input DDD as non-halting.
Here you attempt to use the same name for a constant programs
and univesally
quantifed variable with a poorly specified range. That is a form >>>>>>>> of a well
known mistake called the "fallacy of equivocation".
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.
That does not make sense. Which HHH does that DDD call? Which HHH
is at that fixed machine address?
HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
infinite set of HHH/DDD pairs.
You should not say "another way" before you have one way. What you
presented earlier is not a way as it did not make sense.
DDD itself is a single immutable finite string have the exactly
same instructions at the exact same machine addresses.
That string does not specify what the call to an address outside of the
string does and whether it returns.
It need not do that. It specifies the address of HHH and the empirical behavior of DDD correctly emulated by HHH shows this behavior.
Also it is stipulated that HHH is an infinite set of x86 emulators
that correctly emulate 1,2,3...∞ instructions of DDD.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.
On 7/17/2024 3:03 AM, Mikko wrote:
On 2024-07-16 14:34:19 +0000, olcott said:
On 7/16/2024 2:10 AM, Mikko wrote:
On 2024-07-15 13:21:35 +0000, olcott said:
On 7/15/2024 2:52 AM, Mikko wrote:
On 2024-07-14 14:44:27 +0000, olcott said:
On 7/14/2024 3:48 AM, Mikko wrote:
On 2024-07-13 12:19:36 +0000, olcott said:
On 7/13/2024 2:55 AM, Mikko wrote:
On 2024-07-12 13:28:15 +0000, olcott said:
On 7/12/2024 3:27 AM, Mikko wrote:That is so far from the Common Language that I can't parse. >>>>>>>>>>
On 2024-07-11 14:02:52 +0000, olcott said:
On 7/11/2024 1:22 AM, Mikko wrote:
On 2024-07-10 15:03:46 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
We stipulate that the only measure of a correct emulation >>>>>>>>>>>>>>> is the semantics of the x86 programming language. By this >>>>>>>>>>>>>>> measure when 1 to ∞ steps of DDD are correctly emulated by >>>>>>>>>>>>>>> each pure function x86 emulator HHH (of the infinite set >>>>>>>>>>>>>>> of every HHH that can possibly exist) then DDD cannot >>>>>>>>>>>>>>> possibly reach past its own machine address of 0000216b >>>>>>>>>>>>>>> and halt.
For every instruction that the C compiler generates the x86 language
specifies an unambiguous meaning, leaving no room for "can". >>>>>>>>>>>>>>
then DDD cannot possibly reach past its own machine
address of 0000216b and halt.
As I already said, there is not room for "can". That means there is
no room for "cannot", either. The x86 semantics of the unshown code
determines unambigously what happens.
Of an infinite set behavior X exists for at least one element >>>>>>>>>>> or behavior X does not exist for at least one element.
Of the infinite set of HHH/DDD pairs zero DDD elements halt. >>>>>>>>>>
*This proves that every rebuttal is wrong somewhere*
No DDD instance of each HHH/DDD pair of the infinite set of
every HHH/DDD pair ever reaches past its own machine address of >>>>>>>>> 0000216b and halts thus proving that every HHH is correct to >>>>>>>>> reject its input DDD as non-halting.
Here you attempt to use the same name for a constant programs and univesally
quantifed variable with a poorly specified range. That is a form of a well
known mistake called the "fallacy of equivocation".
I incorporated your suggestion in my paper.
DDD is a fixed constant finite string that calls its
HHH at the same fixed constant machine address.
That does not make sense. Which HHH does that DDD call? Which HHH
is at that fixed machine address?
HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
infinite set of HHH/DDD pairs.
You should not say "another way" before you have one way. What you
presented earlier is not a way as it did not make sense.
DDD itself is a single immutable finite string have the exactly
same instructions at the exact same machine addresses.
That string does not specify what the call to an address outside of the
string does and whether it returns.
It need not do that. It specifies the address of HHH and the empirical behavior of DDD correctly emulated by HHH shows this behavior.
Also it is stipulated that HHH is an infinite set of x86 emulators
that correctly emulate 1,2,3...∞ instructions of DDD.
_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]
*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.
On 7/17/2024 2:08 AM, Mikko wrote:
On 2024-07-16 14:46:40 +0000, olcott said:
On 7/16/2024 2:18 AM, Mikko wrote:
On 2024-07-15 13:32:27 +0000, olcott said:
On 7/15/2024 2:57 AM, Mikko wrote:
On 2024-07-14 14:48:05 +0000, olcott said:
On 7/14/2024 3:49 AM, Mikko wrote:
On 2024-07-13 12:18:27 +0000, olcott said:
When the source of your disagreement is your own ignorance
then your disagreement has no actual basis.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Disagreeing with the above is analogous to disagreeing
with arithmetic.
A lame analogy. A better one is: 2 + 3 = 5 is a proven theorem just >>>>>> like the uncomputability of halting is.
The uncomputability of halting is only proven when the problem
is framed this way: HHH is required to report on the behavior
of an input that was defined to do exactly the opposite of
whatever DDD reports.
No, it is proven about the halting problem as that problem is.
Which is simply a logical impossibility
Yes, a halting decider is a logical impossibility, as can be and has
been proven.
If it is a logical impossibility then it places no
actual limit on computation otherwise we would have
"the CAD problem" of the logical impossibility of making
a CAD system that correctly draws a square circle.
On 7/18/2024 2:55 AM, Mikko wrote:
On 2024-07-17 13:14:43 +0000, olcott said:
On 7/17/2024 2:08 AM, Mikko wrote:
On 2024-07-16 14:46:40 +0000, olcott said:
On 7/16/2024 2:18 AM, Mikko wrote:
On 2024-07-15 13:32:27 +0000, olcott said:
On 7/15/2024 2:57 AM, Mikko wrote:
On 2024-07-14 14:48:05 +0000, olcott said:
On 7/14/2024 3:49 AM, Mikko wrote:
On 2024-07-13 12:18:27 +0000, olcott said:
When the source of your disagreement is your own ignorance
then your disagreement has no actual basis.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Disagreeing with the above is analogous to disagreeing
with arithmetic.
A lame analogy. A better one is: 2 + 3 = 5 is a proven theorem just >>>>>>>> like the uncomputability of halting is.
The uncomputability of halting is only proven when the problem
is framed this way: HHH is required to report on the behavior
of an input that was defined to do exactly the opposite of
whatever DDD reports.
No, it is proven about the halting problem as that problem is.
Which is simply a logical impossibility
Yes, a halting decider is a logical impossibility, as can be and has
been proven.
If it is a logical impossibility then it places no
actual limit on computation otherwise we would have
"the CAD problem" of the logical impossibility of making
a CAD system that correctly draws a square circle.
A logical impossibility does place a limit on computation.
Otherwise it would be possible to build a CAD system that
can correctly draw a square circle.
Of the set of possible things TM's can do them all.
One of the possible things is for a TM to to be a quadrillion
times smarter than any human at anything requiring human intelligence.
One thing isomorphic to the halting problem is the liar paradox.
Not even God can correctly determine whether this sentence is
true or false: "This sentence is not true".
On 7/19/2024 2:30 AM, Mikko wrote:
On 2024-07-18 13:36:53 +0000, olcott said:
On 7/18/2024 2:55 AM, Mikko wrote:
On 2024-07-17 13:14:43 +0000, olcott said:
On 7/17/2024 2:08 AM, Mikko wrote:
On 2024-07-16 14:46:40 +0000, olcott said:
On 7/16/2024 2:18 AM, Mikko wrote:
On 2024-07-15 13:32:27 +0000, olcott said:
On 7/15/2024 2:57 AM, Mikko wrote:
On 2024-07-14 14:48:05 +0000, olcott said:
On 7/14/2024 3:49 AM, Mikko wrote:
On 2024-07-13 12:18:27 +0000, olcott said:
When the source of your disagreement is your own ignorance >>>>>>>>>>> then your disagreement has no actual basis.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Disagreeing with the above is analogous to disagreeing
with arithmetic.
A lame analogy. A better one is: 2 + 3 = 5 is a proven theorem just >>>>>>>>>> like the uncomputability of halting is.
The uncomputability of halting is only proven when the problem >>>>>>>>> is framed this way: HHH is required to report on the behavior >>>>>>>>> of an input that was defined to do exactly the opposite of
whatever DDD reports.
No, it is proven about the halting problem as that problem is.
Which is simply a logical impossibility
Yes, a halting decider is a logical impossibility, as can be and has >>>>>> been proven.
If it is a logical impossibility then it places no
actual limit on computation otherwise we would have
"the CAD problem" of the logical impossibility of making
a CAD system that correctly draws a square circle.
A logical impossibility does place a limit on computation.
Otherwise it would be possible to build a CAD system that
can correctly draw a square circle.
Of the set of possible things TM's can do them all.
Depends on the meanings of "possible" and "thing". Of things other than
computation no TM can do any. A Turing machine can determine whether
a sentence of Presburger arithmetic is provable but no Turing machine
can determine whether a sentence of Peano arithmetic is provable.
Some undecidable expressions are only undecidable because
they are self contradictory. In other words they are undecidable
because there is something wrong with them.
The Liar Paradox: "This sentence is not true"
On 7/20/2024 3:42 AM, Mikko wrote:
On 2024-07-19 13:48:49 +0000, olcott said:
Some undecidable expressions are only undecidable because
they are self contradictory. In other words they are undecidable
because there is something wrong with them.
Being self-contradictory is a semantic property. Being uncdecidable is
independent of any semantics.
Not it is not. When an expression is neither true nor false
that makes it neither provable nor refutable.
As Richard
Montague so aptly showed Semantics can be specified syntactically.
An arithmetic sentence is always about
numbers, not about sentences.
So when Gödel tried to show it could be about provability
he was wrong before he even started?
A proof is about sentences, not about
numbers.
The Liar Paradox: "This sentence is not true"
cannot be said in the language of Peano arithmetic.
Since Tarski anchored his whole undefinability theorem in a self-contradictory sentence he only really showed that sentences that
are neither true nor false cannot be proven true.
https://liarparadox.org/Tarski_247_248.pdf https://liarparadox.org/Tarski_275_276.pdf
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 22:13:54 |
| Calls: | 9,726 |
| Calls today: | 16 |
| Files: | 13,741 |
| Messages: | 6,182,240 |