On 8/15/2021 12:26 PM, Jeff Barnett wrote:
> On 8/14/2021 10:48 PM, olcott wrote:
>> On 8/14/2021 11:07 PM, Jeff Barnett wrote:
>>> On 8/14/2021 5:10 PM, olcott wrote:
>>>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>>
>>>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> The P(P) of main() only halts because...
>>>>>>> As you say, P(P) halts.
>>>>>>>
>>>>>>>> *Halting computation* is any computation that eventually reaches
>>>>>>>> its
>>>>>>>> own final state. This criteria divides computations that halt from
>>>>>>>> those that merely stop running because their simulation was
>>>>>>>> aborted.
>>>>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>>>>> either
>>>>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>>>>> does not halt.
>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>     if (H(x, x))
>>>>>>>>       HERE: goto HERE;
>>>>>>>> }
>>>>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>>>>> Why are you still hiding H?  Is it because you have still not
>>>>>>> figured
>>>>>>> out how to nest a call to the simulator you are using?
>>>>>>> Fortunately "we"
>>>>>>> (i.e. everyone but you) can see that H is wrong without even
>>>>>>> seeing the
>>>>>>> code.  Who is included in the "we" of the subject line?  Have you
>>>>>>> found
>>>>>>> someone else who thinks that false is the correct return from a
>>>>>>> partial
>>>>>>> halt decider called with arguments that represent a halting
>>>>>>> computation?
>>>>>>
>>>>>> I have questions about the PO simulator I hope someone can answer. It
>>>>>> perhaps concerns memory mapping: First - is every instance of a
>>>>>> use at
>>>>>> different levels in its own address space? Second - if not, is there
>>>>>> any way to know when an address is reported, which simulator instance
>>>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>>>> the same address is reached a second time without a conditional
>>>>>> branch
>>>>>> being executed, is there any assurance that the addresses are noted
>>>>>> from the same instance of the simulation? And finally, how can one
>>>>>> determine if it's the same address twice without doing some sort of
>>>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>>>
>>>>> You won't get a straight answer from PO, but I don't think there is
>>>>> any
>>>>> nested simulation happening at all.  PO "knows" it's that same a
>>>>> recursion,
>>>>
>>>> Because context switching is required so that one function can
>>>> resume simulating the middle of another function with DebugStep()
>>>> and then return back to the same point in the middle of the current
>>>> function this requires that each context have its own set of registers.
>>>>
>>>> This makes using ordinary recursion for nested x86 emulation
>>>> infeasible because one process would clobber the stack of the other
>>>> processes.
>>>>
>>>> The stack registers of ESP and EBP are included in this set of saved
>>>> and restored registers. So we also have to have separate stack space
>>>> or one process would clobber the stack space of the other process.
>>>>
>>>> Since no one here could begin to understand even seven lines of
>>>> simple x86 code, I did not bring up these other details to avoid
>>>> confusing my audience much more than they were already confused.
>>>
>>> Our comprehension is just fine; that's not the problem here. The
>>> actual issue is that you neither understand nor are capable of
>>> learning about address mapping (that little thigamajig the page
>>> hardware implements).
>>
>> The x86utm operating system uses a single contiguous block of RAM to
>> most precisely map to the concept of a single contiguous Turing
>> machine tape. All of the code and data of the virtual machines that it
>> executes are contained in this single contiguous block. There is no
>> virtual memory paging in the x86utm operating system.
>
> I'm not suggesting you page. I'm suggesting that a simulator map the
> address spaces of the simulated so it levels and addresses used are kept
> straight. It doesn't seem to now. So your simulator either can't or
> doesn't fully simulate the X86 hardware it seems. Also from your
> response, I'd guess you don't understand the architecture very well either.
>

So you fail to comprehend that simulated virtual machines can be
executed from the same machine code address space?

> As always: seek advise, take your meds, and godspeed.
>

I can't take my chemo therapy meds because this nullifies my covid-19
vaccination and as a result of selfish damn bastards my life may be cut
far too short. It in not anyone's right to infect others with a deadly
disease.

>>> Context switches may need to save and restore registers, etc. Those
>>> are the kinds of things an OS does from day one of its inception. I
>>> think you need to return to high School (see your other thread) and
>>> ask a teacher to hold your hand and bring you up to date; at least to
>>> the mid 1960s. I know that would be rushing things for you. But tiny
>>> steps first. Maybe you'll understand these things better in a few
>>> years. Hell, while you are at it you might retake some of those pesky
>>> HS math classes that so confused you.
>>>
>>> Remember: ask for help that you need; follow instructions; take your
>>> meds. Best of luck.
>>>
>>> BTW At your age, whatever it is, you might need special
>>> recommendations to reenter high school. I'm sure all of us here would
>>> be willing to write a letter of recommendation that will state that
>>> remedial high school classes will be perfect for you. Perhaps this
>>> time around, you will be able to pick up all those tidbits that went
>>> over your head the first time.
>>>
>>>> Not being able to understand seven simple lines of x86 code in many
>>>> months is a horribly terrible degree of comprehension.
>>>>
>>>>> so he just has recursive calls traced from "outside".  I may
>>>>> be wrong, of course, but this is one reason I think H is being kept
>>>>> hidden -- it does not do what says.--
>>> Jeff Barnett

--
Copyright 2021 Pete Olcott

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

On 8/15/2021 8:46 AM, Mike Terry wrote:
> On 14/08/2021 22:20, Jeff Barnett wrote:
>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The P(P) of main() only halts because...
>>>
>>> As you say, P(P) halts.
>>>
>>>> *Halting computation* is any computation that eventually reaches its
>>>> own final state. This criteria divides computations that halt from
>>>> those that merely stop running because their simulation was aborted.
>>>
>>> No.  There is no "special kind of halting".  The computation M(I) either
>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>> does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>
>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>
>>> Why are you still hiding H?  Is it because you have still not figured
>>> out how to nest a call to the simulator you are using?  Fortunately "we"
>>> (i.e. everyone but you) can see that H is wrong without even seeing the
>>> code.  Who is included in the "we" of the subject line?  Have you found
>>> someone else who thinks that false is the correct return from a partial
>>> halt decider called with arguments that represent a halting computation?
>>
>> I have questions about the PO simulator I hope someone can answer. It
>> perhaps concerns memory mapping:
>
>> First - is every instance of a use at different levels in its own
>> address space?
>
> I've tried to get PO to clarify that, and it always /seems/ that he is
> suggesting yes [while avoiding any direct answer] but I have no
> confidence whatsoever that he understands what everybody else would
> understand by "its own address space".
>
> He has definitely said that each simulation has its own stack and
> registers, but my bet would be that they are more like your typical OS
> threads, running in the same address space.  (We could probably find out
> by quizzing him on sharing of globals etc. and giving him concrete
> examples which he could understand.  But it might take a lot of work,
> and for what at the end?  Or more reasonably, if he published all his
> source code as he maintained he would for around two years, we could
> answer these sorts of questions for ourselves...)
>
>> Second - if not, is there any way to know when an address is reported,
>> which simulator instance is being reported on?
>
> I suggested he needed to provide that last year.  And at one point he
> DID change his trace to show the emulation level, so it's not like
> there's any coding difficulty!  But then it was perfectly clear that he
> was correlating trace entries together from completely separate
> emulation levels, so the illusion that it was a "loop" in the normal
> (single) processor-trace sense was lessened.  He subsequently removed
> the column, claiming as excuse that it confused people.
>
> I'd say this is PO misunderstanding the difference between
> call-recursion and emulation-recursion.  The former can /only/ be broken
> by code at the deepest recursion level which then percolates up to the
> top level, like when we calculate n factorial recursively.
> Emulation-recursion /can/ also break out this way, but with emulation
> there is a second possibility - the break can be from the /top/ level
> which simply decides not to emulate any more.  The fact that the deepest
> inner emulations appear to be repeating doesn't mean that they will go
> on forever, because an outer level can always just give up emulating and
> get on with whatever is next.
>
> I suppose without an emulation-id column we can probably work stuff out
> based on the overall flow of the trace together with knowledge about the
> program and what H is doing and so on.  (But why should this be required
> when it's an essential part of the meaning of a trace entry?)
>
>> When the dumb bunny (PO expression) notes that the same address is
>> reached a second time without a conditional branch being executed, is
>> there any assurance that the addresses are noted from the same
>> instance of the simulation?
>
> I can give you an assurance of exactly the opposite - they are
> definitely from /different/ emulation levels!  (I think you know that,
> right?) PO tries to present them to look as much as possible like a
> pattern of behaviour for a /single/ processor, because then he would
> have "call recursion" which can only break inner-to-outer, and his
> "processor trace" could provide some level of evidence that that won't
> happen. (Also I'm remebering his recent remarks about the processor
> "[..having no way to escape from the recursion..]" which might be
> explained as PO not understanding the call/recursion distinction...)
>
> In the past PO has said his rule applies equally for call-recursion and
> emulation-recursion, no difference, while repeating something about
> "equivalent computation", but he has no real /understanding/ of that
> phrase and certainly no /proof/ of soundness even for the simple
> call-recursion case, so it's just the usual unsupported claims.  (And
> there is no prospect of ever going further than this - PO is simply not
> capable of "proving" anything and I doubt he understands what that even
> means.)
>
>> And finally, how can one determine if it's the same address twice
>> without doing some sort of compare and branch?
>
> OK, for PO's H, there are obviously hidden conditional branch
> instructions within H, which is why PO has to come up with some wording
> to convince himself that H can be totally ignored for whatever reason.
> But drilling down on this seems overkill when PO hasn't even presented
> any plausible argument (let alone proof!) that the detection rule being
> used is sound.  What would we be trying to disprove and why? :)  PO has
> agreed that H^(H^) halts, and that H(H^,H^) returns not-halting, so
> that's it.
>
> At least in the end it must be PO's responsibility to present /proofs/
> of anything he claims, but now we've gone like 100 miles beyond his
> capabilities - a complete non-starter...
Thanks for the reply. Your impression and mine seem to agree. I had
hoped to hear answers directly from the horse's mouth; of course if PO
did respond, I'd get the wrong end of that horse.
--
Jeff Barnett

On 8/15/21 12:44 PM, olcott wrote:
> On 8/15/2021 9:45 AM, wij wrote:
>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>>> On 8/15/2021 2:50 AM, wij wrote:
>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>>> On 8/14/2021 1:09 PM, wij wrote:
>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>> This exact same analysis always applies to the input to
>>>>>>>>>>> H(P,P) no matter
>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> P((u32)P);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> Because the halting problem only requires that the (at least
>>>>>>>>>>> partial)
>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not
>>>>>>>>>>> relevant
>>>>>>>>>>> to the halting problem.
>>>>>>>>>>
>>>>>>>>>> I do not know English well, but I (almost every programmer) am
>>>>>>>>>> sure the halting
>>>>>>>>>> problem means a program H decides whether P(input) will halt
>>>>>>>>>> or not.
>>>>>>>>>> If the quoted texts is read to you differently, it is the
>>>>>>>>>> problem of that texts.
>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>
>>>>>>>>> The quoted texts are accurate. The (at least partial) halt
>>>>>>>>> decider must
>>>>>>>>> only correctly decide the halt status of its input.
>>>>>>>>> Computations that
>>>>>>>>> are not inputs to the halt decider do not pertain to the
>>>>>>>>> halting problem.
>>>>>>>>
>>>>>>>> Obviously the quoted text means differently to you and almost
>>>>>>>> all programmers in
>>>>>>>> the world. You are addressing your own interpretation. This is
>>>>>>>> OK, but the
>>>>>>>> interpretation is meaningless.
>>>>>>> "the description of a Turing machine M" does not mean Turing
>>>>>>> machine M.
>>>>>>> If people interpret this to mean Turing machine M they are wrong.
>>>>>>
>>>>>> Then, both Linz and the author of
>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>> are also wrong, I and almost all programmers in the world can
>>>>>> guarantee you this.
>>>>>>
>>>>>> If both authors are also wrong, replying the rest message is
>>>>>> meaningless.
>>>>>> You need to submit your interpretation to Linz and the author of
>>>>>> the wiki.
>>>>>>
>>>>> I think that the problem is that your English is not so good.
>>>>> The Linz text and the Wiki text are correct.
>>>>> Linz retired many years ago.
>>>>
>>>> In your recent post somewhere, you said:
>>>> "I made my refutation of Linz a little more clear by changing all of
>>>> the
>>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>>> understood until after my refutation of simplified Linz / Strachey is
>>>> first understood..."
>>>> Now, you changed mind to say "The Linz text and the Wiki text are
>>>> correct."
>>>>
>>> This text right here is correct:
>>> 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
>>> All of the rest of the text that "proves" the halting problem cannot be
>>> solved it incorrect.
>>
>> Which one did you mean:
>> 1. All of the rest of the text that "proves" the halting problem
>> cannot be
>> solved incorrect. (still ambiguous)
>> 2. All of the rest of the text that "proves" the halting problem cannot
>> solve incorrect.  (ambiguous)
>> 3. All of the rest of the text that "proves" the halting problem
>> cannot be
>> solved, it is incorrect.
>>
>
> All of the rest of the text that "proves" the halting problem cannot be
> solved <IS> incorrect.

Can you point to a single false premise of invalid logical construction
used in the argument?

(Not just that you disagree with the conclusion, can you find an ACTUAL
error in the logic).

Until you do, you haven't actually proved it to be incorrect.

>
>>>> There are much more inconsistent statements in your posts, like "H
>>>> is a total
>>>> function",...,etc. (I do not have time to re-find them).
>>>>
>>> H is a pure function of its inputs in that all of the nested simulations
>>> are simply data derived entirely on the basis of this inputs.
>>
>>  From your description:
>> "The x86utm operating system uses a single contiguous block of RAM to
>> most precisely map to the concept of a single contiguous Turing machine
>> tape. All of the code and data of the virtual machines that it executes
>> are contained in this single contiguous block. There is no virtual
>> memory paging in the x86utm operating system."
>>
>> I believe your H is a 'pure function', you are actually dealing with
>> two "C"
>> function calls. H is not really a simulator as you keeps calling it so.
>> Show me how H(P,P) takes its input P as 'simple data'.
>>
>
> The x86utm operating system is build from an x86 emulator capable of
> emulating all of the 80386 instructions using 4 GB of RAM.
>
> The following x86utm operating system function calls the x86 emulator to
> emulate exactly one instruction of the slave process and then return to
> the calling process. It also decodes the slave instruction that was
> emulated so that it can be stored in the execution trace.
>
> u32 DebugStep(Registers* master_state,
>               Registers* slave_state,
>               Decoded_Line_Of_Code* decoded) {}
>
>> I hate to say that your programming level is very low because this has
>> noting
>> to do with the HP proof. I think many others know x86 and C languages and
>> programming skills better than you do. No need to repeat posting the
>> compiled
>> assembly code fragment and pretend you know better and others cannot
>> see it.
>>
>
> It is ridiculously foolish to claim that P on input P has nothing to do
> with the halting problem proofs:
>
>    Now we construct a new Turing machine D with H as a subroutine.
>    This new TM calls H to determine what M does when the input to
>    M is its own description ⟨M⟩. Once D has determined this information,
>    it does the opposite.  (Sipser:1997:165)
>
> It remains ridiculously foolish for people claiming to fully understand
> the x86 language to disagree with the following statement:
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running thus conclusively proving that
> when H decides this input never halts it is correct.]

On 8/15/21 1:33 PM, olcott wrote:
> On 8/15/2021 12:26 PM, Jeff Barnett wrote:
>> On 8/14/2021 10:48 PM, olcott wrote:
>>> On 8/14/2021 11:07 PM, Jeff Barnett wrote:
>>>> On 8/14/2021 5:10 PM, olcott wrote:
>>>>> On 8/14/2021 5:56 PM, Ben Bacarisse wrote:
>>>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>>>
>>>>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> The P(P) of main() only halts because...
>>>>>>>> As you say, P(P) halts.
>>>>>>>>
>>>>>>>>> *Halting computation* is any computation that eventually
>>>>>>>>> reaches its
>>>>>>>>> own final state. This criteria divides computations that halt from
>>>>>>>>> those that merely stop running because their simulation was
>>>>>>>>> aborted.
>>>>>>>> No.  There is no "special kind of halting".  The computation
>>>>>>>> M(I) either
>>>>>>>> halts or it does not.  H(M, I) should be false if, and only if,
>>>>>>>> M(I)
>>>>>>>> does not halt.
>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>     if (H(x, x))
>>>>>>>>>       HERE: goto HERE;
>>>>>>>>> }
>>>>>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>>>>>> Why are you still hiding H?  Is it because you have still not
>>>>>>>> figured
>>>>>>>> out how to nest a call to the simulator you are using?
>>>>>>>> Fortunately "we"
>>>>>>>> (i.e. everyone but you) can see that H is wrong without even
>>>>>>>> seeing the
>>>>>>>> code.  Who is included in the "we" of the subject line?  Have
>>>>>>>> you found
>>>>>>>> someone else who thinks that false is the correct return from a
>>>>>>>> partial
>>>>>>>> halt decider called with arguments that represent a halting
>>>>>>>> computation?
>>>>>>>
>>>>>>> I have questions about the PO simulator I hope someone can
>>>>>>> answer. It
>>>>>>> perhaps concerns memory mapping: First - is every instance of a
>>>>>>> use at
>>>>>>> different levels in its own address space? Second - if not, is there
>>>>>>> any way to know when an address is reported, which simulator
>>>>>>> instance
>>>>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>>>>> the same address is reached a second time without a conditional
>>>>>>> branch
>>>>>>> being executed, is there any assurance that the addresses are noted
>>>>>>> from the same instance of the simulation? And finally, how can one
>>>>>>> determine if it's the same address twice without doing some sort of
>>>>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>>>>
>>>>>> You won't get a straight answer from PO, but I don't think there
>>>>>> is any
>>>>>> nested simulation happening at all.  PO "knows" it's that same a
>>>>>> recursion,
>>>>>
>>>>> Because context switching is required so that one function can
>>>>> resume simulating the middle of another function with DebugStep()
>>>>> and then return back to the same point in the middle of the current
>>>>> function this requires that each context have its own set of
>>>>> registers.
>>>>>
>>>>> This makes using ordinary recursion for nested x86 emulation
>>>>> infeasible because one process would clobber the stack of the other
>>>>> processes.
>>>>>
>>>>> The stack registers of ESP and EBP are included in this set of
>>>>> saved and restored registers. So we also have to have separate
>>>>> stack space or one process would clobber the stack space of the
>>>>> other process.
>>>>>
>>>>> Since no one here could begin to understand even seven lines of
>>>>> simple x86 code, I did not bring up these other details to avoid
>>>>> confusing my audience much more than they were already confused.
>>>>
>>>> Our comprehension is just fine; that's not the problem here. The
>>>> actual issue is that you neither understand nor are capable of
>>>> learning about address mapping (that little thigamajig the page
>>>> hardware implements).
>>>
>>> The x86utm operating system uses a single contiguous block of RAM to
>>> most precisely map to the concept of a single contiguous Turing
>>> machine tape. All of the code and data of the virtual machines that
>>> it executes are contained in this single contiguous block. There is
>>> no virtual memory paging in the x86utm operating system.
>>
>> I'm not suggesting you page. I'm suggesting that a simulator map the
>> address spaces of the simulated so it levels and addresses used are
>> kept straight. It doesn't seem to now. So your simulator either can't
>> or doesn't fully simulate the X86 hardware it seems. Also from your
>> response, I'd guess you don't understand the architecture very well
>> either.
>>
>
> So you fail to comprehend that simulated virtual machines can be
> executed from the same machine code address space?

Only if the memory spaces are compatible.

As I have pointed out, this means that if program A has the subroutine H
loaded at address X, then it can not decide on another machine that has
some other code at address X.

This means that you system fails the first requirement to be a universal
decider, that of being able to take as input any program.

Yes, for your limited goal, you only need for your universal decider to
get one problem correct, but if its structure doesn't allow it to accept
all possible problems it calls into question the whole basis of your proof.

We haven't pushed this fact that hard, because even allowing your H to
only accept limited programs, it STILL fails to answer the question
correctly. It does open you a bit more wiggle room to try and come up
with invalid reasons to try to argue your point.

If you had to work within the FULL restrictions, your method to detect
the 'recursion' fails, as it is a halting problem level problem in
itself to fully detect that two machines perform the same computation.

>
>> As always: seek advise, take your meds, and godspeed.
>>
>
> I can't take my chemo therapy meds because this nullifies my covid-19
> vaccination and as a result of selfish damn bastards my life may be cut
> far too short. It in not anyone's right to infect others with a deadly
> disease.

Maybe you should re-evaluate your risk choices. What are the real risk
numbers for not doing the chemo vs vaccination. Yes, it might say you
have to stay in a tight isolation for awhile to keep the COVID risk
under control, but those numbers are likely smaller than the cancer risks.

>
>>>> Context switches may need to save and restore registers, etc. Those
>>>> are the kinds of things an OS does from day one of its inception. I
>>>> think you need to return to high School (see your other thread) and
>>>> ask a teacher to hold your hand and bring you up to date; at least
>>>> to the mid 1960s. I know that would be rushing things for you. But
>>>> tiny steps first. Maybe you'll understand these things better in a
>>>> few years. Hell, while you are at it you might retake some of those
>>>> pesky HS math classes that so confused you.
>>>>
>>>> Remember: ask for help that you need; follow instructions; take your
>>>> meds. Best of luck.
>>>>
>>>> BTW At your age, whatever it is, you might need special
>>>> recommendations to reenter high school. I'm sure all of us here
>>>> would be willing to write a letter of recommendation that will state
>>>> that remedial high school classes will be perfect for you. Perhaps
>>>> this time around, you will be able to pick up all those tidbits that
>>>> went over your head the first time.
>>>>
>>>>> Not being able to understand seven simple lines of x86 code in many
>>>>> months is a horribly terrible degree of comprehension.
>>>>>
>>>>>> so he just has recursive calls traced from "outside".  I may
>>>>>> be wrong, of course, but this is one reason I think H is being kept
>>>>>> hidden -- it does not do what says.--
>>>> Jeff Barnett
>
>

On 8/15/21 1:25 PM, olcott wrote:
> On 8/15/2021 10:17 AM, Mike Terry wrote:
>> On 15/08/2021 00:27, Richard Damon wrote:
>>> On 8/14/21 6:56 PM, Ben Bacarisse wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> On 8/14/2021 2:43 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The P(P) of main() only halts because...
>>>>>> As you say, P(P) halts.
>>>>>>
>>>>>>> *Halting computation* is any computation that eventually reaches its
>>>>>>> own final state. This criteria divides computations that halt from
>>>>>>> those that merely stop running because their simulation was aborted.
>>>>>> No.  There is no "special kind of halting".  The computation M(I)
>>>>>> either
>>>>>> halts or it does not.  H(M, I) should be false if, and only if, M(I)
>>>>>> does not halt.
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>     if (H(x, x))
>>>>>>>       HERE: goto HERE;
>>>>>>> }
>>>>>> P(P) halts, yet H(P, P) is false.  That's the wrong answer.
>>>>>> Why are you still hiding H?  Is it because you have still not figured
>>>>>> out how to nest a call to the simulator you are using? 
>>>>>> Fortunately "we"
>>>>>> (i.e. everyone but you) can see that H is wrong without even
>>>>>> seeing the
>>>>>> code.  Who is included in the "we" of the subject line?  Have you
>>>>>> found
>>>>>> someone else who thinks that false is the correct return from a
>>>>>> partial
>>>>>> halt decider called with arguments that represent a halting
>>>>>> computation?
>>>>>
>>>>> I have questions about the PO simulator I hope someone can answer. It
>>>>> perhaps concerns memory mapping: First - is every instance of a use at
>>>>> different levels in its own address space? Second - if not, is there
>>>>> any way to know when an address is reported, which simulator instance
>>>>> is being reported on? When the dumb bunny (PO expression) notes that
>>>>> the same address is reached a second time without a conditional branch
>>>>> being executed, is there any assurance that the addresses are noted
>>>>> from the same instance of the simulation? And finally, how can one
>>>>> determine if it's the same address twice without doing some sort of
>>>>> compare and branch? Thanks in advance for any sort of enlightenment.
>>>>
>>>> You won't get a straight answer from PO, but I don't think there is any
>>>> nested simulation happening at all.  PO "knows" it's that same a
>>>> recursion, so he just has recursive calls traced from "outside".  I may
>>>> be wrong, of course, but this is one reason I think H is being kept
>>>> hidden -- it does not do what says.
>>>>
>>>
>>> He actually has leaked a fair amount about how the system works. H isn't
>>> actually a simulator, but an 'API Entry' into the x86utm system that has
>>> the real simulator, and calls into H as supposed to setup a new 'nested'
>>> level of simulation.
>>
>> My impression is that H is part of the application code rather than an
>> OS call, but within H there are calls to PO's simulation primitives
>> which are trapped by x86utm.exe and implemented within x86utm.  H
>> would still have the task of inspecting the (nested) emulation trace
>> entries to detect what it decides to be non-halting behaviour.  (But
>> then PO has talked about a "global decider" which is part of the OS,
>> so maybe my impression is completely wrong!  To be relevent to Linz,
>> the deciding logic at least must be in the application rather than in
>> x86utm.)
>>
>
> Now that I created
>
> int Simulate(u32 P, u32 I)
> {
>   ((int(*)(int))P)(I);
>   return 1;
> }
>
> The global halt decider is fully obsolete.
>
> I am (of course) aware that the above function directly executes rather
> that emulates its input, none-the-less it provides a very simple way
> that is very easy to understand to provide the computational equivalent
> of simulation.
>
>>>
>>> It sounds like these nested simulations are given their own stacks and
>>> 'user' code isn't supposed to be able to store data anywhere but on the
>>> stack, so that is supposed to be enough for a new environment, since he
>>> erroneously puts everything inside one code segment. (This means that H
>>> isn't a 'Universal' Halt Decider, as its input isn't an arbitrary
>>> machine.
>>>
>>> This would be one reason you can't 'copy' H, is that H isn't really the
>>> code but just an API (and if he allowed copying, his nesting detection
>>> breaks).
>>>
>>> One side effect of this is that I am not sure if his system can actually
>>> really handle finitely but multi-level simulations as at least some of
>>> the leaked implementations made H not really a computation as it used
>>> static memory to communicate between H and the OS.
>>>
>>>
>>> I also wonder if a computation built on P1 using H to decide on P2 which
>>> used H to decide on P3 could return the answer from P3 to P2.
>>>
>>> This structure could be used to solve the twins prime conjecture if the
>>> Halt decider actually worked. P1 would ask P2 to find the highest twin
>>> prime. If it is non-halting there is no highest twin prime.
>>>
>>> P2 would iterate through the twin primes starting at say 3,5 and ask P3
>>> to find the next one. If it find one, then it updates to that point and
>>> uses it again to find the next highest. If P2 is at the highest, then P3
>>> would be non-halting, and P2 would get the non-halting answer and could
>>> tell P1 what is the highest twin prime.
>>>
>>> P3 just takes its input and searches to find the next highest twin prime
>>> from there. If there isn't one it will just be non-halting.
>>>
>>> The problem is that just because P3 becomes non-halting isn't grounds to
>>> call P1 or P2 non-halting, as P3 becoming non-halting is the halting
>>> condition of P2. It is only if for every problem that P2 gives P3 that
>>> it always finds an answer that P2 becomes non-halting, and P1 then knows
>>> that the answer to the question is that there is no highest twin prime.
>>> (P1 halts in all cases).
>>>
>>> The slight problem is that his current definition of H doesn't seem to
>>> allow the caller of H to get the 'answer' from the machine it is
>>> running, so you have to do everything twice, first determine that it
>>> WOULD halt, then just call it to get the answer.
>>>
>>
>> Maybe, but the emulating user code has access to the trace of the
>> emulated program, so in principle it should be able to work out what
>> that program returned. E.g. it can track that it finished by loading
>> RAX with (say) 1 then returned (terminated), meaning that it returned 1.
>>
>> Mike.
>>
>
> The executed (rather than simulated) instance of H has every relevant
> detail of all of its nested emulations as its own data that is derived
> as a pure function of its inputs.
>
>

So, can the directly executed version of H make a simulated version of H
return an answer to the caller of that simulated version of H?

Since it appears from what you are saying that the directly executed
version of H doesn't actually simulate version of H within, does it at
least evaluate their processing decision for the case where that H is
looking at a different question than it is?

Or is this just another limitation on your decider that it can only
'handle' (actually mis-handle) nested identical decisions.

olcott <NoOne@NoWhere.com> writes:

> I want to eliminate the extra 396 pages of extraneous detail...

Not to mention the few pages of essential detail: the source of H. You
could clear everything up by posting it, but that would give the game
away, wouldn't it?

> On 8/15/2021 9:46 AM, Mike Terry wrote:

>> What would we be trying to disprove and why? :)  PO has agreed that
>> H^(H^) halts, and that H(H^,H^) returns not-halting, so that's it.
>
> Because the P of H(P,P) is at a different point in the execution trace
> than the above two cases it is not computationally equivalent to the
> above two cases.

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

If H(P, P) does not give the halting status of P(P) it is useless.
Imagine if you'd been honest about this two and half years ago? "I have
a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
one would care.

I see you've given up on Linz's proof about Turing machines. Just as
well.

--
Ben.

On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I want to eliminate the extra 396 pages of extraneous detail...
>
> Not to mention the few pages of essential detail: the source of H. You
> could clear everything up by posting it, but that would give the game
> away, wouldn't it?
>

Your game is already given away in that your inability to recognize any
detail about operating system context switching would tedn to indicate
that your knowledge of the x86 language is probably on par with this
total lack of knowledge of operating system context switching.

>> On 8/15/2021 9:46 AM, Mike Terry wrote:
>
>>> What would we be trying to disprove and why? :)  PO has agreed that
>>> H^(H^) halts, and that H(H^,H^) returns not-halting, so that's it.
>>
>> Because the P of H(P,P) is at a different point in the execution trace
>> than the above two cases it is not computationally equivalent to the
>> above two cases.
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>
> If H(P, P) does not give the halting status of P(P) it is useless.

In other words your knowledge of infinite recursive invocation is on par
with your knowledge of operating system context switching?

> Imagine if you'd been honest about this two and half years ago? "I have
> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
> one would care.
>

I finally have this one untangled:
int main() { P(P); } is computationally equivalent to
int main() { Simulate(P,P); }

Because they are computationally equivalent they have the same halting
behavior, however:

Neither of them is computationally equivalent to the H(P,P) called from
P because the different placement in the execution trace changes the
halting behavior of P(P).

> I see you've given up on Linz's proof about Turing machines. Just as
> well.
>

--
Copyright 2021 Pete Olcott

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

On 8/15/21 4:59 PM, olcott wrote:
> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I want to eliminate the extra 396 pages of extraneous detail...
>>
>> Not to mention the few pages of essential detail: the source of H.  You
>> could clear everything up by posting it, but that would give the game
>> away, wouldn't it?
>>
>
> Your game is already given away in that your inability to recognize any
> detail about operating system context switching would tedn to indicate
> that your knowledge of the x86 language is probably on par with this
> total lack of knowledge of operating system context switching.

>
>>> On 8/15/2021 9:46 AM, Mike Terry wrote:
>>
>>>> What would we be trying to disprove and why? :)  PO has agreed that
>>>> H^(H^) halts, and that H(H^,H^) returns not-halting, so that's it.
>>>
>>> Because the P of H(P,P) is at a different point in the execution trace
>>> than the above two cases it is not computationally equivalent to the
>>> above two cases.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>
>> If H(P, P) does not give the halting status of P(P) it is useless.
>
> In other words your knowledge of infinite recursive invocation is on par
> with your knowledge of operating system context switching?

Except that you have yet to prove any actual infinite recursion for any
case but the one where H is REALLY just a simulator FOREVER and that H
never answers the question so it isn't right eather.

The fact that (except for that case where H never answers) we can show
that P is, in fact, finite in execution by just running it directly we
show that P is WRONG in its decision, as P was NEVER infinite in execution.

Your so called 'proof' begins with the assumption that H is a 'pure
simulator', which means it NEVER aborts its simulation. Under THAT
condition, you can make the substituion of the trace of the simulator
with the trace of the machine it is simulating. Since this assumption is
NOT true for any H that answers H(P,P), your logic is UNSOUND, and thus
the results are NOT proven.

Note: Acts like a Pure Simulator until .... is NOT equvalent to actually
being a PURE simulator.

Just as counting to 5 is not the same as counting forever, or even
counting to 10, even if you describe it as being like counting forever
until ...

>
>> Imagine if you'd been honest about this two and half years ago?  "I have
>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts."  No
>> one would care.
>>
>
> I finally have this one untangled:
> int main() { P(P); } is computationally equivalent to
> int main() { Simulate(P,P); }
>
> Because they are computationally equivalent they have the same halting
> behavior, however:
>
> Neither of them is computationally equivalent to the H(P,P) called from
> P because the different placement in the execution trace changes the
> halting behavior of P(P).

??? If P(P) is a computation then the results of P(P) will ALWAYS be the
same, regardless of the environment it is called in. That is part of the
DEFINITION of a Computation.

If this is not true, then P(P) is not a computation. Because of how we
construct P, this can only be true if H is not a computation.

Now, this could actually be true, H might not be a computation, but if
that is true then your initial claim that H is the computational
equvalent of the Turing Machine H of the proof, and thus none of your
'proof' means anything.

>
>> I see you've given up on Linz's proof about Turing machines.  Just as
>> well.
>>
>
>

olcott <NoOne@NoWhere.com> writes:

> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:

>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>>
>> If H(P, P) does not give the halting status of P(P) it is useless.
>
> In other words your knowledge of infinite recursive invocation is on
> par with your knowledge of operating system context switching?

P(P) halts.

>> Imagine if you'd been honest about this two and half years ago? "I have
>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>> one would care.
>
> I finally have this one untangled:
> int main() { P(P); } is computationally equivalent to
> int main() { Simulate(P,P); }
>
> Because they are computationally equivalent they have the same halting
> behavior, however:
>
> Neither of them is computationally equivalent to the H(P,P) called
> from P because the different placement in the execution trace changes
> the halting behavior of P(P).

H(M, I) is supposed to report the halting or otherwise of M(I). You
don't claim that your H can do this in all cases, but you boasted (you
like boasting) that it did for the "hat" version of H, AKA P above. It
does not. P(P) halts but H(P, P) == 0. Boring.

--
Ben.

On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
> On 8/15/2021 9:45 AM, wij wrote:
> > On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
> >> On 8/15/2021 2:50 AM, wij wrote:
> >>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
> >>>> On 8/14/2021 1:09 PM, wij wrote:
> >>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
> >>>>>> On 8/14/2021 11:35 AM, wij wrote:
> >>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
> >>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
> >>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
> >>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
> >>>>>>>>>> how it is called including this example:
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> P((u32)P);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>> Because the halting problem only requires that the (at least partial)
> >>>>>>>>>> halt decider decide its input correctly the fact that the direct
> >>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
> >>>>>>>>>> to the halting problem.
> >>>>>>>>>
> >>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
> >>>>>>>>> problem means a program H decides whether P(input) will halt or not.
> >>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
> >>>>>>>>> Submit message to the authors.
> >>>>>>>>>
> >>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
> >>>>>>>> only correctly decide the halt status of its input. Computations that
> >>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
> >>>>>>>
> >>>>>>> Obviously the quoted text means differently to you and almost all programmers in
> >>>>>>> the world. You are addressing your own interpretation. This is OK, but the
> >>>>>>> interpretation is meaningless.
> >>>>>> "the description of a Turing machine M" does not mean Turing machine M.
> >>>>>> If people interpret this to mean Turing machine M they are wrong.
> >>>>>
> >>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
> >>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
> >>>>>
> >>>>> If both authors are also wrong, replying the rest message is meaningless.
> >>>>> You need to submit your interpretation to Linz and the author of the wiki.
> >>>>>
> >>>> I think that the problem is that your English is not so good.
> >>>> The Linz text and the Wiki text are correct.
> >>>> Linz retired many years ago.
> >>>
> >>> In your recent post somewhere, you said:
> >>> "I made my refutation of Linz a little more clear by changing all of the
> >>> subscripts to be numeric. My refutation of Linz cannot be properly
> >>> understood until after my refutation of simplified Linz / Strachey is
> >>> first understood..."
> >>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
> >>>
> >> This text right here is correct:
> >> 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
> >> All of the rest of the text that "proves" the halting problem cannot be
> >> solved it incorrect.
> >
> > Which one did you mean:
> > 1. All of the rest of the text that "proves" the halting problem cannot be
> > solved incorrect. (still ambiguous)
> > 2. All of the rest of the text that "proves" the halting problem cannot
> > solve incorrect. (ambiguous)
> > 3. All of the rest of the text that "proves" the halting problem cannot be
> > solved, it is incorrect.
> >
>
> All of the rest of the text that "proves" the halting problem cannot be
> solved <IS> incorrect.
> >>> There are much more inconsistent statements in your posts, like "H is a total
> >>> function",...,etc. (I do not have time to re-find them).
> >>>
> >> H is a pure function of its inputs in that all of the nested simulations
> >> are simply data derived entirely on the basis of this inputs.
> >
> > From your description:
> > "The x86utm operating system uses a single contiguous block of RAM to
> > most precisely map to the concept of a single contiguous Turing machine
> > tape. All of the code and data of the virtual machines that it executes
> > are contained in this single contiguous block. There is no virtual
> > memory paging in the x86utm operating system."
> >
> > I believe your H is a 'pure function', you are actually dealing with two "C"
> > function calls. H is not really a simulator as you keeps calling it so.
> > Show me how H(P,P) takes its input P as 'simple data'.
> >
> The x86utm operating system is build from an x86 emulator capable of
> emulating all of the 80386 instructions using 4 GB of RAM.

Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
I do not believe you can build a machine or software capable of emulating ALL of
the 80386 instructions. Therefore, I assume all you have is a simulating
application.

> The following x86utm operating system function calls the x86 emulator to
> emulate exactly one instruction of the slave process and then return to
> the calling process. It also decodes the slave instruction that was
> emulated so that it can be stored in the execution trace.
>
> u32 DebugStep(Registers* master_state,
> Registers* slave_state,
> Decoded_Line_Of_Code* decoded) {}

The question how H(P,P) treats its argument P,P as data is still not answered.
E.g. does H contain a call to DebugStep to decode P pointed byte string data?
Actually, there are many implementing problems for your simulator H and P to
be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
the simulation is not necessary for the proof.

> > I hate to say that your programming level is very low because this has noting
> > to do with the HP proof. I think many others know x86 and C languages and
> > programming skills better than you do. No need to repeat posting the compiled
> > assembly code fragment and pretend you know better and others cannot see it.
> >
> It is ridiculously foolish to claim that P on input P has nothing to do
> with the halting problem proofs:
>
> Now we construct a new Turing machine D with H as a subroutine.
> This new TM calls H to determine what M does when the input to
> M is its own description ⟨M⟩. Once D has determined this information,
> it does the opposite. (Sipser:1997:165)
>
> It remains ridiculously foolish for people claiming to fully understand
> the x86 language to disagree with the following statement:
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running ...[Cut]

On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>
>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>
>> In other words your knowledge of infinite recursive invocation is on
>> par with your knowledge of operating system context switching?
>
> P(P) halts.
>
>>> Imagine if you'd been honest about this two and half years ago? "I have
>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>> one would care.
>>
>> I finally have this one untangled:
>> int main() { P(P); } is computationally equivalent to
>> int main() { Simulate(P,P); }
>>
>> Because they are computationally equivalent they have the same halting
>> behavior, however:
>>
>> Neither of them is computationally equivalent to the H(P,P) called
>> from P because the different placement in the execution trace changes
>> the halting behavior of P(P).
>
> H(M, I) is supposed to report the halting or otherwise of M(I). You
> don't claim that your H can do this in all cases, but you boasted (you
> like boasting) that it did for the "hat" version of H, AKA P above. It
> does not. P(P) halts but H(P, P) == 0. Boring.
>

That you don't bother to pay attention to the details or are unable to
understand the x86 language well enough to understand the details in no
way negates the fact that H(P,P) does correctly decide that its input
never halts. No one can possibly provide a rebuttal to this simply
because it is true.

--
Copyright 2021 Pete Olcott

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

On 8/16/2021 1:27 AM, wij wrote:
> On Monday, 16 August 2021 at 00:44:43 UTC+8, olcott wrote:
>> On 8/15/2021 9:45 AM, wij wrote:
>>> On Sunday, 15 August 2021 at 21:45:09 UTC+8, olcott wrote:
>>>> On 8/15/2021 2:50 AM, wij wrote:
>>>>> On Sunday, 15 August 2021 at 02:24:42 UTC+8, olcott wrote:
>>>>>> On 8/14/2021 1:09 PM, wij wrote:
>>>>>>> On Sunday, 15 August 2021 at 01:22:11 UTC+8, olcott wrote:
>>>>>>>> On 8/14/2021 11:35 AM, wij wrote:
>>>>>>>>> On Sunday, 15 August 2021 at 00:16:20 UTC+8, olcott wrote:
>>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>>> This exact same analysis always applies to the input to H(P,P) no matter
>>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> P((u32)P);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> Because the halting problem only requires that the (at least partial)
>>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not relevant
>>>>>>>>>>>> to the halting problem.
>>>>>>>>>>>
>>>>>>>>>>> I do not know English well, but I (almost every programmer) am sure the halting
>>>>>>>>>>> problem means a program H decides whether P(input) will halt or not.
>>>>>>>>>>> If the quoted texts is read to you differently, it is the problem of that texts.
>>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>>
>>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider must
>>>>>>>>>> only correctly decide the halt status of its input. Computations that
>>>>>>>>>> are not inputs to the halt decider do not pertain to the halting problem.
>>>>>>>>>
>>>>>>>>> Obviously the quoted text means differently to you and almost all programmers in
>>>>>>>>> the world. You are addressing your own interpretation. This is OK, but the
>>>>>>>>> interpretation is meaningless.
>>>>>>>> "the description of a Turing machine M" does not mean Turing machine M.
>>>>>>>> If people interpret this to mean Turing machine M they are wrong.
>>>>>>>
>>>>>>> Then, both Linz and the author of https://en.wikipedia.org/wiki/Halting_problem
>>>>>>> are also wrong, I and almost all programmers in the world can guarantee you this.
>>>>>>>
>>>>>>> If both authors are also wrong, replying the rest message is meaningless.
>>>>>>> You need to submit your interpretation to Linz and the author of the wiki.
>>>>>>>
>>>>>> I think that the problem is that your English is not so good.
>>>>>> The Linz text and the Wiki text are correct.
>>>>>> Linz retired many years ago.
>>>>>
>>>>> In your recent post somewhere, you said:
>>>>> "I made my refutation of Linz a little more clear by changing all of the
>>>>> subscripts to be numeric. My refutation of Linz cannot be properly
>>>>> understood until after my refutation of simplified Linz / Strachey is
>>>>> first understood..."
>>>>> Now, you changed mind to say "The Linz text and the Wiki text are correct."
>>>>>
>>>> This text right here is correct:
>>>> 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
>>>> All of the rest of the text that "proves" the halting problem cannot be
>>>> solved it incorrect.
>>>
>>> Which one did you mean:
>>> 1. All of the rest of the text that "proves" the halting problem cannot be
>>> solved incorrect. (still ambiguous)
>>> 2. All of the rest of the text that "proves" the halting problem cannot
>>> solve incorrect. (ambiguous)
>>> 3. All of the rest of the text that "proves" the halting problem cannot be
>>> solved, it is incorrect.
>>>
>>
>> All of the rest of the text that "proves" the halting problem cannot be
>> solved <IS> incorrect.
>>>>> There are much more inconsistent statements in your posts, like "H is a total
>>>>> function",...,etc. (I do not have time to re-find them).
>>>>>
>>>> H is a pure function of its inputs in that all of the nested simulations
>>>> are simply data derived entirely on the basis of this inputs.
>>>
>>> From your description:
>>> "The x86utm operating system uses a single contiguous block of RAM to
>>> most precisely map to the concept of a single contiguous Turing machine
>>> tape. All of the code and data of the virtual machines that it executes
>>> are contained in this single contiguous block. There is no virtual
>>> memory paging in the x86utm operating system."
>>>
>>> I believe your H is a 'pure function', you are actually dealing with two "C"
>>> function calls. H is not really a simulator as you keeps calling it so.
>>> Show me how H(P,P) takes its input P as 'simple data'.
>>>
>> The x86utm operating system is build from an x86 emulator capable of
>> emulating all of the 80386 instructions using 4 GB of RAM.
>
> Firstly, 'x86utm operating system'(all from power on) is likely a misleading name .
> Secondly, if 'x86 emulator' do exist, it is likely a bought commodity, because
> I do not believe you can build a machine or software capable of emulating ALL of
> the 80386 instructions. Therefore, I assume all you have is a simulating
> application.
>
>> The following x86utm operating system function calls the x86 emulator to
>> emulate exactly one instruction of the slave process and then return to
>> the calling process. It also decodes the slave instruction that was
>> emulated so that it can be stored in the execution trace.
>>
>> u32 DebugStep(Registers* master_state,
>> Registers* slave_state,
>> Decoded_Line_Of_Code* decoded) {}
>
> The question how H(P,P) treats its argument P,P as data is still not answered.

The details need not be specified to understand that all the simulations
of the executed simulator are data belonging to the executed H. Details
merely provide the means for endless digression away from the key point.

> E.g. does H contain a call to DebugStep to decode P pointed byte string data?
> Actually, there are many implementing problems for your simulator H and P to
> be a valid proof. But, I saw your reply to Mike Terry that you seem to 'realize'
> the simulation is not necessary for the proof.
>

olcott <NoOne@NoWhere.com> writes:

> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>
>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>
>>> In other words your knowledge of infinite recursive invocation is on
>>> par with your knowledge of operating system context switching?
>> P(P) halts.
>>
>>>> Imagine if you'd been honest about this two and half years ago? "I have
>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>>> one would care.
>>>
>>> I finally have this one untangled:
>>> int main() { P(P); } is computationally equivalent to
>>> int main() { Simulate(P,P); }
>>>
>>> Because they are computationally equivalent they have the same halting
>>> behavior, however:
>>>
>>> Neither of them is computationally equivalent to the H(P,P) called
>>> from P because the different placement in the execution trace changes
>>> the halting behavior of P(P).
>>
>> H(M, I) is supposed to report the halting or otherwise of M(I). You
>> don't claim that your H can do this in all cases, but you boasted (you
>> like boasting) that it did for the "hat" version of H, AKA P above. It
>> does not. P(P) halts but H(P, P) == 0. Boring.
>
> That you don't bother to pay attention to the details or are unable to
> understand the x86 language well enough to understand the details in
> no way negates the fact that H(P,P) does correctly decide that its
> input never halts.

The details don't change whether H(P,P) is right or wrong. H(P,P)
should report the halting or otherwise of P(P). It's that simple.

> No one can possibly provide a rebuttal to this simply because it is
> true.

An H with H(P, P) == false when P(P) halts is obviously possible and I
can't stop you calling it correct. That does not stop it being obvious
and boring. To be interesting it would have to do the impossible thing
you once claimed.

--
Ben.

On 8/16/21 6:49 PM, olcott wrote:
> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>>
>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>
>>> In other words your knowledge of infinite recursive invocation is on
>>> par with your knowledge of operating system context switching?
>>
>> P(P) halts.
>>
>>>> Imagine if you'd been honest about this two and half years ago?  "I
>>>> have
>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts."  No
>>>> one would care.
>>>
>>> I finally have this one untangled:
>>> int main() { P(P); } is computationally equivalent to
>>> int main() { Simulate(P,P); }
>>>
>>> Because they are computationally equivalent they have the same halting
>>> behavior, however:
>>>
>>> Neither of them is computationally equivalent to the H(P,P) called
>>> from P because the different placement in the execution trace changes
>>> the halting behavior of P(P).
>>
>> H(M, I) is supposed to report the halting or otherwise of M(I).  You
>> don't claim that your H can do this in all cases, but you boasted (you
>> like boasting) that it did for the "hat" version of H, AKA P above.  It
>> does not.  P(P) halts but H(P, P) == 0.  Boring.
>>
>
> That you don't bother to pay attention to the details or are unable to
> understand the x86 language well enough to understand the details in no
> way negates the fact that H(P,P) does correctly decide that its input
> never halts. No one can possibly provide a rebuttal to this simply
> because it is true.
>

You say that, but it isn't true.

The x86 assembly is NOT acurrately traced or analyized, because you
ignore the behavior of the function H on the execution.

FAIL.

When we actually run the program P(P), it Halts.

This result is very clear from a simple analysis of the x86 assembly code.

P calls H which does some calculations (its partial simulation of P(P))
and then returns a non-halting answer which causes P to return (its
'halting' response).

This is what the ACTUAL x86 code does. PERIOD. (assuming that H(P,P)
returns the non-halting answer, we don't really need to look at the case
where is doesn't, as that H starts out wrong by not answering).

Your actual argument isn't even really based on x86 code, except that
you are using x86 code that you don't show to generate the faulty output
that you base your argument on.

Your argument stands on the unsond footing of transforming the
simulation of a partial simulator to the simulation of the code it is
simulating. This argument is close to an proper transformation, and you
use sloppy wording to try to claim that case, that of a PURE
UNCONDITIONAL COMPLETE simulation can be replaced.

Since H does NOT meet that requirement, the transform is UNSOUND.

Being an accurate conditional simulatior until you stop is NOT being an
pure unconditional simulator. PERIOD. DEFINITION. Your argument FAILS.

YOU are the one that doesn't bother to pay attention, and this is the
fatal flaw to your plan to get feedback to improve your argument. If you
won't actually listen to advice, it can't help you.

After all, it is written:

The way of fools seems right to them,
but the wise listen to advice.

Maybe, if you will actually look at the rebuttals that have been made,
you could see the problems with your arguments and see where you might
be able to do something. Ignoring it, has basically made that last
couple years of your work really for nought.

On 8/16/21 6:57 PM, olcott wrote:

> The code does what it specifies that it does that alone is complete
> proof. We can know for sure that H does perform a pure simulation of P
> because the x86 code specified by P is exactly exactly as this code
> specifies.

Except that it doesn't, as P calls H but the trace of P doesn't show that.

THIS is a fundamental flaw. Once you have that error, you need to use
details of H to try to argue that this is valid, but your arguement
assumes (and vaguely claims) that it has properties that it actually
doesn't.

The transformation is valid for UNCONDITIONAL simulation, but the
simulation is demonstratively conditional.

On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/15/2021 8:07 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/15/2021 3:31 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>
>>>>> If H(P, P) does not give the halting status of P(P) it is useless.
>>>>
>>>> In other words your knowledge of infinite recursive invocation is on
>>>> par with your knowledge of operating system context switching?
>>> P(P) halts.
>>>
>>>>> Imagine if you'd been honest about this two and half years ago? "I have
>>>>> a function H such that H(H_Hat, H_Hat) == 0 so H_Hat(H_Hat) halts." No
>>>>> one would care.
>>>>
>>>> I finally have this one untangled:
>>>> int main() { P(P); } is computationally equivalent to
>>>> int main() { Simulate(P,P); }
>>>>
>>>> Because they are computationally equivalent they have the same halting
>>>> behavior, however:
>>>>
>>>> Neither of them is computationally equivalent to the H(P,P) called
>>>> from P because the different placement in the execution trace changes
>>>> the halting behavior of P(P).
>>>
>>> H(M, I) is supposed to report the halting or otherwise of M(I). You
>>> don't claim that your H can do this in all cases, but you boasted (you
>>> like boasting) that it did for the "hat" version of H, AKA P above. It
>>> does not. P(P) halts but H(P, P) == 0. Boring.
>>
>> That you don't bother to pay attention to the details or are unable to
>> understand the x86 language well enough to understand the details in
>> no way negates the fact that H(P,P) does correctly decide that its
>> input never halts.
>
> The details don't change whether H(P,P) is right or wrong. H(P,P)
> should report the halting or otherwise of P(P). It's that simple.
>

int main() { H(P,P); } does correctly decide that its input never halts.
Unless the H of main() aborts its simulation of P(P), this input never
halts.

That you simply assume that the behavior of int main() { P(P); }
contradicts the halting decision of H without actually examining the
basis that H uses for its decision is either:

(1) Dishonestly disingenuous.
(2) Beyond your technical capacity, not knowing the x86 language at all.

Because of your total lack of understanding of operating system process
context switching it seems that the latter is much more probable than
the former.

I will offer this contingent apology: If you never were actually lying
about these things, I apologize for calling you a liar. It was an honest
mistake on my part, yet a mistake none-the-less.

>> No one can possibly provide a rebuttal to this simply because it is
>> true.
>
> An H with H(P, P) == false when P(P) halts is obviously possible and I
> can't stop you calling it correct. That does not stop it being obvious
> and boring. To be interesting it would have to do the impossible thing
> you once claimed.
>

--
Copyright 2021 Pete Olcott

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

On 8/16/2021 6:52 PM, Richard Damon wrote:
> On 8/16/21 6:57 PM, olcott wrote:
>
>> The code does what it specifies that it does that alone is complete
>> proof. We can know for sure that H does perform a pure simulation of P
>> because the x86 code specified by P is exactly exactly as this code
>> specifies.
>
> Except that it doesn't, as P calls H but the trace of P doesn't show that.
>

If I explained all of the details about this 150 more times you would
bother to pay enough attention to see that I am right. This just isn't
worth the effort for me.

> THIS is a fundamental flaw. Once you have that error, you need to use
> details of H to try to argue that this is valid, but your arguement
> assumes (and vaguely claims) that it has properties that it actually
> doesn't.
>
> The transformation is valid for UNCONDITIONAL simulation, but the
> simulation is demonstratively conditional.
>

--
Copyright 2021 Pete Olcott

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

On 8/16/21 8:24 PM, olcott wrote:
> On 8/16/2021 6:52 PM, Richard Damon wrote:
>> On 8/16/21 6:57 PM, olcott wrote:
>>
>>> The code does what it specifies that it does that alone is complete
>>> proof. We can know for sure that H does perform a pure simulation of P
>>> because the x86 code specified by P is exactly exactly as this code
>>> specifies.
>>
>> Except that it doesn't, as P calls H but the trace of P doesn't show
>> that.
>>
>
> If I explained all of the details about this 150 more times you would
> bother to pay enough attention to see that I am right. This just isn't
> worth the effort for me.

I.E., you don't have an answer and all you can do is repeat the original
lie.

You claim that it is obvious from the x86 code, but then you don't
actually follow what the plain x86 code says.

FAIL as UNSOUND.

>
>> THIS is a fundamental flaw. Once you have that error, you need to use
>> details of H to try to argue that this is valid, but your arguement
>> assumes (and vaguely claims) that it has properties that it actually
>> doesn't.
>>
>> The transformation is valid for UNCONDITIONAL simulation, but the
>> simulation is demonstratively conditional.
>>
>
>

On 8/16/21 8:20 PM, olcott wrote:
> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:

>> The details don't change whether H(P,P) is right or wrong.  H(P,P)
>> should report the halting or otherwise of P(P).  It's that simple.
>>
>
> int main() { H(P,P); } does correctly decide that its input never halts.
> Unless the H of main() aborts its simulation of P(P), this input never
> halts.

Excpet that isn't the question.

The question is what does P(P) do based on the definition of H that is
being used.

Since H does abort the simulation, you need to see what P does when H
does abort its simulation, which is Halt, so that is the right answer.

You think you need to study basic English.

>
> That you simply assume that the behavior of int main() { P(P); }
> contradicts the halting decision of H without actually examining the
> basis that H uses for its decision is either:

You mean look at the actual definition of the problem>

>
> (1) Dishonestly disingenuous.

Yes, you are.

> (2) Beyond your technical capacity, not knowing the x86 language at all.

And that too.

>
> Because of your total lack of understanding of operating system process
> context switching it seems that the latter is much more probable than
> the former.

Context switches have absolutely nothing to do with the problem.

Actually, since the original problem is about basically simple Turing
Machines, Operating Systems and Context Switching aren't really in view
as Turing Machines don't do it. Yes, they can be configured to compute
the same computation as a computation that does that, but then those
Turing Machines don't really end up with either.

>
> I will offer this contingent apology: If you never were actually lying
> about these things, I apologize for calling you a liar. It was an honest
> mistake on my part, yet a mistake none-the-less.
>
>>> No one can possibly provide a rebuttal to this simply because it is
>>> true.
>>
>> An H with H(P, P) == false when P(P) halts is obviously possible and I
>> can't stop you calling it correct.  That does not stop it being obvious
>> and boring.  To be interesting it would have to do the impossible thing
>> you once claimed.
>>
>
>

On 8/16/2021 8:00 PM, Richard Damon wrote:
> On 8/16/21 8:24 PM, olcott wrote:
>> On 8/16/2021 6:52 PM, Richard Damon wrote:
>>> On 8/16/21 6:57 PM, olcott wrote:
>>>
>>>> The code does what it specifies that it does that alone is complete
>>>> proof. We can know for sure that H does perform a pure simulation of P
>>>> because the x86 code specified by P is exactly exactly as this code
>>>> specifies.
>>>
>>> Except that it doesn't, as P calls H but the trace of P doesn't show
>>> that.
>>>
>>
>> If I explained all of the details about this 150 more times you would
>> bother to pay enough attention to see that I am right. This just isn't
>> worth the effort for me.
>
>
> I.E., you don't have an answer and all you can do is repeat the original
> lie.
>
> You claim that it is obvious from the x86 code, but then you don't
> actually follow what the plain x86 code says.
>
> FAIL as UNSOUND.
>

Try reading this again and again over and over for ten hours straight
until you have 100% perfect understanding of every single word:

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.

It only takes 100% perfectly complete understanding to know that I am
totally correct about this. It is difficult material so it may take ten
continuous hours to fully understand it.

>>
>>> THIS is a fundamental flaw. Once you have that error, you need to use
>>> details of H to try to argue that this is valid, but your arguement
>>> assumes (and vaguely claims) that it has properties that it actually
>>> doesn't.
>>>
>>> The transformation is valid for UNCONDITIONAL simulation, but the
>>> simulation is demonstratively conditional.
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 8/16/2021 8:05 PM, Richard Damon wrote:
> On 8/16/21 8:20 PM, olcott wrote:
>> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>
>>> The details don't change whether H(P,P) is right or wrong.  H(P,P)
>>> should report the halting or otherwise of P(P).  It's that simple.
>>>
>>
>> int main() { H(P,P); } does correctly decide that its input never halts.
>> Unless the H of main() aborts its simulation of P(P), this input never
>> halts.
>
> Excpet that isn't the question.
>
> The question is what does P(P) do based on the definition of H that is
> being used.
>

The question is whether or not the input to H halts and H answers this
question correctly. That is all that is required by the halting problem.

--
Copyright 2021 Pete Olcott

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

On 8/16/21 9:07 PM, olcott wrote:
> On 8/16/2021 8:00 PM, Richard Damon wrote:
>> On 8/16/21 8:24 PM, olcott wrote:
>>> On 8/16/2021 6:52 PM, Richard Damon wrote:
>>>> On 8/16/21 6:57 PM, olcott wrote:
>>>>
>>>>> The code does what it specifies that it does that alone is complete
>>>>> proof. We can know for sure that H does perform a pure simulation of P
>>>>> because the x86 code specified by P is exactly exactly as this code
>>>>> specifies.
>>>>
>>>> Except that it doesn't, as P calls H but the trace of P doesn't show
>>>> that.
>>>>
>>>
>>> If I explained all of the details about this 150 more times you would
>>> bother to pay enough attention to see that I am right. This just isn't
>>> worth the effort for me.
>>
>>
>> I.E., you don't have an answer and all you can do is repeat the original
>> lie.
>>
>> You claim that it is obvious from the x86 code, but then you don't
>> actually follow what the plain x86 code says.
>>
>> FAIL as UNSOUND.
>>
>
> Try reading this again and again over and over for ten hours straight
> until you have 100% perfect understanding of every single word:
>
> 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.

Please read the definitions again.

A Pure simulator NEVER aborts its simulation.

A simulator that acts as a pure simulator of its input until something
is NOT a pure simulator, BY DEFINITION.

FAIL.

Yes, an accurate simulator will not affect what happens to the machine
it is simulating (as far as it simulates it), but the fact that it does
abort its simulation and return an answer does affect the machine it is
being used by.

Thus, when the simulator sees a copy of itself, it needs to take this
fact into account.

If it assumes that the simulator it is simulating will NEVER abort its
simulation, while if that machine was actually simulated for enough time
it would, then the simulator has made an UNSOUND decision.

>
> It only takes 100% perfectly complete understanding to know that I am
> totally correct about this. It is difficult material so it may take ten
> continuous hours to fully understand it.
>

Maybe you can use your '100% perfectly complete understanding' to point
out the actual error that I make above. Which statement is inaccurate?
Not just that you disagree with the conclusion, where is the error in
the logic.

How about explain how you logic allows two different deciders to both
give 'accurate' answers for a problem that are different, and in fact
contractory?

Since it has been shown that a REAL pure simulation of P(P) as well as
the actual running of P(P) both show that it does actually halt.

Maybe your idea that a pure simulator until (which says that the machine
doesn't reach a halting state) is the same as a real UTM (which says
that it does Halt) isn't correct.

This seems like the prototypical definition of an inconsistent logic system.

>>>
>>>> THIS is a fundamental flaw. Once you have that error, you need to use
>>>> details of H to try to argue that this is valid, but your arguement
>>>> assumes (and vaguely claims) that it has properties that it actually
>>>> doesn't.
>>>>
>>>> The transformation is valid for UNCONDITIONAL simulation, but the
>>>> simulation is demonstratively conditional.
>>>>
>>>
>>>
>>
>
>

In summary:

UNSOUND LOGIC.

On 8/16/21 9:19 PM, olcott wrote:
> On 8/16/2021 8:05 PM, Richard Damon wrote:
>> On 8/16/21 8:20 PM, olcott wrote:
>>> On 8/16/2021 6:46 PM, Ben Bacarisse wrote:
>>
>>>> The details don't change whether H(P,P) is right or wrong.  H(P,P)
>>>> should report the halting or otherwise of P(P).  It's that simple.
>>>>
>>>
>>> int main() { H(P,P); } does correctly decide that its input never halts.
>>> Unless the H of main() aborts its simulation of P(P), this input never
>>> halts.
>>
>> Excpet that isn't the question.
>>
>> The question is what does P(P) do based on the definition of H that is
>> being used.
>>
>
> The question is whether or not the input to H halts and H answers this
> question correctly. That is all that is required by the halting problem.
>
>

Read your problem again.

Does the decider correctly decide on the machine REPRESENTED by the input.

Inputs don't Halt. Machines/Compuations do.

The machine the input represents P(P) does Halt, so that is the right
answer.

FAIL

I think you need to take a course in basic English (not college level,
something on the High School to Junior High level would be enough).

On 8/16/2021 8:24 PM, Richard Damon wrote:
> On 8/16/21 9:07 PM, olcott wrote:
>> On 8/16/2021 8:00 PM, Richard Damon wrote:
>>> On 8/16/21 8:24 PM, olcott wrote:
>>>> On 8/16/2021 6:52 PM, Richard Damon wrote:
>>>>> On 8/16/21 6:57 PM, olcott wrote:
>>>>>
>>>>>> The code does what it specifies that it does that alone is complete
>>>>>> proof. We can know for sure that H does perform a pure simulation of P
>>>>>> because the x86 code specified by P is exactly exactly as this code
>>>>>> specifies.
>>>>>
>>>>> Except that it doesn't, as P calls H but the trace of P doesn't show
>>>>> that.
>>>>>
>>>>
>>>> If I explained all of the details about this 150 more times you would
>>>> bother to pay enough attention to see that I am right. This just isn't
>>>> worth the effort for me.
>>>
>>>
>>> I.E., you don't have an answer and all you can do is repeat the original
>>> lie.
>>>
>>> You claim that it is obvious from the x86 code, but then you don't
>>> actually follow what the plain x86 code says.
>>>
>>> FAIL as UNSOUND.
>>>
>>
>> Try reading this again and again over and over for ten hours straight
>> until you have 100% perfect understanding of every single word:
>>
>> 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.
>
> Please read the definitions again.
>
> A Pure simulator NEVER aborts its simulation.

Like I said you probably have to reread what I say a few hundred more
times before you will understand it. I can no longer tolerate people
that continually glace at a few words before forming their rebuttal.

--
Copyright 2021 Pete Olcott

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

On 8/16/21 10:13 PM, olcott wrote:
> On 8/16/2021 8:24 PM, Richard Damon wrote:
>>
>> Please read the definitions again.
>>
>> A Pure simulator NEVER aborts its simulation.
>
> Like I said you probably have to reread what I say a few hundred more
> times before you will understand it. I can no longer tolerate people
> that continually glace at a few words before forming their rebuttal.
>

Ok, so you just admit that you aren't using the real definition.

Please show ANY reliable reference that matches what you are saying.

ANY.

You logic is unsound

YOU are UNSOUND.