On 5/13/2025 11:18 PM, olcott wrote:
On 5/13/2025 9:44 PM, dbush wrote:
On 5/13/2025 10:43 PM, olcott wrote:
On 5/13/2025 8:58 PM, dbush wrote:
On 5/13/2025 9:55 PM, olcott wrote:
On 5/13/2025 8:45 PM, dbush wrote:
On 5/13/2025 9:40 PM, olcott wrote:
On 5/13/2025 8:19 PM, dbush wrote:
On 5/13/2025 9:07 PM, olcott wrote:
On 5/13/2025 7:58 PM, dbush wrote:
On 5/13/2025 5:04 PM, olcott wrote:
On 5/13/2025 12:46 PM, Mike Terry wrote:
The global trace table does not record the simulation level for an entry, so the matching process is agnostic when it comes to simulation levels. Also note there are many conditional branch instructions in HHH which would prevent matches occuring if we were to include HHH instructions in the examined trace!
>
>
Yes that is true. The program-under-test is not the test- program.
>
FALSE!!!!
>
It is *both* the test program *and* part of the program under test. As such, it is not allowed to be changed for any reason, hypothetical or otherwise.
>
Let the record show that no attempt was made to refute the above, therefore Peter Olcott has admitted that HHH part of the code under test, i.e. part of the input.
>
>
When HHH is reporting on the behavior of the finite string of x86
machine code specified by DD,
>
i.e. the machine code of the function DD, the machine code of the function HHH, and the machine code of everything that HHH calls down to the OS leve.
>
>
*would never stop running unless aborted*
Thus meets this spec:
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*would never stop running unless aborted* then
>
Which you lie about Sipser having agreed with:
>
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
> I exchanged emails with him about this. He does not agree with anything
> substantive that PO has written. I won't quote him, as I don't have
> permission, but he was, let's say... forthright, in his reply to me.
>
>
When we go by the exact meaning of the words
he agreed to as the measure then I am correct.
>
But not by the way he and everyone else understood them,
>
This post is only about the fact that HHH does
meet the above spec. It was never about anything
else and your changing the subject is dishonest.
>
Then maybe you should stop implying that Sipser agrees with the above when it's been proven on multiple occasions that he has not.
>
*That* is dishonest.
>
>
I have the emails where he agreed that I could
publish his agreement with those exact words.
>
But he didn't agree to your meaning of those words,
Even you agreed with my meaning of those words.
The above words only have one single correct
meaning.
and your continued implication that he does is a form of lying.
Your trimming of the above constitutes your admission of lying.
People tried for more than a year to get away with
saying the DDD was not emulated by HHH correctly
It's not, and you've admitted as much:
On 5/5/2025 8:24 AM, dbush wrote:
> On 5/4/2025 11:03 PM, dbush wrote:
>> On 5/4/2025 10:05 PM, olcott wrote:
>>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>>> do not allow HHH to stop its emulation,
>>>
>>> Sure they do you freaking moron...
>>
>> Then show where in the Intel instruction manual that the execution of
>> any instruction other than a HLT is allowed to stop instead of
>> executing the next instruction.
>>
>> Failure to do so in your next reply, or within one hour of your next
>> post on this newsgroup, will be taken as you official on-the-record
>> admission that there is no such allowance and that HHH does NOT
>> correctly simulate DD.
>
> Let the record show that Peter Olcott made the following post in this
> newsgroup after the above message:
>
> On 5/4/2025 11:04 PM, olcott wrote:
> > D *WOULD NEVER STOP RUNNING UNLESS*
> > indicates that professor Sipser was agreeing
> > to hypotheticals AS *NOT CHANGING THE INPUT*
> >
> > You are taking
> > *WOULD NEVER STOP RUNNING UNLESS*
> > to mean *NEVER STOPS RUNNING* that is incorrect.
>
> And has made no attempt after over 9 hours to show where in the Intel
> instruction manual that execution is allowed to stop after any
> instruction other than HLT.
>
> Therefore, as per the above criteria:
>
> LET THE RECORD SHOW
>
> That Peter Olcott
>
> Has *officially* admitted
>
> That DD is NOT correctly simulated by HHH
until
I stipulated that DDD is emulated by HHH according to
the rules of the x86 language.
Meaning that HHH doesn't return an answer.
People tried to get away with saying that HHH
cannot not decide halting on the basis of
*simulated D would never stop running unless aborted*
until I pointed out that those exact words are in the spec.
Nope:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
People tried to get away with saying that the correct
emulation of a non-halting input cannot be partial
Because the x86 language doesn't allow stopping until you reach a HLT instruction.
Yet partial simulation is right in the spec:
*H correctly simulates its input D until*
Nope:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
Of course, none of this matters anyway as you've admitted your work has nothing to do with the halting problem:
On 5/13/2025 9:54 PM, dbush wrote:
> On 5/13/2025 9:48 PM, olcott wrote:
>> On 5/13/2025 8:31 PM, dbush wrote:
>>> On 5/13/2025 9:27 PM, olcott wrote:
>>>> On 5/13/2025 8:07 PM, dbush wrote:
>>>>> On 5/13/2025 5:30 PM, olcott wrote:
>>>>>> On 5/13/2025 6:43 AM, Richard Damon wrote:
>>>>>>> On 5/13/25 12:52 AM, olcott wrote:
>>>>>>>> *simulated D would never stop running unless aborted*
>>>>>>>> or they themselves could become non-terminating.
>>>>>>>
>>>>>>> But you aren't simulating the same PROGRAM D that the original
>>>>>>> was given.
>>>>>>>
>>>>>>
>>>>>> It is not supposed to be the same program.
>>>>>
>>>>> So you *explicitly* admit to changing the input.
>>>>>
>>>>
>>>> The finite string of DD is specific sequence bytes.
>>>
>>> Which includes the specific sequence of bytes that is the finite
>>> string HHH
>>>
>>
>> No it does not. A function calls is not macro inclusion.
>>
>
> Then you admit that your HHH not deciding about algorithms and therefore
> has nothing to do with the halting problem.
Formal systems that cannot possibly be incomplete except for unknowns and unknowable
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable
