On 7/2/2021 1:58 AM, David Brown wrote:
> On 02/07/2021 03:52, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>>> that correct answers are impossible.
>>>>>>>
>>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>>> undecidable if the set of yes instances in not recursive.
>>>> <cut>
>>>>> When the entire set of possible {true, false} Boolean return values
>>>>> from an (input / TM) pair provides an incorrect halting status
>>>> For every finite string, one of true or false is always the correct
>>>> halting status for that string: true if the string represents a halting
>>>> computation, false otherwise.
>>>> Stop fighting this obvious fact and agree to it. You are not talking
>>>> about the halting problem until you do.
>>>>
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> if M applied to wM halts, and
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>> if M applied to wM does not halt
>>>
>>> In the Peter Linz proof it is commonly understood that neither the
>>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>>> Turing machine description).
>>
>> I accept that this is your misunderstanding, and it may even be a common
>> misunderstanding, but it is not what the lines from Linz you keep
>> quoting mean. It absolutely does not mean that there is an instance of
>> the halting problem without a correct yes/no answer.
>>
>>> Because you have dodged this question so persistently over the years
>>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>>
>> No. I have never said this. H (as in Linz) does not exist, and neither
>> does H^. There is no string [H^]. The question of whether a TM that
>> does not exist halts when given a non-existent string as its input is
>> too absurd take seriously.
>>
> You know the details of these things better than I, and I am decades out
> of practice. But as I understand it, the whole point of the common
> proof that halting is undecidable is that the assumption that the
> function H is computable leads to the contradiction that Ĥ(Ĥ) is both
> true and false, alternatively that it is neither true nor false. And
> since it must be either true /or/ false (as everything is finite here),
> that cannot be the case. Therefore H could not have been computable.
>
> It seems to me that Olcott's argument is based on assuming H /is/ a real
> computable function, then redefining halting to allow an option of
> "neither halts nor does not halt" to remove the contradiction. Then he
> claims that this means the common proof of halting undecidability is wrong.
>
> Is that a fair summary?
>

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

H determines that P is calling it in infinitely nested simulation, H
aborts its simulation of P on this basis, and then reports that P never
halts. This has no contradiction what-so-ever.

Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/2/2021 2:16 AM, David Brown wrote:
> On 02/07/2021 05:12, Richard Damon wrote:
>> On 7/1/21 7:44 AM, Andy Walker wrote:
>>> On 01/07/2021 03:34, Richard Damon wrote:
>>>> On 6/30/21 1:15 PM, olcott wrote:
>>>>> The other issue doesn't seem to have much of an alternative. A key part
>>>>> of the problem that allowed the halting problem to continue to exist is
>>>>> that it was only analyzed using Turing machines.
>>>
>>>     There is no essential difference between TMs and real computers.
>>> The only actual difference is that a real computer allows for external
>>> connexions, such as people typing at a keyboard or clicking a mouse, or
>>> a clock interrupt, or a temperature sensor raising an alarm.
>>
>> This is TOTALLY wrong. There is a VERY different 'machinery' used in
>> Turing machines rather than a conventional computer.
>>
>> A Turing Machine is fundamentally a finite state machine tied as it only
>> input/output a tape reader/writer. For each instruction the state
>> machine combines the current state and the symbol at the current
>> location on the tape, and that what the next start will be, what
>> character the tape will be changed to be (or it stays the same) and if
>> and in what direction you move the tape.
>>
>> Your typical modern comupter is a stored program machine where you have
>> a set of registers, one of which is a program counter, for each step the
>> instruction at the location in memory (and possible some of the
>> following locations) is read, decoded, and executed. This instruction
>> will typically provide some manipulation of the registers, perhaps
>> reading other locations of memory for 'input' to an operation or storing
>> the contents of the operation into a location of memory.
>>
>> Note some of the big differences, the Turing Machine doesn't have
>> 'registers', all it has is one blob called the 'state' which is sort of
>> like the program counter, but rather than defaulting to incrementing,
>> every instruction has the capability of an N-way branch. The other big
>> difference is that The conventional computer has 'random' access, it can
>> just reach out to a fairly arbitray location in memory to get a value,
>> and tends to have some registers for short (or longer) term storage.
>>
>
>
> Sorry, but I don't think any of that is correct. The registers, the way
> the state is defined, the ability to modify code - none of that matters
> at all.
>
> You can make a Turing machine that simulates Turing machines. The
> "source" for the simulation will be on the tape, and the "host" Turing
> machine can happily change it under way. You can have a simulator that
> runs through all possible combinations of all possible Turing machines
> with all possible inputs - since everything involved is merely countably
> infinite. (Such a system won't halt, of course.)
>
> You can make a Turing machine that simulates a full modern computer, x86
> or otherwise, if you managed to specify it well enough.
>
>
> There are only two differences between a Turing machine and a modern
> computer. One is that the Turing machine tape is unlimited, while the
> computer is finite - and thus halting is decidable (but impractical) for
> all possible programs running on it.
>
> The other is that Turing machine computations get all their input in
> advance, while it is usual to add input underway in a computer. To
> simulate normal use of a computer, you'd have to include a list of all
> keystrokes, mouse movements, network packets, etc., as part of the input
> to the computation.
>
>
> Another way to realise this is to note that there are no computations
> that can be done on an x86 system or other "real" computer that could
> not also be done on a Turing machine, and vice versa. (The same applies
> to other computation models, such as quantum computers, cellular
> automata, the Unseen University's Hex, and any other computer you imagine.)
>
>
> Whether Olcott's x86 simulator is Turing complete or not is another
> matter, of course. But it certainly can't do anything that a Turing
> machine could not.
>

This is the model of computation that forms a bridge between the x86
language and Turing machines.

https://en.wikipedia.org/wiki/Random-access_stored-program_machine

I even figured out how a machine with relative addressing such as x64
RIP addressing could specify unlimited memory using 64-bit registers.

This is the best bridge between the TM architecture and the Intel
architecture because actual programs could be actually written in
exactly this architecture.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott wrote:
> On 7/2/2021 8:16 AM, Peter wrote:
>> olcott wrote:
>>> On 7/1/2021 5:05 PM, Peter wrote:
>>>> olcott wrote:
>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>> olcott wrote:
>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>> quality [...]
>>>>>>
>>>>>> Then fix it.
>>>>>>
>>>>>
>>>>> I didn't know where to begin
>>>>
>>>> If you have access to a university library, read journals.  Halmos
>>>> wrote a paper called 'How to write mathematics' I don't know if it's
>>>> relevant but someone reading this might.  If you've got time and
>>>> money do a post graduate degree--
>>>
>>> I will literally be dead before then I have stage three cancer.
>>>
>>>> not only might you learn how to write mathematics (by imitation) you
>>>> might also learn that your not as clever as you think you are.
>>
>> "you're" not "your".
>>>
>>> The easily verifiable fact that there have literally been zero errors
>>> pointed out in my sound deductive inference in six months provides
>>> very compelling evidence otherwise.
>>
>> Only you are making it impossible for you to become aware of your own
>> limitations.
>
> My proof (sound deductive inference) is correct.
> Software engineers can verify that it is correct.
>

But none have.

--
The world will little note, nor long remember what we say here
Abraham Lincoln at Gettysburg

On 7/2/2021 10:07 AM, Peter wrote:
> olcott wrote:
>> On 7/2/2021 8:16 AM, Peter wrote:
>>> olcott wrote:
>>>> On 7/1/2021 5:05 PM, Peter wrote:
>>>>> olcott wrote:
>>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>>> olcott wrote:
>>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>>> quality [...]
>>>>>>>
>>>>>>> Then fix it.
>>>>>>>
>>>>>>
>>>>>> I didn't know where to begin
>>>>>
>>>>> If you have access to a university library, read journals.  Halmos
>>>>> wrote a paper called 'How to write mathematics' I don't know if
>>>>> it's relevant but someone reading this might.  If you've got time
>>>>> and money do a post graduate degree--
>>>>
>>>> I will literally be dead before then I have stage three cancer.
>>>>
>>>>> not only might you learn how to write mathematics (by imitation)
>>>>> you might also learn that your not as clever as you think you are.
>>>
>>> "you're" not "your".
>>>>
>>>> The easily verifiable fact that there have literally been zero
>>>> errors pointed out in my sound deductive inference in six months
>>>> provides very compelling evidence otherwise.
>>>
>>> Only you are making it impossible for you to become aware of your own
>>> limitations.
>>
>> My proof (sound deductive inference) is correct.
>> Software engineers can verify that it is correct.
>>
>
> But none have.

25 reviews per day by half a dozen reasonably competent reviewers could
not point to a single technical error in any aspect of the ideas
referenced in this paper at any time in the last six months.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

That much of these reviews were entirely based on ad hominem personal
attacks and other forms of mere rhetoric would indicate that they were
biased. That not of them had any technical basis proves that they are
baseless.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott wrote:
> On 7/2/2021 10:07 AM, Peter wrote:
>> olcott wrote:
>>> On 7/2/2021 8:16 AM, Peter wrote:
>>>> olcott wrote:
>>>>> On 7/1/2021 5:05 PM, Peter wrote:
>>>>>> olcott wrote:
>>>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>>>> olcott wrote:
>>>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>>>> quality [...]
>>>>>>>>
>>>>>>>> Then fix it.
>>>>>>>>
>>>>>>>
>>>>>>> I didn't know where to begin
>>>>>>
>>>>>> If you have access to a university library, read journals.  Halmos
>>>>>> wrote a paper called 'How to write mathematics' I don't know if
>>>>>> it's relevant but someone reading this might.  If you've got time
>>>>>> and money do a post graduate degree--
>>>>>
>>>>> I will literally be dead before then I have stage three cancer.
>>>>>
>>>>>> not only might you learn how to write mathematics (by imitation)
>>>>>> you might also learn that your not as clever as you think you are.
>>>>
>>>> "you're" not "your".
>>>>>
>>>>> The easily verifiable fact that there have literally been zero
>>>>> errors pointed out in my sound deductive inference in six months
>>>>> provides very compelling evidence otherwise.
>>>>
>>>> Only you are making it impossible for you to become aware of your
>>>> own limitations.
>>>
>>> My proof (sound deductive inference) is correct.
>>> Software engineers can verify that it is correct.
>>>
>>
>> But none have.
>
> 25 reviews per day by half a dozen reasonably competent reviewers could
> not point to a single technical error in any aspect of the ideas
> referenced in this paper at any time in the last six months.

You are out of touch with reality. You claimed that software engineers
can verify that your "proof" is correct, but what you have just claimed
is that you have failed to accept any of the criticism you've had. Do
you see no difference between those two?
>
> Halting problem undecidability and infinitely nested simulation
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> That much of these reviews were entirely based on ad hominem personal
> attacks and other forms of mere rhetoric would indicate that they were
> biased. That not of them had any technical basis proves that they are
> baseless.
>
>
>

--
The world will little note, nor long remember what we say here
Abraham Lincoln at Gettysburg

On 7/2/2021 10:51 AM, Peter wrote:
> olcott wrote:
>> On 7/2/2021 10:07 AM, Peter wrote:
>>> olcott wrote:
>>>> On 7/2/2021 8:16 AM, Peter wrote:
>>>>> olcott wrote:
>>>>>> On 7/1/2021 5:05 PM, Peter wrote:
>>>>>>> olcott wrote:
>>>>>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>>>>>> olcott wrote:
>>>>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>>>>> quality [...]
>>>>>>>>>
>>>>>>>>> Then fix it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I didn't know where to begin
>>>>>>>
>>>>>>> If you have access to a university library, read journals.
>>>>>>> Halmos wrote a paper called 'How to write mathematics' I don't
>>>>>>> know if it's relevant but someone reading this might.  If you've
>>>>>>> got time and money do a post graduate degree--
>>>>>>
>>>>>> I will literally be dead before then I have stage three cancer.
>>>>>>
>>>>>>> not only might you learn how to write mathematics (by imitation)
>>>>>>> you might also learn that your not as clever as you think you are.
>>>>>
>>>>> "you're" not "your".
>>>>>>
>>>>>> The easily verifiable fact that there have literally been zero
>>>>>> errors pointed out in my sound deductive inference in six months
>>>>>> provides very compelling evidence otherwise.
>>>>>
>>>>> Only you are making it impossible for you to become aware of your
>>>>> own limitations.
>>>>
>>>> My proof (sound deductive inference) is correct.
>>>> Software engineers can verify that it is correct.
>>>>
>>>
>>> But none have.
>>
>> 25 reviews per day by half a dozen reasonably competent reviewers
>> could not point to a single technical error in any aspect of the ideas
>> referenced in this paper at any time in the last six months.
>
> You are out of touch with reality.  You claimed that software engineers
> can verify that your "proof" is correct, but what you have just claimed
> is that you have failed to accept any of the criticism you've had.  Do
> you see no difference between those two?

The strongest "proof" that I am incorrect is simply that people really
really don't believe that I am correct, can you see that this form of
"rebuttal" is utterly baseless?

If you think that anyone had a stronger rebuttal then please point to
the date-time stamp and I will show how it is incorrect.

All of the "rebuttals" that actually used reasoning were shown to be
incorrect. Kaz initially thought that H(P,P) did not specify a
computation because H was not a pure function of its inputs. When I
showed how H is a pure function of its inputs Kaz acquiesced.

>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> That much of these reviews were entirely based on ad hominem personal
>> attacks and other forms of mere rhetoric would indicate that they were
>> biased. That not of them had any technical basis proves that they are
>> baseless.
>>
>>
>>
>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 7/1/2021 8:52 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>>> that correct answers are impossible.
>>>>>>>
>>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>>> undecidable if the set of yes instances in not recursive.
>>>> <cut>
>>>>> When the entire set of possible {true, false} Boolean return values
>>>>> from an (input / TM) pair provides an incorrect halting status
>>>> For every finite string, one of true or false is always the correct
>>>> halting status for that string: true if the string represents a halting
>>>> computation, false otherwise.
>>>> Stop fighting this obvious fact and agree to it. You are not talking
>>>> about the halting problem until you do.
>>>>
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> if M applied to wM halts, and
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>> if M applied to wM does not halt
>>>
>>> In the Peter Linz proof it is commonly understood that neither the
>>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>>> Turing machine description).
>> I accept that this is your misunderstanding, and it may even be a common
>> misunderstanding, but it is not what the lines from Linz you keep
>> quoting mean. It absolutely does not mean that there is an instance of
>> the halting problem without a correct yes/no answer.
>>
>>> Because you have dodged this question so persistently over the years
>>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>> No. I have never said this. H (as in Linz) does not exist, and neither
>> does H^. There is no string [H^]. The question of whether a TM that
>> does not exist halts when given a non-existent string as its input is
>> too absurd take seriously.
>> For every actual TM, X, there is a correct yes/no answer for all the
>> halting problem instances involving X. For every TM for which we can
>> form X^ (which is all of them if we slightly relax the construction) the
>> same is also true. I.e. for every TM X, the instance <[X^],[X^]> has a
>> correct yes/no answer because the computation X^([X^]) either halts or
>> it does not halt. However, X does not give it.
>
> What is the specific term-of-the-art for the category of the cases of
> (TM X / Input I) such that X(I) cannot give the correct answer?

There is none because serious people don't attribute agency to TMs. If
you ask instead what the term is for inputs I such that X(I) is not the
correct answer, then these are just called the cases X gets wrong. You
know that term as well as anyone.

>> This is why your Big Lie of Dec 2018 was considered interesting. You
>> claimed to have an impossible TM pair, fully encoded. Now you simply
>> claim to have a TM (or "equivalent") that gets the answer wrong. That
>> possibility was never in doubt. No one is interested in a TM X that
>> rejects <[X^],[X^]> despite X^([X^]) being a halting computation.

> It is very disgraceful to the many millions of people that have been
> murdered by the Nazis (the origin of the term "big lie") for you to
> use this term in such a cavalier way.

You mean, presumably, disrespectful, but you are quite right. I never
thought of that. Thank you for point it out. I'll call it your Grand
Delusion and I'll also mention the dishonest subsequent cover-up. (I
don't actually think you lied in Dec 2018. You lied afterwards when
walking back the deluded claim you made.)

--
Ben.

On 7/2/2021 2:02 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/1/2021 8:52 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/1/2021 6:24 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/1/2021 4:25 PM, olcott wrote:
>>>>>>> On 7/1/2021 3:23 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> We can make an undecidable problem by simply phrasing a question such
>>>>>>>>> that correct answers are impossible.
>>>>>>>>
>>>>>>>> But decision problems, of which the halting problem is one, are defined
>>>>>>>> as those that always have correct yes/no answers.  Such a problem is
>>>>>>>> undecidable if the set of yes instances in not recursive.
>>>>> <cut>
>>>>>> When the entire set of possible {true, false} Boolean return values
>>>>>> from an (input / TM) pair provides an incorrect halting status
>>>>> For every finite string, one of true or false is always the correct
>>>>> halting status for that string: true if the string represents a halting
>>>>> computation, false otherwise.
>>>>> Stop fighting this obvious fact and agree to it. You are not talking
>>>>> about the halting problem until you do.
>>>>>
>>>>
>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>> if M applied to wM halts, and
>>>>
>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>> if M applied to wM does not halt
>>>>
>>>> In the Peter Linz proof it is commonly understood that neither the
>>>> Ĥ.qy (yes it halts) nor the Ĥ.qn (no it does not halt) are the correct
>>>> halt status that Ĥ can transition to when Ĥ is applied to ⟨Ĥ⟩ (its own
>>>> Turing machine description).
>>> I accept that this is your misunderstanding, and it may even be a common
>>> misunderstanding, but it is not what the lines from Linz you keep
>>> quoting mean. It absolutely does not mean that there is an instance of
>>> the halting problem without a correct yes/no answer.
>>>
>>>> Because you have dodged this question so persistently over the years
>>>> by saying that there is a halt status for Ĥ applied to ⟨Ĥ⟩,
>>> No. I have never said this. H (as in Linz) does not exist, and neither
>>> does H^. There is no string [H^]. The question of whether a TM that
>>> does not exist halts when given a non-existent string as its input is
>>> too absurd take seriously.
>>> For every actual TM, X, there is a correct yes/no answer for all the
>>> halting problem instances involving X. For every TM for which we can
>>> form X^ (which is all of them if we slightly relax the construction) the
>>> same is also true. I.e. for every TM X, the instance <[X^],[X^]> has a
>>> correct yes/no answer because the computation X^([X^]) either halts or
>>> it does not halt. However, X does not give it.
>>
>> What is the specific term-of-the-art for the category of the cases of
>> (TM X / Input I) such that X(I) cannot give the correct answer?
>
> There is none because serious people don't attribute agency to TMs. If
> you ask instead what the term is for inputs I such that X(I) is not the
> correct answer, then these are just called the cases X gets wrong. You
> know that term as well as anyone.
>

So then we are back to my own pathological self-reference(olcott 2004).

>>> This is why your Big Lie of Dec 2018 was considered interesting. You
>>> claimed to have an impossible TM pair, fully encoded. Now you simply
>>> claim to have a TM (or "equivalent") that gets the answer wrong. That
>>> possibility was never in doubt. No one is interested in a TM X that
>>> rejects <[X^],[X^]> despite X^([X^]) being a halting computation.
>
>> It is very disgraceful to the many millions of people that have been
>> murdered by the Nazis (the origin of the term "big lie") for you to
>> use this term in such a cavalier way.
>
> You mean, presumably, disrespectful, but you are quite right. I never
> thought of that. Thank you for point it out. I'll call it your Grand
> Delusion and I'll also mention the dishonest subsequent cover-up. (I
> don't actually think you lied in Dec 2018. You lied afterwards when
> walking back the deluded claim you made.)
>

That the code that I claimed was RASP equivalent rather than an actual
Turing machine is the poetic license that I used when I understood that
it was equivalent to a Turing Machine yet had never yet heard the term
Turing equivalence.

At the point in time I knew that the generic idea of Turing equivalence
was correct yet had no idea that anyone else in the field understood this.

A fully encoded Turing machine is equivalent to a fully encoded RASP
machine which is equivalent to an x86 virtual machine which is
equivalent to the C source code of this x86 virtual machine.

When I pointed out that you already agreed with the one axiom of my
proof (sound deductive inference) and the second premise is easily
verified as an established fact, apparently all that is left to keep up
the ruse of your fake rebuttal is STUTTER.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Premise(1) (axiom) Every computation that never halts unless its
simulation is aborted is a computation that never halts. This verified
as true on the basis of the meaning of its words.

Premise(2) (verified fact) The simulation of the input to H(P,P) never
halts without being aborted is a verified fact on the basis of its x86
execution trace. (shown below).

When the simulator is determining whether or not it must abort the
simulation of its input based on the behavior of its input the simulator
must only examine the behavior of its input and must ignore its own
behavior.

Conclusion(3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> That the code that I claimed was RASP equivalent rather than an actual
> Turing machine is the poetic license that I used when I understood
> that it was equivalent to a Turing Machine yet had never yet heard the
> term Turing equivalence.

This is a lie. You said you had two actually turning machines, fully
encoded, and you knew exactly what that meant when you wrote it. I
accept you were deluded at the time, but you are lying about the
subsequent retraction of the claim.

The last 30 months have included many ironies, but one of the most
striking is that your supposed "solution" is trivial as a pair of actual
Turing machines! All the months of rowing back the claim with piles of
OS code, x86 simulation and endless "traces" are not needed. Given that
you have decided that "reject" (or "no" or "false") is the correct
answer for the specifically constructed "hat" case you should be able to
produce the two actual Turing machines, fully encoded. I can!

You argue that no one uses TMs because they are so impractical, but
every students I have ever taught would be able to write X (and thus X^)
such that X rejects on input <[X^],[X^]> despite X^ halting on input
[X^]. Such an X (and therefore X^) is simple to write. Not that you
could do it, of course, but it is trivial.

All these months of walking back a claim that is, in the light of your
definition of the correct answer, trivial. If you can't produce the two
actual Turing machines that behave like this, shame on you.

--
Ben.

On 7/2/2021 5:16 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> That the code that I claimed was RASP equivalent rather than an actual
>> Turing machine is the poetic license that I used when I understood
>> that it was equivalent to a Turing Machine yet had never yet heard the
>> term Turing equivalence.
>
> This is a lie. You said you had two actually turning machines, fully
> encoded, and you knew exactly what that meant when you wrote it.

Yes and I used poetic license because I knew that what I really had was
equivalent to two Turing machines yet did not know that the concept of
"equivalent to Turing machines" was known by anyone besides myself. All
that I have ever previously heard was the term "Turing complete". I had
never heard of anyone every saying "Turing equivalent".

None-the-less this is all moot now. The only reason that you bring it up
it to distract attention away from what I have now. I have shown how an
H and P in the proper halting problem relation <is> a decidable machine
/ input pair with fully operational C / x86 code.

That you cannot stay focused on this point and very persistently try to
distract attention way from this point is flatly dishonest.

If you utterly reverse course on this artificially contrived fake
rebuttal and do the best that you can to help me improve the quality of
my words I can give you some very significant credit for the success of
my work. I could probably call you and Kaz my most important reviewers
in the same way that the authors of academic papers give direct credit
to their top very few reviewers.

> I
> accept you were deluded at the time, but you are lying about the
> subsequent retraction of the claim.
>
> The last 30 months have included many ironies, but one of the most
> striking is that your supposed "solution" is trivial as a pair of actual
> Turing machines! All the months of rowing back the claim with piles of
> OS code, x86 simulation and endless "traces" are not needed. Given that
> you have decided that "reject" (or "no" or "false") is the correct
> answer for the specifically constructed "hat" case you should be able to
> produce the two actual Turing machines, fully encoded. I can!
>
> You argue that no one uses TMs because they are so impractical, but
> every students I have ever taught would be able to write X (and thus X^)
> such that X rejects on input <[X^],[X^]> despite X^ halting on input
> [X^]. Such an X (and therefore X^) is simple to write. Not that you
> could do it, of course, but it is trivial.
>
> All these months of walking back a claim that is, in the light of your
> definition of the correct answer, trivial. If you can't produce the two
> actual Turing machines that behave like this, shame on you.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 02/07/2021 04:12, Richard Damon wrote:
[I wrote:]
>>     There is no essential difference between TMs and real computers.
>> The only actual difference is that a real computer allows for external
>> connexions, such as people typing at a keyboard or clicking a mouse, or
>> a clock interrupt, or a temperature sensor raising an alarm.
> This is TOTALLY wrong.

No it isn't. It isn't even SLIGHTLY wrong, as long as your
real computer is indeed a finite-state machine. Cf David's reply,
and see also below.

> There is a VERY different 'machinery' used in
> Turing machines rather than a conventional computer.

The machinery is irrelevant. What matters is that both a TM
and a real computer can be described in terms of what happens at each
CPU cycle [or near equivalent]. Whether this is described as a state
transition or as some [typically] binary operation on some bits is a
matter of taste rather than an essential difference. There is a
problem in modern computers if some operations complete [eg] in random
orders or with ill-defined timings, but that's not exactly an advantage
when discussing the theory, just yet another source of bugs and route
for malware.

> A Turing Machine is fundamentally a finite state machine tied as it only
> input/output a tape reader/writer. [...]

Indeed.

> Your typical modern comupter is a stored program machine where you have
> a set of registers, one of which is a program counter, for each step the
> instruction at the location in memory (and possible some of the
> following locations) is read, decoded, and executed. This instruction
> will typically provide some manipulation of the registers, perhaps
> reading other locations of memory for 'input' to an operation or storing
> the contents of the operation into a location of memory.

IOW, it's a FSM with the next state depending on the current
state of the program counter, the registers, etc., etc.

> Note some of the big differences, the Turing Machine doesn't have
> 'registers', all it has is one blob called the 'state' which is sort of
> like the program counter, but rather than defaulting to incrementing,
> every instruction has the capability of an N-way branch. The other big
> difference is that The conventional computer has 'random' access, it can
> just reach out to a fairly arbitray location in memory to get a value,
> and tends to have some registers for short (or longer) term storage.

Yes, and ...? All of that is just a state transition. Yes,
for a practical modern computer the number of possible states is
rather large, but that doesn't affect the theory. How you describe
the states and their transitions is a matter of taste and convenience,
not an essential part of the mechanism.

[Perhaps also worth pointing out that a microcoded computer
is effectively a relatively small FSM with a relatively large tape
representing the computer storage, cf a UTM with a tape containing
the description of the computer being emulated.]

[...]
> The problem is that when we try to break down A or B which aren't Turing
> Machines, it is hard to prove that they don't 'hide' state that allows
> them to give different results for what seems to be the same input.

My definitions of "A" and "B" were that "A" was a computer
with all the expected features, such as arithmetic facilities [eg,
inc floating point, perhaps vector instructions, pipelining, etc]
whereas "B" was a computer with much more limited instructions, in
which, eg, multiplication was implemented by repeated addition as
a software subroutine rather than by hardware. Note that there
have been real computer ranges with such variations [esp, eg, with
FP implemented in software, or with more or less powerful memory
management instructions]. In the limit, "B" could be a computer
with the power [only] to increment, decrement and test against
zero [with an associated jump], yet still be as powerful, in
terms of its abstract capabilities [tho' obviously not speed],
as "A". Whether an actual program running on "A" is "the same
as" a program running on "B" is just another of life's insoluble
problems [equivalent to the HP, in general].

> Yes,
> if you set ALL of memory (including registers and external storage) to
> be identical, you will get the same results, but it takes a very details
> look at a routine that might be called several times to confirm that it
> will always produce the same result for the same input. This is just
> automatic with a Turing Machine, If the two spots use copies of the same
> algorithm, and the tape that this algorithm uses is the same, the
> results must be the same.

If you run the same TM with the same input tape twice, of
course you should get the same results. But again if you have two
different TMs, deciding whether they are "equivalent" is another
variation of the HP.

[...]
> The fact that he can't translate his logic into actual Turing Machines
> is a strong proof that his concepts don't actually apply to this
> particular set of problems.

I think that's a step too far. Rather, he doesn't understand
the relationship between TMs and real computers and languages. Most
of us here, perhaps all, would be perfectly happy if PO could show
whatever-he-thinks-is-worth-showing as C programs, rather than as TMs
or as some weird table of instructions. But of course what that would
actually show is that what he has is obvious and has been known from
the earliest days of the formal theory of computation.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Schumann

On 7/2/21 10:26 AM, olcott wrote:
> On 7/2/2021 6:15 AM, Richard Damon wrote:
>> WRONG. You trace is incorrect. If it was a trace of simulation of P(P),
>> then we would see the simulation of the machibne H within P. We don't,
>> therefore this is NOT the proper trace of the simulation.
>>
>> FAIL.
>
>
> Since the question is whether or not H must abort the simulation of P on
> the basis of the behavior of P it is utterly incorrect for H to examine
> its own behavior. Maybe if I tell you this 150 more times it will start
> to sink in and you will get it.
>

No, since the REAL question is whether TURING MACHINE P(P) is halting or
not, and TURING MACHINE P includes as part of itself that copy of H, the
behavior of that H is part of the behavior of P, you MUST include it in
your analysis. Omitting it is like determining the maximum speed of a
car by just looking at the tires and saying they're the only part that
touches the road, so we can ignore the rest of the car.

Remember the Theorem you are using is talking about actual Turing
Machines, and you begin with the argument that as long as you deal with
equivalents you are ok, well equivalents need to be, like the word says,
equivalent, so the x86 equivalent to the Turing Machine P needs to
include everything that was in the Turing Machine P, so its behavior
needs to include all the behavior or H.

FAIL.

Now, if you are willing to abandon that your proof is about the actual
Halting Problem of Computation theory, but is only the Olcott must abort
problem, maybe you can make a point for that.

On 7/2/2021 6:32 PM, Andy Walker wrote:
> On 02/07/2021 04:12, Richard Damon wrote:
> [I wrote:]
>>>      There is no essential difference between TMs and real computers.
>>> The only actual difference is that a real computer allows for external
>>> connexions, such as people typing at a keyboard or clicking a mouse, or
>>> a clock interrupt, or a temperature sensor raising an alarm.
>> This is TOTALLY wrong.
>
>     No it isn't.  It isn't even SLIGHTLY wrong, as long as your
> real computer is indeed a finite-state machine.  Cf David's reply,
> and see also below.
>
>>              There is a VERY different 'machinery' used in
>> Turing machines rather than a conventional computer.
>
>     The machinery is irrelevant.  What matters is that both a TM
> and a real computer can be described in terms of what happens at each
> CPU cycle [or near equivalent].  Whether this is described as a state
> transition or as some [typically] binary operation on some bits is a
> matter of taste rather than an essential difference.  There is a
> problem in modern computers if some operations complete [eg] in random
> orders or with ill-defined timings, but that's not exactly an advantage
> when discussing the theory, just yet another source of bugs and route
> for malware.
>
>> A Turing Machine is fundamentally a finite state machine tied as it only
>> input/output a tape reader/writer. [...]
>
>     Indeed.
>
>> Your typical modern comupter is a stored program machine where you have
>> a set of registers, one of which is a program counter, for each step the
>> instruction at the location in memory (and possible some of the
>> following locations) is read, decoded, and executed. This instruction
>> will typically provide some manipulation of the registers, perhaps
>> reading other locations of memory for 'input' to an operation or storing
>> the contents of the operation into a location of memory.
>
>     IOW, it's a FSM with the next state depending on the current
> state of the program counter, the registers, etc., etc.
>
>> Note some of the big differences, the Turing Machine doesn't have
>> 'registers', all it has is one blob called the 'state' which is sort of
>> like the program counter, but rather than defaulting to incrementing,
>> every instruction has the capability of an N-way branch. The other big
>> difference is that The conventional computer has 'random' access, it can
>> just reach out to a fairly arbitray location in memory to get a value,
>> and tends to have some registers for short (or longer) term storage.
>
>     Yes, and ...?  All of that is just a state transition.  Yes,
> for a practical modern computer the number of possible states is
> rather large, but that doesn't affect the theory.  How you describe
> the states and their transitions is a matter of taste and convenience,
> not an essential part of the mechanism.
>
>     [Perhaps also worth pointing out that a microcoded computer
> is effectively a relatively small FSM with a relatively large tape
> representing the computer storage, cf a UTM with a tape containing
> the description of the computer being emulated.]
>
> [...]
>> The problem is that when we try to break down A or B which aren't Turing
>> Machines, it is hard to prove that they don't 'hide' state that allows
>> them to give different results for what seems to be the same input.
>
>     My definitions of "A" and "B" were that "A" was a computer
> with all the expected features, such as arithmetic facilities [eg,
> inc floating point, perhaps vector instructions, pipelining, etc]
> whereas "B" was a computer with much more limited instructions, in
> which, eg, multiplication was implemented by repeated addition as
> a software subroutine rather than by hardware.  Note that there
> have been real computer ranges with such variations [esp, eg, with
> FP implemented in software, or with more or less powerful memory
> management instructions].  In the limit, "B" could be a computer
> with the power [only] to increment, decrement and test against
> zero [with an associated jump], yet still be as powerful, in
> terms of its abstract capabilities [tho' obviously not speed],
> as "A".  Whether an actual program running on "A" is "the same
> as" a program running on "B" is just another of life's insoluble
> problems [equivalent to the HP, in general].
>
>>                                     Yes,
>> if you set ALL of memory (including registers and external storage) to
>> be identical, you will get the same results, but it takes a very details
>> look at a routine that might be called several times to confirm that it
>> will always produce the same result for the same input. This is just
>> automatic with a Turing Machine, If the two spots use copies of the same
>> algorithm, and the tape that this algorithm uses is the same, the
>> results must be the same.
>
>     If you run the same TM with the same input tape twice, of
> course you should get the same results.  But again if you have two
> different TMs, deciding whether they are "equivalent" is another
> variation of the HP.
>
> [...]
>> The fact that he can't translate his logic into actual Turing Machines
>> is a strong proof that his concepts don't actually apply to this
>> particular set of problems.
>
>     I think that's a step too far.  Rather, he doesn't understand
> the relationship between TMs and real computers and languages.  Most
> of us here, perhaps all, would be perfectly happy if PO could show
> whatever-he-thinks-is-worth-showing as C programs, rather than as TMs
> or as some weird table of instructions.  But of course what that would
> actually show is that what he has is obvious and has been known from
> the earliest days of the formal theory of computation.
>

It seems to me that any expert software engineer that knows C and the
x86 language can very easily verify that my H / P are in the correct
halting problem relation and H does correctly decide that P does not halt.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/2/2021 6:33 PM, Richard Damon wrote:
> On 7/2/21 10:26 AM, olcott wrote:
>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>> WRONG. You trace is incorrect. If it was a trace of simulation of P(P),
>>> then we would see the simulation of the machibne H within P. We don't,
>>> therefore this is NOT the proper trace of the simulation.
>>>
>>> FAIL.
>>
>>
>> Since the question is whether or not H must abort the simulation of P on
>> the basis of the behavior of P it is utterly incorrect for H to examine
>> its own behavior. Maybe if I tell you this 150 more times it will start
>> to sink in and you will get it.
>>
>
> No, since the REAL question is whether TURING MACHINE P(P) is halting or
> not, and TURING MACHINE P includes as part of itself that copy of H, the
> behavior of that H is part of the behavior of P, you MUST include it in
> your analysis.

Until the behavior of the input demonstrates an infinite execution
behavior pattern the behavior of H is a pure x86 emulator, thus cannot
possibly have any effect on the behavior of its input.

> Omitting it is like determining the maximum speed of a
> car by just looking at the tires and saying they're the only part that
> touches the road, so we can ignore the rest of the car.
>
> Remember the Theorem you are using is talking about actual Turing
> Machines, and you begin with the argument that as long as you deal with
> equivalents you are ok, well equivalents need to be, like the word says,
> equivalent, so the x86 equivalent to the Turing Machine P needs to
> include everything that was in the Turing Machine P, so its behavior
> needs to include all the behavior or H.
>
> FAIL.
>
> Now, if you are willing to abandon that your proof is about the actual
> Halting Problem of Computation theory, but is only the Olcott must abort
> problem, maybe you can make a point for that.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/2/21 8:06 PM, olcott wrote:
> On 7/2/2021 6:33 PM, Richard Damon wrote:
>> On 7/2/21 10:26 AM, olcott wrote:
>>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>>> WRONG. You trace is incorrect. If it was a trace of simulation of P(P),
>>>> then we would see the simulation of the machibne H within P. We don't,
>>>> therefore this is NOT the proper trace of the simulation.
>>>>
>>>> FAIL.
>>>
>>>
>>> Since the question is whether or not H must abort the simulation of P on
>>> the basis of the behavior of P it is utterly incorrect for H to examine
>>> its own behavior. Maybe if I tell you this 150 more times it will start
>>> to sink in and you will get it.
>>>
>>
>> No, since the REAL question is whether TURING MACHINE P(P) is halting or
>> not, and TURING MACHINE P includes as part of itself that copy of H, the
>> behavior of that H is part of the behavior of P, you MUST include it in
>> your analysis.
>
> Until the behavior of the input demonstrates an infinite execution
> behavior pattern the behavior of H is a pure x86 emulator, thus cannot
> possibly have any effect on the behavior of its input.

What difference does that make about whether you can ignore the behavior
the the part of P that happens to be its copy of the algorithm of H?

Also, once H DOES change its behavior, it has changed the behavior of
its calling machine, and thus when it sees a copy of itself, it needs to
be able to see that THAT code isn't a pure simulator but will also be
able to stop its simulation and affet the behavior the the P that the
first machine was simulating that used that H. The error is that H, like
you, isn't smart enough to see that far ahead.

The REAL logic of what is happening when we run P(P) is as follows:

P uses H to decide P(P).
That first H simulates P(P),
and sees that P is calling H(P,P)
That first H sees that this simulated H is going to simulate P(P)
That first H then detects what it thinks is an infinite recursion and
aborts the simulation and decides that the compation is non-haltimg

The error is that this first H is using 'bad logic' as it SHOULD know
that just as it is deciding to abort its simulation of P(P), that
simulated H will ALSO, if given a bit more time ALSO abort ITS simulaton
of its P(P).

Yes, The fact that H aborts is simulation of P(P) doesn't affect the
halting behavior of that copy of P(P), but it also doesn't actually
force that P(P) to be infinite, since it DOES include a H that will
abort its simulation. If forgets that since the H it is simulating can
abort it simulation that DOES possibly affect the behavior of the
machine that USED that H as part of it. And, it turns out that this P,
if/when it gets the (incorrect) non-halting answer from its include H,
end up halting.

>
>> Omitting it is like determining the maximum speed of a
>> car by just looking at the tires and saying they're the only part that
>> touches the road, so we can ignore the rest of the car.
>>
>> Remember the Theorem you are using is talking about actual Turing
>> Machines, and you begin with the argument that as long as you deal with
>> equivalents you are ok, well equivalents need to be, like the word says,
>> equivalent, so the x86 equivalent to the Turing Machine P needs to
>> include everything that was in the Turing Machine P, so its behavior
>> needs to include all the behavior or H.
>>
>> FAIL.
>>
>> Now, if you are willing to abandon that your proof is about the actual
>> Halting Problem of Computation theory, but is only the Olcott must abort
>> problem, maybe you can make a point for that.
>>
>
>

One fundamental problem with your logic is that BEFORE you can ask the
question of does P(P) Halt, we need to have a fully defined P, and that
means we need a fully defined H.

That means the question you ask of what answer should H give to be right
is an improper question at this time, as H has already been required to
programmed with an algorithm that will give some definite answer.

This question, what answer should H give to be right is just like asking
Joe to truthfully answer if he is going to say No. THAT is the improper
question.

Yes, there IS a definite answer to the question of does P(P) halt? For
the H you have defined, that answer is Yes (because you H has been
defined to say no). Thus For THIS H, the problem isn't undecidable, it
just is one that THIS H will get wrong. Build a different H (call it
H2), then the H^ derived from THAT H (H2^ or P2), will be the case that
this new H2 will get wrong.

There is a point when you can ask that question, and that is before you
define that you have an H, you can ask given that I know I will be asked
to decide on a machine built on the ^ template, what answer can I give,
and when you try to decide on that ^ machine, and when you look at it,
you find that there is NO answer you can give, which shows that no such
machine can exist to correct decide that case, which is EXACTLY what the
proof you are trying to refute says, there can't be a machine that gets
every decision on halting correct.

This doesn't mean that there are machines that don't have an answer to
the Halting Question, because since we can't create the H that answers
that conundrum, it means that we don't have the H^ that doesn't have an
answer, it also doesn't exist. And a non-existent machine not having a
definitive answer to its halting isn't a problem, only machines that
actually exist will either Halt or Not.

On 7/2/2021 8:36 PM, Richard Damon wrote:
> On 7/2/21 8:06 PM, olcott wrote:
>> On 7/2/2021 6:33 PM, Richard Damon wrote:
>>> On 7/2/21 10:26 AM, olcott wrote:
>>>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>>>> WRONG. You trace is incorrect. If it was a trace of simulation of P(P),
>>>>> then we would see the simulation of the machibne H within P. We don't,
>>>>> therefore this is NOT the proper trace of the simulation.
>>>>>
>>>>> FAIL.
>>>>
>>>>
>>>> Since the question is whether or not H must abort the simulation of P on
>>>> the basis of the behavior of P it is utterly incorrect for H to examine
>>>> its own behavior. Maybe if I tell you this 150 more times it will start
>>>> to sink in and you will get it.
>>>>
>>>
>>> No, since the REAL question is whether TURING MACHINE P(P) is halting or
>>> not, and TURING MACHINE P includes as part of itself that copy of H, the
>>> behavior of that H is part of the behavior of P, you MUST include it in
>>> your analysis.
>>
>> Until the behavior of the input demonstrates an infinite execution
>> behavior pattern the behavior of H is a pure x86 emulator, thus cannot
>> possibly have any effect on the behavior of its input.
>
> What difference does that make about whether you can ignore the behavior
> the the part of P that happens to be its copy of the algorithm of H?
>
I know how you love to dishonestly change the subject the same way that
Ben does so that to people hardly paying attention it may seem that your
drivel is a rebuttal. P does not contain a copy of H and you know this.

I wish that I could call you a lying scumbag, but that would not have
the proper professional decorum so I must refrain.

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/2/21 9:57 PM, olcott wrote:
> On 7/2/2021 8:36 PM, Richard Damon wrote:
>> On 7/2/21 8:06 PM, olcott wrote:
>>> On 7/2/2021 6:33 PM, Richard Damon wrote:
>>>> On 7/2/21 10:26 AM, olcott wrote:
>>>>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>>>>> WRONG. You trace is incorrect. If it was a trace of simulation of
>>>>>> P(P),
>>>>>> then we would see the simulation of the machibne H within P. We
>>>>>> don't,
>>>>>> therefore this is NOT the proper trace of the simulation.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>>
>>>>> Since the question is whether or not H must abort the simulation of
>>>>> P on
>>>>> the basis of the behavior of P it is utterly incorrect for H to
>>>>> examine
>>>>> its own behavior. Maybe if I tell you this 150 more times it will
>>>>> start
>>>>> to sink in and you will get it.
>>>>>
>>>>
>>>> No, since the REAL question is whether TURING MACHINE P(P) is
>>>> halting or
>>>> not, and TURING MACHINE P includes as part of itself that copy of H,
>>>> the
>>>> behavior of that H is part of the behavior of P, you MUST include it in
>>>> your analysis.
>>>
>>> Until the behavior of the input demonstrates an infinite execution
>>> behavior pattern the behavior of H is a pure x86 emulator, thus cannot
>>> possibly have any effect on the behavior of its input.
>>
>> What difference does that make about whether you can ignore the behavior
>> the the part of P that happens to be its copy of the algorithm of H?
>>
> I know how you love to dishonestly change the subject the same way that
> Ben does so that to people hardly paying attention it may seem that your
> drivel is a rebuttal. P does not contain a copy of H and you know this.

Back to this dishonest dodge.

Please show how TURING MACHINE P can execute the algorithm of H without
including a copy of it, or having it as an explicit input?

This shows how you absolutely have NO understanding of Turing Machines.

Please show any example of actual Turing Machine code (you know, the
actual set of tuples that define a machine) that uses code from another
machine without including a copy of it in the machine or having it as in
input.

If you can't do that, you have FAILED to prove your idiotic assertion
that a Turing Machine can possible 'call' another machine without
including a explicit copy of it in its code or within its input.

>
> I wish that I could call you a lying scumbag, but that would not have
> the proper professional decorum so I must refrain.
>
> void P(u32 x)
> {
>   u32 Input_Halts = H(x, x);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
>
>

Which isn't a complete Turing Machine Description. It isn't even a
complete program, so the definition even fails the concept of basic
Software Engineering.

On 7/3/2021 8:53 AM, Richard Damon wrote:
> On 7/2/21 9:57 PM, olcott wrote:
>> On 7/2/2021 8:36 PM, Richard Damon wrote:
>>> On 7/2/21 8:06 PM, olcott wrote:
>>>> On 7/2/2021 6:33 PM, Richard Damon wrote:
>>>>> On 7/2/21 10:26 AM, olcott wrote:
>>>>>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>>>>>> WRONG. You trace is incorrect. If it was a trace of simulation of
>>>>>>> P(P),
>>>>>>> then we would see the simulation of the machibne H within P. We
>>>>>>> don't,
>>>>>>> therefore this is NOT the proper trace of the simulation.
>>>>>>>
>>>>>>> FAIL.
>>>>>>
>>>>>>
>>>>>> Since the question is whether or not H must abort the simulation of
>>>>>> P on
>>>>>> the basis of the behavior of P it is utterly incorrect for H to
>>>>>> examine
>>>>>> its own behavior. Maybe if I tell you this 150 more times it will
>>>>>> start
>>>>>> to sink in and you will get it.
>>>>>>
>>>>>
>>>>> No, since the REAL question is whether TURING MACHINE P(P) is
>>>>> halting or
>>>>> not, and TURING MACHINE P includes as part of itself that copy of H,
>>>>> the
>>>>> behavior of that H is part of the behavior of P, you MUST include it in
>>>>> your analysis.
>>>>
>>>> Until the behavior of the input demonstrates an infinite execution
>>>> behavior pattern the behavior of H is a pure x86 emulator, thus cannot
>>>> possibly have any effect on the behavior of its input.
>>>
>>> What difference does that make about whether you can ignore the behavior
>>> the the part of P that happens to be its copy of the algorithm of H?
>>>
>> I know how you love to dishonestly change the subject the same way that
>> Ben does so that to people hardly paying attention it may seem that your
>> drivel is a rebuttal. P does not contain a copy of H and you know this.
>
> Back to this dishonest dodge.
>
> Please show how TURING MACHINE P can execute the algorithm of H without
> including a copy of it, or having it as an explicit input?
>
To make my point complete and easy to understand I use C / x86

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

Since you dishonestly want to continue with rebuttals even after I
totally prove my point it looks like you will never get my point.

Revelation 21:8 King James Version
all liars, shall have their part in the lake which burneth with fire and
brimstone: which is the second death.

Your little troll game may have eternal consequences.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/21 10:43 AM, olcott wrote:
> On 7/3/2021 8:53 AM, Richard Damon wrote:
>> On 7/2/21 9:57 PM, olcott wrote:
>>> On 7/2/2021 8:36 PM, Richard Damon wrote:
>>>> On 7/2/21 8:06 PM, olcott wrote:
>>>>> On 7/2/2021 6:33 PM, Richard Damon wrote:
>>>>>> On 7/2/21 10:26 AM, olcott wrote:
>>>>>>> On 7/2/2021 6:15 AM, Richard Damon wrote:
>>>>>>>> WRONG. You trace is incorrect. If it was a trace of simulation of
>>>>>>>> P(P),
>>>>>>>> then we would see the simulation of the machibne H within P. We
>>>>>>>> don't,
>>>>>>>> therefore this is NOT the proper trace of the simulation.
>>>>>>>>
>>>>>>>> FAIL.
>>>>>>>
>>>>>>>
>>>>>>> Since the question is whether or not H must abort the simulation of
>>>>>>> P on
>>>>>>> the basis of the behavior of P it is utterly incorrect for H to
>>>>>>> examine
>>>>>>> its own behavior. Maybe if I tell you this 150 more times it will
>>>>>>> start
>>>>>>> to sink in and you will get it.
>>>>>>>
>>>>>>
>>>>>> No, since the REAL question is whether TURING MACHINE P(P) is
>>>>>> halting or
>>>>>> not, and TURING MACHINE P includes as part of itself that copy of H,
>>>>>> the
>>>>>> behavior of that H is part of the behavior of P, you MUST include
>>>>>> it in
>>>>>> your analysis.
>>>>>
>>>>> Until the behavior of the input demonstrates an infinite execution
>>>>> behavior pattern the behavior of H is a pure x86 emulator, thus cannot
>>>>> possibly have any effect on the behavior of its input.
>>>>
>>>> What difference does that make about whether you can ignore the
>>>> behavior
>>>> the the part of P that happens to be its copy of the algorithm of H?
>>>>
>>> I know how you love to dishonestly change the subject the same way that
>>> Ben does so that to people hardly paying attention it may seem that your
>>> drivel is a rebuttal. P does not contain a copy of H and you know this.
>>
>> Back to this dishonest dodge.

What is dishonest about it. Just that it shows that your statement is wrong.

>>
>> Please show how TURING MACHINE P can execute the algorithm of H without
>> including a copy of it, or having it as an explicit input?
>>
> To make my point complete and easy to understand I use C / x86

But, you make a claim that it is a Turing Equivalent. PROVE IT.

>
> void P(u32 x)
> {
>   u32 Input_Halts = H(x, x);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> Since you dishonestly want to continue with rebuttals even after I
> totally prove my point it looks like you will never get my point.
>
> Revelation 21:8 King James Version
> all liars, shall have their part in the lake which burneth with fire and
> brimstone: which is the second death.
>
> Your little troll game may have eternal consequences.
>

I.E. you can't show your claim in Turing Machines, because they don't apply.

FALSE PREMISE, UNSOUND LOGIC.
PERIOD.

YOU FAIL.

this is a theory group. get the hell out.

Daniel Pehoushek <pehoushek1@gmail.com> writes:

> this is a theory group. get the hell out.

You can't throw people out. All you can do is filter what you read (if
you use a good newsreader). The best way to make the group better is to
post interesting things. How did your Bob program get on in the
competition?

--
Ben.

On Tuesday, July 6, 2021 at 12:36:41 PM UTC-4, Ben Bacarisse wrote:
> Daniel Pehoushek <pehou...@gmail.com> writes:
>
> > this is a theory group. get the hell out.
> You can't throw people out. All you can do is filter what you read (if
> you use a good newsreader). The best way to make the group better is to
> post interesting things. How did your Bob program get on in the
> competition?
>
> --
> Ben.

well, you are probably right. love the pooh by the way.
the model counting competition 2021 results are
going to be announced friday. the competition
is about computing #P on small boolean
formulas. the competition may be
thought of as advanced ai research.

speaking of posts, do you see my other posts on comp.theory?
not getting any bites, so i am unsure my other posts are "going out".
sincerely daniel

Daniel Pehoushek <pehoushek1@gmail.com> writes:

> speaking of posts, do you see my other posts on comp.theory?
> not getting any bites, so i am unsure my other posts are "going out".

I think so, but I don't know how many posts you are referring to. They
were incomprehensible to me. That might explain the lack of interest.

--
Ben.