Sorry, guy, but comp.lang.c is not the place to discuss this
sort of thing. Why don't you try comp.theory ?

(Followups set to comp.theory)

On Mon, 26 Sep 2022 04:31:32 -0700, Prometheus wrote:

> # REPRESENTING BINARY NUMBERS NATURALLY.
>
> What is the Problem?
> -------------------
> In Computer Science, we have various ways to represent numbers.
>
> However,we have to choose the best way to represent numbers.This is
> especially true in strongly typed high level abstract languages like
> C/C++/Java etc.Futhermore, computer sciencient developed a binary number
> system called two complement;it is used to perform arthematic on binary
> numbers which can be transferred to other systems.This include
> decimal(base 10), hexadecimal(base 16), octal(base 8) etc.Two complement
> enables us to represent negative numbers with a signifance of the right
> most bit being a 1.
>
> Is there a data structure and algorithm extension of two complement that
> handle overflow in such way that is indiscremnint of the type of
> data(binary number type) provided not occupy memory thier should not?
>
> For example,and 8 ,and 16 bit can be stored together under one
> class(blueprint for an object) and support the performing of operations
> that will not result any overflow. The importance of this data structure
> is that binary number should apper naturally looking and be more effient
> as if their were represented as regular numbers , not taking memory
> their should not occupy.

--
Lew Pitcher
"In Skills, We Trust"

On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> Sorry, guy, but comp.lang.c is not the place to discuss this
> sort of thing. Why don't you try comp.theory ?

Because Olcott postings will push you out of visibility?

On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> Sorry, guy, but comp.lang.c is not the place to discuss this
>> sort of thing. Why don't you try comp.theory ?
>
> Because Olcott postings will push you out of visibility?

If people would give me a fair and honest review I could quit posting.
You gave up on me before I could point out the error with the
diagonalization argument that you relied on for your rebuttal:

The diagonalization argument merely proves that no value returned to P
from its call to H can possibly be correct. This argument totally
ignores that the return value from H is unreachable by its simulated P
caller when H is based on a simulating halt decider. This makes it
impossible for P to do the opposite of whatever H decides.

Complete halt deciding system (Visual Studio Project)
(a) x86utm operating system
(b) complete x86 emulator
(c) Several halt deciders and their inputs contained within Halt7.c
https://liarparadox.org/2022_09_07.zip

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Mon, 26 Sep 2022 12:15:15 -0500
olcott <none-ya@beez-waxes.com> wrote:

> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> > On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> >> Sorry, guy, but comp.lang.c is not the place to discuss this
> >> sort of thing. Why don't you try comp.theory ?
> >
> > Because Olcott postings will push you out of visibility?
>
> If people would give me a fair and honest review I could quit posting.
> You gave up on me before I could point out the error with the
> diagonalization argument that you relied on for your rebuttal:
>
> The diagonalization argument merely proves that no value returned to
> P from its call to H can possibly be correct. This argument totally
> ignores that the return value from H is unreachable by its simulated
> P caller when H is based on a simulating halt decider. This makes it
> impossible for P to do the opposite of whatever H decides.
>
> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip

You keep making the same mistake again and again. H IS NOT SUPPOSED TO
BE RECURSIVE. A SIMULATING HALT DECIDER DOES NOT HAVE TO BE RECURSIVE
(SEE THE FLIBBLE DECIDER). A VALID HALT DECIDER MUST RETURN A DECISION
TO ITS INVOKER (P) IN FINITE TIME. YOUR DECIDER IS NOT A VALID HALT
DECIDER.

/Flibble

On 9/26/2022 12:19 PM, Mr Flibble wrote:
> On Mon, 26 Sep 2022 12:15:15 -0500
> olcott <none-ya@beez-waxes.com> wrote:
>
>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>> sort of thing. Why don't you try comp.theory ?
>>>
>>> Because Olcott postings will push you out of visibility?
>>
>> If people would give me a fair and honest review I could quit posting.
>> You gave up on me before I could point out the error with the
>> diagonalization argument that you relied on for your rebuttal:
>>
>> The diagonalization argument merely proves that no value returned to
>> P from its call to H can possibly be correct. This argument totally
>> ignores that the return value from H is unreachable by its simulated
>> P caller when H is based on a simulating halt decider. This makes it
>> impossible for P to do the opposite of whatever H decides.
>>
>> Complete halt deciding system (Visual Studio Project)
>> (a) x86utm operating system
>> (b) complete x86 emulator
>> (c) Several halt deciders and their inputs contained within Halt7.c
>> https://liarparadox.org/2022_09_07.zip
>
> You keep making the same mistake again and again. H IS NOT SUPPOSED TO
> BE RECURSIVE.

H(P,P) is not recursive.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Mon, 26 Sep 2022 12:42:02 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/26/2022 12:19 PM, Mr Flibble wrote:
> > On Mon, 26 Sep 2022 12:15:15 -0500
> > olcott <none-ya@beez-waxes.com> wrote:
> >
> >> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> >>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
> >>> wrote:
> >>>> Sorry, guy, but comp.lang.c is not the place to discuss this
> >>>> sort of thing. Why don't you try comp.theory ?
> >>>
> >>> Because Olcott postings will push you out of visibility?
> >>
> >> If people would give me a fair and honest review I could quit
> >> posting. You gave up on me before I could point out the error with
> >> the diagonalization argument that you relied on for your rebuttal:
> >>
> >> The diagonalization argument merely proves that no value returned
> >> to P from its call to H can possibly be correct. This argument
> >> totally ignores that the return value from H is unreachable by its
> >> simulated P caller when H is based on a simulating halt decider.
> >> This makes it impossible for P to do the opposite of whatever H
> >> decides.
> >>
> >> Complete halt deciding system (Visual Studio Project)
> >> (a) x86utm operating system
> >> (b) complete x86 emulator
> >> (c) Several halt deciders and their inputs contained within Halt7.c
> >> https://liarparadox.org/2022_09_07.zip
> >
> > You keep making the same mistake again and again. H IS NOT SUPPOSED
> > TO BE RECURSIVE.
>
> H(P,P) is not recursive.

Your H is recursive because P isn't recursive and yet you have to abort
your infinite recursion: the recursion is caused by your H and not by
P. Nowhere in any halting problem proof does it state that the call to
H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE P, H
IS SUPPOSED TO *ANALYSE* P.

/Flibble

On 9/26/2022 12:48 PM, Mr Flibble wrote:
> On Mon, 26 Sep 2022 12:42:02 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>> olcott <none-ya@beez-waxes.com> wrote:
>>>
>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>> wrote:
>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>
>>>>> Because Olcott postings will push you out of visibility?
>>>>
>>>> If people would give me a fair and honest review I could quit
>>>> posting. You gave up on me before I could point out the error with
>>>> the diagonalization argument that you relied on for your rebuttal:
>>>>
>>>> The diagonalization argument merely proves that no value returned
>>>> to P from its call to H can possibly be correct. This argument
>>>> totally ignores that the return value from H is unreachable by its
>>>> simulated P caller when H is based on a simulating halt decider.
>>>> This makes it impossible for P to do the opposite of whatever H
>>>> decides.
>>>>
>>>> Complete halt deciding system (Visual Studio Project)
>>>> (a) x86utm operating system
>>>> (b) complete x86 emulator
>>>> (c) Several halt deciders and their inputs contained within Halt7.c
>>>> https://liarparadox.org/2022_09_07.zip
>>>
>>> You keep making the same mistake again and again. H IS NOT SUPPOSED
>>> TO BE RECURSIVE.
>>
>> H(P,P) is not recursive.
>
> Your H is recursive because P isn't recursive and yet you have to abort
> your infinite recursion: the recursion is caused by your H and not by
> P. Nowhere in any halting problem proof does it state that the call to
> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE P, H
> IS SUPPOSED TO *ANALYSE* P.
>
> /Flibble

Nowhere in any HP proof (besides mine) is the idea of a simulating halt
decider (SHD) ever thought all the way through.

Because the definition of a UTM specifies that the correct simulation of
a machine description provides the actual behavior of the underlying
machine whenever any simulating halt decider must abort its simulation
to prevent infinite simulation it is necessarily correct to report that
this input does not halt.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Mon, 26 Sep 2022 13:03:36 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/26/2022 12:48 PM, Mr Flibble wrote:
> > On Mon, 26 Sep 2022 12:42:02 -0500
> > olcott <polcott2@gmail.com> wrote:
> >
> >> On 9/26/2022 12:19 PM, Mr Flibble wrote:
> >>> On Mon, 26 Sep 2022 12:15:15 -0500
> >>> olcott <none-ya@beez-waxes.com> wrote:
> >>>
> >>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> >>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
> >>>>> wrote:
> >>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
> >>>>>> sort of thing. Why don't you try comp.theory ?
> >>>>>
> >>>>> Because Olcott postings will push you out of visibility?
> >>>>
> >>>> If people would give me a fair and honest review I could quit
> >>>> posting. You gave up on me before I could point out the error
> >>>> with the diagonalization argument that you relied on for your
> >>>> rebuttal:
> >>>>
> >>>> The diagonalization argument merely proves that no value returned
> >>>> to P from its call to H can possibly be correct. This argument
> >>>> totally ignores that the return value from H is unreachable by
> >>>> its simulated P caller when H is based on a simulating halt
> >>>> decider. This makes it impossible for P to do the opposite of
> >>>> whatever H decides.
> >>>>
> >>>> Complete halt deciding system (Visual Studio Project)
> >>>> (a) x86utm operating system
> >>>> (b) complete x86 emulator
> >>>> (c) Several halt deciders and their inputs contained within
> >>>> Halt7.c https://liarparadox.org/2022_09_07.zip
> >>>
> >>> You keep making the same mistake again and again. H IS NOT
> >>> SUPPOSED TO BE RECURSIVE.
> >>
> >> H(P,P) is not recursive.
> >
> > Your H is recursive because P isn't recursive and yet you have to
> > abort your infinite recursion: the recursion is caused by your H
> > and not by P. Nowhere in any halting problem proof does it state
> > that the call to H by P is recursive in nature BECAUSE H IS NOT
> > SUPPOSED TO EXECUTE P, H IS SUPPOSED TO *ANALYSE* P.
> >
> > /Flibble
>
> Nowhere in any HP proof (besides mine) is the idea of a simulating
> halt decider (SHD) ever thought all the way through.
>
> Because the definition of a UTM specifies that the correct simulation
> of a machine description provides the actual behavior of the
> underlying machine whenever any simulating halt decider must abort
> its simulation to prevent infinite simulation it is necessarily
> correct to report that this input does not halt.

Nope: you are incorrect to map a call to H within an ongoing simulation
to recursive simulation because that fundamentally changes the
definition, nature and behavior of P.

/Flibble

On 9/26/2022 1:31 PM, Mr Flibble wrote:
> On Mon, 26 Sep 2022 13:03:36 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>
>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>
>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>> wrote:
>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>
>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>
>>>>>> If people would give me a fair and honest review I could quit
>>>>>> posting. You gave up on me before I could point out the error
>>>>>> with the diagonalization argument that you relied on for your
>>>>>> rebuttal:
>>>>>>
>>>>>> The diagonalization argument merely proves that no value returned
>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>> totally ignores that the return value from H is unreachable by
>>>>>> its simulated P caller when H is based on a simulating halt
>>>>>> decider. This makes it impossible for P to do the opposite of
>>>>>> whatever H decides.
>>>>>>
>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>> (a) x86utm operating system
>>>>>> (b) complete x86 emulator
>>>>>> (c) Several halt deciders and their inputs contained within
>>>>>> Halt7.c https://liarparadox.org/2022_09_07.zip
>>>>>
>>>>> You keep making the same mistake again and again. H IS NOT
>>>>> SUPPOSED TO BE RECURSIVE.
>>>>
>>>> H(P,P) is not recursive.
>>>
>>> Your H is recursive because P isn't recursive and yet you have to
>>> abort your infinite recursion: the recursion is caused by your H
>>> and not by P. Nowhere in any halting problem proof does it state
>>> that the call to H by P is recursive in nature BECAUSE H IS NOT
>>> SUPPOSED TO EXECUTE P, H IS SUPPOSED TO *ANALYSE* P.
>>>
>>> /Flibble
>>
>> Nowhere in any HP proof (besides mine) is the idea of a simulating
>> halt decider (SHD) ever thought all the way through.
>>
>> Because the definition of a UTM specifies that the correct simulation
>> of a machine description provides the actual behavior of the
>> underlying machine whenever any simulating halt decider must abort
>> its simulation to prevent infinite simulation it is necessarily
>> correct to report that this input does not halt.
>
> Nope: you are incorrect to map a call to H within an ongoing simulation
> to recursive simulation because that fundamentally changes the
> definition, nature and behavior of P.
>
> /Flibble
>

You are insufficiently technically competent to understand these things.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Mon, 26 Sep 2022 14:25:30 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/26/2022 1:31 PM, Mr Flibble wrote:
> > On Mon, 26 Sep 2022 13:03:36 -0500
> > olcott <polcott2@gmail.com> wrote:
> >
> >> On 9/26/2022 12:48 PM, Mr Flibble wrote:
> >>> On Mon, 26 Sep 2022 12:42:02 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>
> >>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
> >>>>> On Mon, 26 Sep 2022 12:15:15 -0500
> >>>>> olcott <none-ya@beez-waxes.com> wrote:
> >>>>>
> >>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> >>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
> >>>>>>> wrote:
> >>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
> >>>>>>>> sort of thing. Why don't you try comp.theory ?
> >>>>>>>
> >>>>>>> Because Olcott postings will push you out of visibility?
> >>>>>>
> >>>>>> If people would give me a fair and honest review I could quit
> >>>>>> posting. You gave up on me before I could point out the error
> >>>>>> with the diagonalization argument that you relied on for your
> >>>>>> rebuttal:
> >>>>>>
> >>>>>> The diagonalization argument merely proves that no value
> >>>>>> returned to P from its call to H can possibly be correct. This
> >>>>>> argument totally ignores that the return value from H is
> >>>>>> unreachable by its simulated P caller when H is based on a
> >>>>>> simulating halt decider. This makes it impossible for P to do
> >>>>>> the opposite of whatever H decides.
> >>>>>>
> >>>>>> Complete halt deciding system (Visual Studio Project)
> >>>>>> (a) x86utm operating system
> >>>>>> (b) complete x86 emulator
> >>>>>> (c) Several halt deciders and their inputs contained within
> >>>>>> Halt7.c https://liarparadox.org/2022_09_07.zip
> >>>>>
> >>>>> You keep making the same mistake again and again. H IS NOT
> >>>>> SUPPOSED TO BE RECURSIVE.
> >>>>
> >>>> H(P,P) is not recursive.
> >>>
> >>> Your H is recursive because P isn't recursive and yet you have to
> >>> abort your infinite recursion: the recursion is caused by your H
> >>> and not by P. Nowhere in any halting problem proof does it state
> >>> that the call to H by P is recursive in nature BECAUSE H IS NOT
> >>> SUPPOSED TO EXECUTE P, H IS SUPPOSED TO *ANALYSE* P.
> >>>
> >>> /Flibble
> >>
> >> Nowhere in any HP proof (besides mine) is the idea of a simulating
> >> halt decider (SHD) ever thought all the way through.
> >>
> >> Because the definition of a UTM specifies that the correct
> >> simulation of a machine description provides the actual behavior
> >> of the underlying machine whenever any simulating halt decider
> >> must abort its simulation to prevent infinite simulation it is
> >> necessarily correct to report that this input does not halt.
> >
> > Nope: you are incorrect to map a call to H within an ongoing
> > simulation to recursive simulation because that fundamentally
> > changes the definition, nature and behavior of P.
> >
> > /Flibble
> >
>
> You are insufficiently technically competent to understand these
> things.

Classic case of psychological projection: you indeed are insufficiently
technically competent to understand these things as evidenced by your
inability to address what people actually say.

/Flibble

On Monday, September 26, 2022 at 6:15:31 PM UTC+1, olcott wrote:
> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> > On 2022-09-26, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
> >> Sorry, guy, but comp.lang.c is not the place to discuss this
> >> sort of thing. Why don't you try comp.theory ?
> >
> > Because Olcott postings will push you out of visibility?
> If people would give me a fair and honest review I could quit posting.
> You gave up on me before I could point out the error with the
> diagonalization argument that you relied on for your rebuttal:
>
> The diagonalization argument merely proves that no value returned to P
> from its call to H can possibly be correct.

And thus proves that H cannot be a halt decider.

> This argument totally
> ignores that the return value from H is unreachable by its simulated P
> caller when H is based on a simulating halt decider.

H is supposed to tell us what P does when run. It's nothing to do with about how anything simulates P.

> This makes it
> impossible for P to do the opposite of whatever H decides.

Rubbish. There's nothing about P that says it has to match a flawed simulation of itself.

> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip

> Copyright 2022 Pete Olcott

You keep saying that, but your recent posts have shown you don't understand copyright properly either.

On 9/26/2022 4:26 PM, Paul N wrote:
> On Monday, September 26, 2022 at 6:15:31 PM UTC+1, olcott wrote:
>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>> On 2022-09-26, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>> sort of thing. Why don't you try comp.theory ?
>>>
>>> Because Olcott postings will push you out of visibility?
>> If people would give me a fair and honest review I could quit posting.
>> You gave up on me before I could point out the error with the
>> diagonalization argument that you relied on for your rebuttal:
>>
>> The diagonalization argument merely proves that no value returned to P
>> from its call to H can possibly be correct.
>
> And thus proves that H cannot be a halt decider.
>
>> This argument totally
>> ignores that the return value from H is unreachable by its simulated P
>> caller when H is based on a simulating halt decider.
>
> H is supposed to tell us what P does when run. It's nothing to do with about how anything simulates P.
>
>> This makes it
>> impossible for P to do the opposite of whatever H decides.
>
> Rubbish. There's nothing about P that says it has to match a flawed simulation of itself.
>

People have given up that claim that the simulation is flawed long ago
because they have found no flaw and have verified for themselves that
the simulation is correct.

My code speaks for itself:

>> Complete halt deciding system (Visual Studio Project)
>> (a) x86utm operating system
>> (b) complete x86 emulator
>> (c) Several halt deciders and their inputs contained within Halt7.c
>> https://liarparadox.org/2022_09_07.zip
>
>> Copyright 2022 Pete Olcott
>
> You keep saying that, but your recent posts have shown you don't understand copyright properly either.

When Flibble copied by code verbatim he violated my copyright.

I know the difference between patent protection and copyright protection
because I wrote two patents that have issued in my name. I figured that
the nuances of difference would be too complex for Flibble so over
simplified it.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Mon, 26 Sep 2022 16:59:39 -0500
olcott <none-ya@beez-waxes.com> wrote:

> On 9/26/2022 4:26 PM, Paul N wrote:
> > On Monday, September 26, 2022 at 6:15:31 PM UTC+1, olcott wrote:
> >> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
> >>> On 2022-09-26, Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
> >>>> Sorry, guy, but comp.lang.c is not the place to discuss this
> >>>> sort of thing. Why don't you try comp.theory ?
> >>>
> >>> Because Olcott postings will push you out of visibility?
> >> If people would give me a fair and honest review I could quit
> >> posting. You gave up on me before I could point out the error with
> >> the diagonalization argument that you relied on for your rebuttal:
> >>
> >> The diagonalization argument merely proves that no value returned
> >> to P from its call to H can possibly be correct.
> >
> > And thus proves that H cannot be a halt decider.
> >
> >> This argument totally
> >> ignores that the return value from H is unreachable by its
> >> simulated P caller when H is based on a simulating halt decider.
> >
> > H is supposed to tell us what P does when run. It's nothing to do
> > with about how anything simulates P.
> >> This makes it
> >> impossible for P to do the opposite of whatever H decides.
> >
> > Rubbish. There's nothing about P that says it has to match a flawed
> > simulation of itself.
>
> People have given up that claim that the simulation is flawed long
> ago because they have found no flaw and have verified for themselves
> that the simulation is correct.
>
> My code speaks for itself:
>
> >> Complete halt deciding system (Visual Studio Project)
> >> (a) x86utm operating system
> >> (b) complete x86 emulator
> >> (c) Several halt deciders and their inputs contained within Halt7.c
> >> https://liarparadox.org/2022_09_07.zip
> >
> >> Copyright 2022 Pete Olcott
> >
> > You keep saying that, but your recent posts have shown you don't
> > understand copyright properly either.
>
> When Flibble copied by code verbatim he violated my copyright.

I didn't copy your code, verbatim or otherwise, so I didn't violate any
copyright. Also, you cannot copyright an idea even if your idea is
flawed.
> I know the difference between patent protection and copyright
> protection because I wrote two patents that have issued in my name. I
> figured that the nuances of difference would be too complex for
> Flibble so over simplified it.
>
>

/Flibble

On 9/26/22 2:03 PM, olcott wrote:
> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>> On Mon, 26 Sep 2022 12:42:02 -0500
>> olcott <polcott2@gmail.com> wrote:
>>
>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>> wrote:
>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>
>>>>>> Because Olcott postings will push you out of visibility?
>>>>>
>>>>> If people would give me a fair and honest review I could quit
>>>>> posting. You gave up on me before I could point out the error with
>>>>> the diagonalization argument that you relied on for your rebuttal:
>>>>>
>>>>> The diagonalization argument merely proves that no value returned
>>>>> to P from its call to H can possibly be correct. This argument
>>>>> totally ignores that the return value from H is unreachable by its
>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>> decides.
>>>>>
>>>>> Complete halt deciding system (Visual Studio Project)
>>>>> (a) x86utm operating system
>>>>> (b) complete x86 emulator
>>>>> (c) Several halt deciders and their inputs contained within Halt7.c
>>>>> https://liarparadox.org/2022_09_07.zip
>>>>
>>>> You keep making the same mistake again and again. H IS NOT SUPPOSED
>>>> TO BE RECURSIVE.
>>>
>>> H(P,P) is not recursive.
>>
>> Your H is recursive because P isn't recursive and yet you have to abort
>> your infinite recursion: the recursion is caused by your H and not by
>> P.  Nowhere in any halting problem proof does it state that the call to
>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE P, H
>> IS SUPPOSED TO *ANALYSE* P.
>>
>> /Flibble
>
> Nowhere in any HP proof (besides mine) is the idea of a simulating halt
> decider (SHD) ever thought all the way through.

Because the proof doesn't care at all how the decider got the answer,

>
> Because the definition of a UTM specifies that the correct simulation of
> a machine description provides the actual behavior of the underlying
> machine whenever any simulating halt decider must abort its simulation
> to prevent infinite simulation it is necessarily correct to report that
> this input does not halt.
>
>

Right, which means it CAN'T be a UTM, and thus *ITS* simulation does not
define the "behavior of the input".

The Halting Problem is about the behavior of a specified machine.

That Machine will Halt if the decider says it won't, so that decider
will be wrong. It doesn't matter that the decider can't determine that .

On 9/26/2022 6:12 PM, Richard Damon wrote:
>
> On 9/26/22 2:03 PM, olcott wrote:
>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>
>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>> wrote:
>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>
>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>
>>>>>> If people would give me a fair and honest review I could quit
>>>>>> posting. You gave up on me before I could point out the error with
>>>>>> the diagonalization argument that you relied on for your rebuttal:
>>>>>>
>>>>>> The diagonalization argument merely proves that no value returned
>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>> totally ignores that the return value from H is unreachable by its
>>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>> decides.
>>>>>>
>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>> (a) x86utm operating system
>>>>>> (b) complete x86 emulator
>>>>>> (c) Several halt deciders and their inputs contained within Halt7.c
>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>
>>>>> You keep making the same mistake again and again. H IS NOT SUPPOSED
>>>>> TO BE RECURSIVE.
>>>>
>>>> H(P,P) is not recursive.
>>>
>>> Your H is recursive because P isn't recursive and yet you have to abort
>>> your infinite recursion: the recursion is caused by your H and not by
>>> P.  Nowhere in any halting problem proof does it state that the call to
>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE P, H
>>> IS SUPPOSED TO *ANALYSE* P.
>>>
>>> /Flibble
>>
>> Nowhere in any HP proof (besides mine) is the idea of a simulating
>> halt decider (SHD) ever thought all the way through.
>
> Because the proof doesn't care at all how the decider got the answer,
>
>>
>> Because the definition of a UTM specifies that the correct simulation
>> of a machine description provides the actual behavior of the
>> underlying machine whenever any simulating halt decider must abort its
>> simulation to prevent infinite simulation it is necessarily correct to
>> report that this input does not halt.
>>
>>
>
> Right, which means it CAN'T be a UTM, and thus *ITS* simulation does not
> define the "behavior of the input".
>

The behavior of the correct simulation of the input is its actual
behavior. That H correctly predicts that its correct simulation never
stops running unless aborted conclusively proves that this correctly
simulated input would never reach its own final state in 1 to ∞ steps of
correct simulation.

> The Halting Problem is about the behavior of a specified machine.
>
> That Machine will Halt if the decider says it won't, so that decider
> will be wrong. It doesn't matter that the decider can't determine that .

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/26/22 7:46 PM, olcott wrote:
> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>
>> On 9/26/22 2:03 PM, olcott wrote:
>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>> olcott <polcott2@gmail.com> wrote:
>>>>
>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>> wrote:
>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>
>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>
>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>> posting. You gave up on me before I could point out the error with
>>>>>>> the diagonalization argument that you relied on for your rebuttal:
>>>>>>>
>>>>>>> The diagonalization argument merely proves that no value returned
>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>> totally ignores that the return value from H is unreachable by its
>>>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>>> decides.
>>>>>>>
>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>> (a) x86utm operating system
>>>>>>> (b) complete x86 emulator
>>>>>>> (c) Several halt deciders and their inputs contained within Halt7.c
>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>
>>>>>> You keep making the same mistake again and again. H IS NOT SUPPOSED
>>>>>> TO BE RECURSIVE.
>>>>>
>>>>> H(P,P) is not recursive.
>>>>
>>>> Your H is recursive because P isn't recursive and yet you have to abort
>>>> your infinite recursion: the recursion is caused by your H and not by
>>>> P.  Nowhere in any halting problem proof does it state that the call to
>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE P, H
>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>
>>>> /Flibble
>>>
>>> Nowhere in any HP proof (besides mine) is the idea of a simulating
>>> halt decider (SHD) ever thought all the way through.
>>
>> Because the proof doesn't care at all how the decider got the answer,
>>
>>>
>>> Because the definition of a UTM specifies that the correct simulation
>>> of a machine description provides the actual behavior of the
>>> underlying machine whenever any simulating halt decider must abort
>>> its simulation to prevent infinite simulation it is necessarily
>>> correct to report that this input does not halt.
>>>
>>>
>>
>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation does
>> not define the "behavior of the input".
>>
>
> The behavior of the correct simulation of the input is its actual
> behavior. That H correctly predicts that its correct simulation never
> stops running unless aborted conclusively proves that this correctly
> simulated input would never reach its own final state in 1 to ∞ steps of
> correct simulation.

But the behavior the halting problem is asking for is the behavior of
the actual machine.

All you are doing is admitting your H isn't a Halt Decider because it is
looking at a different question.

Note, The behavior of the actual machine IS the behavior of a correct
and complete simulation of that input if H is a Halt Decider (By
DEFINITION), so H disagreeing with that just proves that H doesn't
correctly produce that behavior.

The biggest part of the problem is H doesn't do a COMPLETE simulation,
and looks at the behavior of another machine simulating a DIFFERENT
input than the one that H was given, thus it gets the wrong answer.

>
>> The Halting Problem is about the behavior of a specified machine.
>>
>> That Machine will Halt if the decider says it won't, so that decider
>> will be wrong. It doesn't matter that the decider can't determine that .
>

On 9/26/2022 6:59 PM, Richard Damon wrote:
> On 9/26/22 7:46 PM, olcott wrote:
>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>
>>> On 9/26/22 2:03 PM, olcott wrote:
>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>
>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>> wrote:
>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>
>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>
>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>> posting. You gave up on me before I could point out the error with
>>>>>>>> the diagonalization argument that you relied on for your rebuttal:
>>>>>>>>
>>>>>>>> The diagonalization argument merely proves that no value returned
>>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>>> totally ignores that the return value from H is unreachable by its
>>>>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>>>> decides.
>>>>>>>>
>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>> (a) x86utm operating system
>>>>>>>> (b) complete x86 emulator
>>>>>>>> (c) Several halt deciders and their inputs contained within Halt7.c
>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>
>>>>>>> You keep making the same mistake again and again. H IS NOT SUPPOSED
>>>>>>> TO BE RECURSIVE.
>>>>>>
>>>>>> H(P,P) is not recursive.
>>>>>
>>>>> Your H is recursive because P isn't recursive and yet you have to
>>>>> abort
>>>>> your infinite recursion: the recursion is caused by your H and not by
>>>>> P.  Nowhere in any halting problem proof does it state that the
>>>>> call to
>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE
>>>>> P, H
>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>
>>>>> /Flibble
>>>>
>>>> Nowhere in any HP proof (besides mine) is the idea of a simulating
>>>> halt decider (SHD) ever thought all the way through.
>>>
>>> Because the proof doesn't care at all how the decider got the answer,
>>>
>>>>
>>>> Because the definition of a UTM specifies that the correct
>>>> simulation of a machine description provides the actual behavior of
>>>> the underlying machine whenever any simulating halt decider must
>>>> abort its simulation to prevent infinite simulation it is
>>>> necessarily correct to report that this input does not halt.
>>>>
>>>>
>>>
>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation does
>>> not define the "behavior of the input".
>>>
>>
>> The behavior of the correct simulation of the input is its actual
>> behavior. That H correctly predicts that its correct simulation never
>> stops running unless aborted conclusively proves that this correctly
>> simulated input would never reach its own final state in 1 to ∞ steps
>> of correct simulation.
>
> But the behavior the halting problem is asking for is the behavior of
> the actual machine.
>

Only within the context that no one ever bothered to think the
application of a simulating halt decider all the way through.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 9/26/22 8:25 PM, olcott wrote:
> On 9/26/2022 6:59 PM, Richard Damon wrote:
>> On 9/26/22 7:46 PM, olcott wrote:
>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>
>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>
>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>> wrote:
>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>
>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>
>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>> posting. You gave up on me before I could point out the error with
>>>>>>>>> the diagonalization argument that you relied on for your rebuttal:
>>>>>>>>>
>>>>>>>>> The diagonalization argument merely proves that no value returned
>>>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>>>> totally ignores that the return value from H is unreachable by its
>>>>>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>>>>> decides.
>>>>>>>>>
>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>> (a) x86utm operating system
>>>>>>>>> (b) complete x86 emulator
>>>>>>>>> (c) Several halt deciders and their inputs contained within
>>>>>>>>> Halt7.c
>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>
>>>>>>>> You keep making the same mistake again and again. H IS NOT SUPPOSED
>>>>>>>> TO BE RECURSIVE.
>>>>>>>
>>>>>>> H(P,P) is not recursive.
>>>>>>
>>>>>> Your H is recursive because P isn't recursive and yet you have to
>>>>>> abort
>>>>>> your infinite recursion: the recursion is caused by your H and not by
>>>>>> P.  Nowhere in any halting problem proof does it state that the
>>>>>> call to
>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO EXECUTE
>>>>>> P, H
>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Nowhere in any HP proof (besides mine) is the idea of a simulating
>>>>> halt decider (SHD) ever thought all the way through.
>>>>
>>>> Because the proof doesn't care at all how the decider got the answer,
>>>>
>>>>>
>>>>> Because the definition of a UTM specifies that the correct
>>>>> simulation of a machine description provides the actual behavior of
>>>>> the underlying machine whenever any simulating halt decider must
>>>>> abort its simulation to prevent infinite simulation it is
>>>>> necessarily correct to report that this input does not halt.
>>>>>
>>>>>
>>>>
>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation does
>>>> not define the "behavior of the input".
>>>>
>>>
>>> The behavior of the correct simulation of the input is its actual
>>> behavior. That H correctly predicts that its correct simulation never
>>> stops running unless aborted conclusively proves that this correctly
>>> simulated input would never reach its own final state in 1 to ∞ steps
>>> of correct simulation.
>>
>> But the behavior the halting problem is asking for is the behavior of
>> the actual machine.
>>
>
> Only within the context that no one ever bothered to think the
> application of a simulating halt decider all the way through.
>

No, the DEFINITION of a Halt Decider is to decide on the behavior of the
Actual Machine.

You definition of a Simulationg Halt Decider just means they are not
actually Halt Deciders because they are deciding on the WRONG criteria.

Your failure to understand that means you WASTED the last 18 years of
your life.

Remember, you don't get to "redefine" a problem and still claim to be
acutally working on the original problem.

You just seem to be too stupid to understand that basic fact.

On 9/26/2022 7:36 PM, Richard Damon wrote:
> On 9/26/22 8:25 PM, olcott wrote:
>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>> On 9/26/22 7:46 PM, olcott wrote:
>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>
>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>
>>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>>> posting. You gave up on me before I could point out the error
>>>>>>>>>> with
>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>> rebuttal:
>>>>>>>>>>
>>>>>>>>>> The diagonalization argument merely proves that no value returned
>>>>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>>>>> totally ignores that the return value from H is unreachable by
>>>>>>>>>> its
>>>>>>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>>>>>> decides.
>>>>>>>>>>
>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>> (c) Several halt deciders and their inputs contained within
>>>>>>>>>> Halt7.c
>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>
>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>> SUPPOSED
>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>
>>>>>>>> H(P,P) is not recursive.
>>>>>>>
>>>>>>> Your H is recursive because P isn't recursive and yet you have to
>>>>>>> abort
>>>>>>> your infinite recursion: the recursion is caused by your H and
>>>>>>> not by
>>>>>>> P.  Nowhere in any halting problem proof does it state that the
>>>>>>> call to
>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>> EXECUTE P, H
>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> Nowhere in any HP proof (besides mine) is the idea of a simulating
>>>>>> halt decider (SHD) ever thought all the way through.
>>>>>
>>>>> Because the proof doesn't care at all how the decider got the answer,
>>>>>
>>>>>>
>>>>>> Because the definition of a UTM specifies that the correct
>>>>>> simulation of a machine description provides the actual behavior
>>>>>> of the underlying machine whenever any simulating halt decider
>>>>>> must abort its simulation to prevent infinite simulation it is
>>>>>> necessarily correct to report that this input does not halt.
>>>>>>
>>>>>>
>>>>>
>>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation
>>>>> does not define the "behavior of the input".
>>>>>
>>>>
>>>> The behavior of the correct simulation of the input is its actual
>>>> behavior. That H correctly predicts that its correct simulation
>>>> never stops running unless aborted conclusively proves that this
>>>> correctly simulated input would never reach its own final state in 1
>>>> to ∞ steps of correct simulation.
>>>
>>> But the behavior the halting problem is asking for is the behavior of
>>> the actual machine.
>>>
>>
>> Only within the context that no one ever bothered to think the
>> application of a simulating halt decider all the way through.
>>
>
> No, the DEFINITION of a Halt Decider is to decide on the behavior of the
> Actual Machine.
>
That definition is made obsolete by a simulating halt decider.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/26/22 8:58 PM, olcott wrote:
> On 9/26/2022 7:36 PM, Richard Damon wrote:
>> On 9/26/22 8:25 PM, olcott wrote:
>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>
>>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>>
>>>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>>>> posting. You gave up on me before I could point out the error
>>>>>>>>>>> with
>>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>>> rebuttal:
>>>>>>>>>>>
>>>>>>>>>>> The diagonalization argument merely proves that no value
>>>>>>>>>>> returned
>>>>>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>>>>>> totally ignores that the return value from H is unreachable
>>>>>>>>>>> by its
>>>>>>>>>>> simulated P caller when H is based on a simulating halt decider.
>>>>>>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>>>>>>> decides.
>>>>>>>>>>>
>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>> (c) Several halt deciders and their inputs contained within
>>>>>>>>>>> Halt7.c
>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>
>>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>>> SUPPOSED
>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>
>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>
>>>>>>>> Your H is recursive because P isn't recursive and yet you have
>>>>>>>> to abort
>>>>>>>> your infinite recursion: the recursion is caused by your H and
>>>>>>>> not by
>>>>>>>> P.  Nowhere in any halting problem proof does it state that the
>>>>>>>> call to
>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>>> EXECUTE P, H
>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Nowhere in any HP proof (besides mine) is the idea of a
>>>>>>> simulating halt decider (SHD) ever thought all the way through.
>>>>>>
>>>>>> Because the proof doesn't care at all how the decider got the answer,
>>>>>>
>>>>>>>
>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>> simulation of a machine description provides the actual behavior
>>>>>>> of the underlying machine whenever any simulating halt decider
>>>>>>> must abort its simulation to prevent infinite simulation it is
>>>>>>> necessarily correct to report that this input does not halt.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation
>>>>>> does not define the "behavior of the input".
>>>>>>
>>>>>
>>>>> The behavior of the correct simulation of the input is its actual
>>>>> behavior. That H correctly predicts that its correct simulation
>>>>> never stops running unless aborted conclusively proves that this
>>>>> correctly simulated input would never reach its own final state in
>>>>> 1 to ∞ steps of correct simulation.
>>>>
>>>> But the behavior the halting problem is asking for is the behavior
>>>> of the actual machine.
>>>>
>>>
>>> Only within the context that no one ever bothered to think the
>>> application of a simulating halt decider all the way through.
>>>
>>
>> No, the DEFINITION of a Halt Decider is to decide on the behavior of
>> the Actual Machine.
>>
> That definition is made obsolete by a simulating halt decider.
>
>

Nope, the definition IS the definition.

You don't get to change it.

YOU FAIL.

You are just showing you are too stupid to do logic.

On 9/26/2022 8:15 PM, Richard Damon wrote:
> On 9/26/22 8:58 PM, olcott wrote:
>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>> On 9/26/22 8:25 PM, olcott wrote:
>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>>>
>>>>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>>>>> posting. You gave up on me before I could point out the
>>>>>>>>>>>> error with
>>>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>>>> rebuttal:
>>>>>>>>>>>>
>>>>>>>>>>>> The diagonalization argument merely proves that no value
>>>>>>>>>>>> returned
>>>>>>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>>>>>>> totally ignores that the return value from H is unreachable
>>>>>>>>>>>> by its
>>>>>>>>>>>> simulated P caller when H is based on a simulating halt
>>>>>>>>>>>> decider.
>>>>>>>>>>>> This makes it impossible for P to do the opposite of whatever H
>>>>>>>>>>>> decides.
>>>>>>>>>>>>
>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>> (c) Several halt deciders and their inputs contained within
>>>>>>>>>>>> Halt7.c
>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>
>>>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>>>> SUPPOSED
>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>
>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>
>>>>>>>>> Your H is recursive because P isn't recursive and yet you have
>>>>>>>>> to abort
>>>>>>>>> your infinite recursion: the recursion is caused by your H and
>>>>>>>>> not by
>>>>>>>>> P.  Nowhere in any halting problem proof does it state that the
>>>>>>>>> call to
>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>>>> EXECUTE P, H
>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of a
>>>>>>>> simulating halt decider (SHD) ever thought all the way through.
>>>>>>>
>>>>>>> Because the proof doesn't care at all how the decider got the
>>>>>>> answer,
>>>>>>>
>>>>>>>>
>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>> simulation of a machine description provides the actual behavior
>>>>>>>> of the underlying machine whenever any simulating halt decider
>>>>>>>> must abort its simulation to prevent infinite simulation it is
>>>>>>>> necessarily correct to report that this input does not halt.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation
>>>>>>> does not define the "behavior of the input".
>>>>>>>
>>>>>>
>>>>>> The behavior of the correct simulation of the input is its actual
>>>>>> behavior. That H correctly predicts that its correct simulation
>>>>>> never stops running unless aborted conclusively proves that this
>>>>>> correctly simulated input would never reach its own final state in
>>>>>> 1 to ∞ steps of correct simulation.
>>>>>
>>>>> But the behavior the halting problem is asking for is the behavior
>>>>> of the actual machine.
>>>>>
>>>>
>>>> Only within the context that no one ever bothered to think the
>>>> application of a simulating halt decider all the way through.
>>>>
>>>
>>> No, the DEFINITION of a Halt Decider is to decide on the behavior of
>>> the Actual Machine.
>>>
>> That definition is made obsolete by a simulating halt decider.
>>
>>
>
> Nope, the definition IS the definition.
>
> You don't get to change it.
>
I created a new concept that makes earlier ideas about this obsolete:

Because the definition of a UTM specifies that the correct simulation of
a machine description provides the actual behavior of the underlying
machine whenever any simulating halt decider must abort its simulation
to prevent infinite simulation it is necessarily correct to report that
this input does not halt.

Because the above is verified as correct on the basis of the meaning of
its words it is irrefutable.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 9/26/22 9:26 PM, olcott wrote:
> On 9/26/2022 8:15 PM, Richard Damon wrote:
>> On 9/26/22 8:58 PM, olcott wrote:
>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss this
>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>>>>>> posting. You gave up on me before I could point out the
>>>>>>>>>>>>> error with
>>>>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>>>>> rebuttal:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The diagonalization argument merely proves that no value
>>>>>>>>>>>>> returned
>>>>>>>>>>>>> to P from its call to H can possibly be correct. This argument
>>>>>>>>>>>>> totally ignores that the return value from H is unreachable
>>>>>>>>>>>>> by its
>>>>>>>>>>>>> simulated P caller when H is based on a simulating halt
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>> This makes it impossible for P to do the opposite of
>>>>>>>>>>>>> whatever H
>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>> (c) Several halt deciders and their inputs contained within
>>>>>>>>>>>>> Halt7.c
>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>
>>>>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>>>>> SUPPOSED
>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>
>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>
>>>>>>>>>> Your H is recursive because P isn't recursive and yet you have
>>>>>>>>>> to abort
>>>>>>>>>> your infinite recursion: the recursion is caused by your H and
>>>>>>>>>> not by
>>>>>>>>>> P.  Nowhere in any halting problem proof does it state that
>>>>>>>>>> the call to
>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>>>>> EXECUTE P, H
>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of a
>>>>>>>>> simulating halt decider (SHD) ever thought all the way through.
>>>>>>>>
>>>>>>>> Because the proof doesn't care at all how the decider got the
>>>>>>>> answer,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>> behavior of the underlying machine whenever any simulating halt
>>>>>>>>> decider must abort its simulation to prevent infinite
>>>>>>>>> simulation it is necessarily correct to report that this input
>>>>>>>>> does not halt.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation
>>>>>>>> does not define the "behavior of the input".
>>>>>>>>
>>>>>>>
>>>>>>> The behavior of the correct simulation of the input is its actual
>>>>>>> behavior. That H correctly predicts that its correct simulation
>>>>>>> never stops running unless aborted conclusively proves that this
>>>>>>> correctly simulated input would never reach its own final state
>>>>>>> in 1 to ∞ steps of correct simulation.
>>>>>>
>>>>>> But the behavior the halting problem is asking for is the behavior
>>>>>> of the actual machine.
>>>>>>
>>>>>
>>>>> Only within the context that no one ever bothered to think the
>>>>> application of a simulating halt decider all the way through.
>>>>>
>>>>
>>>> No, the DEFINITION of a Halt Decider is to decide on the behavior of
>>>> the Actual Machine.
>>>>
>>> That definition is made obsolete by a simulating halt decider.
>>>
>>>
>>
>> Nope, the definition IS the definition.
>>
>> You don't get to change it.
>>
> I created a new concept that makes earlier ideas about this obsolete:
>
> Because the definition of a UTM specifies that the correct simulation of
> a machine description provides the actual behavior of the underlying
> machine whenever any simulating halt decider must abort its simulation
> to prevent infinite simulation it is necessarily correct to report that
> this input does not halt.
>
> Because the above is verified as correct on the basis of the meaning of
> its words it is irrefutable.
>

Right, but H isn't a UTM, so its simulation doesn't matter.

Thus, the fact that it aborts means nothing.

There is no "Must", because either it is coded to abort or it isn't.

You have two DIFFERENT H's in mind.

There is one H, that doesn't abort, with its P, and yes, that P is
non-halting but that H doesn't answer.

The other H, the one that aborts, is given a DIFFERENT P, so the
behavior of that other machine, deceptivdly also called P, doesn't
matter, as it is a DIFFERENT Machine.

This second H always aborts its simulation of this second P, and returns
0, so a simple inspection of this second P shows that it will halt.

Only because you stupidly confuse these two DIFFERENT inputs, because
you gas lit yourself by your deceptive naming, do you get the wrong answer.

When you name the two different H's with different names, the error
becomes obvious.

The whole idea of H looking at the behavior of another "version" of
itself is incorrect, and show that you are totoally ignorant of the
basic principles of the field.

On 9/26/2022 8:49 PM, Richard Damon wrote:
> On 9/26/22 9:26 PM, olcott wrote:
>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>> On 9/26/22 8:58 PM, olcott wrote:
>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>>>>>>> posting. You gave up on me before I could point out the
>>>>>>>>>>>>>> error with
>>>>>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>>>>>> rebuttal:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The diagonalization argument merely proves that no value
>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>> to P from its call to H can possibly be correct. This
>>>>>>>>>>>>>> argument
>>>>>>>>>>>>>> totally ignores that the return value from H is
>>>>>>>>>>>>>> unreachable by its
>>>>>>>>>>>>>> simulated P caller when H is based on a simulating halt
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>> This makes it impossible for P to do the opposite of
>>>>>>>>>>>>>> whatever H
>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>> (c) Several halt deciders and their inputs contained
>>>>>>>>>>>>>> within Halt7.c
>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>
>>>>>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>>>>>> SUPPOSED
>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>
>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>
>>>>>>>>>>> Your H is recursive because P isn't recursive and yet you
>>>>>>>>>>> have to abort
>>>>>>>>>>> your infinite recursion: the recursion is caused by your H
>>>>>>>>>>> and not by
>>>>>>>>>>> P.  Nowhere in any halting problem proof does it state that
>>>>>>>>>>> the call to
>>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>>>>>> EXECUTE P, H
>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of a
>>>>>>>>>> simulating halt decider (SHD) ever thought all the way through.
>>>>>>>>>
>>>>>>>>> Because the proof doesn't care at all how the decider got the
>>>>>>>>> answer,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>>> behavior of the underlying machine whenever any simulating
>>>>>>>>>> halt decider must abort its simulation to prevent infinite
>>>>>>>>>> simulation it is necessarily correct to report that this input
>>>>>>>>>> does not halt.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation
>>>>>>>>> does not define the "behavior of the input".
>>>>>>>>>
>>>>>>>>
>>>>>>>> The behavior of the correct simulation of the input is its
>>>>>>>> actual behavior. That H correctly predicts that its correct
>>>>>>>> simulation never stops running unless aborted conclusively
>>>>>>>> proves that this correctly simulated input would never reach its
>>>>>>>> own final state in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>> But the behavior the halting problem is asking for is the
>>>>>>> behavior of the actual machine.
>>>>>>>
>>>>>>
>>>>>> Only within the context that no one ever bothered to think the
>>>>>> application of a simulating halt decider all the way through.
>>>>>>
>>>>>
>>>>> No, the DEFINITION of a Halt Decider is to decide on the behavior
>>>>> of the Actual Machine.
>>>>>
>>>> That definition is made obsolete by a simulating halt decider.
>>>>
>>>>
>>>
>>> Nope, the definition IS the definition.
>>>
>>> You don't get to change it.
>>>
>> I created a new concept that makes earlier ideas about this obsolete:
>>
>> Because the definition of a UTM specifies that the correct simulation
>> of a machine description provides the actual behavior of the
>> underlying machine whenever any simulating halt decider must abort its
>> simulation to prevent infinite simulation it is necessarily correct to
>> report that this input does not halt.
>>
>> Because the above is verified as correct on the basis of the meaning
>> of its words it is irrefutable.
>>
>
> Right, but H isn't a UTM, so its simulation doesn't matter.
>

The concept of a UTM defines that the correct simulation of a machine
description provides the actual behavior of this machine description
thus the correct x86 emulation of the machine language of a C function
also provides the actual behavior of this function.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 9/26/22 9:55 PM, olcott wrote:
> On 9/26/2022 8:49 PM, Richard Damon wrote:
>> On 9/26/22 9:26 PM, olcott wrote:
>>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>>> On 9/26/22 8:58 PM, olcott wrote:
>>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If people would give me a fair and honest review I could
>>>>>>>>>>>>>>> quit
>>>>>>>>>>>>>>> posting. You gave up on me before I could point out the
>>>>>>>>>>>>>>> error with
>>>>>>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>>>>>>> rebuttal:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The diagonalization argument merely proves that no value
>>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>>> to P from its call to H can possibly be correct. This
>>>>>>>>>>>>>>> argument
>>>>>>>>>>>>>>> totally ignores that the return value from H is
>>>>>>>>>>>>>>> unreachable by its
>>>>>>>>>>>>>>> simulated P caller when H is based on a simulating halt
>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>> This makes it impossible for P to do the opposite of
>>>>>>>>>>>>>>> whatever H
>>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>>> (c) Several halt deciders and their inputs contained
>>>>>>>>>>>>>>> within Halt7.c
>>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>>>>>>> SUPPOSED
>>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>>
>>>>>>>>>>>> Your H is recursive because P isn't recursive and yet you
>>>>>>>>>>>> have to abort
>>>>>>>>>>>> your infinite recursion: the recursion is caused by your H
>>>>>>>>>>>> and not by
>>>>>>>>>>>> P.  Nowhere in any halting problem proof does it state that
>>>>>>>>>>>> the call to
>>>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>>>>>>> EXECUTE P, H
>>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of a
>>>>>>>>>>> simulating halt decider (SHD) ever thought all the way through.
>>>>>>>>>>
>>>>>>>>>> Because the proof doesn't care at all how the decider got the
>>>>>>>>>> answer,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>>>> behavior of the underlying machine whenever any simulating
>>>>>>>>>>> halt decider must abort its simulation to prevent infinite
>>>>>>>>>>> simulation it is necessarily correct to report that this
>>>>>>>>>>> input does not halt.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS*
>>>>>>>>>> simulation does not define the "behavior of the input".
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The behavior of the correct simulation of the input is its
>>>>>>>>> actual behavior. That H correctly predicts that its correct
>>>>>>>>> simulation never stops running unless aborted conclusively
>>>>>>>>> proves that this correctly simulated input would never reach
>>>>>>>>> its own final state in 1 to ∞ steps of correct simulation.
>>>>>>>>
>>>>>>>> But the behavior the halting problem is asking for is the
>>>>>>>> behavior of the actual machine.
>>>>>>>>
>>>>>>>
>>>>>>> Only within the context that no one ever bothered to think the
>>>>>>> application of a simulating halt decider all the way through.
>>>>>>>
>>>>>>
>>>>>> No, the DEFINITION of a Halt Decider is to decide on the behavior
>>>>>> of the Actual Machine.
>>>>>>
>>>>> That definition is made obsolete by a simulating halt decider.
>>>>>
>>>>>
>>>>
>>>> Nope, the definition IS the definition.
>>>>
>>>> You don't get to change it.
>>>>
>>> I created a new concept that makes earlier ideas about this obsolete:
>>>
>>> Because the definition of a UTM specifies that the correct simulation
>>> of a machine description provides the actual behavior of the
>>> underlying machine whenever any simulating halt decider must abort
>>> its simulation to prevent infinite simulation it is necessarily
>>> correct to report that this input does not halt.
>>>
>>> Because the above is verified as correct on the basis of the meaning
>>> of its words it is irrefutable.
>>>
>>
>> Right, but H isn't a UTM, so its simulation doesn't matter.
>>
>
> The concept of a UTM defines that the correct simulation of a machine
> description provides the actual behavior of this machine description
> thus the correct x86 emulation of the machine language of a C function
> also provides the actual behavior of this function.
>

On 9/26/2022 8:49 PM, Richard Damon wrote:
> On 9/26/22 9:26 PM, olcott wrote:
>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>> On 9/26/22 8:58 PM, olcott wrote:
>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place to discuss
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because Olcott postings will push you out of visibility?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If people would give me a fair and honest review I could quit
>>>>>>>>>>>>>> posting. You gave up on me before I could point out the
>>>>>>>>>>>>>> error with
>>>>>>>>>>>>>> the diagonalization argument that you relied on for your
>>>>>>>>>>>>>> rebuttal:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The diagonalization argument merely proves that no value
>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>> to P from its call to H can possibly be correct. This
>>>>>>>>>>>>>> argument
>>>>>>>>>>>>>> totally ignores that the return value from H is
>>>>>>>>>>>>>> unreachable by its
>>>>>>>>>>>>>> simulated P caller when H is based on a simulating halt
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>> This makes it impossible for P to do the opposite of
>>>>>>>>>>>>>> whatever H
>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Complete halt deciding system (Visual Studio Project)
>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>> (c) Several halt deciders and their inputs contained
>>>>>>>>>>>>>> within Halt7.c
>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>
>>>>>>>>>>>>> You keep making the same mistake again and again. H IS NOT
>>>>>>>>>>>>> SUPPOSED
>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>
>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>
>>>>>>>>>>> Your H is recursive because P isn't recursive and yet you
>>>>>>>>>>> have to abort
>>>>>>>>>>> your infinite recursion: the recursion is caused by your H
>>>>>>>>>>> and not by
>>>>>>>>>>> P.  Nowhere in any halting problem proof does it state that
>>>>>>>>>>> the call to
>>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT SUPPOSED TO
>>>>>>>>>>> EXECUTE P, H
>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea of a
>>>>>>>>>> simulating halt decider (SHD) ever thought all the way through.
>>>>>>>>>
>>>>>>>>> Because the proof doesn't care at all how the decider got the
>>>>>>>>> answer,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>>> behavior of the underlying machine whenever any simulating
>>>>>>>>>> halt decider must abort its simulation to prevent infinite
>>>>>>>>>> simulation it is necessarily correct to report that this input
>>>>>>>>>> does not halt.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, which means it CAN'T be a UTM, and thus *ITS* simulation
>>>>>>>>> does not define the "behavior of the input".
>>>>>>>>>
>>>>>>>>
>>>>>>>> The behavior of the correct simulation of the input is its
>>>>>>>> actual behavior. That H correctly predicts that its correct
>>>>>>>> simulation never stops running unless aborted conclusively
>>>>>>>> proves that this correctly simulated input would never reach its
>>>>>>>> own final state in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>> But the behavior the halting problem is asking for is the
>>>>>>> behavior of the actual machine.
>>>>>>>
>>>>>>
>>>>>> Only within the context that no one ever bothered to think the
>>>>>> application of a simulating halt decider all the way through.
>>>>>>
>>>>>
>>>>> No, the DEFINITION of a Halt Decider is to decide on the behavior
>>>>> of the Actual Machine.
>>>>>
>>>> That definition is made obsolete by a simulating halt decider.
>>>>
>>>>
>>>
>>> Nope, the definition IS the definition.
>>>
>>> You don't get to change it.
>>>
>> I created a new concept that makes earlier ideas about this obsolete:
>>
>> Because the definition of a UTM specifies that the correct simulation
>> of a machine description provides the actual behavior of the
>> underlying machine whenever any simulating halt decider must abort its
>> simulation to prevent infinite simulation it is necessarily correct to
>> report that this input does not halt.
>>
>> Because the above is verified as correct on the basis of the meaning
>> of its words it is irrefutable.
>>
>
> Right, but H isn't a UTM, so its simulation doesn't matter.
>

Unless you can specify that material difference between the two, that
would seem to prove that you are technically incompetent.

So far none of the people that I have spoken with in any of the reviews
of my work know these things any deeper than learned-by-rote.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer