On 8/28/2022 6:01 PM, olcott wrote:
> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>> On 8/28/2022 1:47 PM, olcott wrote:
>>
>> <SNIP> idiotic posted.
>>
>> Since you couldn't even write a TM that decides if a number, base one,
>> was even or odd, how do you justify a thread with this title?
>>
>
> I told you I was very sick from chemo therapy.
> Would it help my credibility if I finished this?
>
> I have been in the middle of fully translating
> my system to Linux. I have most of this done now.
Baby steps first. Baby steps first. There is no one who appears in these
insane threads you generate that gives a POOP about Linux or 32-bit
emulation, etc. Just baby steps. After you can walk, someone might take
an interest in your POOP if you can avoid all those errors - the
repetition for decades -- that you go for like a pig for POOP.
--
Jeff Barnett

On 8/28/22 9:30 PM, olcott wrote:
> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>
>> On 8/28/22 9:15 PM, olcott wrote:
>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>>> in the
>>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>>> these
>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>> ideas are
>>>>>>>>> incoherent.
>>>>>>>>>
>>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>>> implemented.
>>>>>>>>>
>>>>>>>>> void Px(ptr x)
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>> infinite recursion.
>>>>>>>>>
>>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>> physically impossible.
>>>>>>>>>
>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>> H(Px,Px)
>>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>>> call
>>>>>>>>> is executed.
>>>>>>>>>
>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>>> though the call to H is not even executed because all deciders
>>>>>>>>> must
>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>
>>>>>>>> Computer science is correct on this point, what is incorrect is
>>>>>>>> your
>>>>>>>> implementation of H.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>> So you are saying the a computer program that is never even executed
>>>>>>> must still return a result?
>>>>>>
>>>>>> The "result" of a program that never returns is None!
>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>
>>>>>> No problem - is just a definition.
>>>>>
>>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>>> function call from Px to H is never executed.
>>>>
>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>>
>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>>> determines.
>>>>
>>>
>>> You said that H must always return a result to its caller even if
>>> this call is never actually executed.
>>>
>>
>> You don't HAVE a caller unless you execute the call instruction.
>>
>> Do you really not know the meaning of this simple of a word?
>
> You are the one that said H is not a pure function thus not Turing
> computable on the basis that H(Px,Px) does not return a value to Px even
> though the call to H(Px,Px) is never executed.
>
> Are you admitting that you were wrong about this?
>

No, since Px DOES call H(Px,Px) the complete behavior of that input must
include that call and return.

As I have said, the PARTIAL simulation of H has no rules, and doesn't by
it self prove anything.

You don't seem to have a handle on reality.

The rule of all calls must return only applies to things that are REAL,
or accurate simulation.

H is perfectly fine in not simulating to the return, but it answer must
take into account that the complete simulation of its actual input WILL
have that return.

You seem to have this strange idea that just because H doesn't simulate
something that this means that the correct and complete simulation of
the input, which you agree is what defined the behavior, doesn't do it.

H, if it aborts, doesn't do a Complete simulation, so that partial
simulation is under no restrictions, just that any logic based on this
simulation needs to take the ACTUAL behavior into account.

Thus H needs to understand that Px(Px) calling H(Px,Px) must, in
reality, result in that H(Px,Px) eventually returning, thus showing tha
your claimed "infinite behavior pattern" (that you have never been able
to show is correct) is incorrect. That is the only logical conclusion.

You aren't allowed to just make up patterns.

On 8/28/22 9:21 PM, olcott wrote:
> On 8/28/2022 7:51 PM, Richard Damon wrote:
>> On 8/28/22 8:10 PM, olcott wrote:
>>> On 8/28/2022 7:02 PM, Richard Damon wrote:
>>>> On 8/28/22 7:54 PM, olcott wrote:
>>>>> On 8/28/2022 3:16 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/28/22 3:47 PM, olcott wrote:
>>>>>>> Since Turing machines are mathematical objects that only exist in
>>>>>>> the mind people can have contradictory thus incoherent ideas
>>>>>>> about these abstract mathematical objects and never realize that
>>>>>>> their ideas are incoherent.
>>>>>>
>>>>>> Please name ONE. If there is a contradiction, you should be able
>>>>>> to precisely state it, since the advantage of Mathematical objects
>>>>>> is they are very precisel defined.
>>>>>>
>>>>>>>
>>>>>>> When we study the theory of computation using physically existing
>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>> abstract ideas are shown to be incoherent in that they cannot be
>>>>>>> physically implemented.
>>>>>>
>>>>>> Yes, not all Mathematical idea can be physically implemented, like
>>>>>> a Halt Decider.
>>>>>>
>>>>>>>
>>>>>>> void Px(ptr x)
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H(Px, Px));
>>>>>>> }
>>>>>>>
>>>>>>> If a decider must always return a value whenever it is called
>>>>>>> this requires H to return a value to Px even though H is called
>>>>>>> in infinite recursion.
>>>>>>
>>>>>> As has been pointed out, it HASN'T been called in infinite Recursion.
>>>>>>
>>>>>> The ACTUAL BEHAVIOR of the ACTUAL INPUT is:
>>>>>>
>>>>>> (1) Px(Px) calls
>>>>>> (2) H(Px,Px) which simulates
>>>>>> (3) Px(Px) which it simulates to calling
>>>>>> (4) H(Px,Px)
>>>>>> (5) At this point (2) H(Px,Px) aborts its simulation and returns
>>>>>> to (1)
>>>>>> (6) The (1) Px(Px) getting an answer from (2) H(Px,Px) then Halts.
>>>>>>
>>>>>> So, no infinite recursion.
>>>>>>
>>>>>>>
>>>>>>> This even requires that the function call from Px to H(Px,Px)
>>>>>>> must return a value to Px even if this function call to H is not
>>>>>>> even executed. In the physical model of computation it is an
>>>>>>> axiom the programs that are not executed never return values
>>>>>>> because it is physically impossible.
>>>>>>
>>>>>> Where is this requirement?
>>>>>>
>>>>>>>
>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>> H(Px,Px) in infinite recursion H aborts its simulation of Px
>>>>>>> before this call is executed.
>>>>>>
>>>>>> No it sees a call from Px(Px) to H(Px,Px) that it decides
>>>>>> (INCORRECTLY) will cause infinite recursion so H aborts its
>>>>>> simulation, as programmed.
>>>>>>
>>>>>> There is actually no infinite recursion, only faulty logic. The
>>>>>> lack of infinite recursion was shows above. H only decides on
>>>>>> infinite recursion becuase it was given a faulty rule to use.
>>>>>>
>>>>>> Yes, it is because of that faulty logic/rule that the input halts,
>>>>>> but without the faulty logic H will just fail to answer, so fails
>>>>>> to meet its requirements.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>> though the call to H is not even executed because all deciders
>>>>>>> must ALWAYS return to their caller.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> No, YOU are incorrect on this point.
>>>>>>
>>>>>> And WHERE was the requirement for H to return a value to Px
>>>>>> without a call to H?
>>>>>
>>>>> That came from you. You said that H must always return to Px even
>>>>> in the case when H(Px,Px) aborts its simulation of Px before Px
>>>>> executes its call to H(Px,Px).
>>>>>
>>>>
>>>> Yes, the COMPLETE simulation of the input will see that call and
>>>> return, yes. If it saw the Call, it will see the Return.
>>>>
>>>
>>> So you are saying that UTM(Px,Px) will return to Px?
>>
>> No, but thst wasn't the definition of Px.
>>
>
> void Px(ptr x)
> {
>   int Halt_Status = UTM(x, x);
>   return;
> }

L IIIII EEEEE
L I E
L I E
L I EEEEE
L I E
L I E
LLLLL IIIII EEEEE

That was NOT the definition of Px.

>
> Then you are contradicting yourself. You said that only a UTM provides a
> COMPLETE simulation and now you are disagreeing with what you said.

No, but that isn't how you do the UTM simulation.

The UTM simulation is NOT put "into" the computation, it can't be,
because then H can't meet its requirement.

You just run UTM(Px,Px) as its own process, or a seperate call from main.

>
> A complete simulation of the input to H(Px,Px) is only possible if H is
> replaced by a UTM. If H is not replaced by a UTM then a complete
> simulation of the inpit to H(Px,Px) is not possible.
>

Nope. You are an IDIOT.

I think you need to go back to High School Programing class.

Maybe Elementary School these days.

I showed you the program:

void Px(ptr x)
{ H(x,x);
return;
}

int main()
{ Output("Input Halts = ", H(Px,Px));
UTM(Px,Px);
Output(" And Px(Px) actually Halts");
}

The call to H in main gets the answer that H provides.

The call to UTM afterwards sees if the input to H(Px,Px) will halt when
properly simulated.

On 8/28/22 9:50 PM, olcott wrote:
> On 8/28/2022 7:02 PM, Richard Damon wrote:
>> On 8/28/22 7:54 PM, olcott wrote:
>>> On 8/28/2022 3:16 PM, Richard Damon wrote:
>>>>
>>>> On 8/28/22 3:47 PM, olcott wrote:
>>>>> Since Turing machines are mathematical objects that only exist in
>>>>> the mind people can have contradictory thus incoherent ideas about
>>>>> these abstract mathematical objects and never realize that their
>>>>> ideas are incoherent.
>>>>
>>>> Please name ONE. If there is a contradiction, you should be able to
>>>> precisely state it, since the advantage of Mathematical objects is
>>>> they are very precisel defined.
>>>>
>>>>>
>>>>> When we study the theory of computation using physically existing
>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>> implemented.
>>>>
>>>> Yes, not all Mathematical idea can be physically implemented, like a
>>>> Halt Decider.
>>>>
>>>>>
>>>>> void Px(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H(Px, Px));
>>>>> }
>>>>>
>>>>> If a decider must always return a value whenever it is called this
>>>>> requires H to return a value to Px even though H is called in
>>>>> infinite recursion.
>>>>
>>>> As has been pointed out, it HASN'T been called in infinite Recursion.
>>>>
>>>> The ACTUAL BEHAVIOR of the ACTUAL INPUT is:
>>>>
>>>> (1) Px(Px) calls
>>>> (2) H(Px,Px) which simulates
>>>> (3) Px(Px) which it simulates to calling
>>>> (4) H(Px,Px)
>>>> (5) At this point (2) H(Px,Px) aborts its simulation and returns to (1)
>>>> (6) The (1) Px(Px) getting an answer from (2) H(Px,Px) then Halts.
>>>>
>>>> So, no infinite recursion.
>>>>
>>>>>
>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>> return a value to Px even if this function call to H is not even
>>>>> executed. In the physical model of computation it is an axiom the
>>>>> programs that are not executed never return values because it is
>>>>> physically impossible.
>>>>
>>>> Where is this requirement?
>>>>
>>>>>
>>>>> When simulating halt decider H sees that Px is about to call
>>>>> H(Px,Px) in infinite recursion H aborts its simulation of Px before
>>>>> this call is executed.
>>>>
>>>> No it sees a call from Px(Px) to H(Px,Px) that it decides
>>>> (INCORRECTLY) will cause infinite recursion so H aborts its
>>>> simulation, as programmed.
>>>>
>>>> There is actually no infinite recursion, only faulty logic. The lack
>>>> of infinite recursion was shows above. H only decides on infinite
>>>> recursion becuase it was given a faulty rule to use.
>>>>
>>>> Yes, it is because of that faulty logic/rule that the input halts,
>>>> but without the faulty logic H will just fail to answer, so fails to
>>>> meet its requirements.
>>>>
>>>>
>>>>>
>>>>> *Clearly computer science is incorrect on this point*
>>>>> Computer science says that H must still return a value to Px even
>>>>> though the call to H is not even executed because all deciders must
>>>>> ALWAYS return to their caller.
>>>>>
>>>>>
>>>>
>>>> No, YOU are incorrect on this point.
>>>>
>>>> And WHERE was the requirement for H to return a value to Px without
>>>> a call to H?
>>>
>>> That came from you. You said that H must always return to Px even in
>>> the case when H(Px,Px) aborts its simulation of Px before Px executes
>>> its call to H(Px,Px).
>>>
>>
>> Yes, the COMPLETE simulation of the input will see that call and
>> return, yes. If it saw the Call, it will see the Return.
> In what exact case do you imagine that H(Px,Px) returns a value to its
> simulated input?
>
>

You are just showing youself to be an idiot agian.

The simulator NEVER "returns" a value to something it is simulating, it
just simulates what that input says to do.

Note, this is one problem with you H intecepting calls to H, you get the
roles of the siulator and the simulated mixed up, and need to be VERY
carefull to keep things straight.

EVERY call to H(Px,Px) that H comes to, it needs to consider that the
correct and complete simulation WILL return 0 to the caller (whether H
actually simulates that call or not).

On 8/28/2022 8:53 PM, Jeff Barnett wrote:
> On 8/28/2022 6:01 PM, olcott wrote:
>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>
>>> <SNIP> idiotic posted.
>>>
>>> Since you couldn't even write a TM that decides if a number, base
>>> one, was even or odd, how do you justify a thread with this title?
>>>
>>
>> I told you I was very sick from chemo therapy.
>> Would it help my credibility if I finished this?
>>
>> I have been in the middle of fully translating
>> my system to Linux. I have most of this done now.
> Baby steps first. Baby steps first. There is no one who appears in these
> insane threads you generate that gives a POOP about Linux or 32-bit
> emulation, etc. Just baby steps. After you can walk, someone might take
> an interest in your POOP if you can avoid all those errors - the
> repetition for decades -- that you go for like a pig for POOP.
> --
> Jeff Barnett

I have correctly refuted every rebuttal of my work.

The problem is that all of the rebuttals depend on the words of computer
science textbooks as if these words were the infallible word of God and
my words are dismissed out-of-hand without review.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/28/22 9:27 PM, olcott wrote:
> On 8/28/2022 7:53 PM, Richard Damon wrote:
>> On 8/28/22 8:01 PM, olcott wrote:
>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>
>>>> <SNIP> idiotic posted.
>>>>
>>>> Since you couldn't even write a TM that decides if a number, base
>>>> one, was even or odd, how do you justify a thread with this title?
>>>>
>>>
>>> I told you I was very sick from chemo therapy.
>>> Would it help my credibility if I finished this?
>>>
>>> I have been in the middle of fully translating
>>> my system to Linux. I have most of this done now.
>>>
>>>
>>
>> It might let you see where your problem is.
>>
>> You seem very good at getting yourself side tracked from doing the
>> actually important things.
>
> If people were to simply review my work objectively without the bias
> that I must be wrong they would see that I am correct.

THe problem is that people HAVE objectively reviewed your work, but you
refuse to objectively look at the response.

>
> The problem is that they review my work on the basis of dogma that they
> take as infallible thus refuse to seriously consider the reasoning that
> proves this dogma is incorrect.

Note "Dogma", but FACTS and DEFINTIONS.

>
> Textbooks say that H(P,P) must be based on the behavior of P(P).

As it must.

>
> Correct reasoning says that H(P,P) must be based on the behavior of the
> correct simulation of the input to H in the hypothetical case where H
> never aborted the simulation of its input.

And that reasoning is WRONG.

Try to PROVE your assertion.

Note, the problem statement says that H is deciding on the actual
behavior of the machine provided as the input.

If you aren't answering that question, you aren't doing the problem.

This is where you end up working on POOP instead of the Halting Problem.

>
> Because the dogma is considered to be the infallible word of God the
> correct reasoning is dismissed out-of-hand without review.
>

the "DOGMA" goes by the DEFINITIONS.

Don't follow the defintions, then you just ARE WRONG.

There is room for novilty, and being creative, but you still need to
follow the basic rules and definition that define the problem.

To show that the Halting THeorem is Wrong, you need to be working on the
same Halting Problem as it is based on, and that includes the actual
test to determine Halting.

If you come up with another definition that EXACTLY matches the behavior
of that one, fine, you can use it. That is where the UTM version of the
problem comes from. (Note, that doesn't say replace H with a UTM, it
says as a INDEPENDENT computiton compute UTM(P,d) and compare that
result to the answer that H(P,d) gave.

Note, the answer that H(P,d) gives can't be a function of ANYTHING other
than P and d, so it doesn't matter who/what invokes that function, it
needs to return the same answer every time.

On 8/28/2022 8:19 PM, Richard Damon wrote:
>
> On 8/28/22 9:15 PM, olcott wrote:
>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>> On 8/28/22 8:07 PM, olcott wrote:
>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>> in the
>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>> these
>>>>>>>> abstract mathematical objects and never realize that their ideas
>>>>>>>> are
>>>>>>>> incoherent.
>>>>>>>>
>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>> implemented.
>>>>>>>>
>>>>>>>> void Px(ptr x)
>>>>>>>> {
>>>>>>>> H(x, x);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>> infinite recursion.
>>>>>>>>
>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>> programs that are not executed never return values because it is
>>>>>>>> physically impossible.
>>>>>>>>
>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>> H(Px,Px)
>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>> call
>>>>>>>> is executed.
>>>>>>>>
>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>> though the call to H is not even executed because all deciders must
>>>>>>>> ALWAYS return to their caller.
>>>>>>>
>>>>>>> Computer science is correct on this point, what is incorrect is your
>>>>>>> implementation of H.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> So you are saying the a computer program that is never even executed
>>>>>> must still return a result?
>>>>>
>>>>> The "result" of a program that never returns is None!
>>>>> This is equivalent of treating non-termination as an effect.
>>>>>
>>>>> No problem - is just a definition.
>>>>
>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>> function call from Px to H is never executed.
>>>
>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>
>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>> determines.
>>>
>>
>> You said that H must always return a result to its caller even if this
>> call is never actually executed.
>>

*Your next reply has already forgotten that you just said this*
*Your next reply has already forgotten that you just said this*
*Your next reply has already forgotten that you just said this*
*Your next reply has already forgotten that you just said this*

>
> You don't HAVE a caller unless you execute the call instruction.

H simulates Px until it reaches [0000110d] then it aborts its simulation
of Px before the first call to H(px,Px) is ever invoked from Px.

_Px()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](03) 8b4508 mov eax,[ebp+08]
[00001108](01) 50 push eax // push Px
[00001109](03) 8b4d08 mov ecx,[ebp+08]
[0000110c](01) 51 push ecx // push Px
[0000110d](05) e880fdffff call 00000e92 // call H
[00001112](03) 83c408 add esp,+08
[00001115](01) 5d pop ebp
[00001116](01) c3 ret
Size in bytes:(0021) [00001116]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/28/22 10:16 PM, olcott wrote:
> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>
>> On 8/28/22 9:15 PM, olcott wrote:
>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>>> in the
>>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>>> these
>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>> ideas are
>>>>>>>>> incoherent.
>>>>>>>>>
>>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>>> implemented.
>>>>>>>>>
>>>>>>>>> void Px(ptr x)
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>> infinite recursion.
>>>>>>>>>
>>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>> physically impossible.
>>>>>>>>>
>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>> H(Px,Px)
>>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>>> call
>>>>>>>>> is executed.
>>>>>>>>>
>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>>> though the call to H is not even executed because all deciders
>>>>>>>>> must
>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>
>>>>>>>> Computer science is correct on this point, what is incorrect is
>>>>>>>> your
>>>>>>>> implementation of H.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>> So you are saying the a computer program that is never even executed
>>>>>>> must still return a result?
>>>>>>
>>>>>> The "result" of a program that never returns is None!
>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>
>>>>>> No problem - is just a definition.
>>>>>
>>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>>> function call from Px to H is never executed.
>>>>
>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>>
>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>>> determines.
>>>>
>>>
>>> You said that H must always return a result to its caller even if
>>> this call is never actually executed.
>>>
>
> *Your next reply has already forgotten that you just said this*
> *Your next reply has already forgotten that you just said this*
> *Your next reply has already forgotten that you just said this*
> *Your next reply has already forgotten that you just said this*

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

You aren't even ready for beginner programming 101.

I said the COMPLETE SIMULATION would have this

>
>>
>> You don't HAVE a caller unless you execute the call instruction.
>
> H simulates Px until it reaches [0000110d] then it aborts its simulation
> of Px before the first call to H(px,Px) is ever invoked from Px.

Right, and the COMPLETE simulation of that input will see that after
that point, the execution trace will go into H, will trace it simulating
its input until that simulation reaches it simulating Px calling H, and
then this simulated H returning to the instruction after the call to H,
and then Px will shortly return and reach its final state.

Do you deny that?

That this would be what a call from main of UTM(Px,Px) would show?

Note, H DOESN'T DO a COMPLETE simulation, so you can't look at it for
the determination of Halting.

It might use some logic to determine it, but if that logic is valid,
then it will BY DEFINITION match the behavior of that ACUTAL complete
simulation of the ACTUAL input, i.e. the Px that calls H(Px,Px) as you
code shows.

>
> _Px()
> [00001102](01)  55             push ebp
> [00001103](02)  8bec           mov ebp,esp
> [00001105](03)  8b4508         mov eax,[ebp+08]
> [00001108](01)  50             push eax      // push Px
> [00001109](03)  8b4d08         mov ecx,[ebp+08]
> [0000110c](01)  51             push ecx      // push Px
> [0000110d](05)  e880fdffff     call 00000e92 // call H
> [00001112](03)  83c408         add esp,+08
> [00001115](01)  5d             pop ebp
> [00001116](01)  c3             ret
> Size in bytes:(0021) [00001116]
>
>
>

I guess you just don't understand the word complete.

Let me give you a hint.

You are proving yourself to be a COMPLETE IDIOT.

On 8/28/22 10:08 PM, olcott wrote:
> On 8/28/2022 8:53 PM, Jeff Barnett wrote:
>> On 8/28/2022 6:01 PM, olcott wrote:
>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>
>>>> <SNIP> idiotic posted.
>>>>
>>>> Since you couldn't even write a TM that decides if a number, base
>>>> one, was even or odd, how do you justify a thread with this title?
>>>>
>>>
>>> I told you I was very sick from chemo therapy.
>>> Would it help my credibility if I finished this?
>>>
>>> I have been in the middle of fully translating
>>> my system to Linux. I have most of this done now.
>> Baby steps first. Baby steps first. There is no one who appears in
>> these insane threads you generate that gives a POOP about Linux or
>> 32-bit emulation, etc. Just baby steps. After you can walk, someone
>> might take an interest in your POOP if you can avoid all those errors
>> - the repetition for decades -- that you go for like a pig for POOP.
>> --
>> Jeff Barnett
>
> I have correctly refuted every rebuttal of my work.

Nope. Maybe you think you have, but that only shows how STUPID you are.

>
> The problem is that all of the rebuttals depend on the words of computer
> science textbooks as if these words were the infallible word of God and
> my words are dismissed out-of-hand without review.
>

And you rely on words that have no source of Truth at all.

Note, the Textbooks DO state that ACTUAL definitions of what you are
tryig to do.

To Deny that is denying that you are actually working on what you claim
to be working on.

All you statement shows is that you are just a big fat liar, who doesn't
care what the actual definitions are of what he says he is doing, but
feels it is ok to do what ever he think might sound gud.

You are dumbed than Skep Dick, he at least shows signs that he knows
what are the actual rules, ad just tries to streach them.

You are just totally ignorant of what actually is.

On 8/28/2022 9:32 PM, Richard Damon wrote:
>
> On 8/28/22 10:16 PM, olcott wrote:
>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>
>>> On 8/28/22 9:15 PM, olcott wrote:
>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>>>> in the
>>>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>>>> these
>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>> ideas are
>>>>>>>>>> incoherent.
>>>>>>>>>>
>>>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>> abstract
>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>> physically
>>>>>>>>>> implemented.
>>>>>>>>>>
>>>>>>>>>> void Px(ptr x)
>>>>>>>>>> {
>>>>>>>>>> H(x, x);
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If a decider must always return a value whenever it is called
>>>>>>>>>> this
>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>> infinite recursion.
>>>>>>>>>>
>>>>>>>>>> This even requires that the function call from Px to H(Px,Px)
>>>>>>>>>> must
>>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>>> physically impossible.
>>>>>>>>>>
>>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>>> H(Px,Px)
>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>> this call
>>>>>>>>>> is executed.
>>>>>>>>>>
>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>>>> though the call to H is not even executed because all deciders
>>>>>>>>>> must
>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>
>>>>>>>>> Computer science is correct on this point, what is incorrect is
>>>>>>>>> your
>>>>>>>>> implementation of H.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>> executed
>>>>>>>> must still return a result?
>>>>>>>
>>>>>>> The "result" of a program that never returns is None!
>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>
>>>>>>> No problem - is just a definition.
>>>>>>
>>>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>>>> function call from Px to H is never executed.
>>>>>
>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>>>
>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that
>>>>> H determines.
>>>>>
>>>>
>>>> You said that H must always return a result to its caller even if
>>>> this call is never actually executed.
>>>>
>>
>> *Your next reply has already forgotten that you just said this*
>> *Your next reply has already forgotten that you just said this*
>> *Your next reply has already forgotten that you just said this*
>> *Your next reply has already forgotten that you just said this*
>
> Nope, you are just showing you don't know what you are talking about.
>
> You aren't even ready for beginner programming 101.
>
> I said the COMPLETE SIMULATION would have this
>
>>
>>>
>>> You don't HAVE a caller unless you execute the call instruction.
>>
>> H simulates Px until it reaches [0000110d] then it aborts its
>> simulation of Px before the first call to H(px,Px) is ever invoked
>> from Px.
>
> Right, and the COMPLETE simulation
We are not talking about that.
A decider must always return to its caller:
*ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY INVOKED*

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/28/2022 8:19 PM, Richard Damon wrote:
>
> On 8/28/22 9:15 PM, olcott wrote:
>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>> On 8/28/22 8:07 PM, olcott wrote:
>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>> in the
>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>> these
>>>>>>>> abstract mathematical objects and never realize that their ideas
>>>>>>>> are
>>>>>>>> incoherent.
>>>>>>>>
>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>> implemented.
>>>>>>>>
>>>>>>>> void Px(ptr x)
>>>>>>>> {
>>>>>>>> H(x, x);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>> infinite recursion.
>>>>>>>>
>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>> programs that are not executed never return values because it is
>>>>>>>> physically impossible.
>>>>>>>>
>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>> H(Px,Px)
>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>> call
>>>>>>>> is executed.
>>>>>>>>
>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>> though the call to H is not even executed because all deciders must
>>>>>>>> ALWAYS return to their caller.
>>>>>>>
>>>>>>> Computer science is correct on this point, what is incorrect is your
>>>>>>> implementation of H.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> So you are saying the a computer program that is never even executed
>>>>>> must still return a result?
>>>>>
>>>>> The "result" of a program that never returns is None!
>>>>> This is equivalent of treating non-termination as an effect.
>>>>>
>>>>> No problem - is just a definition.
>>>>
>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>> function call from Px to H is never executed.
>>>
>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>
>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>> determines.
>>>
>>
>> You said that H must always return a result to its caller even if this
>> call is never actually executed.
>>
>
> You don't HAVE a caller unless you execute the call instruction.

DON'T CHANGE THE SUBJECT
DON'T CHANGE THE SUBJECT
DON'T CHANGE THE SUBJECT

A decider must always return to its caller:
*ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 29/08/2022 01:01, olcott wrote:
> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>> On 8/28/2022 1:47 PM, olcott wrote:
>>
>> <SNIP> idiotic posted.
>>
>> Since you couldn't even write a TM that decides if a number, base one, was even or odd, how do you
>> justify a thread with this title?
>>
>
> I told you I was very sick from chemo therapy.
> Would it help my credibility if I finished this?

I rather doubt that, but there's a chance that you might /learn/ something about TMs and how they
are used if you completed Ben's program. Simply learning about TMs won't specifically help your
credibility though, unless it leads you to recognise the problems with your current claims and
withdraw them. That /would/ improve your credibility somewhat, but only in a "negative negative"
sort of way. (I'm guessing you'd still be claiming to have refuted all sorts of other things, which
would still mark you as a crank for most readers. And besides I don't see anything Ben is going to
try to teach you as likely to cause you to withdraw any of your claims.)

Just writing the one TM to decide even numbers in itself won't help your credibility much, because I
imagine most people are already prepared to believe you could do that with appropriate effort.

I've just had the thought that perhaps you believe people reject your claims because you lack
credibility as an expert : if only you "had more credibility" then the things you say would
transform magically from nonsense into correctly proven claims? That doesn't make ANY sense, but
perhaps its how you view the world... Are you thinking if you demonstrate a simple programming
task, your already spoken words will start being interpreted differently? That's not going to happen.

>
> I have been in the middle of fully translating
> my system to Linux. I have most of this done now.

None of that will further your goals of publishing in a reputable peer-reviewd journal ONE IOTA!
Neither will wasting the rest of your life arguing with people here in comp.theory! You will simply
die one day, then the world will just forget you (as it forgets 99.9999% of us...) and carry on.

Seriously - if your true aim is for your work to be remembered, you need to actually present it to a
publisher. Forget about porting stuff to Linux, or building exercise TMs or even arguing
interminably on comp.theory - unless really you're just looking to use up remaining time and bow out
comfortably... [the latter is actually not an unreasonable path for you]

Mike.

On 8/28/22 10:41 PM, olcott wrote:
> On 8/28/2022 9:32 PM, Richard Damon wrote:
>>
>> On 8/28/22 10:16 PM, olcott wrote:
>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>
>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>> exist in the
>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>> about these
>>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>>> ideas are
>>>>>>>>>>> incoherent.
>>>>>>>>>>>
>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>> existing
>>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>>> abstract
>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>> physically
>>>>>>>>>>> implemented.
>>>>>>>>>>>
>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> H(x, x);
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> If a decider must always return a value whenever it is called
>>>>>>>>>>> this
>>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>
>>>>>>>>>>> This even requires that the function call from Px to H(Px,Px)
>>>>>>>>>>> must
>>>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>>>> executed. In the physical model of computation it is an axiom
>>>>>>>>>>> the
>>>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>>>> physically impossible.
>>>>>>>>>>>
>>>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>>>> H(Px,Px)
>>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>>> this call
>>>>>>>>>>> is executed.
>>>>>>>>>>>
>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>> Computer science says that H must still return a value to Px
>>>>>>>>>>> even
>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>> deciders must
>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>
>>>>>>>>>> Computer science is correct on this point, what is incorrect
>>>>>>>>>> is your
>>>>>>>>>> implementation of H.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>>> executed
>>>>>>>>> must still return a result?
>>>>>>>>
>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>
>>>>>>>> No problem - is just a definition.
>>>>>>>
>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the when
>>>>>>> Px calls H(Px,Px) that H must return a value to Px even though
>>>>>>> this function call from Px to H is never executed.
>>>>>>
>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>> executed.
>>>>>>
>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that
>>>>>> H determines.
>>>>>>
>>>>>
>>>>> You said that H must always return a result to its caller even if
>>>>> this call is never actually executed.
>>>>>
>>>
>>> *Your next reply has already forgotten that you just said this*
>>> *Your next reply has already forgotten that you just said this*
>>> *Your next reply has already forgotten that you just said this*
>>> *Your next reply has already forgotten that you just said this*
>>
>> Nope, you are just showing you don't know what you are talking about.
>>
>> You aren't even ready for beginner programming 101.
>>
>> I said the COMPLETE SIMULATION would have this
>>
>>>
>>>>
>>>> You don't HAVE a caller unless you execute the call instruction.
>>>
>>> H simulates Px until it reaches [0000110d] then it aborts its
>>> simulation of Px before the first call to H(px,Px) is ever invoked
>>> from Px.
>>
>> Right, and the COMPLETE simulation
> We are not talking about that.
> A decider must always return to its caller:
> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY INVOKED*
>

Right, but Px invokes H(Px,Px) so a correct and complete simulation of
the input to H(Px,Px) will see the call and the return, and the fact
that Px halted.

You arguement seems to be that since H aborted its simulation (and thus
doesn't do a correct and complete simulation) means that the actual
behavior of that input never invoked H, while the actual behavior is
defined by the CORRECT AND COMPLETE simulation of the input, which DOES
invoke H and thus will see the return too.

Can't you see how silly your words are.

You seem to be implying that Px never calls H even though the code
clearly does.

You seem to be stuck on the fact that you want H to qualify as a correct
and complete simulation for your definition of halting, but it can't be
and meet the requirements of a decider. In your mind H seems to be a
Schrodinger function that works two different ways at the same time, but
that isn't allowed.

H needs to decide on the AcTUAL BEHAVIOR of the ACTUAL INPUT given to
it, and that input calls the H that does the aborting, and the AcTUAL
BEHAVIOR is to be determined by the CORRECT AND COMPLETE simulation of
the input to H, which H doesn't do.

This means that as a SEPARATE PROCESS, we evaluate UTM(Px,Px) and
compare it to the results returned by the defined code of H. THe code
for Px, including that of H, being exactly like that given to the input
of H(Px,Px) and the H that is doing this deciding.

Your refusal to understand this shows either a pathological avoidance of
the truth or a total ignorance of what you are suppposed to be doing.

I sort of think it is some of both. It has been clear that you do not
respect the truth, but you also show yourself to be woefully lacking in
your understanding of basic concept. At least some of this ignorance
appears to be intentionally inflicted to avoid being "correupted" by
incorrect ideas, which just means you are forcing yourself to not know
what you need to know to do what you want to do.

On 8/28/22 10:47 PM, olcott wrote:
> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>
>> On 8/28/22 9:15 PM, olcott wrote:
>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>>> in the
>>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>>> these
>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>> ideas are
>>>>>>>>> incoherent.
>>>>>>>>>
>>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>>> implemented.
>>>>>>>>>
>>>>>>>>> void Px(ptr x)
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>> infinite recursion.
>>>>>>>>>
>>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>> physically impossible.
>>>>>>>>>
>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>> H(Px,Px)
>>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>>> call
>>>>>>>>> is executed.
>>>>>>>>>
>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>>> though the call to H is not even executed because all deciders
>>>>>>>>> must
>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>
>>>>>>>> Computer science is correct on this point, what is incorrect is
>>>>>>>> your
>>>>>>>> implementation of H.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>> So you are saying the a computer program that is never even executed
>>>>>>> must still return a result?
>>>>>>
>>>>>> The "result" of a program that never returns is None!
>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>
>>>>>> No problem - is just a definition.
>>>>>
>>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>>> function call from Px to H is never executed.
>>>>
>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>>
>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>>> determines.
>>>>
>>>
>>> You said that H must always return a result to its caller even if
>>> this call is never actually executed.
>>>
>>
>> You don't HAVE a caller unless you execute the call instruction.
>
> DON'T CHANGE THE SUBJECT
> DON'T CHANGE THE SUBJECT
> DON'T CHANGE THE SUBJECT

I DIDN'T. I don't think you know what a subject is.

>
> A decider must always return to its caller:
> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*
>

So, you don't think that Px calls H?

You don't understand that correct simulation needs to match the actual
execution of the code being simulated?

And thus, the complete simulation of Px will call H, and thus the
complete simulation of Px will see H return to it?

I think you need a remedial English course.

On 8/28/22 10:57 PM, Mike Terry wrote:
> On 29/08/2022 01:01, olcott wrote:
>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>
>>> <SNIP> idiotic posted.
>>>
>>> Since you couldn't even write a TM that decides if a number, base
>>> one, was even or odd, how do you justify a thread with this title?
>>>
>>
>> I told you I was very sick from chemo therapy.
>> Would it help my credibility if I finished this?
>
> I rather doubt that, but there's a chance that you might /learn/
> something about TMs and how they are used if you completed Ben's
> program.  Simply learning about TMs won't specifically help your
> credibility though, unless it leads you to recognise the problems with
> your current claims and withdraw them.  That /would/ improve your
> credibility somewhat, but only in a "negative negative" sort of way.
> (I'm guessing you'd still be claiming to have refuted all sorts of other
> things, which would still mark you as a crank for most readers.  And
> besides I don't see anything Ben is going to try to teach you as likely
> to cause you to withdraw any of your claims.)
>
> Just writing the one TM to decide even numbers in itself won't help your
> credibility much, because I imagine most people are already prepared to
> believe you could do that with appropriate effort.
>
> I've just had the thought that perhaps you believe people reject your
> claims because you lack credibility as an expert : if only you "had more
> credibility" then the things you say would transform magically from
> nonsense into correctly proven claims?  That doesn't make ANY sense, but
> perhaps its how you view the world...  Are you thinking if you
> demonstrate a simple programming task, your already spoken words will
> start being interpreted differently?  That's not going to happen.
>
>>
>> I have been in the middle of fully translating
>> my system to Linux. I have most of this done now.
>
> None of that will further your goals of publishing in a reputable
> peer-reviewd journal ONE IOTA! Neither will wasting the rest of your
> life arguing with people here in comp.theory!  You will simply die one
> day, then the world will just forget you (as it forgets 99.9999% of
> us...) and carry on.
>
> Seriously - if your true aim is for your work to be remembered, you need
> to actually present it to a publisher.  Forget about porting stuff to
> Linux, or building exercise TMs or even arguing interminably on
> comp.theory - unless really you're just looking to use up remaining time
> and bow out comfortably... [the latter is actually not an unreasonable
> path for you]
>
>
> Mike.

My guess is that something in him KNOWS that if he just submits the
paper with what he currently has, it will just get rejected (it they
even bother to tell him it is rejected).

He seems desperate to try to find the right words that might let his
lies sneek past the reviews and get him published.

In a sense, his discussion here in comp.theory are just like him porting
his system to linux, a good excuse to delay getting to where he want to
be, because he knows subconsciously that if he actully get there he will
just fail.

On 8/28/2022 9:57 PM, Mike Terry wrote:
> On 29/08/2022 01:01, olcott wrote:
>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>
>>> <SNIP> idiotic posted.
>>>
>>> Since you couldn't even write a TM that decides if a number, base
>>> one, was even or odd, how do you justify a thread with this title?
>>>
>>
>> I told you I was very sick from chemo therapy.
>> Would it help my credibility if I finished this?
>
> I rather doubt that, but there's a chance that you might /learn/
> something about TMs and how they are used if you completed Ben's
> program.  Simply learning about TMs won't specifically help your
> credibility though, unless it leads you to recognise the problems with
> your current claims and withdraw them.  That /would/ improve your
> credibility somewhat, but only in a "negative negative" sort of way.
> (I'm guessing you'd still be claiming to have refuted all sorts of other
> things, which would still mark you as a crank for most readers.  And
> besides I don't see anything Ben is going to try to teach you as likely
> to cause you to withdraw any of your claims.)
>
> Just writing the one TM to decide even numbers in itself won't help your
> credibility much, because I imagine most people are already prepared to
> believe you could do that with appropriate effort.
>
> I've just had the thought that perhaps you believe people reject your
> claims because you lack credibility as an expert : if only you "had more
> credibility" then the things you say would transform magically from
> nonsense into correctly proven claims?  That doesn't make ANY sense, but
> perhaps its how you view the world...  Are you thinking if you
> demonstrate a simple programming task, your already spoken words will
> start being interpreted differently?  That's not going to happen.
>
>>
>> I have been in the middle of fully translating
>> my system to Linux. I have most of this done now.
>
> None of that will further your goals of publishing in a reputable
> peer-reviewd journal ONE IOTA! Neither will wasting the rest of your
> life arguing with people here in comp.theory!  You will simply die one
> day, then the world will just forget you (as it forgets 99.9999% of
> us...) and carry on.
>
> Seriously - if your true aim is for your work to be remembered, you need
> to actually present it to a publisher.  Forget about porting stuff to
> Linux, or building exercise TMs or even arguing interminably on
> comp.theory - unless really you're just looking to use up remaining time
> and bow out comfortably... [the latter is actually not an unreasonable
> path for you]
>
>
> Mike.

I can't possibly publish *UNTIL AFTER I AM UNDERSTOOD*

If people fully understood what I am saying then they would understand
that that the dogma of computer science textbooks that say that H(P,P)
must base its halt status decision on the behavior of P(P) is incorrect.

They have to very carefully to go through every single detail of my
explanation of exactly how and why it is incorrect and

*utterly stop short-circuiting to the dogma*
*utterly stop short-circuiting to the dogma*
*utterly stop short-circuiting to the dogma*

One of the ways that they short circuit is to say that it is a
definition thus cannot be incorrect. A definition can be incorrect
*only* when it directly contradicts other correct definitions.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/28/2022 10:01 PM, Richard Damon wrote:
> On 8/28/22 10:47 PM, olcott wrote:
>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>
>>> On 8/28/22 9:15 PM, olcott wrote:
>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>>>> in the
>>>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>>>> these
>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>> ideas are
>>>>>>>>>> incoherent.
>>>>>>>>>>
>>>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>> abstract
>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>> physically
>>>>>>>>>> implemented.
>>>>>>>>>>
>>>>>>>>>> void Px(ptr x)
>>>>>>>>>> {
>>>>>>>>>> H(x, x);
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If a decider must always return a value whenever it is called
>>>>>>>>>> this
>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>> infinite recursion.
>>>>>>>>>>
>>>>>>>>>> This even requires that the function call from Px to H(Px,Px)
>>>>>>>>>> must
>>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>>> physically impossible.
>>>>>>>>>>
>>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>>> H(Px,Px)
>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>> this call
>>>>>>>>>> is executed.
>>>>>>>>>>
>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>>>> though the call to H is not even executed because all deciders
>>>>>>>>>> must
>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>
>>>>>>>>> Computer science is correct on this point, what is incorrect is
>>>>>>>>> your
>>>>>>>>> implementation of H.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>> executed
>>>>>>>> must still return a result?
>>>>>>>
>>>>>>> The "result" of a program that never returns is None!
>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>
>>>>>>> No problem - is just a definition.
>>>>>>
>>>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>>>> function call from Px to H is never executed.
>>>>>
>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>>>
>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that
>>>>> H determines.
>>>>>
>>>>
>>>> You said that H must always return a result to its caller even if
>>>> this call is never actually executed.
>>>>
>>>
>>> You don't HAVE a caller unless you execute the call instruction.
>>
>> DON'T CHANGE THE SUBJECT
>> DON'T CHANGE THE SUBJECT
>> DON'T CHANGE THE SUBJECT
>
> I DIDN'T. I don't think you know what a subject is.
>
>>
>> A decider must always return to its caller:
>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*
>>
>
> So, you don't think that Px calls H?

The call to H(Px,Px) from P is never executed, thus H need not return to
Px.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/28/2022 6:01 PM, olcott wrote:
> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>> On 8/28/2022 1:47 PM, olcott wrote:
>>
>> <SNIP> idiotic posted.
>>
>> Since you couldn't even write a TM that decides if a number, base one,
>> was even or odd, how do you justify a thread with this title?
>>
>
> I told you I was very sick from chemo therapy.
> Would it help my credibility if I finished this?
>
> I have been in the middle of fully translating
> my system to Linux. I have most of this done now.
If you have that much time to fully translate to Linux, you certainly
had ten minutes to write the fucking TM. Of course you couldn't
concentrate for ten minutes, now or in the past. Grade school kids can
do it with a little coaching. You can't. You have no credibility, just a
mouth that constantly spouts gibberish. Sorry about your cancer but it's
time you properly finish at least one simple task correctly. If it gets
you soon, you'll be known as the man/child who never accomplished
anything and showed a genetic-based discipline to resist learning
anything too. What a total waste.
--
Jeff Barnett

On 8/28/22 11:15 PM, olcott wrote:
> On 8/28/2022 10:01 PM, Richard Damon wrote:
>> On 8/28/22 10:47 PM, olcott wrote:
>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>
>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>> exist in the
>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>> about these
>>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>>> ideas are
>>>>>>>>>>> incoherent.
>>>>>>>>>>>
>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>> existing
>>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>>> abstract
>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>> physically
>>>>>>>>>>> implemented.
>>>>>>>>>>>
>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> H(x, x);
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> If a decider must always return a value whenever it is called
>>>>>>>>>>> this
>>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>
>>>>>>>>>>> This even requires that the function call from Px to H(Px,Px)
>>>>>>>>>>> must
>>>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>>>> executed. In the physical model of computation it is an axiom
>>>>>>>>>>> the
>>>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>>>> physically impossible.
>>>>>>>>>>>
>>>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>>>> H(Px,Px)
>>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>>> this call
>>>>>>>>>>> is executed.
>>>>>>>>>>>
>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>> Computer science says that H must still return a value to Px
>>>>>>>>>>> even
>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>> deciders must
>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>
>>>>>>>>>> Computer science is correct on this point, what is incorrect
>>>>>>>>>> is your
>>>>>>>>>> implementation of H.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>>> executed
>>>>>>>>> must still return a result?
>>>>>>>>
>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>
>>>>>>>> No problem - is just a definition.
>>>>>>>
>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the when
>>>>>>> Px calls H(Px,Px) that H must return a value to Px even though
>>>>>>> this function call from Px to H is never executed.
>>>>>>
>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>> executed.
>>>>>>
>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that
>>>>>> H determines.
>>>>>>
>>>>>
>>>>> You said that H must always return a result to its caller even if
>>>>> this call is never actually executed.
>>>>>
>>>>
>>>> You don't HAVE a caller unless you execute the call instruction.
>>>
>>> DON'T CHANGE THE SUBJECT
>>> DON'T CHANGE THE SUBJECT
>>> DON'T CHANGE THE SUBJECT
>>
>> I DIDN'T. I don't think you know what a subject is.
>>
>>>
>>> A decider must always return to its caller:
>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*
>>>
>>
>> So, you don't think that Px calls H?
>
> The call to H(Px,Px) from P is never executed, thus H need not return to
> Px.
>
>

But it is in the complete simulation of the input to H(Px,Px), and that
is what matters for the answer that H is supposed to give.

You still don't understand that H isn't doing a complete simulation
since it DOES abort its simulation.

On 8/28/22 11:11 PM, olcott wrote:
> On 8/28/2022 9:57 PM, Mike Terry wrote:
>> On 29/08/2022 01:01, olcott wrote:
>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>
>>>> <SNIP> idiotic posted.
>>>>
>>>> Since you couldn't even write a TM that decides if a number, base
>>>> one, was even or odd, how do you justify a thread with this title?
>>>>
>>>
>>> I told you I was very sick from chemo therapy.
>>> Would it help my credibility if I finished this?
>>
>> I rather doubt that, but there's a chance that you might /learn/
>> something about TMs and how they are used if you completed Ben's
>> program.  Simply learning about TMs won't specifically help your
>> credibility though, unless it leads you to recognise the problems with
>> your current claims and withdraw them.  That /would/ improve your
>> credibility somewhat, but only in a "negative negative" sort of way.
>> (I'm guessing you'd still be claiming to have refuted all sorts of
>> other things, which would still mark you as a crank for most readers.
>> And besides I don't see anything Ben is going to try to teach you as
>> likely to cause you to withdraw any of your claims.)
>>
>> Just writing the one TM to decide even numbers in itself won't help
>> your credibility much, because I imagine most people are already
>> prepared to believe you could do that with appropriate effort.
>>
>> I've just had the thought that perhaps you believe people reject your
>> claims because you lack credibility as an expert : if only you "had
>> more credibility" then the things you say would transform magically
>> from nonsense into correctly proven claims?  That doesn't make ANY
>> sense, but perhaps its how you view the world...  Are you thinking if
>> you demonstrate a simple programming task, your already spoken words
>> will start being interpreted differently?  That's not going to happen.
>>
>>>
>>> I have been in the middle of fully translating
>>> my system to Linux. I have most of this done now.
>>
>> None of that will further your goals of publishing in a reputable
>> peer-reviewd journal ONE IOTA! Neither will wasting the rest of your
>> life arguing with people here in comp.theory!  You will simply die one
>> day, then the world will just forget you (as it forgets 99.9999% of
>> us...) and carry on.
>>
>> Seriously - if your true aim is for your work to be remembered, you
>> need to actually present it to a publisher.  Forget about porting
>> stuff to Linux, or building exercise TMs or even arguing interminably
>> on comp.theory - unless really you're just looking to use up remaining
>> time and bow out comfortably... [the latter is actually not an
>> unreasonable path for you]
>>
>>
>> Mike.
>
> I can't possibly publish *UNTIL AFTER I AM UNDERSTOOD*
>
> If people fully understood what I am saying then they would understand
> that that the dogma of computer science textbooks that say that H(P,P)
> must base its halt status decision on the behavior of P(P) is incorrect. >
> They have to very carefully to go through every single detail of my
> explanation of exactly how and why it is incorrect and
>
> *utterly stop short-circuiting to the dogma*
> *utterly stop short-circuiting to the dogma*
> *utterly stop short-circuiting to the dogma*
>
> One of the ways that they short circuit is to say that it is a
> definition thus cannot be incorrect. A definition can be incorrect
> *only* when it directly contradicts other correct definitions.
>
>

And what is that contradiction?

Quote SOURCES for the definitions you are using. (Not just "The Meaning
of the words", what source is providing the meaning of the words).

I think you will find that you aren't actully using correct definitions.

You have been relying on your own understanding of what things must be
like, but you also have refused to learn the definitions of those
things, so you are working in a total absence of actual facts.

You have made it clear from your rants where you disagree with things,
but you provide NO source for what you are basing your idea on.

Note, Starting from First Principles means you actually need to START
with the First Principle definitions.

And, if from those first principles you come up with an idea that is
sort of like by not identical to an idea from the original system, you
can't just call your thing the same as the original thing.

That method may work for emperical systems, where you have a clear goal
of what you want to acheive in the physical universe, and are looking
for a better way to get there.

It doesn't work so well in a Theoretical Realm, where different
defintions mean things are different. You can perhaps discover new
concepts, but not 'correct' and existing one by redefining it.

On 8/28/2022 10:18 PM, Jeff Barnett wrote:
> On 8/28/2022 6:01 PM, olcott wrote:
>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>
>>> <SNIP> idiotic posted.
>>>
>>> Since you couldn't even write a TM that decides if a number, base
>>> one, was even or odd, how do you justify a thread with this title?
>>>
>>
>> I told you I was very sick from chemo therapy.
>> Would it help my credibility if I finished this?
>>
>> I have been in the middle of fully translating
>> my system to Linux. I have most of this done now.
> If you have that much time to fully translate to Linux, you certainly
> had ten minutes to write the fucking TM. Of course you couldn't

It looks like it might be a 12 hour day to find out why my TM simulator
is not working and another 12 hour day to load all of the details in my
head. Some of the guys here that have written these things many times
could probably figure it out in ten minutes.

All but the actual halt decider itself has already been fully ported to
Linux so that it works under both Linux and Windows. I have to complete
my ELF_Object parser.

> concentrate for ten minutes, now or in the past. Grade school kids can
> do it with a little coaching. You can't. You have no credibility, just a
> mouth that constantly spouts gibberish. Sorry about your cancer but it's
> time you properly finish at least one simple task correctly. If it gets
> you soon, you'll be known as the man/child who never accomplished
> anything and showed a genetic-based discipline to resist learning
> anything too. What a total waste.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 29/08/2022 04:08, Richard Damon wrote:
> On 8/28/22 10:57 PM, Mike Terry wrote:
>> On 29/08/2022 01:01, olcott wrote:
>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>
>>>> <SNIP> idiotic posted.
>>>>
>>>> Since you couldn't even write a TM that decides if a number, base one, was even or odd, how do
>>>> you justify a thread with this title?
>>>>
>>>
>>> I told you I was very sick from chemo therapy.
>>> Would it help my credibility if I finished this?
>>
>> I rather doubt that, but there's a chance that you might /learn/ something about TMs and how they
>> are used if you completed Ben's program.  Simply learning about TMs won't specifically help your
>> credibility though, unless it leads you to recognise the problems with your current claims and
>> withdraw them.  That /would/ improve your credibility somewhat, but only in a "negative negative"
>> sort of way. (I'm guessing you'd still be claiming to have refuted all sorts of other things,
>> which would still mark you as a crank for most readers.  And besides I don't see anything Ben is
>> going to try to teach you as likely to cause you to withdraw any of your claims.)
>>
>> Just writing the one TM to decide even numbers in itself won't help your credibility much, because
>> I imagine most people are already prepared to believe you could do that with appropriate effort.
>>
>> I've just had the thought that perhaps you believe people reject your claims because you lack
>> credibility as an expert : if only you "had more credibility" then the things you say would
>> transform magically from nonsense into correctly proven claims?  That doesn't make ANY sense, but
>> perhaps its how you view the world...  Are you thinking if you demonstrate a simple programming
>> task, your already spoken words will start being interpreted differently?  That's not going to
>> happen.
>>
>>>
>>> I have been in the middle of fully translating
>>> my system to Linux. I have most of this done now.
>>
>> None of that will further your goals of publishing in a reputable peer-reviewd journal ONE IOTA!
>> Neither will wasting the rest of your life arguing with people here in comp.theory!  You will
>> simply die one day, then the world will just forget you (as it forgets 99.9999% of us...) and
>> carry on.
>>
>> Seriously - if your true aim is for your work to be remembered, you need to actually present it to
>> a publisher.  Forget about porting stuff to Linux, or building exercise TMs or even arguing
>> interminably on comp.theory - unless really you're just looking to use up remaining time and bow
>> out comfortably... [the latter is actually not an unreasonable path for you]
>>
>>
>> Mike.
>
> My guess is that something in him KNOWS that if he just submits the paper with what he currently
> has, it will just get rejected (it they even bother to tell him it is rejected).
>
> He seems desperate to try to find the right words that might let his lies sneek past the reviews and
> get him published.
>
> In a sense, his discussion here in comp.theory are just like him porting his system to linux, a good
> excuse to delay getting to where he want to be, because he knows subconsciously that if he actully
> get there he will just fail.

Yes, I think this is likely. Going a bit further, I think we are all capabable of deceiving
ourselves to some extent when we're trapped in an unpalatable situation, in order to get through the
situation with our psyches unharmed. And PO is especially adept at self deception! But mostly at
some deep level we also know we are deceiving ourselves, even while we subconciously avoid
situations which might lead us to confront those deceptions... we have to deceive ourselves "just
enough" to get through...

Anyhow, I'm confident PO will never actually get around to submitting his paper. He'd have to get
it (coherently) written, for starters, and I don't think he's got a clue where to start on that. He
just doesn't understand what's required for a research paper, or even what definitions and proofs
look like, let alone what actually needs to be proved etc.. Maybe he could hire someone to write it
for him, but such a helper can't magically turn wrong claims into valid proofs, so he's stuck.

Mike.

On 8/28/2022 8:19 PM, Richard Damon wrote:
>
> On 8/28/22 9:15 PM, olcott wrote:
>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>> On 8/28/22 8:07 PM, olcott wrote:
>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>> in the
>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>> these
>>>>>>>> abstract mathematical objects and never realize that their ideas
>>>>>>>> are
>>>>>>>> incoherent.
>>>>>>>>
>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>> implemented.
>>>>>>>>
>>>>>>>> void Px(ptr x)
>>>>>>>> {
>>>>>>>> H(x, x);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>> infinite recursion.
>>>>>>>>
>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>> programs that are not executed never return values because it is
>>>>>>>> physically impossible.
>>>>>>>>
>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>> H(Px,Px)
>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>> call
>>>>>>>> is executed.
>>>>>>>>
>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>> though the call to H is not even executed because all deciders must
>>>>>>>> ALWAYS return to their caller.
>>>>>>>
>>>>>>> Computer science is correct on this point, what is incorrect is your
>>>>>>> implementation of H.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>> So you are saying the a computer program that is never even executed
>>>>>> must still return a result?
>>>>>
>>>>> The "result" of a program that never returns is None!
>>>>> This is equivalent of treating non-termination as an effect.
>>>>>
>>>>> No problem - is just a definition.
>>>>
>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>> function call from Px to H is never executed.
>>>
>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>
>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>> determines.
>>>
>>
>> You said that H must always return a result to its caller even if this
>> call is never actually executed.
>>
>
> You don't HAVE a caller unless you execute the call instruction.

DON'T CHANGE THE SUBJECT
DON'T CHANGE THE SUBJECT
DON'T CHANGE THE SUBJECT

A decider must always return to its caller:
*ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*

H simulates Px until Px reaches its machine address [0000110d] and then
H aborts its simulation of Px so the call from H(Px,Px) is never
executed thus H is still a decider.

_Px()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](03) 8b4508 mov eax,[ebp+08]
[00001108](01) 50 push eax // Push Px
[00001109](03) 8b4d08 mov ecx,[ebp+08]
[0000110c](01) 51 push ecx // Push Px
[0000110d](05) e880fdffff call 00000e92 // call H
[00001112](03) 83c408 add esp,+08
[00001115](01) 5d pop ebp
[00001116](01) c3 ret
Size in bytes:(0021) [00001116]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/28/2022 10:27 PM, Richard Damon wrote:
>
> On 8/28/22 11:11 PM, olcott wrote:
>> On 8/28/2022 9:57 PM, Mike Terry wrote:
>>> On 29/08/2022 01:01, olcott wrote:
>>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>>
>>>>> <SNIP> idiotic posted.
>>>>>
>>>>> Since you couldn't even write a TM that decides if a number, base
>>>>> one, was even or odd, how do you justify a thread with this title?
>>>>>
>>>>
>>>> I told you I was very sick from chemo therapy.
>>>> Would it help my credibility if I finished this?
>>>
>>> I rather doubt that, but there's a chance that you might /learn/
>>> something about TMs and how they are used if you completed Ben's
>>> program.  Simply learning about TMs won't specifically help your
>>> credibility though, unless it leads you to recognise the problems
>>> with your current claims and withdraw them.  That /would/ improve
>>> your credibility somewhat, but only in a "negative negative" sort of
>>> way. (I'm guessing you'd still be claiming to have refuted all sorts
>>> of other things, which would still mark you as a crank for most
>>> readers. And besides I don't see anything Ben is going to try to
>>> teach you as likely to cause you to withdraw any of your claims.)
>>>
>>> Just writing the one TM to decide even numbers in itself won't help
>>> your credibility much, because I imagine most people are already
>>> prepared to believe you could do that with appropriate effort.
>>>
>>> I've just had the thought that perhaps you believe people reject your
>>> claims because you lack credibility as an expert : if only you "had
>>> more credibility" then the things you say would transform magically
>>> from nonsense into correctly proven claims?  That doesn't make ANY
>>> sense, but perhaps its how you view the world...  Are you thinking if
>>> you demonstrate a simple programming task, your already spoken words
>>> will start being interpreted differently?  That's not going to happen.
>>>
>>>>
>>>> I have been in the middle of fully translating
>>>> my system to Linux. I have most of this done now.
>>>
>>> None of that will further your goals of publishing in a reputable
>>> peer-reviewd journal ONE IOTA! Neither will wasting the rest of your
>>> life arguing with people here in comp.theory!  You will simply die
>>> one day, then the world will just forget you (as it forgets 99.9999%
>>> of us...) and carry on.
>>>
>>> Seriously - if your true aim is for your work to be remembered, you
>>> need to actually present it to a publisher.  Forget about porting
>>> stuff to Linux, or building exercise TMs or even arguing interminably
>>> on comp.theory - unless really you're just looking to use up
>>> remaining time and bow out comfortably... [the latter is actually not
>>> an unreasonable path for you]
>>>
>>>
>>> Mike.
>>
>> I can't possibly publish *UNTIL AFTER I AM UNDERSTOOD*
>>
>> If people fully understood what I am saying then they would understand
>> that that the dogma of computer science textbooks that say that H(P,P)
>> must base its halt status decision on the behavior of P(P) is
>> incorrect. >
>> They have to very carefully to go through every single detail of my
>> explanation of exactly how and why it is incorrect and
>>
>> *utterly stop short-circuiting to the dogma*
>> *utterly stop short-circuiting to the dogma*
>> *utterly stop short-circuiting to the dogma*
>>
>> One of the ways that they short circuit is to say that it is a
>> definition thus cannot be incorrect. A definition can be incorrect
>> *only* when it directly contradicts other correct definitions.
>>
>>
>
> And what is that contradiction?
>

I am not going to talk about it with you your mind wanders too much.

> Quote SOURCES for the definitions you are using. (Not just "The Meaning
> of the words", what source is providing the meaning of the words).
>
> I think you will find that you aren't actully using correct definitions.
>
> You have been relying on your own understanding of what things must be
> like, but you also have refused to learn the definitions of those
> things, so you are working in a total absence of actual facts.
>
>
> You have made it clear from your rants where you disagree with things,
> but you provide NO source for what you are basing your idea on.
>
> Note, Starting from First Principles means you actually need to START
> with the First Principle definitions.
>
> And, if from those first principles you come up with an idea that is
> sort of like by not identical to an idea from the original system, you
> can't just call your thing the same as the original thing.
>
> That method may work for emperical systems, where you have a clear goal
> of what you want to acheive in the physical universe, and are looking
> for a better way to get there.
>
> It doesn't work so well in a Theoretical Realm, where different
> defintions mean things are different. You can perhaps discover new
> concepts, but not 'correct' and existing one by redefining it.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Sunday, August 28, 2022 at 8:50:51 PM UTC-7, Mike Terry wrote:
> On 29/08/2022 04:08, Richard Damon wrote:
> > On 8/28/22 10:57 PM, Mike Terry wrote:
> >> On 29/08/2022 01:01, olcott wrote:
> >>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
> >>>> On 8/28/2022 1:47 PM, olcott wrote:
> >>>>
> >>>> <SNIP> idiotic posted.
> >>>>
> >>>> Since you couldn't even write a TM that decides if a number, base one, was even or odd, how do
> >>>> you justify a thread with this title?
> >>>>
> >>>
> >>> I told you I was very sick from chemo therapy.
> >>> Would it help my credibility if I finished this?
> >>
> >> I rather doubt that, but there's a chance that you might /learn/ something about TMs and how they
> >> are used if you completed Ben's program. Simply learning about TMs won't specifically help your
> >> credibility though, unless it leads you to recognise the problems with your current claims and
> >> withdraw them. That /would/ improve your credibility somewhat, but only in a "negative negative"
> >> sort of way. (I'm guessing you'd still be claiming to have refuted all sorts of other things,
> >> which would still mark you as a crank for most readers. And besides I don't see anything Ben is
> >> going to try to teach you as likely to cause you to withdraw any of your claims.)
> >>
> >> Just writing the one TM to decide even numbers in itself won't help your credibility much, because
> >> I imagine most people are already prepared to believe you could do that with appropriate effort.
> >>
> >> I've just had the thought that perhaps you believe people reject your claims because you lack
> >> credibility as an expert : if only you "had more credibility" then the things you say would
> >> transform magically from nonsense into correctly proven claims? That doesn't make ANY sense, but
> >> perhaps its how you view the world... Are you thinking if you demonstrate a simple programming
> >> task, your already spoken words will start being interpreted differently? That's not going to
> >> happen.
> >>
> >>>
> >>> I have been in the middle of fully translating
> >>> my system to Linux. I have most of this done now.
> >>
> >> None of that will further your goals of publishing in a reputable peer-reviewd journal ONE IOTA!
> >> Neither will wasting the rest of your life arguing with people here in comp.theory! You will
> >> simply die one day, then the world will just forget you (as it forgets 99.9999% of us...) and
> >> carry on.
> >>
> >> Seriously - if your true aim is for your work to be remembered, you need to actually present it to
> >> a publisher. Forget about porting stuff to Linux, or building exercise TMs or even arguing
> >> interminably on comp.theory - unless really you're just looking to use up remaining time and bow
> >> out comfortably... [the latter is actually not an unreasonable path for you]
> >>
> >>
> >> Mike.
> >
> > My guess is that something in him KNOWS that if he just submits the paper with what he currently
> > has, it will just get rejected (it they even bother to tell him it is rejected).
> >
> > He seems desperate to try to find the right words that might let his lies sneek past the reviews and
> > get him published.
> >
> > In a sense, his discussion here in comp.theory are just like him porting his system to linux, a good
> > excuse to delay getting to where he want to be, because he knows subconsciously that if he actully
> > get there he will just fail.
> Yes, I think this is likely. Going a bit further, I think we are all capabable of deceiving
> ourselves to some extent when we're trapped in an unpalatable situation, in order to get through the
> situation with our psyches unharmed. And PO is especially adept at self deception! But mostly at
> some deep level we also know we are deceiving ourselves, even while we subconciously avoid
> situations which might lead us to confront those deceptions... we have to deceive ourselves "just
> enough" to get through...
>
> Anyhow, I'm confident PO will never actually get around to submitting his paper. He'd have to get
> it (coherently) written, for starters, and I don't think he's got a clue where to start on that. He
> just doesn't understand what's required for a research paper, or even what definitions and proofs
> look like, let alone what actually needs to be proved etc.. Maybe he could hire someone to write it
> for him, but such a helper can't magically turn wrong claims into valid proofs, so he's stuck.
>
Surely somewhere there is a vanity mathematical journal that will publish
his paper for a price. But I discover I don't know about one. Are there any?

An interesting busines opportunity ?