On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
  HHH(DDD);
  return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD, in particular, it says
NOTHING about the behavior of the rest of the instructions of DDD.

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, if a HHH returns to its caller, the correct emulation of the DDD
that calls that HHH when correctly emulated by an unlimited emulator
WILL reach its final instruction, as it will see DDD call HHH, then HHH
emulate N instructions of a copy of DDD, then abort its emulation and
return to its caller, which is DDD, which will return.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs, thus
the behavior of non-inputs is outside of their domain.

And that behavior that they are REQUIRED to report on is the behavior of
the direct exectuion of the machine the input FULLY represents.

THAT IS DEFINITION.

If the "halt decider" tries to consider anything else that doesn't give
the exact same answer as the behavior of the input, it just isn't a halt decider.

THAT IS DEFINITION.

Sorry, you are just showing your self-made ignorance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you claim
is incorrect.

For an emulation to be "correct" it must be complete, as partial
emulations are only partially correct, so without the partial modifier,
they are not correct.

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*
(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers".

The SUBJECT of the sentence is "DDD", that is the name of a PROGRAM, and
DDD includes all the code of HHH, If it doesn't we can't even correctly
emulate DDD past the call instruction.

The VERB of the sentence is "Returns" that is the action of DDD that we
are talking about.

The OBJECT of the sentence is "its callers" which indicates who we are
asking if DDD returns to.

The phrase "emulated by HHH" is a modifier phrase attached to DDD to
specify which of potential different DDDs we are talking about, and make
it clear that we are talking about the DDD that calls the HHH that we
are talking abut.

Thus, the behavior of that DDD, is to call HHH(DDD), at which point this subroutine HHH will emulate the code specified by its input to emulate N instructions, in that time it will not reach a final state, and so it
will return the value 0 to its caller, which is DDD, and DDD will then
return to its caller, showing how it does it.


The sentence you seem to want to talk about would be something more like:

The simulation of DDD by HHH will never return to its caller.

Here, the subject is the "simulation", of what: DDD, by whom: HHH.

Yes, that simulation will never reach a return of DDD, so that statement
would be true.

The problem is that it makes it clear that if HHH aborts is simulation
that is only partial that clearly doesn't mean that the full simulation
of the input would be non-halting.

And that clarity is your problem, because it breaks your next step.

Your argument NEEDS there to be wiggle room to switch meaning, because
it needs to generate the needed LIE by doing that.

Sorry, you are just proving that you just don't know what you are
talking about, or that you are just pathetically a pathological liar
that doesn't care how much you lie.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you
claim is incorrect.

For an emulation to be "correct" it must be complete, as partial
emulations are only partially correct, so without the partial
modifier, they are not correct.

A complete emulation of one instruction is
a complete emulation of one instruction

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*
(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers".

Show the exact machine code trace of how DDD emulated
by HHH (according to the semantics of the x86 language)
reaches its own machine address 00002183

No. The trace is to long, and since you HHH doesn't meet your
requirements (since it isn't a pure function) you can't give me a
compldte input to trace.

If the input DDD is just what you show below, your problem has a
category error as that isn't a complete program, and thus not something
that can be completely traced.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When DDD is emulated by HHH
HHH emulates the lines of DDD in this order:
[00002172]
[00002173]
[00002175]
[0000217a] calls HHH(DDD)

And here you show that you don't understand what a correct by x86
semantics means.

Following the call to HHH, must be the instuctions of HHH being emulated.

THAT *IS* the requirements of emulation by the semantics of the x86
language.

Since HHH(DDD) is know to return, if HHH actually WAS a pure function,
then this call MUST return to DDD.

You are just shown how stuoid you are.

which emulates the lines of DDD in this order
HHH emulates the lines of DDD in this order:
[00002172]
[00002173]
[00002175]
[0000217a]

with 200 pages of HHH emulating itself emulating
DDD inbetween.

No, about 300 lines. (if we allow the skipping of the actual OS code
that your trace skips). The 200 pages is the trace of the HHH deciding
on the input, not the trace it DOES of the input. That has about 1-2 instructions emulated per page of trace.

Obviously you don't read the message, I guess you are just to stupid to understand long posts.

You are just PROVING you are just a self-made idiot that just doesn't
know what he is talking about, and so stupid that he doesn't realize he
is an idiot, which is the worse kind.

That, you are you no sense of ethics that make you want to even try to
tell the truth, because you think lying is just fine.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

You were trying to label an incomplete/partial/aborted simulation
as correct.

A correct simulation of N instructions of DDD by HHH is sufficient to
correctly predict the behavior of an unlimited simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*

how *HHH* returns

(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

HHH simulates DDD enter the matrix
DDD calls HHH(DDD) Fred: could be eliminated
HHH simulates DDD second level
DDD calls HHH(DDD) recursion detected
HHH aborts, returns outside interference
DDD halts voila
HHH halts

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 14.aug.2024 om 02:52 schreef olcott:

void DDD()
{
  HHH(DDD);
  return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Again the same joke? It seems you are short of memory.

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

It is only a correct start of an incomplete simulation.

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

It is not, since the semantics of the x86 language, used in the direct execution of the same input, shows that DDD halts.
It is clear that HHH aborts its own simulation one cycle to soon. The
simulated HHH had only one cycle to go, when aborted. Therefore, the
prediction of a non-halting behaviour is premature.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs.

Exactly. And this is the same input that, when used in direct execution,
halts.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs, thus
the behavior of non-inputs is outside of their domain.

Indeed, so your dreams of a HHH that does not abort and does not halt,
is a non-input and is outside the domain.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
HHH(DDD);
return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/14/24 12:24 AM, olcott wrote:

On 8/13/2024 11:04 PM, Richard Damon wrote:

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you
claim is incorrect.

For an emulation to be "correct" it must be complete, as partial
emulations are only partially correct, so without the partial
modifier, they are not correct.

A complete emulation of one instruction is
a complete emulation of one instruction

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*
(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers".

Show the exact machine code trace of how DDD emulated
by HHH (according to the semantics of the x86 language)
reaches its own machine address 00002183

No. The trace is to long,

Show the Trace of DDD emulated by HHH
and show the trace of DDD emulated by HHH
emulated by the executed HHH
Just show the DDD code traces.

First you need to make a DDD that meets the requirements, and that means
that it calls an HHH that meets the requirements.

Since you HHH doesn't, I can't show what isn't there yet.

The biggest problem with HHH is that it isn't pure function of just its declared inputs, it detects via a side channel if it is the "root"
emulator, and changes its behavior because of that.

So, since we don't have an actual DDD that meets its requirements, we
can't make a correct trace of it to show what it does.

Second, you have an incoherent requiremnet in your challenge, the "trace
of DDD emulated by HHH" will not be created by HHH, since your HHH
doesn't do a complete emulation, and your requirement is for a complete
trace, so you are just creating a strawman deception.

It shouldn't be too hard for a decent programmer to actually make the
required HHH, but from what I see of your code, you are not one of
those. Of course, getting it to behave like you want would be tougher,
as you need to program in a BUG make it ignore the conditionals inside
of HHH when it emulates the input.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 14 Aug 2024 08:14:42 -0500 schrieb olcott:

On 8/14/2024 2:43 AM, joes wrote:

Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

You were trying to label an incomplete/partial/aborted simulation as
correct.

When one instruction of DDD is correctly emulated then one instruction
was correctly emulated.

Only one, so not all.

A correct simulation of N instructions of DDD by HHH is sufficient
to correctly predict the behavior of an unlimited simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*

how *HHH* returns

Changing the question is the strawman error or reasoning.

Richard was talking about HHH returning.

(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

HHH simulates DDD enter the matrix
DDD calls HHH(DDD) Fred: could be eliminated
HHH simulates DDD second level
DDD calls HHH(DDD) recursion detected
HHH aborts, returns outside interference
DDD halts voila
HHH halts

That is the strawman error of reasoning.

This is not a misrepresentation of your position, this is mine.

DDD correctly emulated by HHH never reaches its own "return"
instruction. Show how it does or admit that I am correct.

See above. Show the error.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 14 Aug 2024 08:38:51 -0500 schrieb olcott:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour you
must prove that HHH(DDD) does not terminate.

What is wrong about that?

That is the strawman error of reasoning.

Not at all. A strawman is a wrong presentation of opposing arguments.
There aren't even any arguments here.

The focus of the post was to show that DDD emulated by HHH according to
the semantics of the x86 language cannot possibly reach its own "return" instruction.

Yes, and that was a direct reply. As Fred said, DDD could be replaced
by a direct call to HHH(HHH).

By changing the subject you cheat.

You are avoiding questions.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 14 Aug 2024 08:06:27 -0500 schrieb olcott:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour you
must prove that HHH(DDD) does not terminate.

Wrong.

How can DDD not halt if HHH does?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 14.aug.2024 om 15:38 schreef olcott:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

That is the strawman error of reasoning.

The focus of the post was to show that DDD emulated by HHH
according to the semantics of the x86 language cannot possibly
reach its own "return" instruction.

A simulation that fails to reach the end is never correct.
It is the strawmen error to think that a correct start of a simulation
makes the whole simulation correct.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 14.aug.2024 om 15:18 schreef olcott:

On 8/14/2024 4:09 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 02:52 schreef olcott:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Again the same joke? It seems you are short of memory.

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

It is only a correct start of an incomplete simulation.

When one instruction is emulated completely then this
is a complete emulation of one instruction.

That is what I said: It is the correct start of the simulation of a
program. But for the correct simulation of the program we need more.

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

It is not,

When one instruction is emulated completely then this
is a complete emulation of one instruction.
Until you agree with that we are dead in the water.

I agreed already that the correct simulation of one instruction is the
correct start of the simulation of a program. But for the correct
simulation of the program we need more.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 14.aug.2024 om 15:14 schreef olcott:

On 8/14/2024 2:43 AM, joes wrote:

Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

You were trying to label an incomplete/partial/aborted simulation
as correct.

When one instruction of DDD is correctly emulated then one
instruction was correctly emulated.

A correct simulation of N instructions of DDD by HHH is sufficient to >>>>> correctly predict the behavior of an unlimited simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*

how *HHH* returns

Changing the question is the strawman error or reasoning.

(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

HHH simulates DDD    enter the matrix
   DDD calls HHH(DDD)    Fred: could be eliminated
   HHH simulates DDD    second level
     DDD calls HHH(DDD)    recursion detected
   HHH aborts, returns    outside interference
   DDD halts        voila
HHH halts

That is the strawman error of reasoning.
DDD correctly emulated by HHH never reaches its own "return"
instruction. Show how it does or admit that I am correct.

Only because the HHH simulated by HHH was not allowed by the simulating
HHH to continue up to the end. The simulating HHH aborted one cycle too
soon. So, the only reason why the simulation does not reach the end is
that the simulation is incomplete.
Every simulation that aborts is incomplete.


--
Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/08/2024 08:43, joes wrote:

Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

You were trying to label an incomplete/partial/aborted simulation
as correct.

A correct simulation of N instructions of DDD by HHH is sufficient to
correctly predict the behavior of an unlimited simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*

how *HHH* returns

(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

HHH simulates DDD enter the matrix
DDD calls HHH(DDD) Fred: could be eliminated
HHH simulates DDD second level
DDD calls HHH(DDD) recursion detected
HHH aborts, returns outside interference
DDD halts voila
HHH halts

You're misunderstanding the scenario? If your simulated HHH aborts its simulation [line 5 above],
then the outer level H would have aborted its identical simulation earlier. You know that, right?
[It's what people have been discussing here endlessly for the last few months! :) ]

So your trace is impossible...


Mike.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 14 Aug 2024 08:18:18 -0500 schrieb olcott:

On 8/14/2024 4:09 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 02:52 schreef olcott:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

It is only a correct start of an incomplete simulation.

When one instruction is emulated completely then this is a complete
emulation of one instruction.

And not an emulation of all instructions.

A correct simulation of N instructions of DDD by HHH is sufficient to
correctly predict the behavior of an unlimited simulation.

It is not,

When one instruction is emulated completely then this is a complete
emulation of one instruction.
Until you agree with that we are dead in the water.

That's on you.

Termination analyzers / halt deciders are only required to correctly
predict the behavior of their inputs.

Exactly. And this is the same input that, when used in direct
execution, halts.

Termination analyzers / halt deciders are only required to correctly
predict the behavior of their inputs, thus the behavior of non-inputs
is outside of their domain.

Indeed, so your dreams of a HHH that does not abort and does not halt,
is a non-input and is outside the domain.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 14 Aug 2024 16:07:43 +0100 schrieb Mike Terry:

On 14/08/2024 08:43, joes wrote:

Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

You were trying to label an incomplete/partial/aborted simulation as
correct.

A correct simulation of N instructions of DDD by HHH is sufficient
to correctly predict the behavior of an unlimited simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*

how *HHH* returns

HHH simulates DDD enter the matrix
DDD calls HHH(DDD) Fred: could be eliminated HHH simulates

DDD

second level
DDD calls HHH(DDD) recursion detected
HHH aborts, returns outside interference DDD halts

voila

HHH halts

You're misunderstanding the scenario? If your simulated HHH aborts its simulation [line 5 above],
then the outer level H would have aborted its identical simulation
earlier. You know that, right?

Of course. I made it only to illustrate one step in the paradoxical
reasoning, as long as we're calling programs that do or don't abort
the same.

So your trace is impossible...

Just like all the others are wrong.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14 04:04:23 +0000, Richard Damon said:

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you claim
is incorrect.

For an emulation to be "correct" it must be complete, as partial
emulations are only partially correct, so without the partial modifier,
they are not correct.

A complete emulation of one instruction is
a complete emulation of one instruction

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*
(the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers".

Show the exact machine code trace of how DDD emulated
by HHH (according to the semantics of the x86 language)
reaches its own machine address 00002183

No. The trace is to long, and since you HHH doesn't meet your
requirements (since it isn't a pure function) you can't give me a
compldte input to trace.

The trace is regular enough that we could define a formal language for
the trace and construct an analyzer program to detect deviations from
x86 semnatics and hidden inputs.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14 13:38:51 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

That is the strawman error of reasoning.

No, the word "strawman" means someting else.

The focus of the post was to show that DDD emulated by HHH
according to the semantics of the x86 language cannot possibly
reach its own "return" instruction.

By changing the subject you cheat.

That is false. Everything you say is a valid topic for a reply.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14 13:06:27 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

Wrong.

At least the proof that DDD does not terminate also proves as an
intermedate result or an obvious corollary that HHH does not halt.

Non-halting means that an infinite number of instructions can be
executed without halting. That means that at least one instruction
is executed infinitely many times as there are only finitely many
instructions. But not instrunctions of DDD outside HHH is executed
infinitely many times.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/08/2024 08:00, joes wrote:

Am Wed, 14 Aug 2024 16:07:43 +0100 schrieb Mike Terry:

On 14/08/2024 08:43, joes wrote:

Am Tue, 13 Aug 2024 21:38:07 -0500 schrieb olcott:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

A simulation of N instructions of DDD by HHH according to the
semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

You were trying to label an incomplete/partial/aborted simulation as
correct.

A correct simulation of N instructions of DDD by HHH is sufficient >>>>>> to correctly predict the behavior of an unlimited simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller*

how *HHH* returns

HHH simulates DDD enter the matrix
DDD calls HHH(DDD) Fred: could be eliminated HHH simulates

DDD

second level
DDD calls HHH(DDD) recursion detected
HHH aborts, returns outside interference DDD halts

voila

HHH halts

You're misunderstanding the scenario? If your simulated HHH aborts its
simulation [line 5 above],
then the outer level H would have aborted its identical simulation
earlier. You know that, right?

Of course. I made it only to illustrate one step in the paradoxical reasoning, as long as we're calling programs that do or don't abort
the same.

So... it seems that perhaps you agree on this one specific point: that when (some specific) HHH
partially simulates its associated (specific) DDD, that SIMULATION does not get as far as simulating
DDD returning? [Well, it did in your example above, but you seem to have agreed that was logically
wrong.]

For example, perhaps HHH never aborts so the simulation never terminates, or in the case of PO's HHH
in halt7.c, HHH aborts its simulation before DDD gets as far as returning. Either way /the partial
simulation/ does not proceed to a point where DDD returns...

That's a completely different question from asking whether computation DDD() ever returns, which is
what a halt decider must decide. You shouldn't feel that if you agree with the former, that you're
also agreeing that DDD() never halts, or that "not halting is the right answer for HHH to give for
input DDD" or any other PO nonsense!

I'd just add that if you do agree with PO on this one specific point, why argue with him about it?
Just agree and PO will soon move on to some completely ridiculous conclusion that surely would be
more fun to argue with (assuming you enjoy arguing with PO :)).


Mike.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/15/24 10:58 AM, olcott wrote:

On 8/15/2024 3:19 AM, Mikko wrote:

On 2024-08-14 04:04:23 +0000, Richard Damon said:

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N
instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you
claim is incorrect.

For an emulation to be "correct" it must be complete, as partial
emulations are only partially correct, so without the partial
modifier, they are not correct.

A complete emulation of one instruction is
a complete emulation of one instruction

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller* >>>>>> (the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers".

Show the exact machine code trace of how DDD emulated
by HHH (according to the semantics of the x86 language)
reaches its own machine address 00002183

No. The trace is to long, and since you HHH doesn't meet your
requirements (since it isn't a pure function) you can't give me a
compldte input to trace.

The trace is regular enough that we could define a formal language for
the trace and construct an analyzer program to detect deviations from
x86 semnatics and hidden inputs.

There are no deviations. The x86utm operating system is
built from libx86emu that has had decades of development
effort. HHH really does emulate itself emulating DDD.

And then ignores that emulation, so it really didn't effectively emulate it.

*This source-code proves it* https://github.com/plolcott/x86utm/blob/master/Halt7.c
Mike seems to have the best understanding of that source-code.

Amd it proves that HHH is *NOT* a "pure function" and thus doesn't even
qualify to be a "decider".

Sorry, but the simple inspection of the code proves that you have been
lying about this the full time, and thus none of your proof that looks
at that is valid.

He might not yet understand that HHH does emulate itself
emulating DDD. He could find out how HHH does this.

HHH calls the x86utm operating system to create a new
process context to emulate DDD. HHH emulates itself in
the same process context. Its emulated self calls x86utm
to create another process context to emulate its own
DDD instance.

And ignores the fact that the DDD that it is emulting (which includes
the code of the HHH that it calls) only CONDITIONALLY emulates the next
layer, and that it WILL abort its emulation (since it does the same as
this HHH since it is the same code, or at least it would when you fix
the impurity of the code) and thus HHH can not consider DDD to be
non-halting.

Of course, the fact that as has been pointed out, your HHH that you have
worked on for all these years STILL fails to meet the basic requirements
of being a pure function and thus isn't eligable to be a Decider in the
first place.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/15/24 10:26 PM, olcott wrote:

On 8/15/2024 8:57 PM, Richard Damon wrote:

On 8/15/24 10:58 AM, olcott wrote:

On 8/15/2024 3:19 AM, Mikko wrote:

On 2024-08-14 04:04:23 +0000, Richard Damon said:

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it is just the correct PARTIAL emulation of the first N >>>>>>>>> instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you >>>>>>> claim is incorrect.

For an emulation to be "correct" it must be complete, as partial >>>>>>> emulations are only partially correct, so without the partial
modifier, they are not correct.

A complete emulation of one instruction is
a complete emulation of one instruction

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited >>>>>>>>>> simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller* >>>>>>>> (the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers".

Show the exact machine code trace of how DDD emulated
by HHH (according to the semantics of the x86 language)
reaches its own machine address 00002183

No. The trace is to long, and since you HHH doesn't meet your
requirements (since it isn't a pure function) you can't give me a
compldte input to trace.

The trace is regular enough that we could define a formal language for >>>> the trace and construct an analyzer program to detect deviations from
x86 semnatics and hidden inputs.

There are no deviations. The x86utm operating system is
built from libx86emu that has had decades of development
effort. HHH really does emulate itself emulating DDD.

And then ignores that emulation,

counter-factual but you don't care.

Then why does it say there were no conditional branches in the
simulation of the code of the program "DDD" where there were in the
simulation of the HHH that was called by DDD and thus part of the
program DDD.

Or, are you going to admit that you fail to understand the definition of
a program, and thus your last two decades of work just went up in the
smoke of error due to self-created ignorance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, 15 Aug 2024 23:20:06 -0500 schrieb olcott:

On 8/15/2024 11:02 PM, Richard Damon wrote:

On 8/15/24 10:26 PM, olcott wrote:

On 8/15/2024 8:57 PM, Richard Damon wrote:

On 8/15/24 10:58 AM, olcott wrote:

On 8/15/2024 3:19 AM, Mikko wrote:

On 2024-08-14 04:04:23 +0000, Richard Damon said:

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

No. The trace is too long, and since you HHH doesn't meet your
requirements (since it isn't a pure function) you can't give me a >>>>>>> compldte input to trace.

The trace is regular enough that we could define a formal language >>>>>> for the trace and construct an analyzer program to detect
deviations from x86 semnatics and hidden inputs.

There are no deviations. The x86utm operating system is built from
libx86emu that has had decades of development effort. HHH really
does emulate itself emulating DDD.

And then ignores that emulation,

counter-factual but you don't care.

Then why does it say there were no conditional branches in the
simulation of the code of the program "DDD" where there were in the
simulation of the HHH that was called by DDD and thus part of the
program DDD.

Never heard of dividing the program under test from the test program?
HHH is reporting on the behavior of DDD.

Only that is not possible here, because HHH is part of DDD by design.
If you change the abort conditions on one of them, you break the
recursive structure.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-14 13:38:51 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

That is the strawman error of reasoning.

No, it is not. A "strawman" is a refutation (or an attempted refutation)
of a claim that is falsely attributed to the opponent.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-15 15:25:07 +0000, olcott said:

On 8/15/2024 5:22 AM, Mikko wrote:

On 2024-08-14 13:06:27 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

Wrong.

At least the proof that DDD does not terminate also proves as an
intermedate result or an obvious corollary that HHH does not halt.

Non-halting means that an infinite number of instructions can be
executed without halting. That means that at least one instruction
is executed infinitely many times as there are only finitely many
instructions. But not instrunctions of DDD outside HHH is executed
infinitely many times.

Wrong. Non-halting only means that when DDD is emulated
according to the semantics of the x86 language and this
emulation is unlimited that DDD would never reach its
own "return" instruction.

If what I said is wrong then what you said is wrong, too,
as you say what I said.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-15 14:14:42 +0000, olcott said:

On 8/15/2024 5:26 AM, Mikko wrote:

On 2024-08-14 13:38:51 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

That is the strawman error of reasoning.

No, the word "strawman" means someting else.

The focus of the post was to show that DDD emulated by HHH
according to the semantics of the x86 language cannot possibly
reach its own "return" instruction.

By changing the subject you cheat.

That is false. Everything you say is a valid topic for a reply.

The focus of the post was to show that DDD emulated by HHH
according to the semantics of the x86 language cannot possibly
reach its own "return" instruction.

The focus of your post.

Whatever you say that does not directly address these exact
words is construed as a dishonest dodge away from the point.

You may construe whatever you want. That does not ressttrict others.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-16 04:20:06 +0000, olcott said:

On 8/15/2024 11:02 PM, Richard Damon wrote:

On 8/15/24 10:26 PM, olcott wrote:

On 8/15/2024 8:57 PM, Richard Damon wrote:

On 8/15/24 10:58 AM, olcott wrote:

On 8/15/2024 3:19 AM, Mikko wrote:

On 2024-08-14 04:04:23 +0000, Richard Damon said:

On 8/13/24 11:48 PM, olcott wrote:

On 8/13/2024 10:21 PM, Richard Damon wrote:

On 8/13/24 10:38 PM, olcott wrote:

On 8/13/2024 9:29 PM, Richard Damon wrote:

On 8/13/24 8:52 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

A simulation of N instructions of DDD by HHH according to >>>>>>>>>>>> the semantics of the x86 language is necessarily correct. >>>>>>>>>>>>

Nope, it is just the correct PARTIAL emulation of the first N >>>>>>>>>>> instructions of DDD, and not of all of DDD,

That is what I said dufuss.

Nope. You didn't. I added clairifying words, pointing out why you claim
is incorrect.

For an emulation to be "correct" it must be complete, as partial >>>>>>>>> emulations are only partially correct, so without the partial modifier,
they are not correct.

A complete emulation of one instruction is
a complete emulation of one instruction

A correct simulation of N instructions of DDD by HHH is >>>>>>>>>>>> sufficient to correctly predict the behavior of an unlimited >>>>>>>>>>>> simulation.

Nope, if a HHH returns to its caller,

*Try to show exactly how DDD emulated by HHH returns to its caller* >>>>>>>>>> (the first one doesn't even have a caller)
Use the above machine language instructions to show this.

Remember how English works:

When you ask "How DDD emulated by HHH returns to its callers". >>>>>>>>

Show the exact machine code trace of how DDD emulated
by HHH (according to the semantics of the x86 language)
reaches its own machine address 00002183

No. The trace is to long, and since you HHH doesn't meet your
requirements (since it isn't a pure function) you can't give me a >>>>>>> compldte input to trace.

The trace is regular enough that we could define a formal language for >>>>>> the trace and construct an analyzer program to detect deviations from >>>>>> x86 semnatics and hidden inputs.

There are no deviations. The x86utm operating system is
built from libx86emu that has had decades of development
effort. HHH really does emulate itself emulating DDD.

And then ignores that emulation,

counter-factual but you don't care.

Then why does it say there were no conditional branches in the
simulation of the code of the program "DDD" where there were in the
simulation of the HHH that was called by DDD and thus part of the
program DDD.

Never heard of dividing the program under test from the test program?
HHH is reporting on the behavior of DDD.

I have worked with many differend kinds of testing of programs for many different purposes, and I have never heard anyone to say so or anything
like that.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 16 Aug 2024 07:42:22 -0500 schrieb olcott:

On 8/16/2024 3:53 AM, Mikko wrote:

On 2024-08-15 15:25:07 +0000, olcott said:

On 8/15/2024 5:22 AM, Mikko wrote:

On 2024-08-14 13:06:27 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

At least the proof that DDD does not terminate also proves as an
intermedate result or an obvious corollary that HHH does not halt.
Non-halting means that an infinite number of instructions can be
executed without halting. That means that at least one instruction is
executed infinitely many times as there are only finitely many
instructions. But not instrunctions of DDD outside HHH is executed
infinitely many times.

Wrong. Non-halting only means that when DDD is emulated according to
the semantics of the x86 language and this emulation is unlimited that
DDD would never reach its own "return" instruction.

If what I said is wrong then what you said is wrong, too,
as you say what I said.

*You are getting the computer science incorrectly*
On 8/2/2024 11:32 PM, Jeff Barnett wrote:

...In some formulations, there are specific states
defined as "halting states" and the machine only halts if either
the start state is a halt state...
...these and many other definitions all have
equivalent computing prowess...

The "return" instruction is the halt state of DDD.

It's kind of amazing to see you quote unrelated stuff.
How does HHH not simulate DDD returning, while not executing the same instructions infinitely?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/24 8:42 AM, olcott wrote:

On 8/16/2024 3:53 AM, Mikko wrote:

On 2024-08-15 15:25:07 +0000, olcott said:

On 8/15/2024 5:22 AM, Mikko wrote:

On 2024-08-14 13:06:27 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

Wrong.

At least the proof that DDD does not terminate also proves as an
intermedate result or an obvious corollary that HHH does not halt.

Non-halting means that an infinite number of instructions can be
executed without halting. That means that at least one instruction
is executed infinitely many times as there are only finitely many
instructions. But not instrunctions of DDD outside HHH is executed
infinitely many times.

Wrong. Non-halting only means that when DDD is emulated
according to the semantics of the x86 language and this
emulation is unlimited that DDD would never reach its
own "return" instruction.

If what I said is wrong then what you said is wrong, too,
as you say what I said.

*You are getting the computer science incorrectly*

On 8/2/2024 11:32 PM, Jeff Barnett wrote:

...In some formulations, there are specific states
    defined as "halting states" and the machine only
    halts if either the start state is a halt state...

...these and many other definitions all have
    equivalent computing prowess...

The "return" instruction is the halt state of DDD.

Which DDD (the program) reaches if the HHH that it calls returns, which
it will if any copy of that HHH given that same input does (or you are admitting you are lying about the properties of HHH).

Remember, behavior as described above it based on the actual running (or COMPLETE simulation) of it, not on the partial simulation of it that HHH
does.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-16 12:42:22 +0000, olcott said:

On 8/16/2024 3:53 AM, Mikko wrote:

On 2024-08-15 15:25:07 +0000, olcott said:

On 8/15/2024 5:22 AM, Mikko wrote:

On 2024-08-14 13:06:27 +0000, olcott said:

On 8/14/2024 3:17 AM, Mikko wrote:

On 2024-08-14 00:52:36 +0000, olcott said:

void DDD()
{
   HHH(DDD);
   return;
}

In order to prove that the above specifies a non-halting behavour
you must prove that HHH(DDD) does not terminate.

Wrong.

At least the proof that DDD does not terminate also proves as an
intermedate result or an obvious corollary that HHH does not halt.

Non-halting means that an infinite number of instructions can be
executed without halting. That means that at least one instruction
is executed infinitely many times as there are only finitely many
instructions. But not instrunctions of DDD outside HHH is executed
infinitely many times.

Wrong. Non-halting only means that when DDD is emulated
according to the semantics of the x86 language and this
emulation is unlimited that DDD would never reach its
own "return" instruction.

If what I said is wrong then what you said is wrong, too,
as you say what I said.

*You are getting the computer science incorrectly*

On 8/2/2024 11:32 PM, Jeff Barnett wrote:

...In some formulations, there are specific states
defined as "halting states" and the machine only
halts if either the start state is a halt state...

These formulations have the problem that it is possible that
a computation reaches a state where the computation shall not
halt and cannot be continued. Therefore most authors prefer a
simpler formulation (introduced by Post) where halting simply
means impossibility to continue. For x86 processors the best
definition is that a computation halts when the SP register
gets a value that is greater than its value at the start of
the computation (in x86 processors the stack grows downwards
to smaller addresses).

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)