Re: Bad faith and dishonesty

On 5/25/2025 3:40 PM, olcott wrote:

On 5/25/2025 2:39 PM, dbush wrote:

On 5/25/2025 3:04 PM, olcott wrote:

On 5/25/2025 1:48 PM, dbush wrote:

On 5/25/2025 2:39 PM, olcott wrote:

On 5/25/2025 11:59 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 5/25/2025 10:49 AM, Fred. Zwarts wrote:

Op 25.mei.2025 om 16:36 schreef olcott:

On 5/25/2025 1:21 AM, Mikko wrote:

On 2025-05-24 01:20:18 +0000, Mr Flibble said:

>

So much bad faith and dishonesty shown in this forum that myself and
Peter
Olcott have to fight against.

>

Everything here seems to be dishonesty and protests against dishonesty.
If you could remove all dishonesty the protests woud stop, too, and
nothing would be left.

>
>

_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

>

Then acknowledge that DDD simulated by HHH according
to the rules of the x86 language cannot possibly reach
its own "ret" instruction final halt state.

Why repeating this bug in HHH?

>

That everyone that understands these things
sees that there is no bug ....

>
That is untrue.  The bug is clear to anybody who understands C code.
>

>
OK then to prove that you are not a damned liar
(you won't do this because you know that you are a liar)
show how DDD simulated by HHH according to the rules
of the x86 language

>
Which doesn't happen as you have admitted on the record:
>

>
You Are the epitome of bad faith and dishonesty.

>
That I call you out on your lies and back it up with evidence is anything but.

 You must be an atheist or you would fear telling these lies.
 

It is a verified fact that you have admitted the following on the record:
- That HHH does not correctly simulate DDD
- That the simulation of DDD by HHH and HHH1 are identical up the the point that HHH aborts
- That your doesn't operate on algorithms and therefore has nothing to do with the halting problem
- That the theorem that the halting problem proofs prove is correct
And below is a copy of the record where you have made these admissions:
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
 >
On 5/6/2025 5:17 PM, dbush wrote:
 > On 5/6/2025 5:03 PM, olcott wrote:
 >> On 5/6/2025 3:51 PM, dbush wrote:
 >>> On 5/6/2025 4:46 PM, olcott wrote:
 >>>> On 5/6/2025 3:31 PM, dbush wrote:
 >>>>> Then what is the first instruction emulated by HHH that differs
 >>>>> from the emulation performed by UTM?
 >>>>>
 >>>>
 >>>> HHH1 is exactly the same as HHH except that DD
 >>>> does not call HHH1. This IS the UTM emulator.
 >>>> It does not abort.
 >>>
 >>> Last chance:
 >>>
 >>> What is the first instruction emulated by HHH that differs from the
 >>> emulation performed by HHH1?
 >>
 >> Go back and read the part you ignored moron.
 >
 > Let the record show that Peter Olcott has neglected to identify an
 > instruction that HHH emulates differently from HHH1.
 >
 >>> Failure to provide this in your next message or within one hour of
 >>> your next post in this newsgroup will be taken as your official on-
 >>> the-record admission that the emulations performed by HHH and HHH1
 >>> are in fact exactly the same up until the point that HHH aborts, at
 >>> which point HHH did not correctly simulate the last instruction it
 >>> simulated as you are previously on record as admitting.
 >
 > Therefore, as per the above requirements:
 >
 > LET THE RECORD SHOW
 >
 > That Peter Olcott
 >
 > Has *officially* admitted
 >
 > That the emulations performed by HHH and HHH1 are in fact exactly the
 > same up until the point that HHH aborts, at which point HHH did not
 > correctly simulate the last instruction it simulated as he is previously
 > on record as admitting.
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.
On 3/24/2025 10:07 PM, olcott wrote:
 > A halt decider cannot exist
On 4/28/2025 2:47 PM, olcott wrote:
 > On 4/28/2025 11:54 AM, dbush wrote:
 >> And the halting function below is not a computable function:
 >>
 >
 > It is NEVER a computable function
 >
 >> 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
On 3/14/2025 1:19 PM, olcott wrote:
 > When we define the HP as having H return a value
 > corresponding to the halting behavior of input D
 > and input D can actually does the opposite of whatever
 > value that H returns, then we have boxed ourselves
 > in to a problem having no solution.
On 6/21/2024 1:22 PM, olcott wrote:
 > the logical impossibility of specifying a halt decider H
 > that correctly reports the halt status of input D that is
 > defined to do the opposite of whatever value that H reports.
 > Of course this is impossible.
On 7/4/2023 12:57 AM, olcott wrote:
 > If you frame the problem in that a halt decider must divide up finite
 > strings pairs into those that halt when directly executed and those that
 > do not, then no single program can do this.
On 5/5/2025 5:39 PM, olcott wrote:
 > On 5/5/2025 4:31 PM, dbush wrote:
 >> Strawman.  The square root of a dead rabbit does not exist, but the
 >> question of whether any arbitrary algorithm X with input Y halts when
 >> executed directly has a correct answer in all cases.
 >>
 >
 > It has a correct answer that cannot ever be computed
On 5/13/2025 5:16 PM, olcott wrote:
 > There is no time that we are ever going to directly
 > encode omniscience into a computer program. The
 > screwy idea of a universal halt decider that is
 > literally ALL KNOWING is just a screwy idea.