On Wednesday, 18 August 2021 at 22:07:23 UTC+8, olcott wrote:
> On 8/18/2021 6:48 AM, Richard Damon wrote:
> > On 8/18/21 12:09 AM, olcott wrote:
> >
> >> While H does nothing to change the behavior of its input
> >> H does do something that changes the behavior of its input.
> >>
> >> By this same reasoning all black cats are white.
> >>
> > Thinking on this, I would like to point out a FUNDAMENTAL problem with
> > all your arguments, you presume that if you come up with some pithy
> > statement that sounds sort of true, you can just assume it to be true
> > and move on from there.
> >
> > This is WRONG.
> >
> > Every statement, other than the fundamental axioms of the system, that
> > everyone agrees to, needs to be proven, actually proven.
> >
> > You don't get to add new axioms to an existing system except with BROAD
> > community support.
> >
> Sure I do. I can create any axioms that I want to as long as they can be
> objectively verified as always consistently true under all conditions.
>
> If some people are simply not bright enough to understand that they are
> always necessarily consistently true then these people are simply
> excluded from my target audience.
>
> The key axiom that I created that my work depends upon is that
> when-so-ever an input would never stop running while H remains in pure
> simulation mode then the input is always correctly decided as never
> halting.
>
> This axiom derives the same correct results for all halting
> computations, for the subset of infinite loops that H recognizes, for
> the subset of infinite recursion that H recognizes and for the simple
> halting problem counter-example programs that I have been providing.
>
> The x86 code that I have provided consistently proves that this axiom is
> correct.

I was also shocked you misinterpret logic implication to nearly the same as
logic AND. And, you have 'too arbitrarily' modified The Halting Problem to
your flavor. I can say nothing but just mind you some points from the visible P.

void P(u32 x) // This P is a future program/function
{ if (H(x, x))
HERE: goto HERE;
}

1. P is written after H is written.
2. P is defined to refute H.

H cannot hard-code P in it. Deciding a specific P is a wrong proof.
In Linz's proof and the wiki page, the given P is not hard-coded. Their proof
take the description of any given arbitrary machine, including the 'description'
of H.

> > Fortunately, many things have already been proven, so we are allowed to
> > rely on existing proofs, but to do that, it requires us to have actually
> > studied the field to know what has been proven.
> >
> > Note, many times I have asked you if you can show someone else who has
> > the same idea. I do this because it has been clear that YOU don't know
> > how to even write a proper proof, so if you can't prove it, you need to
> > rely on statements that others have proven.
> >
> > Maybe you haven't studied logic theory enough to know that rule, but
> > that just says that you have fallen into the same trap that the ancient
> > philosophers did until the worked out the actual rules of logic.
> > Knowledge is built of actual PROOFS, not just fancy rhetorical
> > arguments. There are many things that at first seem to be true, but when
> > we examine them more closely we find that they are not.
> >
> > For instance, many will say that the next term in this sequence:
> > 1, 2, 4, 8, 16 is obviously going to be 32, but in some problems the
> > right answer is 31. This is the case of dividing a circle into areas
> > with complete graphs
> >
> > (https://en.wikipedia.org/wiki/Dividing_a_circle_into_areas)
> >
> > This sort of case shows that intuition and what the simple meaning of
> > words is NOT sufficient to determine truth.
> >
> > Therefore, what you REALLY need to do to make your proof workable, is to
> > look at your fundamental ideas that you base it on, go back to the field
> > to see if someone else has actually proven that idea, and if so, look at
> > the proof to refine what that idea actually means (your big problem is
> > that many of your statements are mostly true, you just have a wrong
> > slant in them).
> >
> > Learn what HAS been proven as a base. Then you can have things you can
> > actually work with to use. The Fundamental are much harder to actually
> > prove than later ideas, because you need to prove the fundamentals from
> > just the barest of axioms.
> >
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

On 8/18/2021 10:28 AM, Malcolm McLean wrote:
> On Wednesday, 18 August 2021 at 14:57:10 UTC+1, olcott wrote:
>>
>> H has no effect on the machine that it simulates until after its halt
>> status decision has been made. This conclusively proves that H can
>> ignore its in execution trace during its halt status analysis.
>>
>> Anyone disagreeing with this is either not intelligent or knowledgeable
>> enough to understand it, or a liar.
>>
>> That H does effect the behavior or its input at some other point is
>> utterly irrelevant to this analysis. We are only answering the single
>> question: Is it correct for H to ignore its own execution trace during
>> its halt status analysis?
>>
> If H is analysing H, it can't ignore the behaviour of H. That's why your results
> are wrong despite the execution trace seeming to show a non-halting
> behaviour.
>

Because H only acts as a pure simulator of its input until after
its halt status decision has been made it has no behavior that
can possibly effect the behavior of its input. Because of this H
screens out its own address range in every execution trace that
it examines. This is why we never see any instructions of H in
any execution trace after an input calls H.

The above proves itself true entirely on the basis of the meaning
of its words. There is no possible correct rebuttal there is only
a failure to comprehend. If you believe that there is a correct
rebuttal please provide it and I will point out your error.

--
Copyright 2021 Pete Olcott

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

On 8/18/2021 10:38 AM, wij wrote:
> On Wednesday, 18 August 2021 at 22:07:23 UTC+8, olcott wrote:
>> On 8/18/2021 6:48 AM, Richard Damon wrote:
>>> On 8/18/21 12:09 AM, olcott wrote:
>>>
>>>> While H does nothing to change the behavior of its input
>>>> H does do something that changes the behavior of its input.
>>>>
>>>> By this same reasoning all black cats are white.
>>>>
>>> Thinking on this, I would like to point out a FUNDAMENTAL problem with
>>> all your arguments, you presume that if you come up with some pithy
>>> statement that sounds sort of true, you can just assume it to be true
>>> and move on from there.
>>>
>>> This is WRONG.
>>>
>>> Every statement, other than the fundamental axioms of the system, that
>>> everyone agrees to, needs to be proven, actually proven.
>>>
>>> You don't get to add new axioms to an existing system except with BROAD
>>> community support.
>>>
>> Sure I do. I can create any axioms that I want to as long as they can be
>> objectively verified as always consistently true under all conditions.
>>
>> If some people are simply not bright enough to understand that they are
>> always necessarily consistently true then these people are simply
>> excluded from my target audience.
>>
>> The key axiom that I created that my work depends upon is that
>> when-so-ever an input would never stop running while H remains in pure
>> simulation mode then the input is always correctly decided as never
>> halting.
>>
>> This axiom derives the same correct results for all halting
>> computations, for the subset of infinite loops that H recognizes, for
>> the subset of infinite recursion that H recognizes and for the simple
>> halting problem counter-example programs that I have been providing.
>>
>> The x86 code that I have provided consistently proves that this axiom is
>> correct.
>
> I was also shocked you misinterpret logic implication to nearly the same as
> logic AND. And, you have 'too arbitrarily' modified The Halting Problem to
> your flavor. I can say nothing but just mind you some points from the visible P.
>

I did not modify the actual halting problem. I merely examined all of
the details of using a simulating halt decider. No one has ever done
this before to the extent that I have. Because of this I must explain
that a simulating halt decider has two possible correct actions:

(1) Allow the simulation of its input to complete while remaining in
pure simulation mode.

(2) Abort its simulation of its input as soon as the simulating halt
decider determines that the input would never stop running while it
remains in pure simulation mode.

> void P(u32 x) // This P is a future program/function
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> 1. P is written after H is written.
> 2. P is defined to refute H.
>
> H cannot hard-code P in it. Deciding a specific P is a wrong proof.
> In Linz's proof and the wiki page, the given P is not hard-coded. Their proof
> take the description of any given arbitrary machine, including the 'description'
> of H.
>

H simulates whatever the machine-code address of its input specifies
using an x86 emulator. There is no function written in C and translated
to 32-bit x86 machine language using the Microsoft C compiler that H
cannot simulate because its x86 emulation is provided by a very robust
3rd party x86 emulator. I had to adapt the x86 emulator so that it could
directly execute the COFF object file output of the Microsoft C compiler.

H acts as a simulating halt decider with the two possible correct
actions specified above.

>>> Fortunately, many things have already been proven, so we are allowed to
>>> rely on existing proofs, but to do that, it requires us to have actually
>>> studied the field to know what has been proven.
>>>
>>> Note, many times I have asked you if you can show someone else who has
>>> the same idea. I do this because it has been clear that YOU don't know
>>> how to even write a proper proof, so if you can't prove it, you need to
>>> rely on statements that others have proven.
>>>
>>> Maybe you haven't studied logic theory enough to know that rule, but
>>> that just says that you have fallen into the same trap that the ancient
>>> philosophers did until the worked out the actual rules of logic.
>>> Knowledge is built of actual PROOFS, not just fancy rhetorical
>>> arguments. There are many things that at first seem to be true, but when
>>> we examine them more closely we find that they are not.
>>>
>>> For instance, many will say that the next term in this sequence:
>>> 1, 2, 4, 8, 16 is obviously going to be 32, but in some problems the
>>> right answer is 31. This is the case of dividing a circle into areas
>>> with complete graphs
>>>
>>> (https://en.wikipedia.org/wiki/Dividing_a_circle_into_areas)
>>>
>>> This sort of case shows that intuition and what the simple meaning of
>>> words is NOT sufficient to determine truth.
>>>
>>> Therefore, what you REALLY need to do to make your proof workable, is to
>>> look at your fundamental ideas that you base it on, go back to the field
>>> to see if someone else has actually proven that idea, and if so, look at
>>> the proof to refine what that idea actually means (your big problem is
>>> that many of your statements are mostly true, you just have a wrong
>>> slant in them).
>>>
>>> Learn what HAS been proven as a base. Then you can have things you can
>>> actually work with to use. The Fundamental are much harder to actually
>>> prove than later ideas, because you need to prove the fundamentals from
>>> just the barest of axioms.
>>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/17/2021 7:02 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/17/2021 5:14 PM, Ben Bacarisse wrote:
>>
>>>> The facts come from you. They are not a matter of opinion. P(P) halts.
>>>> H(P,P) == 0.
>> ...
>>>> You are happy with that answer, but I can specify a function you can't
>>>> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
>>>> You don't get to choose what the "correct" answer is, so your only
>>>> option if to ignore the challenge.
>>>
>>> At this point I expect and require that those seeking an actual honest
>>> dialogue use the basis that I provided to verify that H does decide
>>> the halt status of its inputs correctly. Everyone else is written off
>>> as dishonest.
>> That's up to you. I can't stop you wasting time on a function no one
>> cares about, but you know you can't write the function I specified, so
>> you are back where you started 17 years ago. There are still
>> undecidable sets.
>
> The function does meet the spec

You don't know that because you have not asked for the proper spec. You
have not even accepted my challenge. Are you accepting the challenge
and proposing H as an implementation without knowing the full spec? I'm
happy for you to say yes if that is what you want to do.

> I certainly won't make any denigrating remarks about this.

Why not? You do that all the time. Do you think I care one iota about
your opinion of me?

--
Ben.

On 8/18/2021 2:44 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/17/2021 7:02 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/17/2021 5:14 PM, Ben Bacarisse wrote:
>>>
>>>>> The facts come from you. They are not a matter of opinion. P(P) halts.
>>>>> H(P,P) == 0.
>>> ...
>>>>> You are happy with that answer, but I can specify a function you can't
>>>>> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
>>>>> You don't get to choose what the "correct" answer is, so your only
>>>>> option if to ignore the challenge.
>>>>
>>>> At this point I expect and require that those seeking an actual honest
>>>> dialogue use the basis that I provided to verify that H does decide
>>>> the halt status of its inputs correctly. Everyone else is written off
>>>> as dishonest.
>>> That's up to you. I can't stop you wasting time on a function no one
>>> cares about, but you know you can't write the function I specified, so
>>> you are back where you started 17 years ago. There are still
>>> undecidable sets.
>>
>> The function does meet the spec
>
> You don't know that because you have not asked for the proper spec. You
> have not even accepted my challenge. Are you accepting the challenge
> and proposing H as an implementation without knowing the full spec? I'm
> happy for you to say yes if that is what you want to do.

I know what the spec is:

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program
and an input, whether the program will finish running, or continue
to run forever. https://en.wikipedia.org/wiki/Halting_problem

description of a Turing machine M (not a Turing Machine)
description of an arbitrary computer program (not an executable program)

What is your opinion of what the spec is?

>
>> I certainly won't make any denigrating remarks about this.
>
> Why not? You do that all the time. Do you think I care one iota about
> your opinion of me?
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> Let's get back to something that you seem to know well:

Why start again? You just walked away from this discussion before.
I'll just bring up the errors you made in those threads again...

> Ĥ.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
>
> Can you understand that Ĥ applied to ⟨Ĥ⟩ would never stop running if
> the machine at Ĥ.qx was a UTM?

Sigh. I'm pretty sure I know what you are trying to say (it's "Halts
with line 15 commented out" again), and I really want to agree with it
(again) but what you ask is literal nonsense. If the machine at Ĥ.qx is
a UTM and not H (well, technically it's H' and not H) then asking what Ĥ
applied to ⟨Ĥ⟩ does is, at best, ambiguous and at worst just daft
because the name Ĥ is meaningless unless the embedded TM at qx is H
which is not a UTM. It's what the "hat" means.

If J is a TM like H but without the states and code that makes it stop
being a UTM (in some cases) then, yes, Ĵ applied to ⟨Ĵ⟩ is a non-halting
computation. This wording, whilst correct, does not cloud the water
enough. Your use of Ĥ when it's not H at qx is central to you game so
you won't accept this way of putting it.

And have you changed your mind about the computation represented by a
tape containing ⟨Ĥ⟩ ⟨Ĥ⟩? You falsely asserted, point blank, that that
tape represents a non-halting computation.

--
Ben.

On Wednesday, August 18, 2021 at 6:50:34 AM UTC-7, olcott wrote:
> H does exist. I spent 1.5 years creating the x86utm operating system. It
> took me three full months to get context switching correctly so that
> Nested simulation of virtual machines could operate correctly to an
> arbitrary recursive depth.
>
> I had to make sure that I had everything working properly because I do
> intend to publish as soon as I have words that are sufficiently clear to
> prove my point. I will have to refactor my code so that it is cleaner.

You must be aware that no moderated group will accept your x86
equivalence approach as a proof of anything. So your work is
quixotic. No amount of refactoring will ever help. No words exist
that will justify it. Be prepared to lose.

On 8/18/2021 3:03 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Let's get back to something that you seem to know well:
>
> Why start again? You just walked away from this discussion before.
> I'll just bring up the errors you made in those threads again...
>
>> Ĥ.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
>>
>> Can you understand that Ĥ applied to ⟨Ĥ⟩ would never stop running if
>> the machine at Ĥ.qx was a UTM?
>
> Sigh. I'm pretty sure I know what you are trying to say (it's "Halts
> with line 15 commented out" again), and I really want to agree with it
> (again) but what you ask is literal nonsense. If the machine at Ĥ.qx is
> a UTM and not H (well, technically it's H' and not H) then asking what Ĥ
> applied to ⟨Ĥ⟩ does is, at best, ambiguous and at worst just daft
> because the name Ĥ is meaningless unless the embedded TM at qx is H
> which is not a UTM. It's what the "hat" means.
>
> If J is a TM like H but without the states and code that makes it stop
> being a UTM (in some cases) then, yes, Ĵ applied to ⟨Ĵ⟩ is a non-halting
> computation. This wording, whilst correct, does not cloud the water
> enough.

Ah great a breakthrough.

> Your use of Ĥ when it's not H at qx is central to you game so
> you won't accept this way of putting it.
>

When we adapt Ĥ so that the machine at Ĥ.qx is a UTM and we call this
new machine Ĵ, then Ĵ applied to ⟨Ĵ⟩ never halts.

> And have you changed your mind about the computation represented by a
> tape containing ⟨Ĥ⟩ ⟨Ĥ⟩? You falsely asserted, point blank, that that
> tape represents a non-halting computation.
>

When we know that Ĵ applied to ⟨Ĵ⟩ never halts then we also know that Ĥ
applied to ⟨Ĥ⟩ never stops running unless the simulating halt decider at
Ĥ.qx aborts the simulation of its input.

If we accept the statement that every input to simulating halt decider H
that never halts while H remains in pure simulation mode is a
computation that never halts then we have this axiom basis to determined
that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

--
Copyright 2021 Pete Olcott

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

On 8/18/2021 3:05 PM, dklei...@gmail.com wrote:
> On Wednesday, August 18, 2021 at 6:50:34 AM UTC-7, olcott wrote:
>> H does exist. I spent 1.5 years creating the x86utm operating system. It
>> took me three full months to get context switching correctly so that
>> Nested simulation of virtual machines could operate correctly to an
>> arbitrary recursive depth.
>>
>> I had to make sure that I had everything working properly because I do
>> intend to publish as soon as I have words that are sufficiently clear to
>> prove my point. I will have to refactor my code so that it is cleaner.
>
> You must be aware that no moderated group will accept your x86
> equivalence approach as a proof of anything. So your work is
> quixotic. No amount of refactoring will ever help. No words exist
> that will justify it. Be prepared to lose.
>

No I do not accept this because of the Turing equivalence between the
H(P,P) computation and the simplified Linz Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
computation.

People that fail to sufficiently understand Turing equivalence may
disagree. They are not in my target audience.

--
Copyright 2021 Pete Olcott

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

On 8/17/2021 6:33 PM, olcott wrote:
> On 8/17/2021 8:19 PM, Chris M. Thomasson wrote:
>> On 8/17/2021 6:15 PM, olcott wrote:
>>> On 8/17/2021 8:11 PM, Chris M. Thomasson wrote:
>>>> On 8/17/2021 5:50 PM, Richard Damon wrote:
>>>>> On 8/17/21 7:18 PM, Chris M. Thomasson wrote:
>>>>>
>>>>>>
>>>>>> Can he emulate lock cmpxchg?
>>>>>
>>>>> It is very possible to emulate ANY instruction. Some require a bit
>>>>> more
>>>>> care than others.
>>>>>
>>>>> Since is emulator is really only emulating a single thread of
>>>>> execution,
>>>>> so things like locks are really not that important.
>>>>>
>>>>
>>>> Okay, well does he have cmpxchg, xadd, xchg, completed? Just wondering.
>>>
>>> https://github.com/wfeldt/libx86emu
>>>
>>
>> Yikes! I forgot that 386 does not support CMPXCHG or XADD, my bad,
>> sorry! It does have XCHG. Mixed in some 486. ;^o
>
> It might even do Pentium instructions:
> https://en.wikipedia.org/wiki/X86_instruction_listings
>
> I only need a tiny subset of the 80386 instructions so that is why I
> refer to its as being capable of 80386 emulation.
>

Oh, for some reason I thought your work can emulate 386 programs, that
are unknown to you.

On 8/18/2021 5:51 PM, Chris M. Thomasson wrote:
> On 8/17/2021 6:33 PM, olcott wrote:
>> On 8/17/2021 8:19 PM, Chris M. Thomasson wrote:
>>> On 8/17/2021 6:15 PM, olcott wrote:
>>>> On 8/17/2021 8:11 PM, Chris M. Thomasson wrote:
>>>>> On 8/17/2021 5:50 PM, Richard Damon wrote:
>>>>>> On 8/17/21 7:18 PM, Chris M. Thomasson wrote:
>>>>>>
>>>>>>>
>>>>>>> Can he emulate lock cmpxchg?
>>>>>>
>>>>>> It is very possible to emulate ANY instruction. Some require a bit
>>>>>> more
>>>>>> care than others.
>>>>>>
>>>>>> Since is emulator is really only emulating a single thread of
>>>>>> execution,
>>>>>> so things like locks are really not that important.
>>>>>>
>>>>>
>>>>> Okay, well does he have cmpxchg, xadd, xchg, completed? Just
>>>>> wondering.
>>>>
>>>> https://github.com/wfeldt/libx86emu
>>>>
>>>
>>> Yikes! I forgot that 386 does not support CMPXCHG or XADD, my bad,
>>> sorry! It does have XCHG. Mixed in some 486. ;^o
>>
>> It might even do Pentium instructions:
>> https://en.wikipedia.org/wiki/X86_instruction_listings
>>
>> I only need a tiny subset of the 80386 instructions so that is why I
>> refer to its as being capable of 80386 emulation.
>>
>
> Oh, for some reason I thought your work can emulate 386 programs, that
> are unknown to you.

You just have to make sure to pay attention to everything that I said to
get that answer.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/18/2021 5:51 PM, Chris M. Thomasson wrote:

>> Oh, for some reason I thought your work can emulate 386 programs, that
>> are unknown to you.
>
> You just have to make sure to pay attention to everything that I said
> to get that answer.

And you need to apply a huge dose of sceptical revisionism. For example
when you said, back in Dec 2018:

"I now have an actual H that decides actual halting for an actual (Ĥ,
Ĥ) input pair. I have to write the UTM to execute this code, that
should not take very long. The key thing is the H and Ĥ are 100%
fully encoded as actual Turing machines."

What you meant was that don't have any actual Turing machines but maybe
some fragments of C. You were not preparing to write a UTM but to find
an x86 emulator. And something (not sure what) did take a long time --
much longer than writing a UTM would take. And the key things is that H
and Ĥ are not at all fully encoded as actual Turing machines.

I'm not sure anyone could have worked this out from just "paying
attention". It took months for this claim to unravel.

--
Ben.

On 8/18/21 10:07 AM, olcott wrote:
> On 8/18/2021 6:48 AM, Richard Damon wrote:
>> On 8/18/21 12:09 AM, olcott wrote:
>>
>>> While H does nothing to change the behavior of its input
>>> H does do something that changes the behavior of its input.
>>>
>>> By this same reasoning all black cats are white.
>>>
>> Thinking on this, I would like to point out a FUNDAMENTAL problem with
>> all your arguments, you presume that if you come up with some pithy
>> statement that sounds sort of true, you can just assume it to be true
>> and move on from there.
>>
>> This is WRONG.
>>
>> Every statement, other than the fundamental axioms of the system, that
>> everyone agrees to, needs to be proven, actually proven.
>>
>> You don't get to add new axioms to an existing system except with BROAD
>> community support.
>>
>
> Sure I do. I can create any axioms that I want to as long as they can be
> objectively verified as always consistently true under all conditions.

No, you can't, Axioms, the accepted while unproven statements must be
agreed by the field.

If you can actually PROVE them, then they don't need to be taken as axioms.

Now, if they can be OBJECTIVELY verified from the accepted truths, then
they are theorems, not axiom, but you have yet to prove any of your
statement.

This is especially ironic since you also make the claim that unless you
can analytically prove it, it isn't true.

FAIL.

Your statement basically proves that your entire logic is outside the
the logic of the system, and thus it UNSOUND and has ZERO application to
the theory. It also seems to imply tha that you have taken yourself not
only out of Computation Theory, but TOTALLY out of the basic theory of
Logic, since you don't seem to accept the basics of Axiometric logic
(that the Axioms are agreed to by those in the field).

>
> If some people are simply not bright enough to understand that they are
> always necessarily consistently true then these people are simply
> excluded from my target audience.

Seems like a great example of Dunning-Kruger in effect. You make up a
truth and just can't understand why others don't fall for your con.

>
> The key axiom that I created that my work depends upon is that
> when-so-ever an input would never stop running while H remains in pure
> simulation mode then the input is always correctly decided as never
> halting.

Which is pure garbage thinking. UNSOUND as is your mind.

FAIL.

>
> This axiom derives the same correct results for all halting
> computations, for the subset of infinite loops that H recognizes, for
> the subset of infinite recursion that H recognizes and for the simple
> halting problem counter-example programs that I have been providing.

UNSOUND.

>
> The x86 code that I have provided consistently proves that this axiom is
> correct.

FALSE, UNSOUND
>
>> Fortunately, many things have already been proven, so we are allowed to
>> rely on existing proofs, but to do that, it requires us to have actually
>> studied the field to know what has been proven.
>>
>> Note, many times I have asked you if you can show someone else who has
>> the same idea. I do this because it has been clear that YOU don't know
>> how to even write a proper proof, so if you can't prove it, you need to
>> rely on statements that others have proven.
>>
>> Maybe you haven't studied logic theory enough to know that rule, but
>> that just says that you have fallen into the same trap that the ancient
>> philosophers did until the worked out the actual rules of logic.
>> Knowledge is built of actual PROOFS, not just fancy rhetorical
>> arguments. There are many things that at first seem to be true, but when
>> we examine them more closely we find that they are not.
>>
>> For instance, many will say that the next term in this sequence:
>> 1, 2, 4, 8, 16 is obviously going to be 32, but in some problems the
>> right answer is 31. This is the case of dividing a circle into areas
>> with complete graphs
>>
>> (https://en.wikipedia.org/wiki/Dividing_a_circle_into_areas)
>>
>> This sort of case shows that intuition and what the simple meaning of
>> words is NOT sufficient to determine truth.
>>
>> Therefore, what you REALLY need to do to make your proof workable, is to
>> look at your fundamental ideas that you base it on, go back to the field
>> to see if someone else has actually proven that idea, and if so, look at
>> the proof to refine what that idea actually means (your big problem is
>> that many of your statements are mostly true, you just have a wrong
>> slant in them).
>>
>> Learn what HAS been proven as a base. Then you can have things you can
>> actually work with to use. The Fundamental are much harder to actually
>> prove than later ideas, because you need to prove the fundamentals from
>> just the barest of axioms.
>>
>
>

Simple Theorem with Proof: Peter Olcott's ideas are worthless.

The definition of an inconsistent logic system is one which can prove a
statement and its complement at the same time.

For H^ developed per the proofs in view, it HAS been shown that H^(<H^>)
when run as an independent machine is a Halting Computation.

Peter has 'proved' that H(<H^>,<H^>) saying non-halting is correct
because of is logic.

Because H^ is claimed to be a compuation, by the DEFINITION of a
computaiton, all copies of H^ will act the same.

Thus, Peter's proof has shown that H^(<H^>) is both a Halting and a
non-halting computation.

Thus Peter's logic system is inconsistent.

It is well established that in ANY logic system that is inconsistent it
is possible to eventually prove (and disprove by proving the opposite)
ANY statement imagined that can be expressed in the system.

A logic system that can't distinguish any truth from falsehood is by
definition worthless.

ERGO, Peter Olcotts whole system is not worth the electronic paper it is
(or isn't) written on.

Give it up Peter, you have basically dug a hole so deep here that you
probably can't get out of it.

On 8/18/21 9:57 AM, olcott wrote:
> On 8/18/2021 5:26 AM, Richard Damon wrote:
>> On 8/18/21 12:09 AM, olcott wrote:
>>> On 8/17/2021 10:37 PM, Richard Damon wrote:
>>>> On 8/17/21 11:17 PM, olcott wrote:
>>>>> On 8/17/2021 10:10 PM, Richard Damon wrote:
>>>>>> On 8/17/21 10:50 PM, olcott wrote:
>>>>>>> On 8/17/2021 9:36 PM, Richard Damon wrote:
>>>>>>>> On 8/17/21 10:04 PM, olcott wrote:
>>>>>>>>> On 8/17/2021 8:49 PM, Richard Damon wrote:
>>>>>>>>>> On 8/17/21 9:40 PM, olcott wrote:
>>>>>>>>>>> On 8/17/2021 8:35 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/17/21 9:24 PM, olcott wrote:
>>>>>>>>>>>>> On 8/17/2021 8:17 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> That you keep erasing these words rather than carefully
>>>>>>>>>>>>>>>>> critqueing
>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>> one of them sufficiently proves that you are dishonest:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --Because H only acts as a pure simulator of its input
>>>>>>>>>>>>>>>>> --until after its halt status decision has been made it
>>>>>>>>>>>>>>>>> --has no behavior that can possibly effect the behavior
>>>>>>>>>>>>>>>>> --of its input. Because of this H screens out its own
>>>>>>>>>>>>>>>>> --address range in every execution trace that it examines.
>>>>>>>>>>>>>>>>> --This is why we never see any instructions of H in any
>>>>>>>>>>>>>>>>> --execution trace after an input calls H.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Pure simulator *until*, Then it isn't because it
>>>>>>>>>>>>>>>> terminates its
>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is this key fact that allows it to ignore its own code
>>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>> making its halt status decision. The entire time that it is
>>>>>>>>>>>>>>> making its
>>>>>>>>>>>>>>> halt status decision <it is> a pure simulator.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But then it isn't, so the copy that it was simulating wasn't
>>>>>>>>>>>>>> either.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It <is> a pure simulator until after it makes its halt status
>>>>>>>>>>>>> decision
>>>>>>>>>>>>> therefore it <can> ignore its own code <while> it is making
>>>>>>>>>>>>> this
>>>>>>>>>>>>> halt
>>>>>>>>>>>>> status decision.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And then it isn't, and so it NEVER was. UNSOUND LOGIC.
>>>>>>>>>>>
>>>>>>>>>>> X = "H is a pure simulator while it is making its halt status
>>>>>>>>>>> decision"
>>>>>>>>>>>
>>>>>>>>>>> You are concluding that X is not true on the basis that X is
>>>>>>>>>>> true?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am says that the assertion that "H IS a pure simulator" is not
>>>>>>>>>> true.
>>>>>>>>>
>>>>>>>>> I am saying that H is a pure simulator some of the time and you
>>>>>>>>> are
>>>>>>>>> saying no I am wrong because H is not a pure simulator all of the
>>>>>>>>> time
>>>>>>>>> then it is not a pure simulator some of the time.
>>>>>>>>
>>>>>>>> Something can't really be a pure simulator part of the time.
>>>>>>>
>>>>>>> Sure it can and in fact H is a pure simulator for the entire time
>>>>>>> that
>>>>>>> it could otherwise possibly effect the behavior of its input. This
>>>>>>> seems
>>>>>>> to be beyond your capacity to understand.
>>>>>>>
>>>>>>
>>>>>> No, It can't. PERIOD.
>>>>>>
>>>>>> H can act like a pure simulator for the part of the trace that it
>>>>>> runs,
>>>>>> but H is NOT a pure simulator, at least as far as transformation
>>>>>> rules
>>>>>> for copies of it in the simulation.
>>>>>>
>>>>>
>>>>> Every recursive invocation of H continues to act like a pure simulator
>>>>> until after H makes it halt status decision.
>>>>
>>>> UNSOUND.
>>>>
>>>> Since H at some point will STOP being a pure simulator, its affect on
>>>> the machine CALLING it is NOT the same as a Pure Simulator.
>>>>
>>>
>>> While H does nothing to change the behavior of its input
>>> H does do something that changes the behavior of its input.
>>
>> Not what I said.
>>
>
> It is what you implied.
>
>> H does affect the machine that uses it.
>>
>
> H has no effect on the machine that it simulates until after its halt
> status decision has been made. This conclusively proves that H can
> ignore its in execution trace during its halt status analysis.

No, that is NOT a proof. What establish axiom or theorem are you basing
this 'proof' on.

FAIL

UNSOUND.

>
> Anyone disagreeing with this is either not intelligent or knowledgeable
> enough to understand it, or a liar.
>

Anyone making such a statement is proving that they are an ignoramous.

> That H does effect the behavior or its input at some other point is
> utterly irrelevant to this analysis. We are only answering the single
> question: Is it correct for H to ignore its own execution trace during
> its halt status analysis?

Which you have NOT established. Since any copy of your H, if run long
enopugh WILL abort its simulation (or it is the Hn that doesn't answer
so starts off wrong). It is UNSOUND logic for H to presume that the H is
is simulating will not abort its simulation.

Remember, YOU have established that the act of aborting the simulation
doesn't actually change the behavior of the machine it is simulating,
therefore it is valid to take that exact same input and run it with a
truely pure simulator, i.e. a REAL UTM, and when we do, we see that in
that case, the input will proceed to the point where its H will decide
to abort is simulation, return the non-halting result, and that machine
will then Halt.

Since the simulating machine aborting hasn't changed the 'real' behavior
of the machine, only how much we have seen, it is thus clear that <H^>
applied to <H^> is actually a halting computation, and H was WRONG in
deciding elsewise, BECAUSE it used the UNSOUND logic of assuming that
the simulated H would never abort its simulation.

FFFFFFFFFF AA IIIIIIIIII LL
FF AA AA II LL
FF AA AA II LL
FFFFFF AAAAAAAAAA II LL
FF AA AA II LL
FF AA AA II LL
FF AA AA IIIIIIIIII LLLLLLLLLL

On 8/18/2021 6:32 PM, Richard Damon wrote:
> On 8/18/21 10:07 AM, olcott wrote:
>> On 8/18/2021 6:48 AM, Richard Damon wrote:
>>> On 8/18/21 12:09 AM, olcott wrote:
>>>
>>>> While H does nothing to change the behavior of its input
>>>> H does do something that changes the behavior of its input.
>>>>
>>>> By this same reasoning all black cats are white.
>>>>
>>> Thinking on this, I would like to point out a FUNDAMENTAL problem with
>>> all your arguments, you presume that if you come up with some pithy
>>> statement that sounds sort of true, you can just assume it to be true
>>> and move on from there.
>>>
>>> This is WRONG.
>>>
>>> Every statement, other than the fundamental axioms of the system, that
>>> everyone agrees to, needs to be proven, actually proven.
>>>
>>> You don't get to add new axioms to an existing system except with BROAD
>>> community support.
>>>
>>
>> Sure I do. I can create any axioms that I want to as long as they can be
>> objectively verified as always consistently true under all conditions.
>
> No, you can't, Axioms, the accepted while unproven statements must be
> agreed by the field.
>
> If you can actually PROVE them, then they don't need to be taken as axioms.
>
> Now, if they can be OBJECTIVELY verified from the accepted truths, then
> they are theorems, not axiom, but you have yet to prove any of your
> statement.
>

Yes theorem would be a more apt term.

Because H only acts as a pure simulator of its input until after
its halt status decision has been made it has no behavior that
can possibly effect the behavior of its input. Because of this H
screens out its own address range in every execution trace that
it examines. This is why we never see any instructions of H in
any execution trace after an input calls H.

The above proves itself true entirely on the basis of the meaning
of its words. There is no possible correct rebuttal there is only
a failure to comprehend. If you believe that there is a correct
rebuttal please provide it and I will point out your error.

> This is especially ironic since you also make the claim that unless you
> can analytically prove it, it isn't true.
>
> FAIL.
>
> Your statement basically proves that your entire logic is outside the
> the logic of the system, and thus it UNSOUND and has ZERO application to
> the theory. It also seems to imply tha that you have taken yourself not
> only out of Computation Theory, but TOTALLY out of the basic theory of
> Logic, since you don't seem to accept the basics of Axiometric logic
> (that the Axioms are agreed to by those in the field).
>
>>
>> If some people are simply not bright enough to understand that they are
>> always necessarily consistently true then these people are simply
>> excluded from my target audience.
>
> Seems like a great example of Dunning-Kruger in effect. You make up a
> truth and just can't understand why others don't fall for your con.
>
>>
>> The key axiom that I created that my work depends upon is that
>> when-so-ever an input would never stop running while H remains in pure
>> simulation mode then the input is always correctly decided as never
>> halting.
>
> Which is pure garbage thinking. UNSOUND as is your mind.

Dogmatic statements such as this count as less than no rebuttal at all.

>
> FAIL.
>
>>
>> This axiom derives the same correct results for all halting
>> computations, for the subset of infinite loops that H recognizes, for
>> the subset of infinite recursion that H recognizes and for the simple
>> halting problem counter-example programs that I have been providing.
>
>
> UNSOUND.
>
>>
>> The x86 code that I have provided consistently proves that this axiom is
>> correct.
>
>
> FALSE, UNSOUND
>>
>>> Fortunately, many things have already been proven, so we are allowed to
>>> rely on existing proofs, but to do that, it requires us to have actually
>>> studied the field to know what has been proven.
>>>
>>> Note, many times I have asked you if you can show someone else who has
>>> the same idea. I do this because it has been clear that YOU don't know
>>> how to even write a proper proof, so if you can't prove it, you need to
>>> rely on statements that others have proven.
>>>
>>> Maybe you haven't studied logic theory enough to know that rule, but
>>> that just says that you have fallen into the same trap that the ancient
>>> philosophers did until the worked out the actual rules of logic.
>>> Knowledge is built of actual PROOFS, not just fancy rhetorical
>>> arguments. There are many things that at first seem to be true, but when
>>> we examine them more closely we find that they are not.
>>>
>>> For instance, many will say that the next term in this sequence:
>>> 1, 2, 4, 8, 16 is obviously going to be 32, but in some problems the
>>> right answer is 31. This is the case of dividing a circle into areas
>>> with complete graphs
>>>
>>> (https://en.wikipedia.org/wiki/Dividing_a_circle_into_areas)
>>>
>>> This sort of case shows that intuition and what the simple meaning of
>>> words is NOT sufficient to determine truth.
>>>
>>> Therefore, what you REALLY need to do to make your proof workable, is to
>>> look at your fundamental ideas that you base it on, go back to the field
>>> to see if someone else has actually proven that idea, and if so, look at
>>> the proof to refine what that idea actually means (your big problem is
>>> that many of your statements are mostly true, you just have a wrong
>>> slant in them).
>>>
>>> Learn what HAS been proven as a base. Then you can have things you can
>>> actually work with to use. The Fundamental are much harder to actually
>>> prove than later ideas, because you need to prove the fundamentals from
>>> just the barest of axioms.
>>>
>>
>>
>
> Simple Theorem with Proof: Peter Olcott's ideas are worthless.
>
> The definition of an inconsistent logic system is one which can prove a
> statement and its complement at the same time.
>
> For H^ developed per the proofs in view, it HAS been shown that H^(<H^>)
> when run as an independent machine is a Halting Computation.
>
> Peter has 'proved' that H(<H^>,<H^>) saying non-halting is correct
> because of is logic.
>
> Because H^ is claimed to be a compuation, by the DEFINITION of a
> computaiton, all copies of H^ will act the same.
>
> Thus, Peter's proof has shown that H^(<H^>) is both a Halting and a
> non-halting computation.
>
> Thus Peter's logic system is inconsistent.
>
> It is well established that in ANY logic system that is inconsistent it
> is possible to eventually prove (and disprove by proving the opposite)
> ANY statement imagined that can be expressed in the system.
>
> A logic system that can't distinguish any truth from falsehood is by
> definition worthless.
>
> ERGO, Peter Olcotts whole system is not worth the electronic paper it is
> (or isn't) written on.
>
> Give it up Peter, you have basically dug a hole so deep here that you
> probably can't get out of it.
>

--
Copyright 2021 Pete Olcott

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

On 8/18/21 4:45 PM, olcott wrote:
> On 8/18/2021 3:05 PM, dklei...@gmail.com wrote:
>> On Wednesday, August 18, 2021 at 6:50:34 AM UTC-7, olcott wrote:
>>> H does exist. I spent 1.5 years creating the x86utm operating system. It
>>> took me three full months to get context switching correctly so that
>>> Nested simulation of virtual machines could operate correctly to an
>>> arbitrary recursive depth.
>>>
>>> I had to make sure that I had everything working properly because I do
>>> intend to publish as soon as I have words that are sufficiently clear to
>>> prove my point. I will have to refactor my code so that it is cleaner.
>>
>> You must be aware that no moderated group will accept your x86
>> equivalence approach as a proof of anything. So your work is
>> quixotic. No amount of refactoring will ever help. No words exist
>> that will justify it. Be prepared to lose.
>>
>
> No I do not accept this because of the Turing equivalence between the
> H(P,P) computation and the simplified Linz Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
> computation.
>
> People that fail to sufficiently understand Turing equivalence may
> disagree. They are not in my target audience.
>
>

You actually have just claimed the Turing Equivalence, which you really
need to PROVE to use, and to do that you really need to show H.

We actually know in fact that it isn't, as your H can not accept any and
all input machine due to it not having its input in an isolated memory
space, thus there are some inputs that the Turing Machine H can accept
that your x86 H can not.

The actaully leads to being able to show that H^ is not in the right
relationship to H in your x86 model as they are in the actual Turing
Machine model.

On 8/18/2021 6:43 PM, Richard Damon wrote:
> On 8/18/21 9:57 AM, olcott wrote:
>> On 8/18/2021 5:26 AM, Richard Damon wrote:
>>> On 8/18/21 12:09 AM, olcott wrote:
>>>> On 8/17/2021 10:37 PM, Richard Damon wrote:
>>>>> On 8/17/21 11:17 PM, olcott wrote:
>>>>>> On 8/17/2021 10:10 PM, Richard Damon wrote:
>>>>>>> On 8/17/21 10:50 PM, olcott wrote:
>>>>>>>> On 8/17/2021 9:36 PM, Richard Damon wrote:
>>>>>>>>> On 8/17/21 10:04 PM, olcott wrote:
>>>>>>>>>> On 8/17/2021 8:49 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/17/21 9:40 PM, olcott wrote:
>>>>>>>>>>>> On 8/17/2021 8:35 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 8/17/21 9:24 PM, olcott wrote:
>>>>>>>>>>>>>> On 8/17/2021 8:17 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> That you keep erasing these words rather than carefully
>>>>>>>>>>>>>>>>>> critqueing
>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>> one of them sufficiently proves that you are dishonest:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --Because H only acts as a pure simulator of its input
>>>>>>>>>>>>>>>>>> --until after its halt status decision has been made it
>>>>>>>>>>>>>>>>>> --has no behavior that can possibly effect the behavior
>>>>>>>>>>>>>>>>>> --of its input. Because of this H screens out its own
>>>>>>>>>>>>>>>>>> --address range in every execution trace that it examines.
>>>>>>>>>>>>>>>>>> --This is why we never see any instructions of H in any
>>>>>>>>>>>>>>>>>> --execution trace after an input calls H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Pure simulator *until*, Then it isn't because it
>>>>>>>>>>>>>>>>> terminates its
>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is this key fact that allows it to ignore its own code
>>>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>>> making its halt status decision. The entire time that it is
>>>>>>>>>>>>>>>> making its
>>>>>>>>>>>>>>>> halt status decision <it is> a pure simulator.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But then it isn't, so the copy that it was simulating wasn't
>>>>>>>>>>>>>>> either.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It <is> a pure simulator until after it makes its halt status
>>>>>>>>>>>>>> decision
>>>>>>>>>>>>>> therefore it <can> ignore its own code <while> it is making
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>> status decision.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And then it isn't, and so it NEVER was. UNSOUND LOGIC.
>>>>>>>>>>>>
>>>>>>>>>>>> X = "H is a pure simulator while it is making its halt status
>>>>>>>>>>>> decision"
>>>>>>>>>>>>
>>>>>>>>>>>> You are concluding that X is not true on the basis that X is
>>>>>>>>>>>> true?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I am says that the assertion that "H IS a pure simulator" is not
>>>>>>>>>>> true.
>>>>>>>>>>
>>>>>>>>>> I am saying that H is a pure simulator some of the time and you
>>>>>>>>>> are
>>>>>>>>>> saying no I am wrong because H is not a pure simulator all of the
>>>>>>>>>> time
>>>>>>>>>> then it is not a pure simulator some of the time.
>>>>>>>>>
>>>>>>>>> Something can't really be a pure simulator part of the time.
>>>>>>>>
>>>>>>>> Sure it can and in fact H is a pure simulator for the entire time
>>>>>>>> that
>>>>>>>> it could otherwise possibly effect the behavior of its input. This
>>>>>>>> seems
>>>>>>>> to be beyond your capacity to understand.
>>>>>>>>
>>>>>>>
>>>>>>> No, It can't. PERIOD.
>>>>>>>
>>>>>>> H can act like a pure simulator for the part of the trace that it
>>>>>>> runs,
>>>>>>> but H is NOT a pure simulator, at least as far as transformation
>>>>>>> rules
>>>>>>> for copies of it in the simulation.
>>>>>>>
>>>>>>
>>>>>> Every recursive invocation of H continues to act like a pure simulator
>>>>>> until after H makes it halt status decision.
>>>>>
>>>>> UNSOUND.
>>>>>
>>>>> Since H at some point will STOP being a pure simulator, its affect on
>>>>> the machine CALLING it is NOT the same as a Pure Simulator.
>>>>>
>>>>
>>>> While H does nothing to change the behavior of its input
>>>> H does do something that changes the behavior of its input.
>>>
>>> Not what I said.
>>>
>>
>> It is what you implied.
>>
>>> H does affect the machine that uses it.
>>>
>>
>> H has no effect on the machine that it simulates until after its halt
>> status decision has been made. This conclusively proves that H can
>> ignore its in execution trace during its halt status analysis.
>
> No, that is NOT a proof. What establish axiom or theorem are you basing
> this 'proof' on.
>

That you fail to comprehend what I say counts as less than no rebuttal
at all. A rebuttal requires a sequence of valid deductive logical
inference beginning with premises that can be verified as true.

The meaning of my above words prove that they are true.

> FAIL
>
> UNSOUND.
>
>>
>> Anyone disagreeing with this is either not intelligent or knowledgeable
>> enough to understand it, or a liar.
>>
>
> Anyone making such a statement is proving that they are an ignoramous.
>
>> That H does effect the behavior or its input at some other point is
>> utterly irrelevant to this analysis. We are only answering the single
>> question: Is it correct for H to ignore its own execution trace during
>> its halt status analysis?
>
> Which you have NOT established. Since any copy of your H, if run long
> enopugh WILL abort its simulation (or it is the Hn that doesn't answer
> so starts off wrong). It is UNSOUND logic for H to presume that the H is
> is simulating will not abort its simulation.
>
> Remember, YOU have established that the act of aborting the simulation
> doesn't actually change the behavior of the machine it is simulating,
> therefore it is valid to take that exact same input and run it with a
> truely pure simulator, i.e. a REAL UTM, and when we do, we see that in
> that case, the input will proceed to the point where its H will decide
> to abort is simulation, return the non-halting result, and that machine
> will then Halt.
>
> Since the simulating machine aborting hasn't changed the 'real' behavior
> of the machine, only how much we have seen, it is thus clear that <H^>
> applied to <H^> is actually a halting computation, and H was WRONG in
> deciding elsewise, BECAUSE it used the UNSOUND logic of assuming that
> the simulated H would never abort its simulation.
>
>
> FFFFFFFFFF AA IIIIIIIIII LL
> FF AA AA II LL
> FF AA AA II LL
> FFFFFF AAAAAAAAAA II LL
> FF AA AA II LL
> FF AA AA II LL
> FF AA AA IIIIIIIIII LLLLLLLLLL
>
>>
>>> H0 does not affect the behavior of the machine that is represented by
>>> its input, P1.
>>>
>>> H1, which is used by P1, does affect the behavior of P1.
>>>
>>> If you want to try some stained logic to claim that No H affects the
>>> behavior of any P because an instance of P is used as an instance of H
>>> then you are using Unsound Logic.
>>>
>>> By the method of construction, the behavior of P is directly controlled
>>> by the behavior of H.
>>>
>>> To deny that is to say you are not following the pattern.
>>>
>>> FFFFFFFFFF       AA      IIIIIIIIII  LL
>>> FF             AA  AA        II      LL
>>> FF           AA      AA      II      LL
>>> FFFFFF       AAAAAAAAAA      II      LL
>>> FF           AA      AA      II      LL
>>> FF           AA      AA      II      LL
>>> FF           AA      AA  IIIIIIIIII  LLLLLLLLLL
>>>
>>>>
>>>> By this same reasoning all black cats are white.
>>>
>>> Nope. Strawman.
>>>
>>> UNSOUND LOGIC.
>>>
>>> Please try to actually PROVE something, you are just using rhetorical
>>> arguments that aren't actually very good.
>>>
>>>>
>>>>> You have a false premise in your logic so you have an UNSOUND argument.
>>>>>
>>>>>>
>>>>>> This allows Every recursive invocation of H to totally ignore its own
>>>>>> execution in every halt status analysis execution trace.
>>>>>
>>>>> FALSE. Prove your claim. Really, Try to.
>>>>>
>>>>> UNSOUND.
>>>>>
>>>>> H may be able to ignore the affect of its own aborting on the behavior
>>>>> of the machine it is simulating, but it MUST take into account that
>>>>> same
>>>>> aborting behavior in the invocation of the copies of it the machine it
>>>>> is simulating, as that activity DOES affect those machines.
>>>>>
>>>>> Remember, The fact that H0 is aborting the simulation of P1 doesn't
>>>>> affect the real behavior of P1, thus we do need to look at what P1
>>>>> would
>>>>> do if H0 didn't abort it, and from your run of P0, we know that after
>>>>> just a little bit more, H1 will also decide to abort its simulation of
>>>>> P2, and then return to P1 and then P1 will Halt.
>>>>>
>>>>> Thus, since the decision of H0 to abort doesn't affect the behavior of
>>>>> the machine that is its input, we see that P1 is STILL a Halting
>>>>> Computation, and that H1 will FAIL to be a Pure Simulation, so H0 is in
>>>>> error for treating it as one.
>>>>>
>>>>>>
>>>>>>> You confuse its affect on the input, which is a representation of a
>>>>>>> machine, which you are right it can't affect (not if it is an
>>>>>>> accurate
>>>>>>> simulator) for it having an affect on the machine it is imbedded in.
>>>>>>>
>>>>>>> If H is a pure simulator, the it CAN'T return an answer to the
>>>>>>> machine
>>>>>>> that 'called' it until the machine it is simulating has finished.
>>>>>>> Since
>>>>>>> it doesn't do that, it isn't a pure simulator, and thus the
>>>>>>> transformation of tracing the simulation of the simulator to the
>>>>>>> traceing of the machine it is simulationg isn't valid, as they are
>>>>>>> NOT
>>>>>>> equivalent.
>>>>>>>
>>>>>>> The problem isn't the consideration of H0, the outer simulator
>>>>>>> (possibly
>>>>>>> being called by P0) but how you have to treat H1. Since the
>>>>>>> behavior of
>>>>>>> H1, even after it would have made its decision will affect the
>>>>>>> execution
>>>>>>> of P1, it can NOT be treated as a UTM, as it doesn't act like one.
>>>>>>>
>>>>>>> You logic is UNSOUND and FALSE. FAIL.
>>>>>>>
>>>>>>> H1's aborting affects P1's behavior (since that is its caller, not
>>>>>>> its
>>>>>>> input) so this means that even though H0's decision to abort can't
>>>>>>> affect P1's behavior, it does need to consider H1's behavior as not a
>>>>>>> pure simulatior.
>>>>>>>
>>>>>>> In fact, your claimed rule, if you want to hold to it, means that
>>>>>>> switching H0 to a real UTM can't affect the behavior of P1, and we
>>>>>>> know
>>>>>>> that P(P) is halting, and thus UTM(P,P) is halting, so UTM(P1,P2) is
>>>>>>> halting (since all levels of P are the same), the we can show that
>>>>>>> the
>>>>>>> 'input' to H0 is a halting computation, it is just a fact that H0
>>>>>>> doesn't simulate it far enough to see that.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

On 8/18/2021 6:46 PM, Richard Damon wrote:
> On 8/18/21 4:45 PM, olcott wrote:
>> On 8/18/2021 3:05 PM, dklei...@gmail.com wrote:
>>> On Wednesday, August 18, 2021 at 6:50:34 AM UTC-7, olcott wrote:
>>>> H does exist. I spent 1.5 years creating the x86utm operating system. It
>>>> took me three full months to get context switching correctly so that
>>>> Nested simulation of virtual machines could operate correctly to an
>>>> arbitrary recursive depth.
>>>>
>>>> I had to make sure that I had everything working properly because I do
>>>> intend to publish as soon as I have words that are sufficiently clear to
>>>> prove my point. I will have to refactor my code so that it is cleaner.
>>>
>>> You must be aware that no moderated group will accept your x86
>>> equivalence approach as a proof of anything. So your work is
>>> quixotic. No amount of refactoring will ever help. No words exist
>>> that will justify it. Be prepared to lose.
>>>
>>
>> No I do not accept this because of the Turing equivalence between the
>> H(P,P) computation and the simplified Linz Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>> computation.
>>
>> People that fail to sufficiently understand Turing equivalence may
>> disagree. They are not in my target audience.
>>
>>
>
> You actually have just claimed the Turing Equivalence, which you really
> need to PROVE to use, and to do that you really need to show H.
>
> We actually know in fact that it isn't, as your H can not accept any and
> all input machine due to it not having its input in an isolated memory
> space, thus there are some inputs that the Turing Machine H can accept
> that your x86 H can not.
>

See that is an example of what I mean. I am saying that H(P,P) is
equivalent to a simplified Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ essentially a single
freaking computation not an infinite set of computations.

> The actaully leads to being able to show that H^ is not in the right
> relationship to H in your x86 model as they are in the actual Turing
> Machine model.
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/18/2021 3:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Let's get back to something that you seem to know well:
>> Why start again? You just walked away from this discussion before.
>> I'll just bring up the errors you made in those threads again...
>>
>>> Ĥ.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
>>>
>>> Can you understand that Ĥ applied to ⟨Ĥ⟩ would never stop running if
>>> the machine at Ĥ.qx was a UTM?
>>
>> Sigh. I'm pretty sure I know what you are trying to say (it's "Halts
>> with line 15 commented out" again), and I really want to agree with it
>> (again) but what you ask is literal nonsense. If the machine at Ĥ.qx is
>> a UTM and not H (well, technically it's H' and not H) then asking what Ĥ
>> applied to ⟨Ĥ⟩ does is, at best, ambiguous and at worst just daft
>> because the name Ĥ is meaningless unless the embedded TM at qx is H
>> which is not a UTM. It's what the "hat" means.
>>
>> If J is a TM like H but without the states and code that makes it stop
>> being a UTM (in some cases) then, yes, Ĵ applied to ⟨Ĵ⟩ is a non-halting
>> computation. This wording, whilst correct, does not cloud the water
>> enough.
>
> Ah great a breakthrough.

You accept my re-wording? You finally understand it? You won't use
names to refer to things that they are not? Any of these would be a
breakthrough indeed.

>> Your use of Ĥ when it's not H at qx is central to you game so
>> you won't accept this way of putting it.
>
> When we adapt Ĥ so that the machine at Ĥ.qx is a UTM and we call this
> new machine Ĵ, then Ĵ applied to ⟨Ĵ⟩ never halts.

Why did not you not accept this any of the other times I've said it?

>> And have you changed your mind about the computation represented by a
>> tape containing ⟨Ĥ⟩ ⟨Ĥ⟩? You falsely asserted, point blank, that that
>> tape represents a non-halting computation.
>
> When we know that Ĵ applied to ⟨Ĵ⟩ never halts then we also know that
> Ĥ applied to ⟨Ĥ⟩ never stops running unless the simulating halt
> decider at Ĥ.qx aborts the simulation of its input.

That's not an answer. Do you still claim that ⟨Ĥ⟩ ⟨Ĥ⟩ (that's your Ĥ,
the one you claim to actually have written) represents a non-halting
computation?

I don't want yet another explanation about /why/ you might think this.
I just want a clear and unequivocal statement that you do indeed still
believe it.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/18/2021 2:44 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/17/2021 7:02 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/17/2021 5:14 PM, Ben Bacarisse wrote:
>>>>
>>>>>> The facts come from you. They are not a matter of opinion. P(P) halts.
>>>>>> H(P,P) == 0.
>>>> ...
>>>>>> You are happy with that answer, but I can specify a function you can't
>>>>>> write: B(M, I) such that B(M, I) is non zero if and only if M(I) halts.
>>>>>> You don't get to choose what the "correct" answer is, so your only
>>>>>> option if to ignore the challenge.
>>>>>
>>>>> At this point I expect and require that those seeking an actual honest
>>>>> dialogue use the basis that I provided to verify that H does decide
>>>>> the halt status of its inputs correctly. Everyone else is written off
>>>>> as dishonest.
>>>> That's up to you. I can't stop you wasting time on a function no one
>>>> cares about, but you know you can't write the function I specified, so
>>>> you are back where you started 17 years ago. There are still
>>>> undecidable sets.
>>>
>>> The function does meet the spec
>> You don't know that because you have not asked for the proper spec. You
>> have not even accepted my challenge. Are you accepting the challenge
>> and proposing H as an implementation without knowing the full spec? I'm
>> happy for you to say yes if that is what you want to do.
>
> I know what the spec is:

No you don't. The spec comes from me, and only if you say you want to
try the challenge. I am promising you the specification of a function
you can't write -- a clear demonstration that there are natural
uncomputable functions.

> What is your opinion of what the spec is?

It's not "the spec", it's my spec. If you take the challenge, I'll
write it out. I won't bother writing it out properly if you don't want
to try.

--
Ben.

On 8/18/21 4:40 PM, olcott wrote:
> On 8/18/2021 3:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Let's get back to something that you seem to know well:
>>
>> Why start again?  You just walked away from this discussion before.
>> I'll just bring up the errors you made in those threads again...
>>
>>> Ĥ.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
>>>
>>> Can you understand that Ĥ applied to ⟨Ĥ⟩ would never stop running if
>>> the machine at Ĥ.qx was a UTM?
>>
>> Sigh.  I'm pretty sure I know what you are trying to say (it's "Halts
>> with line 15 commented out" again), and I really want to agree with it
>> (again) but what you ask is literal nonsense.  If the machine at Ĥ.qx is
>> a UTM and not H (well, technically it's H' and not H) then asking what Ĥ
>> applied to ⟨Ĥ⟩ does is, at best, ambiguous and at worst just daft
>> because the name Ĥ is meaningless unless the embedded TM at qx is H
>> which is not a UTM.  It's what the "hat" means.
>>
>> If J is a TM like H but without the states and code that makes it stop
>> being a UTM (in some cases) then, yes, Ĵ applied to ⟨Ĵ⟩ is a non-halting
>> computation.  This wording, whilst correct, does not cloud the water
>> enough. 
>
> Ah great a breakthrough.
>
>> Your use of Ĥ when it's not H at qx is central to you game so
>> you won't accept this way of putting it.
>>
>
> When we adapt Ĥ so that the machine at Ĥ.qx is a UTM and we call this
> new machine Ĵ, then Ĵ applied to ⟨Ĵ⟩ never halts.
>
>> And have you changed your mind about the computation represented by a
>> tape containing ⟨Ĥ⟩ ⟨Ĥ⟩?  You falsely asserted, point blank, that that
>> tape represents a non-halting computation.
>>
>
> When we know that Ĵ applied to ⟨Ĵ⟩ never halts then we also know that Ĥ
> applied to ⟨Ĥ⟩ never stops running unless the simulating halt decider at
> Ĥ.qx aborts the simulation of its input.

Yes, we can show that given the proposition
A: H will never abort its simulation of the input <H^>,<H^>

we can prove that H^(<H^>) is non-halting.

Problem is, since H does abort its simulation of the input <H^>, <H^>,
and logic based on proposition A being true is UNSOUND, and incorrect.

FAIL.

The definition of Halting does NOT include some exception for having a
copy of itself having its simulation aborted.

Since, when run as a machine, H^(<H^>) does halt in finite time, it is a
Halting computation, and thus the required answer from H for it to be
correct is Halting. Since that is NOT the answer it gives, it is WRONG.

PERIOD.

>
> If we accept the statement that every input to simulating halt decider H
> that never halts while H remains in pure simulation mode is a
> computation that never halts then we have this axiom basis to determined
> that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>
>

On 8/18/21 7:46 PM, olcott wrote:
> On 8/18/2021 6:43 PM, Richard Damon wrote:
>> On 8/18/21 9:57 AM, olcott wrote:
>>> On 8/18/2021 5:26 AM, Richard Damon wrote:
>>>> On 8/18/21 12:09 AM, olcott wrote:
>>>>> On 8/17/2021 10:37 PM, Richard Damon wrote:
>>>>>> On 8/17/21 11:17 PM, olcott wrote:
>>>>>>> On 8/17/2021 10:10 PM, Richard Damon wrote:
>>>>>>>> On 8/17/21 10:50 PM, olcott wrote:
>>>>>>>>> On 8/17/2021 9:36 PM, Richard Damon wrote:
>>>>>>>>>> On 8/17/21 10:04 PM, olcott wrote:
>>>>>>>>>>> On 8/17/2021 8:49 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/17/21 9:40 PM, olcott wrote:
>>>>>>>>>>>>> On 8/17/2021 8:35 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/17/21 9:24 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/17/2021 8:17 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> That you keep erasing these words rather than carefully
>>>>>>>>>>>>>>>>>>> critqueing
>>>>>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>> one of them sufficiently proves that you are dishonest:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --Because H only acts as a pure simulator of its input
>>>>>>>>>>>>>>>>>>> --until after its halt status decision has been made it
>>>>>>>>>>>>>>>>>>> --has no behavior that can possibly effect the behavior
>>>>>>>>>>>>>>>>>>> --of its input. Because of this H screens out its own
>>>>>>>>>>>>>>>>>>> --address range in every execution trace that it
>>>>>>>>>>>>>>>>>>> examines.
>>>>>>>>>>>>>>>>>>> --This is why we never see any instructions of H in any
>>>>>>>>>>>>>>>>>>> --execution trace after an input calls H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Pure simulator *until*, Then it isn't because it
>>>>>>>>>>>>>>>>>> terminates its
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is this key fact that allows it to ignore its own code
>>>>>>>>>>>>>>>>> while
>>>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>>>> making its halt status decision. The entire time that
>>>>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>>>>> making its
>>>>>>>>>>>>>>>>> halt status decision <it is> a pure simulator.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But then it isn't, so the copy that it was simulating
>>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>>> either.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It <is> a pure simulator until after it makes its halt
>>>>>>>>>>>>>>> status
>>>>>>>>>>>>>>> decision
>>>>>>>>>>>>>>> therefore it <can> ignore its own code <while> it is making
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>> status decision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And then it isn't, and so it NEVER was. UNSOUND LOGIC.
>>>>>>>>>>>>>
>>>>>>>>>>>>> X = "H is a pure simulator while it is making its halt status
>>>>>>>>>>>>> decision"
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are concluding that X is not true on the basis that X is
>>>>>>>>>>>>> true?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I am says that the assertion that "H IS a pure simulator" is
>>>>>>>>>>>> not
>>>>>>>>>>>> true.
>>>>>>>>>>>
>>>>>>>>>>> I am saying that H is a pure simulator some of the time and you
>>>>>>>>>>> are
>>>>>>>>>>> saying no I am wrong because H is not a pure simulator all of
>>>>>>>>>>> the
>>>>>>>>>>> time
>>>>>>>>>>> then it is not a pure simulator some of the time.
>>>>>>>>>>
>>>>>>>>>> Something can't really be a pure simulator part of the time.
>>>>>>>>>
>>>>>>>>> Sure it can and in fact H is a pure simulator for the entire time
>>>>>>>>> that
>>>>>>>>> it could otherwise possibly effect the behavior of its input. This
>>>>>>>>> seems
>>>>>>>>> to be beyond your capacity to understand.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, It can't. PERIOD.
>>>>>>>>
>>>>>>>> H can act like a pure simulator for the part of the trace that it
>>>>>>>> runs,
>>>>>>>> but H is NOT a pure simulator, at least as far as transformation
>>>>>>>> rules
>>>>>>>> for copies of it in the simulation.
>>>>>>>>
>>>>>>>
>>>>>>> Every recursive invocation of H continues to act like a pure
>>>>>>> simulator
>>>>>>> until after H makes it halt status decision.
>>>>>>
>>>>>> UNSOUND.
>>>>>>
>>>>>> Since H at some point will STOP being a pure simulator, its affect on
>>>>>> the machine CALLING it is NOT the same as a Pure Simulator.
>>>>>>
>>>>>
>>>>> While H does nothing to change the behavior of its input
>>>>> H does do something that changes the behavior of its input.
>>>>
>>>> Not what I said.
>>>>
>>>
>>> It is what you implied.
>>>
>>>> H does affect the machine that uses it.
>>>>
>>>
>>> H has no effect on the machine that it simulates until after its halt
>>> status decision has been made. This conclusively proves that H can
>>> ignore its in execution trace during its halt status analysis.
>>
>> No, that is NOT a proof. What establish axiom or theorem are you basing
>> this 'proof' on.
>>
>
> That you fail to comprehend what I say counts as less than no rebuttal
> at all. A rebuttal requires a sequence of valid deductive logical
> inference beginning with premises that can be verified as true.

The fact that you actually never try to actually prove anything by the
ground rules of logic shows that you are working outside the field and
EVERYTHING you say is logically just garbage.

On 8/18/21 7:43 PM, olcott wrote:
> On 8/18/2021 6:32 PM, Richard Damon wrote:
>> On 8/18/21 10:07 AM, olcott wrote:
>>> On 8/18/2021 6:48 AM, Richard Damon wrote:
>>>> On 8/18/21 12:09 AM, olcott wrote:
>>>>
>>>>> While H does nothing to change the behavior of its input
>>>>> H does do something that changes the behavior of its input.
>>>>>
>>>>> By this same reasoning all black cats are white.
>>>>>
>>>> Thinking on this, I would like to point out a FUNDAMENTAL problem with
>>>> all your arguments, you presume that if you come up with some pithy
>>>> statement that sounds sort of true, you can just assume it to be true
>>>> and move on from there.
>>>>
>>>> This is WRONG.
>>>>
>>>> Every statement, other than the fundamental axioms of the system, that
>>>> everyone agrees to, needs to be proven, actually proven.
>>>>
>>>> You don't get to add new axioms to an existing system except with BROAD
>>>> community support.
>>>>
>>>
>>> Sure I do. I can create any axioms that I want to as long as they can be
>>> objectively verified as always consistently true under all conditions.
>>
>> No, you can't, Axioms, the accepted while unproven statements must be
>> agreed by the field.
>>
>> If you can actually PROVE them, then they don't need to be taken as
>> axioms.
>>
>> Now, if they can be OBJECTIVELY verified from the accepted truths, then
>> they are theorems, not axiom, but you have yet to prove any of your
>> statement.
>>
>
> Yes theorem would be a more apt term.
>
> Because H only acts as a pure simulator of its input until after
> its halt status decision has been made it has no behavior that
> can possibly effect the behavior of its input. Because of this H
> screens out its own address range in every execution trace that
> it examines. This is why we never see any instructions of H in
> any execution trace after an input calls H.
>
> The above proves itself true entirely on the basis of the meaning
> of its words. There is no possible correct rebuttal there is only
> a failure to comprehend. If you believe that there is a correct
> rebuttal please provide it and I will point out your error.
>
>
>> This is especially ironic since you also make the claim that unless you
>> can analytically prove it, it isn't true.
>>
>> FAIL.
>>
>> Your statement basically proves that your entire logic is outside the
>> the logic of the system, and thus it UNSOUND and has ZERO application to
>> the theory. It also seems to imply tha that you have taken yourself not
>> only out of Computation Theory, but TOTALLY out of the basic theory of
>> Logic, since you don't seem to accept the basics of Axiometric logic
>> (that the Axioms are agreed to by those in the field).
>>
>>>
>>> If some people are simply not bright enough to understand that they are
>>> always necessarily consistently true then these people are simply
>>> excluded from my target audience.
>>
>> Seems like a great example of Dunning-Kruger in effect. You make up a
>> truth and just can't understand why others don't fall for your con.
>>
>>>
>>> The key axiom that I created that my work depends upon is that
>>> when-so-ever an input would never stop running while H remains in pure
>>> simulation mode then the input is always correctly decided as never
>>> halting.
>>
>> Which is pure garbage thinking. UNSOUND as is your mind.
>
> Dogmatic statements such as this count as less than no rebuttal at all.

And who doesn't say anything but simple dogma. I list reasons based on
the fundamentals of logic. I have shown it many different ways.

You just make the dogmatic claim that you must be right and no one else
is smart enough to understand you.

Smart people know how to break down their logic into small piece that
mast people can understand it. Most people in this group seem to get
what we are all saying.

Dumb people can't easily rephrase their statements as they can't
actually think about them. That is you.

>
>>
>> FAIL.
>>
>>>
>>> This axiom derives the same correct results for all halting
>>> computations, for the subset of infinite loops that H recognizes, for
>>> the subset of infinite recursion that H recognizes and for the simple
>>> halting problem counter-example programs that I have been providing.
>>
>>
>> UNSOUND.
>>
>>>
>>> The x86 code that I have provided consistently proves that this axiom is
>>> correct.
>>
>>
>> FALSE, UNSOUND
>>>
>>>> Fortunately, many things have already been proven, so we are allowed to
>>>> rely on existing proofs, but to do that, it requires us to have
>>>> actually
>>>> studied the field to know what has been proven.
>>>>
>>>> Note, many times I have asked you if you can show someone else who has
>>>> the same idea. I do this because it has been clear that YOU don't know
>>>> how to even write a proper proof, so if you can't prove it, you need to
>>>> rely on statements that others have proven.
>>>>
>>>> Maybe you haven't studied logic theory enough to know that rule, but
>>>> that just says that you have fallen into the same trap that the ancient
>>>> philosophers did until the worked out the actual rules of logic.
>>>> Knowledge is built of actual PROOFS, not just fancy rhetorical
>>>> arguments. There are many things that at first seem to be true, but
>>>> when
>>>> we examine them more closely we find that they are not.
>>>>
>>>> For instance, many will say that the next term in this sequence:
>>>> 1, 2, 4, 8, 16 is obviously going to be 32, but in some problems the
>>>> right answer is 31. This is the case of dividing a circle into areas
>>>> with complete graphs
>>>>
>>>> (https://en.wikipedia.org/wiki/Dividing_a_circle_into_areas)
>>>>
>>>> This sort of case shows that intuition and what the simple meaning of
>>>> words is NOT sufficient to determine truth.
>>>>
>>>> Therefore, what you REALLY need to do to make your proof workable,
>>>> is to
>>>> look at your fundamental ideas that you base it on, go back to the
>>>> field
>>>> to see if someone else has actually proven that idea, and if so,
>>>> look at
>>>> the proof to refine what that idea actually means (your big problem is
>>>> that many of your statements are mostly true, you just have a wrong
>>>> slant in them).
>>>>
>>>> Learn what HAS been proven as a base. Then you can have things you can
>>>> actually work with to use. The Fundamental are much harder to actually
>>>> prove than later ideas, because you need to prove the fundamentals from
>>>> just the barest of axioms.
>>>>
>>>
>>>
>>
>> Simple Theorem with Proof: Peter Olcott's ideas are worthless.
>>
>> The definition of an inconsistent logic system is one which can prove a
>> statement and its complement at the same time.
>>
>> For H^ developed per the proofs in view, it HAS been shown that H^(<H^>)
>> when run as an independent machine is a Halting Computation.
>>
>> Peter has 'proved' that H(<H^>,<H^>) saying non-halting is correct
>> because of is logic.
>>
>> Because H^ is claimed to be a compuation, by the DEFINITION of a
>> computaiton, all copies of H^ will act the same.
>>
>> Thus, Peter's proof has shown that H^(<H^>) is both a Halting and a
>> non-halting computation.
>>
>> Thus Peter's logic system is inconsistent.
>>
>> It is well established that in ANY logic system that is inconsistent it
>> is possible to eventually prove (and disprove by proving the opposite)
>> ANY statement imagined that can be expressed in the system.
>>
>> A logic system that can't distinguish any truth from falsehood is by
>> definition worthless.
>>
>> ERGO, Peter Olcotts whole system is not worth the electronic paper it is
>> (or isn't) written on.
>>
>> Give it up Peter, you have basically dug a hole so deep here that you
>> probably can't get out of it.
>>
>
>

On 8/18/21 7:50 PM, olcott wrote:
> On 8/18/2021 6:46 PM, Richard Damon wrote:
>> On 8/18/21 4:45 PM, olcott wrote:
>>> On 8/18/2021 3:05 PM, dklei...@gmail.com wrote:
>>>> On Wednesday, August 18, 2021 at 6:50:34 AM UTC-7, olcott wrote:
>>>>> H does exist. I spent 1.5 years creating the x86utm operating
>>>>> system. It
>>>>> took me three full months to get context switching correctly so that
>>>>> Nested simulation of virtual machines could operate correctly to an
>>>>> arbitrary recursive depth.
>>>>>
>>>>> I had to make sure that I had everything working properly because I do
>>>>> intend to publish as soon as I have words that are sufficiently
>>>>> clear to
>>>>> prove my point. I will have to refactor my code so that it is cleaner.
>>>>
>>>> You must be aware that no moderated group will accept your x86
>>>> equivalence approach as a proof of anything. So your work is
>>>> quixotic. No amount of refactoring will ever help. No words exist
>>>> that will justify it. Be prepared to lose.
>>>>
>>>
>>> No I do not accept this because of the Turing equivalence between the
>>> H(P,P) computation and the simplified Linz Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>> computation.
>>>
>>> People that fail to sufficiently understand Turing equivalence may
>>> disagree. They are not in my target audience.
>>>
>>>
>>
>> You actually have just claimed the Turing Equivalence, which you really
>> need to PROVE to use, and to do that you really need to show H.
>>
>> We actually know in fact that it isn't, as your H can not accept any and
>> all input machine due to it not having its input in an isolated memory
>> space, thus there are some inputs that the Turing Machine H can accept
>> that your x86 H can not.
>>
>
> See that is an example of what I mean. I am saying that H(P,P) is
> equivalent to a simplified Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ essentially a single
> freaking computation not an infinite set of computations.

Which just shows that you don't understand the problem at all. A partial
decider still must be able to be posed to the decider, it just doesn't
need to be able to get them all right.

Since your H can't be given any arbitrary machine, it fails to be a
proper partial decider.

As I have said, this isn't an important point, as even with this
'advantage' it still must get the answer wrong. The error does open up
some avenues to cheat, but the basis of the halting problem proof is so
strong that as long as your H meets the requirement of being a true
Computation (and thus always give the same answer for the same input)
and is able to accept an input enough like the requried H^, it is doomed
to fail.

Sometimes it is important to point out just how far you are from your goal.

>
>
>
>> The actaully leads to being able to show that H^ is not in the right
>> relationship to H in your x86 model as they are in the actual Turing
>> Machine model.
>>
>
>

On 8/18/2021 6:51 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/18/2021 3:03 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Let's get back to something that you seem to know well:
>>> Why start again? You just walked away from this discussion before.
>>> I'll just bring up the errors you made in those threads again...
>>>
>>>> Ĥ.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
>>>>
>>>> Can you understand that Ĥ applied to ⟨Ĥ⟩ would never stop running if
>>>> the machine at Ĥ.qx was a UTM?
>>>
>>> Sigh. I'm pretty sure I know what you are trying to say (it's "Halts
>>> with line 15 commented out" again), and I really want to agree with it
>>> (again) but what you ask is literal nonsense. If the machine at Ĥ.qx is
>>> a UTM and not H (well, technically it's H' and not H) then asking what Ĥ
>>> applied to ⟨Ĥ⟩ does is, at best, ambiguous and at worst just daft
>>> because the name Ĥ is meaningless unless the embedded TM at qx is H
>>> which is not a UTM. It's what the "hat" means.
>>>
>>> If J is a TM like H but without the states and code that makes it stop
>>> being a UTM (in some cases) then, yes, Ĵ applied to ⟨Ĵ⟩ is a non-halting
>>> computation. This wording, whilst correct, does not cloud the water
>>> enough.
>>
>> Ah great a breakthrough.
>
> You accept my re-wording? You finally understand it? You won't use
> names to refer to things that they are not? Any of these would be a
> breakthrough indeed.
>
>>> Your use of Ĥ when it's not H at qx is central to you game so
>>> you won't accept this way of putting it.
>>
>> When we adapt Ĥ so that the machine at Ĥ.qx is a UTM and we call this
>> new machine Ĵ, then Ĵ applied to ⟨Ĵ⟩ never halts.
>
> Why did not you not accept this any of the other times I've said it?
>

I don't know that I didn't.

>>> And have you changed your mind about the computation represented by a
>>> tape containing ⟨Ĥ⟩ ⟨Ĥ⟩? You falsely asserted, point blank, that that
>>> tape represents a non-halting computation.
>>
>> When we know that Ĵ applied to ⟨Ĵ⟩ never halts then we also know that
>> Ĥ applied to ⟨Ĥ⟩ never stops running unless the simulating halt
>> decider at Ĥ.qx aborts the simulation of its input.
>
> That's not an answer. Do you still claim that ⟨Ĥ⟩ ⟨Ĥ⟩ (that's your Ĥ,
> the one you claim to actually have written) represents a non-halting
> computation?
>

The above is a simple paraphrase of what you already agreed to:

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.

Because the input to the simulating halt decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never
stops unless this simulating halt decider stops it at some point we can
know that this input specifies infinite execution.

> I don't want yet another explanation about /why/ you might think this.
> I just want a clear and unequivocal statement that you do indeed still
> believe it.
>

--
Copyright 2021 Pete Olcott

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