XPost: sci.logic

On 6/22/24 10:11 AM, olcott wrote:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

On 6/22/2024 3:05 AM, Mikko wrote:

On 2024-06-21 13:19:28 +0000, olcott said:

On 6/21/2024 2:11 AM, Mikko wrote:

On 2024-06-20 15:23:09 +0000, olcott said:

On 6/20/2024 10:08 AM, Mikko wrote:

On 2024-06-20 05:40:28 +0000, olcott said:

On 6/20/2024 12:29 AM, Mikko wrote:

On 2024-06-19 14:05:29 +0000, olcott said:

On 6/19/2024 4:29 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 6/18/2024 4:36 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:

Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:

void DDD()
{
H0(DDD);
}
DDD correctly simulated by any H0 cannot possibly halt. >>>>>>>>>>>>>>>>>> DDD halts iff H0 halts.

So H0 returns "doesn't halt" to DDD, which then stops >>>>>>>>>>>>>>>> running,
so H0 should have returned "halts".

This was three messages ago.
I had to make sure that you understood that halting >>>>>>>>>>>>>>> does not mean stopping for any reason and only includes >>>>>>>>>>>>>>> the equivalent of terminating normally.

No.  You're wrong, here.  A turing machine is either >>>>>>>>>>>>>> running or it's
halted.  There's no third alternative.  If your C programs >>>>>>>>>>>>>> are not in one
of these two states, they're not equivalent to turing >>>>>>>>>>>>>> machines.

Although I agree with this there seems to be nuances of >>>>>>>>>>>>> disagreement across the experts.

I doubt that very much.  The whole point of turing machines >>>>>>>>>>>> is to remove
ambiguity and unneeded features from the theory of
computation.  A third
alternative state is unneeded.

Some people say that a TM can halt in a non-final state.

People may use different words to express the same facts. What >>>>>>>>>> some
people call "halting in a non-final state" is called
"rejecting" by
some other people. But the facts are what they are
independently of
the words used to express them.

Ambiguity and vagueness make communication less effective.

As does use of common words and expressions for uncommon meanings. >>>>>>>>

I use C because there are zero gaps in exactly what it means. >>>>>>>>

THere are lont of gaps in C. Some are mistakes that are
corrected in
technical corrigenda. Others are undefined and implementation
defined
behaviour. Your program uses non-standard extensions to C so it >>>>>>>> does
not communicate well. If also is too big to be a part of a
publishable
article.

*There are zero gaps in the behavior of DDD correctly simulated
by HH0*
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf

_DDD()
[00002093] 55               push ebp
[00002094] 8bec             mov ebp,esp
[00002096] 6893200000       push 00002093 ; push DDD
[0000209b] e853f4ffff       call 000014f3 ; call HH0
[000020a0] 83c404           add esp,+04
[000020a3] 5d               pop ebp
[000020a4] c3               ret
Size in bytes:(0018) [000020a4]

Whereas the Linz specification of Ĥ says that embedded_H
does something or other that is totally unspecified:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz Ĥ is fully defined in terms of H, so its behaviour can be
inferred
from the behaviour of H. Therefore Linz can prove about the
behaviour of
both Ĥ and H what needs be proven.

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation

Linz says nothing about simulations

I am the sole inventor of the simulating halt decider.

Ben Bacarisse contacted professor Sipser to verify that he
really did says this. The details are in this forum about
the same date.

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/

<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>

And, as I remember, he also verified that he disagrees with your
definition of correct simulation.

*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Right, Ben was willing to do what I am not that you can prove that, by
your definition, H can show that it "must" abort its simulation or the
input will run forever.

But, just like me, he also agrees that this is NOT the defintion of
Halting, so H is just shown to be a correct (partial) POOP decider but
ot a Halt Decider, not even for that one input.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

He knows and accepts that P(P) actually does stop. The
wrong answer is justified by what would happen if H
(and hence a different P) where not what they actually are.

*Ben agrees that the criteria is met for the input*

Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output* https://en.wikipedia.org/wiki/Computable_function

*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*

No, you don't understand the words he is using because you have
distroted the meaning of too many words.

He is agreeing that H can correctly decide the POOP criteria, the it can
say that "no H can correctly simulate that input to a final state", but
he does NOT agree that it means it doesn't HALT, because that isn't the
meaning of Halting, and your definition of Correct Simulation isn't what Professor Sipser was using, so you can't use that.

So, you are just stuck in your lies.

void DDD()
{
  HHH0(DDD);
}

int main()
{
  Output("Input_Halts = ", HHH0(DDD));
  Output("Input_Halts = ", HHH1(DDD));
}

It is a verified fact that the behavior that finite string DDD
presents to HH0 is that when DDD correctly simulated by HH0
calls HH0(DDD) that this call DOES NOT RETURN.

It is a verified fact that the behavior that finite string DDD
presents to HH1 is that when DDD correctly simulated by HH1
calls HH0(DDD) that this call DOES RETURN.

*I don't get why people here insist on lying about verified facts*

The problem is that the "behavior" that the finite string DDD presents
to HH0, is DEFINED by the problem. And if that problem is the Halting
Problem, that behavior is the behavior of the machine the input
represents. If HH0 treats the input as having a different behavior, then
HH0 just isn't a Halting Decider, but something else.

If HH0 is supposed to be a Halting decider, but uses a method that makes
it see something other than that behavior, then it is just an incorrect
Halting Decider, and its algorithm just creates an incorrect recreation
of the property of the input it is supposed to be working on.


A bit of a side note, the actual "Input" to HH0, is a pointer to memory,
and as such it passes a reference to ALL of memory considering the
starting point to be that address, so your "Input" isn't actually the
few bytes of DDD, but ALL of memory and a starting point. If you
actually mean that the input is just those few bytes pointed to by the
address, then the input is improperly formed and is NOT a proper
representation of the input machine, becuase it is incomplete.

The fact you don't understand this, seems to imply you are lacking the
basic knowledge to be talking about this sort of thing.

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

XPost: sci.logic

Am Sat, 22 Jun 2024 09:11:28 -0500 schrieb olcott:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

On 6/22/2024 3:05 AM, Mikko wrote:

On 2024-06-21 13:19:28 +0000, olcott said:

On 6/21/2024 2:11 AM, Mikko wrote:

On 2024-06-20 15:23:09 +0000, olcott said:

On 6/20/2024 10:08 AM, Mikko wrote:

On 2024-06-20 05:40:28 +0000, olcott said:

On 6/20/2024 12:29 AM, Mikko wrote:

On 2024-06-19 14:05:29 +0000, olcott said:

On 6/19/2024 4:29 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 6/18/2024 4:36 PM, Alan Mackenzie wrote:

In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:

Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:

I use C because there are zero gaps in exactly what it means. >>>>>>>>

THere are lont of gaps in C. Some are mistakes that are corrected >>>>>>>> in technical corrigenda. Others are undefined and implementation >>>>>>>> defined behaviour. Your program uses non-standard extensions to C >>>>>>>> so it does not communicate well. If also is too big to be a part >>>>>>>> of a publishable article.

*There are zero gaps in the behavior of DDD correctly simulated by >>>>>>> HH0*

That is a completely different statement. Still wrong, as HH0 can't
simulate itself.

Linz Ĥ is fully defined in terms of H, so its behaviour can be
inferred from the behaviour of H. Therefore Linz can prove about
the behaviour of both Ĥ and H what needs be proven.

Ben Bacarisse contacted professor Sipser to verify that he really did
says this. The details are in this forum about the same date.

And, as I remember, he also verified that he disagrees with your
definition of correct simulation.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H (it's
trivial to do for this one case) that correctly determines that
P(P) *would* never stop running *unless* aborted.

Right, Ben was willing to do what I am not that you can prove that, by
your definition, H can show that it "must" abort its simulation or the
input will run forever.
But, just like me, he also agrees that this is NOT the defintion of
Halting, so H is just shown to be a correct (partial) POOP decider but
ot a Halt Decider, not even for that one input.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

He knows and accepts that P(P) actually does stop. The wrong answer
is justified by what would happen if H (and hence a different P)
were not what they actually are.

*Ben agrees that the criteria is met for the input*
*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs *DO NOT
COUNT*

The input is always just DDD, along with its embedded "decider".

void DDD()
{
HHH0(DDD);
}
int main()
{
Output("Input_Halts = ", HHH0(DDD));
Output("Input_Halts = ", HHH1(DDD));
}

It is a verified fact that the behavior that finite string DDD presents
to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that
this call DOES NOT RETURN.

Making DDD's halting undecidable.

It is a verified fact that the behavior that finite string DDD presents
to HH1 is that when DDD correctly simulated by HH1 calls HH0(DDD) that
this call DOES RETURN.

This is the correct behaviour.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

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

XPost: sci.logic

On 6/22/24 10:42 AM, olcott wrote:

On 6/22/2024 9:20 AM, Richard Damon wrote:

On 6/22/24 10:11 AM, olcott wrote:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/

<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> >>>>

And, as I remember, he also verified that he disagrees with your
definition of correct simulation.

*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Right, Ben was willing to do what I am not that you can prove that,
by your definition, H can show that it "must" abort its simulation
or the input will run forever.

But, just like me, he also agrees that this is NOT the defintion of
Halting, so H is just shown to be a correct (partial) POOP decider
but ot a Halt Decider, not even for that one input.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
;
He knows and accepts that P(P) actually does stop. The
wrong answer is justified by what would happen if H
(and hence a different P) where not what they actually are.
;

*Ben agrees that the criteria is met for the input*

Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function

*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*

No, you don't understand the words he is using because you have
distroted the meaning of too many words.

He is agreeing that H can correctly decide the POOP criteria, the it can

The criteria that professor Sipser agreed is correct
and agreed that I can quote his agreement.

say that "no H can correctly simulate that input to a final state",
but he does NOT agree that it means it doesn't HALT,

And the ONLY meaning that Professor Sipser has for "Correctly Simulate"
is a simulation that EXACTLY reproduces the behavior of the input, and
that means doesn't abort. Which H doesn't do.

Also, the input to a Halt Decider is the representation of a COMPLETE
PROGRAM, so in your case, the D specifies an exact H that it uses.

So, when you use his statement to "change H", you change JUST the H
doing the deciding, and NOT the H that is used by D, that is still the
original H.

When we do this, your hypothetical H doing the simulating WILL SEE (if
it runs long enough) the simulate original-H deciding it can use the
criteria to abort, and then return 0 to the D that called it and D halting.

Thus, original-H is INCORRECT in thinking that it can correctly decide
that "NO H" can never correctly simulate THIS INPUT to a final state, as
some alternate Hs can.

He also agreed that

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.

But only if it proved the first step.

*So yet again you try to get away with denying verified facts*
and are busted.

Nope, your lies are exposed an YOU are busted.

You fundamentally don't understand the rules of the game you are trying
to play, and keep on making illegal moves and complaing that the other
player, who does know the rules, is cheating by not letting you make the illegal moves.

because that isn't the meaning of Halting, and your definition of
Correct Simulation isn't what Professor Sipser was using, so you can't
use that.

So, you are just stuck in your lies.

void DDD()
{
   HHH0(DDD);
}

int main()
{
   Output("Input_Halts = ", HHH0(DDD));
   Output("Input_Halts = ", HHH1(DDD));
}

It is a verified fact that the behavior that finite string DDD
presents to HH0 is that when DDD correctly simulated by HH0
calls HH0(DDD) that this call DOES NOT RETURN.

It is a verified fact that the behavior that finite string DDD
presents to HH1 is that when DDD correctly simulated by HH1
calls HH0(DDD) that this call DOES RETURN.

*I don't get why people here insist on lying about verified facts*

The problem is that the "behavior" that the finite string DDD presents
to HH0, is DEFINED by the problem.

*Not not at all, not in the least little bit*

No textbook is allowed to override and supersede
the semantics of the x86 programming language.

So, what in the x86 programming language says ANYTHING about "Halt
Deciding"? (citation please, or you admit to making that up)

And, as has been shown, the ACTUAL behavior of a correct simulation of
the x86 code EXACTLY REPRODUCES the behavior of the input directly
executed. The "difference" you see are when you don't actually simulate
an instruction by try to argue (incorrectly) what it must be the
equivalent of.,

for instance, a CALL H instruction, since H WILL return 0 when directly
called, WILL eventally see a return with the value of 0.

The fact the simulator can't simulate to that point for any version of H
you try to make doesn't change that behavior, it just means that no H
can KNOW what the will do before it decides it needs to stop to give an
answer.

it can't just assume it will not return, THAT is incorrect logic.

Unlike you this does seem to be an honest mistake
on their part.

Nope, just shows you don't know what you are talking about.

 And if that problem is the Halting Problem, that behavior is the
behavior of the machine the input represents.

Some abstract idea that contradicts the semantics of the x86
programming language IS WRONG.

I have had enough of your willful deception for one post.

If HH0 treats the input as having a different behavior, then HH0 just
isn't a Halting Decider, but something else.

If HH0 is supposed to be a Halting decider, but uses a method that
makes it see something other than that behavior, then it is just an
incorrect Halting Decider, and its algorithm just creates an incorrect
recreation of the property of the input it is supposed to be working on.


A bit of a side note, the actual "Input" to HH0, is a pointer to
memory, and as such it passes a reference to ALL of memory considering
the starting point to be that address, so your "Input" isn't actually
the few bytes of DDD, but ALL of memory and a starting point. If you
actually mean that the input is just those few bytes pointed to by the
address, then the input is improperly formed and is NOT a proper
representation of the input machine, becuase it is incomplete.

The fact you don't understand this, seems to imply you are lacking the
basic knowledge to be talking about this sort of thing.

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

On 2024-06-22 14:11:28 +0000, olcott said:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

On 6/22/2024 3:05 AM, Mikko wrote:

On 2024-06-21 13:19:28 +0000, olcott said:

On 6/21/2024 2:11 AM, Mikko wrote:

On 2024-06-20 15:23:09 +0000, olcott said:

On 6/20/2024 10:08 AM, Mikko wrote:

On 2024-06-20 05:40:28 +0000, olcott said:

On 6/20/2024 12:29 AM, Mikko wrote:

On 2024-06-19 14:05:29 +0000, olcott said:

On 6/19/2024 4:29 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 6/18/2024 4:36 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 6/18/2024 12:57 PM, joes wrote:

Am Tue, 18 Jun 2024 12:25:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 6/18/2024 12:06 PM, joes wrote:

void DDD()
{
H0(DDD);
}
DDD correctly simulated by any H0 cannot possibly halt. >>>>>>>>>>>>>>>>>> DDD halts iff H0 halts.

So H0 returns "doesn't halt" to DDD, which then stops running, >>>>>>>>>>>>>>>> so H0 should have returned "halts".

This was three messages ago.
I had to make sure that you understood that halting >>>>>>>>>>>>>>> does not mean stopping for any reason and only includes >>>>>>>>>>>>>>> the equivalent of terminating normally.

No.  You're wrong, here.  A turing machine is either running or it's
halted.  There's no third alternative.  If your C programs are not in one
of these two states, they're not equivalent to turing machines. >>>>>>>>>>>>

Although I agree with this there seems to be nuances of >>>>>>>>>>>>> disagreement across the experts.

I doubt that very much.  The whole point of turing machines is to remove
ambiguity and unneeded features from the theory of computation.  A third
alternative state is unneeded.

Some people say that a TM can halt in a non-final state.

People may use different words to express the same facts. What some >>>>>>>>>> people call "halting in a non-final state" is called "rejecting" by >>>>>>>>>> some other people. But the facts are what they are independently of >>>>>>>>>> the words used to express them.

Ambiguity and vagueness make communication less effective.

As does use of common words and expressions for uncommon meanings. >>>>>>>>

I use C because there are zero gaps in exactly what it means. >>>>>>>>

THere are lont of gaps in C. Some are mistakes that are corrected in >>>>>>>> technical corrigenda. Others are undefined and implementation defined >>>>>>>> behaviour. Your program uses non-standard extensions to C so it does >>>>>>>> not communicate well. If also is too big to be a part of a publishable >>>>>>>> article.

*There are zero gaps in the behavior of DDD correctly simulated by HH0* >>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf

_DDD()
[00002093] 55               push ebp
[00002094] 8bec             mov ebp,esp
[00002096] 6893200000       push 00002093 ; push DDD
[0000209b] e853f4ffff       call 000014f3 ; call HH0
[000020a0] 83c404           add esp,+04
[000020a3] 5d               pop ebp
[000020a4] c3               ret
Size in bytes:(0018) [000020a4]

Whereas the Linz specification of Ĥ says that embedded_H
does something or other that is totally unspecified:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz Ĥ is fully defined in terms of H, so its behaviour can be inferred >>>>>> from the behaviour of H. Therefore Linz can prove about the behaviour of >>>>>> both Ĥ and H what needs be proven.

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation

Linz says nothing about simulations

I am the sole inventor of the simulating halt decider.

Ben Bacarisse contacted professor Sipser to verify that he
really did says this. The details are in this forum about
the same date.

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/


<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>

And, as I remember, he also verified that he disagrees with your
definition of correct simulation.

*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Right, Ben was willing to do what I am not that you can prove that, by
your definition, H can show that it "must" abort its simulation or the
input will run forever.

But, just like me, he also agrees that this is NOT the defintion of
Halting, so H is just shown to be a correct (partial) POOP decider but
ot a Halt Decider, not even for that one input.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

He knows and accepts that P(P) actually does stop. The
wrong answer is justified by what would happen if H
(and hence a different P) where not what they actually are.

*Ben agrees that the criteria is met for the input*

Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output* https://en.wikipedia.org/wiki/Computable_function

*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*

In particular, you can't. You have insisted that your "decider"
or "anlyzer" (or whatever word you happen to use) H or HH (or
hwatever name you happen to use) must return false because a
non-input (where instead of the actually called function another
function that does not halt is called) does not halt.

void DDD()
{
HHH0(DDD);
}

int main()
{
Output("Input_Halts = ", HHH0(DDD));
Output("Input_Halts = ", HHH1(DDD));
}

It is a verified fact that the behavior that finite string DDD
presents to HH0 is that when DDD correctly simulated by HH0
calls HH0(DDD) that this call DOES NOT RETURN.

It is a verified fact that the behavior that finite string DDD
presents to HH1 is that when DDD correctly simulated by HH1
calls HH0(DDD) that this call DOES RETURN.

--
Mikko

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

On 2024-06-23 13:13:42 +0000, olcott said:

On 6/23/2024 2:57 AM, Mikko wrote:

On 2024-06-22 14:11:28 +0000, olcott said:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

I am the sole inventor of the simulating halt decider.

Ben Bacarisse contacted professor Sipser to verify that he
really did says this. The details are in this forum about
the same date.

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/


<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> >>>>

And, as I remember, he also verified that he disagrees with your
definition of correct simulation.

*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Right, Ben was willing to do what I am not that you can prove that, by >>>> your definition, H can show that it "must" abort its simulation or the >>>> input will run forever.

But, just like me, he also agrees that this is NOT the defintion of
Halting, so H is just shown to be a correct (partial) POOP decider but >>>> ot a Halt Decider, not even for that one input.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
;
He knows and accepts that P(P) actually does stop. The
wrong answer is justified by what would happen if H
(and hence a different P) where not what they actually are.
;

*Ben agrees that the criteria is met for the input*

Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function

*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*

In particular, you can't. You have insisted that your "decider"
or "anlyzer" (or whatever word you happen to use) H or HH (or
hwatever name you happen to use) must return false because a
non-input (where instead of the actually called function another
function that does not halt is called) does not halt.

You said it backwards. When I say that I am not guilty and did
not rob the liquor store you cannot paraphrase this as he admitted
that he robbed the liquor store.

The important qestion is not whether you admit but what the police
finds out.

H performs a sequence of finite string transformations on
its finite input of x86 machine code. These transformations
include that D calls H(D,D) while being simulated by H. In
such a case the call from D to H(D,D) cannot possibly return.

Which is all we need to know about H in ordet to determine that
it is not a decider.

--
Mikko

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

Am Mon, 24 Jun 2024 08:46:56 -0500 schrieb olcott:

On 6/24/2024 2:22 AM, Mikko wrote:

On 2024-06-23 13:13:42 +0000, olcott said:

On 6/23/2024 2:57 AM, Mikko wrote:

On 2024-06-22 14:11:28 +0000, olcott said:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

In particular, you can't. You have insisted that your "decider" or
"anlyzer" (or whatever word you happen to use) H or HH (or hwatever
name you happen to use) must return false because a non-input (where
instead of the actually called function another function that does
not halt is called) does not halt.

Which is all we need to know about H in ordet to determine that it is
not a decider.

void DDD()
{
H0(DDD);
}
The call from DDD to H0(DDD) when DDD is correctly emulated by H0 cannot possibly return.

Why not? H0 is a decider AND simulator, so it can simulate itself
terminating.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

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

joes <noreply@example.com> wrote:

[ .... ]

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik sind sie vollkommen nutzlos. --Wolfgang Mückenheim

Or, in English, "You can't do arithmetic with dark numbers. For actual mathematics, they're completely useless.".

Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of
the few remaining ones after Google shut down their Usenet servers in
February. He insists on the existence of something he calls "dark
numbers" and gives crank-like justifications for them, which do not hold
up under more robust questioning.

--
Alan Mackenzie (Nuremberg, Germany).

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

On 6/24/24 5:10 PM, olcott wrote:

On 6/24/2024 3:27 PM, Alan Mackenzie wrote:

joes <noreply@example.com> wrote:

[ .... ]

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche
Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

Or, in English, "You can't do arithmetic with dark numbers.  For actual
mathematics, they're completely useless.".

Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of
the few remaining ones after Google shut down their Usenet servers in
February.  He insists on the existence of something he calls "dark
numbers" and gives crank-like justifications for them, which do not hold
up under more robust questioning.

In my case people have been disagreeing with the semantics of
the x86 programming language for three years when they have
insisted that D correctly simulated by H must have the same
behavior as the directly executed D(D).

No, we fully understand its semantics.

Not sure you do, as you can't produce a trace by the decider that
correctly goes past the decider by the requirements to follow those
semantics.

*The following is a dumbed down version that is much more*
*difficult to rebut without looking foolish*

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see that
when DDD is correctly emulated by H0 that its call to H0(DDD)
cannot possibly return.

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

When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().

And the emulation by H0 and H1 will be IDETICAL to the point where H0
stops its emulation. This is a fundamental fact.

If you disagree, please show what instruction, CORRECTLY EMULATED per
the definition of the x86 instruction set, that is the point of divergance.

Your failure, for years to show this just indicate that you know you
claim is false, but need to hang onto it to try to fabricate a lie for
your false proof.

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

On 6/24/24 5:12 PM, olcott wrote:

On 6/24/2024 2:52 PM, joes wrote:

Am Mon, 24 Jun 2024 08:46:56 -0500 schrieb olcott:

On 6/24/2024 2:22 AM, Mikko wrote:

On 2024-06-23 13:13:42 +0000, olcott said:

On 6/23/2024 2:57 AM, Mikko wrote:

On 2024-06-22 14:11:28 +0000, olcott said:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

In particular, you can't. You have insisted that your "decider" or >>>>>> "anlyzer" (or whatever word you happen to use) H or HH (or hwatever >>>>>> name you happen to use) must return false because a non-input (where >>>>>> instead of the actually called function another function that does >>>>>> not halt is called) does not halt.

Which is all we need to know about H in ordet to determine that it is
not a decider.

void DDD()
{
    H0(DDD);
}
The call from DDD to H0(DDD) when DDD is correctly emulated by H0 cannot >>> possibly return.

Why not? H0 is a decider AND simulator, so it can simulate itself
terminating.

That is a stupid thing to say.
When H0 is called in recursive emulation the semantics of the x86
language do not allow H0 to simply ignore this and still terminate.

THe semantic of the x86 language do not talk at ALL about "recursion" or "emulation" as no instruction in the set needs to directly deal with
such things. Yes, you can build recursion emulation out of the
instrucitons, but that is a DERIVED property, not an innate one.

You just don't seem to understand such FACTS, perhaps because you don't
really understand the things you are trying to talk about.

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

On 6/24/24 9:46 AM, olcott wrote:

On 6/24/2024 2:22 AM, Mikko wrote:

On 2024-06-23 13:13:42 +0000, olcott said:

On 6/23/2024 2:57 AM, Mikko wrote:

On 2024-06-22 14:11:28 +0000, olcott said:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

I am the sole inventor of the simulating halt decider.

Ben Bacarisse contacted professor Sipser to verify that he
really did says this. The details are in this forum about
the same date.

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/

<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>

And, as I remember, he also verified that he disagrees with your
definition of correct simulation.

*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>>  > that P(P) *would* never stop running *unless* aborted.

Right, Ben was willing to do what I am not that you can prove
that, by your definition, H can show that it "must" abort its
simulation or the input will run forever.

But, just like me, he also agrees that this is NOT the defintion
of Halting, so H is just shown to be a correct (partial) POOP
decider but ot a Halt Decider, not even for that one input.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.
;
He knows and accepts that P(P) actually does stop. The
wrong answer is justified by what would happen if H
(and hence a different P) where not what they actually are.
;

*Ben agrees that the criteria is met for the input*

Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function

*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*

In particular, you can't. You have insisted that your "decider"
or "anlyzer" (or whatever word you happen to use) H or HH (or
hwatever name you happen to use) must return false because a
non-input (where instead of the actually called function another
function that does not halt is called) does not halt.

You said it backwards. When I say that I am not guilty and did
not rob the liquor store you cannot paraphrase this as he admitted
that he robbed the liquor store.

The important qestion is not whether you admit but what the police
finds out.

H performs a sequence of finite string transformations on
its finite input of x86 machine code. These transformations
include that D calls H(D,D) while being simulated by H. In
such a case the call from D to H(D,D) cannot possibly return.

Which is all we need to know about H in ordet to determine that
it is not a decider.

void DDD()
{
  H0(DDD);
}

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

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

So?

Can you PROVE it?

And why do we care, since it isn't what Halting is defined to be.

DDD does halt if H0 gives an answer.

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

Am Mon, 24 Jun 2024 16:10:00 -0500 schrieb olcott:

In my case people have been disagreeing with the semantics of the x86 programming language for three years when they have insisted that D
correctly simulated by H must have the same behavior as the directly
executed D(D).

What are the rules on how much a simulator can diverge from the actual behaviour of its input?

When we stipulate that the only measure of a correct emulation is the semantics of the x86 programming language then we see that when DDD is correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

With that I agree. It follows that H0 does not simulate correctly.

When we define H1 as identical to H0 except that DDD does not call H1
then we see that when DDD is correctly emulated by H1 that its call to H0(DDD) does return. This is the same behavior as the directly executed DDD().

That is the actual behaviour. If a simulator does something different,
it is wrong. A simulation does not change behaviour.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

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

On 2024-06-24 20:27:55 +0000, Alan Mackenzie said:

joes <noreply@example.com> wrote:

[ .... ]

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche
Mathematik> sind sie vollkommen nutzlos. --Wolfgang Mückenheim

Or, in English, "You can't do arithmetic with dark numbers. For actual mathematics, they're completely useless.".

Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of
the few remaining ones after Google shut down their Usenet servers in February. He insists on the existence of something he calls "dark
numbers" and gives crank-like justifications for them, which do not hold
up under more robust questioning.

From the first order Peano axioms it is not possible to prove that there
are no non-standard numbers. It is possible to construct (for example in
ZF) a model of the first order Peano arithmetic that has a proper subset
that is another model of the same Peano artichmetic. And it is possible
to do arithmetic with those numbers. Whether useful, I don't know.

--
Mikko

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

Op 24.jun.2024 om 23:10 schreef olcott:

On 6/24/2024 3:27 PM, Alan Mackenzie wrote:

joes <noreply@example.com> wrote:

[ .... ]

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche
Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

Or, in English, "You can't do arithmetic with dark numbers.  For actual
mathematics, they're completely useless.".

Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of
the few remaining ones after Google shut down their Usenet servers in
February.  He insists on the existence of something he calls "dark
numbers" and gives crank-like justifications for them, which do not hold
up under more robust questioning.

In my case people have been disagreeing with the semantics of
the x86 programming language for three years when they have
insisted that D correctly simulated by H must have the same
behavior as the directly executed D(D).

*The following is a dumbed down version that is much more*
*difficult to rebut without looking foolish*

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see that
when DDD is correctly emulated by H0 that its call to H0(DDD)
cannot possibly return.

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

When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().

And that is the correct behaviour that H0 should simulate as well, but
what it cannot do, showing that H0's simulation is incorrect.
You are faking that the disagreement is about the X86 programming
language, but the only point of disagreement is that you think that
aborting belongs to that language, but others think is does not.

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

Mikko <mikko.levanto@iki.fi> wrote:

On 2024-06-24 20:27:55 +0000, Alan Mackenzie said:

joes <noreply@example.com> wrote:

[ .... ]

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche
Mathematik> sind sie vollkommen nutzlos. --Wolfgang Mückenheim

Or, in English, "You can't do arithmetic with dark numbers. For actual
mathematics, they're completely useless.".

Wolfgang Mückenheim is a crank in sci.math and de.sci.mathematik, one of
the few remaining ones after Google shut down their Usenet servers in
February. He insists on the existence of something he calls "dark
numbers" and gives crank-like justifications for them, which do not hold
up under more robust questioning.

From the first order Peano axioms it is not possible to prove that there
are no non-standard numbers. It is possible to construct (for example in
ZF) a model of the first order Peano arithmetic that has a proper subset
that is another model of the same Peano artichmetic. And it is possible
to do arithmetic with those numbers. Whether useful, I don't know.

Yes. All that is over Wolfgang Mückenheim's head. He doesn't have a
degree in maths, but I believe he has a Phd in physics. His intuitions
in set theory are those of a rebellious teenager, and he refuses to
accept many established mathematical results. The threads he gets
involved in in sci.math feel similar to the threads in comp.theory
involving Peter Olcott.

Such people completely miss the fascination of surreal numbers, Robinson integers, and the rest. Other posters just wish they could get the
cranks to learn new (for them) things. Personally, I never learnt much
about mathematical logic and the foundations in my maths degree, but I
could catch up if I could be bothered, and I'm broadly aware of what I've missed. That distinguishes me from the cranks.

--
Mikko

--
Alan Mackenzie (Nuremberg, Germany).

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