On 7/22/2022 6:55 PM, Skep Dick wrote:
> On Saturday, 23 July 2022 at 01:53:36 UTC+2, olcott wrote:
>> On 7/22/2022 6:25 PM, Skep Dick wrote:
>>> On Saturday, 23 July 2022 at 01:10:11 UTC+2, olcott wrote:
>>>> On 7/22/2022 5:45 PM, Skep Dick wrote:
>>>>> On Saturday, 23 July 2022 at 00:36:06 UTC+2, olcott wrote:
>>>>>> On 7/22/2022 4:57 PM, Skep Dick wrote:
>>>>>>> On Friday, 22 July 2022 at 23:43:57 UTC+2, olcott wrote:
>>>>>>>> If a Turing Machines cannot see that the input to a halt decider
>>>>>>>> specifies infinitely recursive simulation and humans can see this then
>>>>>>>> Turing machines must be not the best model of computation.
>>>>>>>
>>>>>>> This is non-sensical statement. A computation **IS** any calculation that follows a well-defined model.
>>>>>>>
>>>>>>> "follows a well defined model" means the same thing as "obeys rules".
>>>>>> I have always believed that a TM can calculate anything that any
>>>>>> computer can calculate
>>>>>
>>>>> I don't see what this has to do with my point.
>>>>>
>>>>> Calculations are strictly mechanical/quantitative activity based on structure/rules. That is why we can it to a machine.
>>>>>
>>>> Then the fact that my C function does determine that its conventional
>>>> pathological input never halts must also apply to Turing machines
>>>> without making any difference whether or not H is a pure function.
>>>
>>> Again. What does this have to do with anything?
>>>
>>> All determinations of H about P are incorrect.
>>>
>> If we have a cat we have an animal.
>>
>> Kingdom: Animalia
>> Phylum: Chordata
>> Class: Mammalia
>> Order: Carnivora
>> Suborder: Feliformia
>> Family: Felidae
>> Subfamily:Felinae
>> Genus: Felis
>> Species: F. catus
>>
>> If a simulating halt decider continues to correctly simulate its input
>> until it correctly matches a non-halting behavior pattern then this SHD
>> is necessarily correct when it aborts its simulation and reports
>> non-halting.
>>
>> H does do this so it is necessarily correct
>>> Because if H determines that P never halts... that's precisely when P halts.
>>> And if H determines that P halts...that's precisely when P doesn't halt.
>>>
>> I am only referring to the correctly simulated input that never halts no
>> matter what. Everyone keeps dishonestly changing the subject to an
>> entirely different sequence of instructions.
>
>
> Pete, stop wasting my time and just play my game "Will I call you an idiot?"
I made a perfectly correct rebuttal and you responded with mere rhetoric
indicating that you are not interested in any honest rebuttal.

THIS IS IMPOSSIBLY FALSE
If a simulating halt decider continues to correctly simulate its input
until it correctly matches a non-halting behavior pattern then this SHD
is necessarily correct when it aborts its simulation and reports
non-halting.

THIS IS PROVABLY TRUE
I am only referring to the correctly simulated input to H(P,P) that
never halts no matter what. The directly executed P(P) specifies an
entirely different sequence of instructions.

--
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 7/22/22 8:54 PM, olcott wrote:
> On 7/22/2022 6:55 PM, Skep Dick wrote:
>> On Saturday, 23 July 2022 at 01:53:36 UTC+2, olcott wrote:
>>> On 7/22/2022 6:25 PM, Skep Dick wrote:
>>>> On Saturday, 23 July 2022 at 01:10:11 UTC+2, olcott wrote:
>>>>> On 7/22/2022 5:45 PM, Skep Dick wrote:
>>>>>> On Saturday, 23 July 2022 at 00:36:06 UTC+2, olcott wrote:
>>>>>>> On 7/22/2022 4:57 PM, Skep Dick wrote:
>>>>>>>> On Friday, 22 July 2022 at 23:43:57 UTC+2, olcott wrote:
>>>>>>>>> If a Turing Machines cannot see that the input to a halt decider
>>>>>>>>> specifies infinitely recursive simulation and humans can see
>>>>>>>>> this then
>>>>>>>>> Turing machines must be not the best model of computation.
>>>>>>>>
>>>>>>>> This is non-sensical statement. A computation **IS** any
>>>>>>>> calculation that follows a well-defined model.
>>>>>>>>
>>>>>>>> "follows a well defined model" means the same thing as "obeys
>>>>>>>> rules".
>>>>>>> I have always believed that a TM can calculate anything that any
>>>>>>> computer can calculate
>>>>>>
>>>>>> I don't see what this has to do with my point.
>>>>>>
>>>>>> Calculations are strictly mechanical/quantitative activity based
>>>>>> on structure/rules. That is why we can it to a machine.
>>>>>>
>>>>> Then the fact that my C function does determine that its conventional
>>>>> pathological input never halts must also apply to Turing machines
>>>>> without making any difference whether or not H is a pure function.
>>>>
>>>> Again. What does this have to do with anything?
>>>>
>>>> All determinations of H about P are incorrect.
>>>>
>>> If we have a cat we have an animal.
>>>
>>> Kingdom: Animalia
>>> Phylum: Chordata
>>> Class: Mammalia
>>> Order: Carnivora
>>> Suborder: Feliformia
>>> Family: Felidae
>>> Subfamily:Felinae
>>> Genus: Felis
>>> Species: F. catus
>>>
>>> If a simulating halt decider continues to correctly simulate its input
>>> until it correctly matches a non-halting behavior pattern then this SHD
>>> is necessarily correct when it aborts its simulation and reports
>>> non-halting.
>>>
>>> H does do this so it is necessarily correct
>>>> Because if H determines that P never halts... that's precisely when
>>>> P halts.
>>>> And if H determines that P halts...that's precisely when P doesn't
>>>> halt.
>>>>
>>> I am only referring to the correctly simulated input that never halts no
>>> matter what. Everyone keeps dishonestly changing the subject to an
>>> entirely different sequence of instructions.
>>
>>
>> Pete, stop wasting my time and just play my game "Will I call you an
>> idiot?"
> I made a perfectly correct rebuttal and you responded with mere rhetoric
> indicating that you are not interested in any honest rebuttal.
>
> THIS IS IMPOSSIBLY FALSE
> If a simulating halt decider continues to correctly simulate its input
> until it correctly matches a non-halting behavior pattern then this SHD
> is necessarily correct when it aborts its simulation and reports
> non-halting.

Right, *IF* it finds a finite correct non-halting pattern, which has
been proved to not exist. Showing that if it finds a pattern that
doesn't exist it gives the right answer doesn't show that it gave the
right answers. That is like saying if cats were dogs, then cats would bark.

>
> THIS IS PROVABLY TRUE
> I am only referring to the correctly simulated input to H(P,P) that
> never halts no matter what. The directly executed P(P) specifies an
> entirely different sequence of instructions.
>

FALSE. IF H(P,P) does not refer to the behavior of P(P), then H and P
fail to met the definitions they have to meet.

The "logic" you use to make your proof is totally bogus, based on
INCORRECT definition, and thus don't actually prove what you claim to be
proving.

HALTING, is define ONLY by the MACHINE ITSELF, or replaceable by things
that are ACTUALLY PROVABLY EQUIVALENT.

P, by definition asks H about itself applied to its input, so if H(P,P)
doesn't ask about P(P), then your P is not the required computation, and
you whole proof is shown to be a LIE.

H needs to answer based on the ACTUAL behavior of the machine the input
represents, and for H(P,P) that IS P(P), as there is no other machine in
view that it could be. We can replace that behavior by a CORRECT AND
COMPLETE simulation by a simulator that NEVER aborts, which isn't H if H
answers non-halting, so ANY proof that refers to the partial simulation
of H, needs to also show that the results apply when that exact same
input (so it calls the H that does the aborting) is given to an actual
correct and complete simulator, which BY DEFINITION will give the same
answer as P(P).

You insistance on this "proof" just proves that you do not understand
the nature of actual logic.

The only correct simulation of H(P,P) that never halts is for an H that
never aborts. Since that H never answwer, it is not the H that you claim
correctly answer H(P,P) as non-halting.

All you are doing is showing that you are lying somewhere or are too
stupid to know what you are saying.

On 7/22/2022 6:52 PM, Chris M. Thomasson wrote:
> On 7/22/2022 2:43 PM, olcott wrote:
>> On 7/22/2022 4:12 PM, olcott wrote:
>>> On 7/22/2022 3:51 PM, Skep Dick wrote:
>>>> On Friday, 22 July 2022 at 22:08:28 UTC+2, olcott wrote:
>>>>> I do this by showing the criteria that humans use to recognize
>>>>> ordinary
>>>>> infinite recursion between two functions.
>>>>
>>>> The criteria humans use are not applicable to Turing machines.
>>>>
>>>> Because Turing-decidability and Human-decidability are not the same
>>>> thing.
>>>>
>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>
>>>
>>> If Turing machines cannot not see what humans see then Turing
>>> machines may be an incorrect model of computation.
>>>
>>>
>>
>> Please stop cutting out the immediate context, leave at least the last
>> four messages.
> [...]
>
> The last 1000 messages?
>

I apologize I meant to make very few posts to comp.c and comp.c++ and
always make the followup to comp.theory.

*If anyone replies to this post please change the group to comp.theory*

--
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 7/22/22 3:14 PM, olcott wrote:
> On 7/22/2022 2:09 PM, Skep Dick wrote:
>> On Friday, 22 July 2022 at 21:08:00 UTC+2, olcott wrote:
>>> First of all you have the facts incorrectly, only H is simulating.
>>
>> Really?
>>
>> So why does your code look like this...
>>
>> int H(ptr p, ptr i)
>> {
>> p(i);
>> }
>>
>> and not like this...
>>
>>
>> int H(ptr p, ptr i)
>> {
>> simulate(p(i));
>> }
>
> That is a simplistic example to communicate the simplest possible case
> of infinite recursion.
>

The problem is you "simplistic example" is too simplified.

H doesn't actually simulate its input and implies that simulation is
identical to calling.

Since the simulation that H does is actually conditional, there is a BIG
difference between the two.

On Friday, 22 July 2022 at 17:25:08 UTC+8, olcott wrote:
> On 7/21/2022 11:36 PM, wij wrote:
> > On Friday, 22 July 2022 at 11:20:57 UTC+8, olcott wrote:
> >> *Infinite recursion / infinitely recursive emulation detection criteria*
> >>
> >> int H(ptr p, ptr i)
> >> {
> >> p(i);
> >> }
> >>
> >> void P(ptr x)
> >> {
> >> H(x, x);
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> H(P,P);
> >> }
> >>
> >> If the execution trace of function P() called by function H() shows:
> >> (1) Function H() is called twice in sequence from the same machine
> >> address of P().
> >> (2) With the same parameters to H().
> >> (3) With no control flow instructions between the invocation of P() and
> >> the call to H() from P().
> >>
> >> Then the function call from P() to H() is infinitely recursive.
> >> The exact same pattern applies when H() simulates its input with an x86
> >> emulator.
> >>
> >> When H is an infinite recursion detector it simply matches the above
> >> criteria in its execution trace of P, aborts its simulation of its input
> >> and reports that its simulated input would never reach its "return"
> >> instruction.
> >>
> >> To avoid using static local memory for its stored execution trace H must
> >> know its own address and see itself called from P with the same
> >> arguments that it was called with.
> >>
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > EVERYBODY KNOWS the H and P shown are both "infinite recursive functions".
> > This fact is like 2+3=5, very elementary, does not need a complicated program
> > or devise other criteria to prove. It is ALREADY VERY OBVIOUS (lots of your work
> > addresses this unnecessary/useless part).
> >
> Great. I also want H() to know this, that is why I need specific
> criteria to be validated.

No, you don't need 'criteria', because you cannot understand what those technical words mean.

> > However, the HP asks for a deterministic (pure) decision PROGRAM H (not you):
> > H(P,x)==1, if P(x) halts.
> > H(P,x)==0, otherwise.
> >
> I am not even talking about halts. I am talking about P() never reaching
> its "return" instruction.
> > The deterministic (pure) H means H(P,P) must return the same value whether or
> > not it is from main or from P. Otherwise, this H is not a function in discussion and interested.
> >
> I am not asking if a Turing machine determines if its input halts. I am
> asking if my C function H() determines whether it not its simulated
> input P() reaches its "return" instruction.

Not an interesting question. The HP problem asks H to return 1 or 0, disregard
how the answer is derived.

> > int main() {
> > H(P,P); // H must return the same value as the one in P
> > P(P); // this P
> > }
> >
> Maybe if H() is required to be a pure function. I am dropping that
> requirement for now.
> > No matter what criteria you use, copy from all possible authoritative sources as
> > you can, it will all be useless because we know the author is an idiot who
> > cannot even get the basic logic right. It contains no technical meaning.
> >
> > This only chance for you is a real H that satisfies the requirements shown, not
> > your 'criteria'. So far as we know it for these years, none.
> I am taking this as a two step process:
> (1) Seeing if people are honest:
> (a) If they say that the simulated P() can reach its "return"
> instruction then they flunked the honesty test.
>
> (b) If they refuse to confirm that the simulated P() can never reach its
> "return" instruction then they flunked the honesty test.
>
> After they pass these two tests then we can begin to examine pure
> functions.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

Your H is not a pure function. Thus, POOH is not valid for the HP problem.

On 7/22/2022 9:46 PM, Richard Damon wrote:
> On 7/22/22 3:14 PM, olcott wrote:
>> On 7/22/2022 2:09 PM, Skep Dick wrote:
>>> On Friday, 22 July 2022 at 21:08:00 UTC+2, olcott wrote:
>>>> First of all you have the facts incorrectly, only H is simulating.
>>>
>>> Really?
>>>
>>> So why does your code look like this...
>>>
>>> int H(ptr p, ptr i)
>>> {
>>> p(i);
>>> }
>>>
>>> and not like this...
>>>
>>>
>>> int H(ptr p, ptr i)
>>> {
>>> simulate(p(i));
>>> }
>>
>> That is a simplistic example to communicate the simplest possible case
>> of infinite recursion.
>>
>
> The problem is you "simplistic example" is too simplified.
>
> H doesn't actually simulate its input and implies that simulation is
> identical to calling.
>
> Since the simulation that H does is actually conditional, there is a BIG
> difference between the two.

Your way of saying it is clearer than mine, I will update mine.

The above example is to merely communicate the idea that the same halt
deciding criteria applies equally to infinite recursion and infinitely
recursive emulation.

I have now provided a link to the complete source-code of the whole
system and a file-by-file description of all the files in my updated
paper. After I clean up the x86utm code I may put the whole system in a
repository.

*Halting problem proofs refuted on the basis of software engineering* ?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
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 Saturday, 23 July 2022 at 05:56:37 UTC+2, olcott wrote:
> On 7/22/2022 9:46 PM, Richard Damon wrote:
> > On 7/22/22 3:14 PM, olcott wrote:
> >> On 7/22/2022 2:09 PM, Skep Dick wrote:
> >>> On Friday, 22 July 2022 at 21:08:00 UTC+2, olcott wrote:
> >>>> First of all you have the facts incorrectly, only H is simulating.
> >>>
> >>> Really?
> >>>
> >>> So why does your code look like this...
> >>>
> >>> int H(ptr p, ptr i)
> >>> {
> >>> p(i);
> >>> }
> >>>
> >>> and not like this...
> >>>
> >>>
> >>> int H(ptr p, ptr i)
> >>> {
> >>> simulate(p(i));
> >>> }
> >>
> >> That is a simplistic example to communicate the simplest possible case
> >> of infinite recursion.
> >>
> >
> > The problem is you "simplistic example" is too simplified.
> >
> > H doesn't actually simulate its input and implies that simulation is
> > identical to calling.
> >
> > Since the simulation that H does is actually conditional, there is a BIG
> > difference between the two.
> Your way of saying it is clearer than mine, I will update mine.
>
> The above example is to merely communicate the idea that the same halt
> deciding criteria applies equally to infinite recursion and infinitely
> recursive emulation.

The halting problem has nothing to do with recursion.
It has to do with the problem being undecidable after 1; or infinitely many steps.

Everything implemented as recursive function, can also be implemented as an infinite loop.

https://en.wikipedia.org/wiki/Loop_unrolling

On 7/22/22 11:56 PM, olcott wrote:
> On 7/22/2022 9:46 PM, Richard Damon wrote:
>> On 7/22/22 3:14 PM, olcott wrote:
>>> On 7/22/2022 2:09 PM, Skep Dick wrote:
>>>> On Friday, 22 July 2022 at 21:08:00 UTC+2, olcott wrote:
>>>>> First of all you have the facts incorrectly, only H is simulating.
>>>>
>>>> Really?
>>>>
>>>> So why does your code look like this...
>>>>
>>>> int H(ptr p, ptr i)
>>>> {
>>>> p(i);
>>>> }
>>>>
>>>> and not like this...
>>>>
>>>>
>>>> int H(ptr p, ptr i)
>>>> {
>>>> simulate(p(i));
>>>> }
>>>
>>> That is a simplistic example to communicate the simplest possible
>>> case of infinite recursion.
>>>
>>
>> The problem is you "simplistic example" is too simplified.
>>
>> H doesn't actually simulate its input and implies that simulation is
>> identical to calling.
>>
>> Since the simulation that H does is actually conditional, there is a
>> BIG difference between the two.
>
> Your way of saying it is clearer than mine, I will update mine.
>
> The above example is to merely communicate the idea that the same halt
> deciding criteria applies equally to infinite recursion and infinitely
> recursive emulation.

How, since it doesn't show any emulation?

And, CONDITIONAL emulation, as your H uses DOES have different criteria,
because H can stop simulating P after it starts it, but when you call a
function, while that called function is running, the caller can't do
anything about it.

This seems to be the thing that you are ignoring.

When we run P(P) it calls H(P,P) which starts a simulation of P(P).
That P(P) calls H(P,P) which if the simulation was unconditional WOULD
allow proving that the behavior was infinite, but because H is
CONDITIONALLLY simulating the machine it was given, the out H called can
at this point decide to stop stimulating to prevent the infinite loop
and return an answer to P, and if it returns 0 to that P it will halt.

The fact that this H will do this means the H that it was simulating
will also do the same thing, so H hasn't actually "proven" that the
input is non-halting, that determination was made under conditions that
don't hold (H not aborting its simulation).

Mr Flibble has recently presents a different version of the simulator
that can help with problem (I mentioned this same idea years ago) that
rather than just aborting the simulation, you check what happens if you
continue the simulation of the machine returning both 0 and 1 and see if
either answer give a correct answer, and if you find one, that can be
the answer.

The problem will be that when you do that you find out that P is
contradictory, so H knows that it can't give a correct answer.

>
> I have now provided a link to the complete source-code of the whole
> system and a file-by-file description of all the files in my updated
> paper. After I clean up the x86utm code I may put the whole system in a
> repository.
>
> *Halting problem proofs refuted on the basis of software engineering* ?
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
>

On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> THIS IS PROVABLY TRUE
> I am only referring to the correctly simulated input to H(P,P) that
> never halts no matter what. The directly executed P(P) specifies an
> entirely different sequence of instructions.

You realise this is essentially the same as saying "Reality does not agree with my predictions, but my predictions are nevertheless correct" ?

On 7/23/2022 8:11 AM, Paul N wrote:
> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>> THIS IS PROVABLY TRUE
>> I am only referring to the correctly simulated input to H(P,P) that
>> never halts no matter what. The directly executed P(P) specifies an
>> entirely different sequence of instructions.
>
> You realise this is essentially the same as saying "Reality does not agree with my predictions, but my predictions are nevertheless correct" ?

In programming language theory, semantics is the field concerned with
the rigorous mathematical study of the meaning of programming
languages.[1] It does so by evaluating the meaning of syntactically
valid strings defined by a specific programming language, showing the
computation involved. In such a case that the evaluation would be of
syntactically invalid strings, the result would be non-computation.
Semantics describes the processes a computer follows when executing a
program in that specific language.
https://en.wikipedia.org/wiki/Semantics_(computer_science)

The code proves that the correctly simulated input would never reach its
"return" instruction.

--
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 7/23/22 9:30 AM, olcott wrote:
> On 7/23/2022 8:11 AM, Paul N wrote:
>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>> THIS IS PROVABLY TRUE
>>> I am only referring to the correctly simulated input to H(P,P) that
>>> never halts no matter what. The directly executed P(P) specifies an
>>> entirely different sequence of instructions.
>>
>> You realise this is essentially the same as saying "Reality does not
>> agree with my predictions, but my predictions are nevertheless correct" ?
>
>
> In programming language theory, semantics is the field concerned with
> the rigorous mathematical study of the meaning of programming
> languages.[1] It does so by evaluating the meaning of syntactically
> valid strings defined by a specific programming language, showing the
> computation involved. In such a case that the evaluation would be of
> syntactically invalid strings, the result would be non-computation.
> Semantics describes the processes a computer follows when executing a
> program in that specific language.
> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>
> The code proves that the correctly simulated input would never reach its
> "return" instruction.
>

No, it doesn't.

You have just proved that *IF* you H is an H that never aborts, that
this creeates a P that will never reach its return instruction.

You have also shown that no H can be designed that correcly simulates
its input to that return instruction.

This does NOT prove, that, given an H that aborts its simulation (and
thus doesn't meet either of the above conditions) the correct and
complete simulation of the input to H, by an actual correct an complete
simulator which H is no, would not halt.

In fact, it is easy to show that if H(P,P) aborts its simulation and
returns 0, then P(P) will Halt.

Note, refering to the correct and complete simulation by H, for an H
that aborts its simulation, is an illogical statement that is looking at
something that just doesn't happen.

The ONLY version of H that actually does a correct and complete
simulation of its input (and thus can directly show non-halting) is the
H that NEVER aborts its simulation, and that can NEVER correctly return
0 in finite time, because that requires either aborting its simulation
(and violating your preconditions) or doing infinite work in finite steps.

On 7/23/2022 8:30 AM, olcott wrote:
> On 7/23/2022 8:11 AM, Paul N wrote:
>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>> THIS IS PROVABLY TRUE
>>> I am only referring to the correctly simulated input to H(P,P) that
>>> never halts no matter what. The directly executed P(P) specifies an
>>> entirely different sequence of instructions.
>>
>> You realise this is essentially the same as saying "Reality does not
>> agree with my predictions, but my predictions are nevertheless correct" ?
>
>
> In programming language theory, semantics is the field concerned with
> the rigorous mathematical study of the meaning of programming
> languages.[1] It does so by evaluating the meaning of syntactically
> valid strings defined by a specific programming language, showing the
> computation involved. In such a case that the evaluation would be of
> syntactically invalid strings, the result would be non-computation.
> Semantics describes the processes a computer follows when executing a
> program in that specific language.
> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>
> The code proves that the correctly simulated input would never reach its
> "return" instruction.
>

It is like I am saying 2 + 3 = 5 and everyone disagrees.
The correct execution trace of the correctly simulated input to H(P,P)
conclusively proves that the simulated P cannot possibly reach its
"return" instruction.

Humans having sufficient technical knowledge can see this and H can see
this. To say that I am incorrect based on not having having sufficient
technical knowledge is both incorrect and rude.

--
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 Saturday, 23 July 2022 at 22:27:21 UTC+8, olcott wrote:
> On 7/23/2022 8:30 AM, olcott wrote:
> > On 7/23/2022 8:11 AM, Paul N wrote:
> >> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> >>> THIS IS PROVABLY TRUE
> >>> I am only referring to the correctly simulated input to H(P,P) that
> >>> never halts no matter what. The directly executed P(P) specifies an
> >>> entirely different sequence of instructions.
> >>
> >> You realise this is essentially the same as saying "Reality does not
> >> agree with my predictions, but my predictions are nevertheless correct" ?
> >
> >
> > In programming language theory, semantics is the field concerned with
> > the rigorous mathematical study of the meaning of programming
> > languages.[1] It does so by evaluating the meaning of syntactically
> > valid strings defined by a specific programming language, showing the
> > computation involved. In such a case that the evaluation would be of
> > syntactically invalid strings, the result would be non-computation.
> > Semantics describes the processes a computer follows when executing a
> > program in that specific language.
> > https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >
> > The code proves that the correctly simulated input would never reach its
> > "return" instruction.
> >
> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> The correct execution trace of the correctly simulated input to H(P,P)
> conclusively proves that the simulated P cannot possibly reach its
> "return" instruction.
>
> Humans having sufficient technical knowledge can see this and H can see
> this. To say that I am incorrect based on not having having sufficient
> technical knowledge is both incorrect and rude.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

So, if you are honest, you should say H(P,P)=undecidable (cannot possibly reach its "return" instruction)

On Sat, 23 Jul 2022 09:27:13 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/23/2022 8:30 AM, olcott wrote:
> > On 7/23/2022 8:11 AM, Paul N wrote:
> >> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> >>> THIS IS PROVABLY TRUE
> >>> I am only referring to the correctly simulated input to H(P,P)
> >>> that never halts no matter what. The directly executed P(P)
> >>> specifies an entirely different sequence of instructions.
> >>
> >> You realise this is essentially the same as saying "Reality does
> >> not agree with my predictions, but my predictions are nevertheless
> >> correct" ?
> >
> >
> > In programming language theory, semantics is the field concerned
> > with the rigorous mathematical study of the meaning of programming
> > languages.[1] It does so by evaluating the meaning of syntactically
> > valid strings defined by a specific programming language, showing
> > the computation involved. In such a case that the evaluation would
> > be of syntactically invalid strings, the result would be
> > non-computation. Semantics describes the processes a computer
> > follows when executing a program in that specific language.
> > https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >
> > The code proves that the correctly simulated input would never
> > reach its "return" instruction.
> >
>
> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> The correct execution trace of the correctly simulated input to
> H(P,P) conclusively proves that the simulated P cannot possibly reach
> its "return" instruction.

The only reason P cannot possibly reach its "return" instruction is
because H invokes infinite recursion which is why H is invalid: I have
shown that a simulating halt decider needn't be recursive in nature.

>
> Humans having sufficient technical knowledge can see this and H can
> see this. To say that I am incorrect based on not having having
> sufficient technical knowledge is both incorrect and rude.
Humans can clearly see that you are barking up the wrong tree.

/Flibble

On Fri, 22 Jul 2022 17:07:18 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Saturday, 23 July 2022 at 02:03:23 UTC+2, Mr Flibble wrote:
> > I have shown that a SHD needn't be recursive in nature *and* return
> > a correct halting decision for *all* inputs, something your SHD
> > fails to do.
>
> We have another player for our little game!
>
> The game is called "Will I call you an idiot?" (if you haven't
> already heard).
>
> I have given you the rules by which I am playing - the "source code"
> of my "software".
>
> If you guess that I'll call you an idiot then I won't call you an
> idiot. If you guess that I won't call you an idiot then I will call
> you an idiot.
>
> Go ahead and produce the correct decision!

My signaling halt decider always produces the correction decision (or a
signaled exception due to pathological input).

/Flibble

On 7/23/2022 9:37 AM, wij wrote:
> On Saturday, 23 July 2022 at 22:27:21 UTC+8, olcott wrote:
>> On 7/23/2022 8:30 AM, olcott wrote:
>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>> THIS IS PROVABLY TRUE
>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>> entirely different sequence of instructions.
>>>>
>>>> You realise this is essentially the same as saying "Reality does not
>>>> agree with my predictions, but my predictions are nevertheless correct" ?
>>>
>>>
>>> In programming language theory, semantics is the field concerned with
>>> the rigorous mathematical study of the meaning of programming
>>> languages.[1] It does so by evaluating the meaning of syntactically
>>> valid strings defined by a specific programming language, showing the
>>> computation involved. In such a case that the evaluation would be of
>>> syntactically invalid strings, the result would be non-computation.
>>> Semantics describes the processes a computer follows when executing a
>>> program in that specific language.
>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>
>>> The code proves that the correctly simulated input would never reach its
>>> "return" instruction.
>>>
>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>> The correct execution trace of the correctly simulated input to H(P,P)
>> conclusively proves that the simulated P cannot possibly reach its
>> "return" instruction.
>>
>> Humans having sufficient technical knowledge can see this and H can see
>> this. To say that I am incorrect based on not having having sufficient
>> technical knowledge is both incorrect and rude.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> So, if you are honest, you should say H(P,P)=undecidable (cannot possibly reach its "return" instruction)
>

If I am honest and technically correct I say that the correctly
simulated input to H(P,P) cannot possibly reach its "return" instruction
and H correctly rejects its input as non-halting on that basis.

--
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 Sat, 23 Jul 2022 09:41:55 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/23/2022 9:37 AM, wij wrote:
> > On Saturday, 23 July 2022 at 22:27:21 UTC+8, olcott wrote:
> >> On 7/23/2022 8:30 AM, olcott wrote:
> >>> On 7/23/2022 8:11 AM, Paul N wrote:
> >>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> >>>>> THIS IS PROVABLY TRUE
> >>>>> I am only referring to the correctly simulated input to H(P,P)
> >>>>> that never halts no matter what. The directly executed P(P)
> >>>>> specifies an entirely different sequence of instructions.
> >>>>
> >>>> You realise this is essentially the same as saying "Reality does
> >>>> not agree with my predictions, but my predictions are
> >>>> nevertheless correct" ?
> >>>
> >>>
> >>> In programming language theory, semantics is the field concerned
> >>> with the rigorous mathematical study of the meaning of programming
> >>> languages.[1] It does so by evaluating the meaning of
> >>> syntactically valid strings defined by a specific programming
> >>> language, showing the computation involved. In such a case that
> >>> the evaluation would be of syntactically invalid strings, the
> >>> result would be non-computation. Semantics describes the
> >>> processes a computer follows when executing a program in that
> >>> specific language.
> >>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >>>
> >>> The code proves that the correctly simulated input would never
> >>> reach its "return" instruction.
> >>>
> >> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> >> The correct execution trace of the correctly simulated input to
> >> H(P,P) conclusively proves that the simulated P cannot possibly
> >> reach its "return" instruction.
> >>
> >> Humans having sufficient technical knowledge can see this and H
> >> can see this. To say that I am incorrect based on not having
> >> having sufficient technical knowledge is both incorrect and rude.
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > So, if you are honest, you should say H(P,P)=undecidable (cannot
> > possibly reach its "return" instruction)
>
> If I am honest and technically correct I say that the correctly
> simulated input to H(P,P) cannot possibly reach its "return"
> instruction and H correctly rejects its input as non-halting on that
> basis.

Such a mapping is incorrect so you are incorrect on that basis. Your H
aborting because it is designed incorrectly (as it is recursive in
nature) is definitely a case of "undecidable" rather than
input being "non-halting".

/Flibble

On 7/23/2022 9:55 AM, Mr Flibble wrote:
> On Sat, 23 Jul 2022 09:41:55 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/23/2022 9:37 AM, wij wrote:
>>> On Saturday, 23 July 2022 at 22:27:21 UTC+8, olcott wrote:
>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>> THIS IS PROVABLY TRUE
>>>>>>> I am only referring to the correctly simulated input to H(P,P)
>>>>>>> that never halts no matter what. The directly executed P(P)
>>>>>>> specifies an entirely different sequence of instructions.
>>>>>>
>>>>>> You realise this is essentially the same as saying "Reality does
>>>>>> not agree with my predictions, but my predictions are
>>>>>> nevertheless correct" ?
>>>>>
>>>>>
>>>>> In programming language theory, semantics is the field concerned
>>>>> with the rigorous mathematical study of the meaning of programming
>>>>> languages.[1] It does so by evaluating the meaning of
>>>>> syntactically valid strings defined by a specific programming
>>>>> language, showing the computation involved. In such a case that
>>>>> the evaluation would be of syntactically invalid strings, the
>>>>> result would be non-computation. Semantics describes the
>>>>> processes a computer follows when executing a program in that
>>>>> specific language.
>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>
>>>>> The code proves that the correctly simulated input would never
>>>>> reach its "return" instruction.
>>>>>
>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>> The correct execution trace of the correctly simulated input to
>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>> Humans having sufficient technical knowledge can see this and H
>>>> can see this. To say that I am incorrect based on not having
>>>> having sufficient technical knowledge is both incorrect and rude.
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> So, if you are honest, you should say H(P,P)=undecidable (cannot
>>> possibly reach its "return" instruction)
>>
>> If I am honest and technically correct I say that the correctly
>> simulated input to H(P,P) cannot possibly reach its "return"
>> instruction and H correctly rejects its input as non-halting on that
>> basis.
>
> Such a mapping is incorrect so you are incorrect on that basis.

That is the same as saying 2 + 3 != 5

> Your H
> aborting because it is designed incorrectly (as it is recursive in
> nature) is definitely a case of "undecidable" rather than
> input being "non-halting".
>
> /Flibble
>

--
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 7/23/22 10:27 AM, olcott wrote:
> On 7/23/2022 8:30 AM, olcott wrote:
>> On 7/23/2022 8:11 AM, Paul N wrote:
>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>> THIS IS PROVABLY TRUE
>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>> never halts no matter what. The directly executed P(P) specifies an
>>>> entirely different sequence of instructions.
>>>
>>> You realise this is essentially the same as saying "Reality does not
>>> agree with my predictions, but my predictions are nevertheless
>>> correct" ?
>>
>>
>> In programming language theory, semantics is the field concerned with
>> the rigorous mathematical study of the meaning of programming
>> languages.[1] It does so by evaluating the meaning of syntactically
>> valid strings defined by a specific programming language, showing the
>> computation involved. In such a case that the evaluation would be of
>> syntactically invalid strings, the result would be non-computation.
>> Semantics describes the processes a computer follows when executing a
>> program in that specific language.
>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>
>> The code proves that the correctly simulated input would never reach
>> its "return" instruction.
>>
>
> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> The correct execution trace of the correctly simulated input to H(P,P)
> conclusively proves that the simulated P cannot possibly reach its
> "return" instruction.
>
> Humans having sufficient technical knowledge can see this and H can see
> this. To say that I am incorrect based on not having having sufficient
> technical knowledge is both incorrect and rude.
>

No, because your proof isn't correct, even if you think it is.

Actually, it is more like you claiming that 1 + 1 is 11, because you
wrote a program that did:

print("1" + "1")

and it said 11, so it must be right. (Not C, but other higher level
languages)

The errors have been pointed out, and you have ignored them, not even
trying to come up with a rebuttal, but just saying they must be wrong
because you disagree with them.

All you have done is proved your inability to understand the basics of
logic.

On 7/23/2022 10:27 AM, Richard Damon wrote:
> On 7/23/22 10:27 AM, olcott wrote:
>> On 7/23/2022 8:30 AM, olcott wrote:
>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>> THIS IS PROVABLY TRUE
>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>> entirely different sequence of instructions.
>>>>
>>>> You realise this is essentially the same as saying "Reality does not
>>>> agree with my predictions, but my predictions are nevertheless
>>>> correct" ?
>>>
>>>
>>> In programming language theory, semantics is the field concerned with
>>> the rigorous mathematical study of the meaning of programming
>>> languages.[1] It does so by evaluating the meaning of syntactically
>>> valid strings defined by a specific programming language, showing the
>>> computation involved. In such a case that the evaluation would be of
>>> syntactically invalid strings, the result would be non-computation.
>>> Semantics describes the processes a computer follows when executing a
>>> program in that specific language.
>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>
>>> The code proves that the correctly simulated input would never reach
>>> its "return" instruction.
>>>
>>
>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>> The correct execution trace of the correctly simulated input to H(P,P)
>> conclusively proves that the simulated P cannot possibly reach its
>> "return" instruction.
>>
>> Humans having sufficient technical knowledge can see this and H can
>> see this. To say that I am incorrect based on not having having
>> sufficient technical knowledge is both incorrect and rude.
>>
>
> No, because your proof isn't correct, even if you think it is.
>
That you say that I am wrong on the basis that you do not know that the
semantics of the x86 language proves that I am correct causes me to
ignore almost all of your posts.

--
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 7/23/22 11:30 AM, olcott wrote:
> On 7/23/2022 10:27 AM, Richard Damon wrote:
>> On 7/23/22 10:27 AM, olcott wrote:
>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>> THIS IS PROVABLY TRUE
>>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>>> entirely different sequence of instructions.
>>>>>
>>>>> You realise this is essentially the same as saying "Reality does
>>>>> not agree with my predictions, but my predictions are nevertheless
>>>>> correct" ?
>>>>
>>>>
>>>> In programming language theory, semantics is the field concerned
>>>> with the rigorous mathematical study of the meaning of programming
>>>> languages.[1] It does so by evaluating the meaning of syntactically
>>>> valid strings defined by a specific programming language, showing
>>>> the computation involved. In such a case that the evaluation would
>>>> be of syntactically invalid strings, the result would be
>>>> non-computation. Semantics describes the processes a computer
>>>> follows when executing a program in that specific language.
>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>
>>>> The code proves that the correctly simulated input would never reach
>>>> its "return" instruction.
>>>>
>>>
>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>> The correct execution trace of the correctly simulated input to
>>> H(P,P) conclusively proves that the simulated P cannot possibly reach
>>> its "return" instruction.
>>>
>>> Humans having sufficient technical knowledge can see this and H can
>>> see this. To say that I am incorrect based on not having having
>>> sufficient technical knowledge is both incorrect and rude.
>>>
>>
>> No, because your proof isn't correct, even if you think it is.
>>
> That you say that I am wrong on the basis that you do not know that the
> semantics of the x86 language proves that I am correct causes me to
> ignore almost all of your posts.
> LIAR!

I have pointed out errors in the proofs that you just won't make an
effort to rebut, implying that you have no reasoning to handle the
errors pointed out.

You have NO actual proof of your claims, and just are throwing out
worthless statements to try to stroke your ego. You are really just an
idiot.

WHAT in the x86 language proves your claim?

P(P) Halts, it halts when you trace the EXACT x86 instruction that make
up the code you claim. THIS IS FACT.

In fact, you proof disagrees with this behavior and shows you don't
understand how computers actually work.

You have claimed that the exact same instructions using the exact same
input data can give different results. That just shows you don't know
what you are talking about.

LOOK at your claimed proof. It doesn't ACTUALLY use details of the
things it claims to, but trys to make the claim that you can replace a
call to H with a rule based on a behavior of H that it doesn't actually
have.

That just shows you fail to understand the very basics of logic.

On 7/23/2022 10:47 AM, Richard Damon wrote:
> On 7/23/22 11:30 AM, olcott wrote:
>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>> On 7/23/22 10:27 AM, olcott wrote:
>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>> THIS IS PROVABLY TRUE
>>>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>>>> entirely different sequence of instructions.
>>>>>>
>>>>>> You realise this is essentially the same as saying "Reality does
>>>>>> not agree with my predictions, but my predictions are nevertheless
>>>>>> correct" ?
>>>>>
>>>>>
>>>>> In programming language theory, semantics is the field concerned
>>>>> with the rigorous mathematical study of the meaning of programming
>>>>> languages.[1] It does so by evaluating the meaning of syntactically
>>>>> valid strings defined by a specific programming language, showing
>>>>> the computation involved. In such a case that the evaluation would
>>>>> be of syntactically invalid strings, the result would be
>>>>> non-computation. Semantics describes the processes a computer
>>>>> follows when executing a program in that specific language.
>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>
>>>>> The code proves that the correctly simulated input would never
>>>>> reach its "return" instruction.
>>>>>
>>>>
>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>> The correct execution trace of the correctly simulated input to
>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>> Humans having sufficient technical knowledge can see this and H can
>>>> see this. To say that I am incorrect based on not having having
>>>> sufficient technical knowledge is both incorrect and rude.
>>>>
>>>
>>> No, because your proof isn't correct, even if you think it is.
>>>
>> That you say that I am wrong on the basis that you do not know that
>> the semantics of the x86 language proves that I am correct causes me
>> to ignore almost all of your posts.
>>
>
> I have pointed out errors in the proofs that you just won't make an
> effort to rebut,

That is another thing that you do.
I make one point and then you change the subject as your rebuttal.

https://en.wikipedia.org/wiki/Semantics_(computer_science)

I am only referring to the fact that the semantics of the x86 language
conclusively proves that the correctly simulated input to H(P,P) cannot
possibly ever reach the "return" instruction of P.

--
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 7/23/22 12:05 PM, olcott wrote:
> On 7/23/2022 10:47 AM, Richard Damon wrote:
>> On 7/23/22 11:30 AM, olcott wrote:
>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>> I am only referring to the correctly simulated input to H(P,P) that
>>>>>>>> never halts no matter what. The directly executed P(P) specifies an
>>>>>>>> entirely different sequence of instructions.
>>>>>>>
>>>>>>> You realise this is essentially the same as saying "Reality does
>>>>>>> not agree with my predictions, but my predictions are
>>>>>>> nevertheless correct" ?
>>>>>>
>>>>>>
>>>>>> In programming language theory, semantics is the field concerned
>>>>>> with the rigorous mathematical study of the meaning of programming
>>>>>> languages.[1] It does so by evaluating the meaning of
>>>>>> syntactically valid strings defined by a specific programming
>>>>>> language, showing the computation involved. In such a case that
>>>>>> the evaluation would be of syntactically invalid strings, the
>>>>>> result would be non-computation. Semantics describes the processes
>>>>>> a computer follows when executing a program in that specific
>>>>>> language.
>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>
>>>>>> The code proves that the correctly simulated input would never
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>
>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>> The correct execution trace of the correctly simulated input to
>>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>>> reach its "return" instruction.
>>>>>
>>>>> Humans having sufficient technical knowledge can see this and H can
>>>>> see this. To say that I am incorrect based on not having having
>>>>> sufficient technical knowledge is both incorrect and rude.
>>>>>
>>>>
>>>> No, because your proof isn't correct, even if you think it is.
>>>>
>>> That you say that I am wrong on the basis that you do not know that
>>> the semantics of the x86 language proves that I am correct causes me
>>> to ignore almost all of your posts.
>>>
>>
>> I have pointed out errors in the proofs that you just won't make an
>> effort to rebut,
>
> That is another thing that you do.
> I make one point and then you change the subject as your rebuttal.

How is pointing out an error in your proof a change of subject?

>
> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>
> I am only referring to the fact that the semantics of the x86 language
> conclusively proves that the correctly simulated input to H(P,P) cannot
> possibly ever reach the "return" instruction of P.
>
>

What semantics of the x86 language prove this?

Note, you begin with wrong definitions.

Halting is DEFINED based on the actual operation of the machine.

You can only replace that with a simulation that exact replicates the
FULL behavior of that machine. That mean the simulation needs to be
correct and complete.

If H aborts its simulation, it does not do a correct and complete
simulation of its input, so this simulation doesn't actually show
non-halting.

The only H you have ever shown that does a actual correct and complete
simualtion is your hypothetical version that never aborts. Yes for THAT
version of H, you can show that P(P) is non-halting, but the H that does
that never reports that answer, so isn't a decider.

To consider that P is calling that H when a different H is deciding just
proves you don't understand the basic symantics of the problem.

Since showing that H never reaches the return instruction when H has
aborted its simulation doesn't prove anything, your initial problem
statement is shown to be incorrect.

You can't look at the simulation done by H, but by your statement need
to look at the simulation done by an actual correct and complete
simulator, and that does show that P(P) and the correct and complete
simulation of the input to H(P,P) will reach the return instruction if
H(P.P) ever returns 0.

It should be noted that in your logic, your replace the full behavior of
the call H and following code, NOT by the actual behavior of the x86
code that is present, but by logic that presumes behavior of H that
isn't the actual behavior of H. You logic presumes H will
unconditionally simulate its input and not stop it, when in fact it will
stop its simulation.

This can be seen if we actually simulate this input with a real
unconditional simulator (keeping the input the same so it calls the H
that does the aborting), and look at the ACTUAL behavior of the x86 code
of H, not some incorrect "approximate" model of it.

This is NOT changing the subject, but showing the fundamental errors in
you logic.

If you don't understand that, I am sorry that you are that stupid.

On 7/23/2022 11:23 AM, Richard Damon wrote:
>
> On 7/23/22 12:05 PM, olcott wrote:
>> On 7/23/2022 10:47 AM, Richard Damon wrote:
>>> On 7/23/22 11:30 AM, olcott wrote:
>>>> On 7/23/2022 10:27 AM, Richard Damon wrote:
>>>>> On 7/23/22 10:27 AM, olcott wrote:
>>>>>> On 7/23/2022 8:30 AM, olcott wrote:
>>>>>>> On 7/23/2022 8:11 AM, Paul N wrote:
>>>>>>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
>>>>>>>>> THIS IS PROVABLY TRUE
>>>>>>>>> I am only referring to the correctly simulated input to H(P,P)
>>>>>>>>> that
>>>>>>>>> never halts no matter what. The directly executed P(P)
>>>>>>>>> specifies an
>>>>>>>>> entirely different sequence of instructions.
>>>>>>>>
>>>>>>>> You realise this is essentially the same as saying "Reality does
>>>>>>>> not agree with my predictions, but my predictions are
>>>>>>>> nevertheless correct" ?
>>>>>>>
>>>>>>>
>>>>>>> In programming language theory, semantics is the field concerned
>>>>>>> with the rigorous mathematical study of the meaning of
>>>>>>> programming languages.[1] It does so by evaluating the meaning of
>>>>>>> syntactically valid strings defined by a specific programming
>>>>>>> language, showing the computation involved. In such a case that
>>>>>>> the evaluation would be of syntactically invalid strings, the
>>>>>>> result would be non-computation. Semantics describes the
>>>>>>> processes a computer follows when executing a program in that
>>>>>>> specific language.
>>>>>>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
>>>>>>>
>>>>>>> The code proves that the correctly simulated input would never
>>>>>>> reach its "return" instruction.
>>>>>>>
>>>>>>
>>>>>> It is like I am saying 2 + 3 = 5 and everyone disagrees.
>>>>>> The correct execution trace of the correctly simulated input to
>>>>>> H(P,P) conclusively proves that the simulated P cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>> Humans having sufficient technical knowledge can see this and H
>>>>>> can see this. To say that I am incorrect based on not having
>>>>>> having sufficient technical knowledge is both incorrect and rude.
>>>>>>
>>>>>
>>>>> No, because your proof isn't correct, even if you think it is.
>>>>>
>>>> That you say that I am wrong on the basis that you do not know that
>>>> the semantics of the x86 language proves that I am correct causes me
>>>> to ignore almost all of your posts.
>>>>
>>>
>>> I have pointed out errors in the proofs that you just won't make an
>>> effort to rebut,
>>
>> That is another thing that you do.
>> I make one point and then you change the subject as your rebuttal.
>
> How is pointing out an error in your proof a change of subject?
>

I claim that X is true and your rebuttal is that you believe that Y is
false.

https://en.wikipedia.org/wiki/Semantics_(computer_science)

I am only referring to the fact that the semantics of the x86 language
conclusively proves that the correctly simulated input to H(P,P) by H
cannot possibly ever reach the "return" instruction of P.

The only relevant rebuttal is a step-by-step proof showing line-by-line
of the source-code of P exactly how H diverges from its correct x86
emulation of its input.

This is your last chance before I won't even glance at your messages for
a long time.

--
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 Saturday, 23 July 2022 at 17:30:12 UTC+2, olcott wrote:
> On 7/23/2022 10:27 AM, Richard Damon wrote:
> > On 7/23/22 10:27 AM, olcott wrote:
> >> On 7/23/2022 8:30 AM, olcott wrote:
> >>> On 7/23/2022 8:11 AM, Paul N wrote:
> >>>> On Saturday, July 23, 2022 at 1:54:57 AM UTC+1, olcott wrote:
> >>>>> THIS IS PROVABLY TRUE
> >>>>> I am only referring to the correctly simulated input to H(P,P) that
> >>>>> never halts no matter what. The directly executed P(P) specifies an
> >>>>> entirely different sequence of instructions.
> >>>>
> >>>> You realise this is essentially the same as saying "Reality does not
> >>>> agree with my predictions, but my predictions are nevertheless
> >>>> correct" ?
> >>>
> >>>
> >>> In programming language theory, semantics is the field concerned with
> >>> the rigorous mathematical study of the meaning of programming
> >>> languages.[1] It does so by evaluating the meaning of syntactically
> >>> valid strings defined by a specific programming language, showing the
> >>> computation involved. In such a case that the evaluation would be of
> >>> syntactically invalid strings, the result would be non-computation.
> >>> Semantics describes the processes a computer follows when executing a
> >>> program in that specific language.
> >>> https://en.wikipedia.org/wiki/Semantics_(computer_science)
> >>>
> >>> The code proves that the correctly simulated input would never reach
> >>> its "return" instruction.
> >>>
> >>
> >> It is like I am saying 2 + 3 = 5 and everyone disagrees.
> >> The correct execution trace of the correctly simulated input to H(P,P)
> >> conclusively proves that the simulated P cannot possibly reach its
> >> "return" instruction.
> >>
> >> Humans having sufficient technical knowledge can see this and H can
> >> see this. To say that I am incorrect based on not having having
> >> sufficient technical knowledge is both incorrect and rude.
> >>
> >
> > No, because your proof isn't correct, even if you think it is.
> >
> That you say that I am wrong on the basis that you do not know that the
> semantics of the x86 language proves that I am correct causes me to
> ignore almost all of your posts.

Semantics don't prove anything.

Proof theory (and by implication computational proofs) are strictly about syntax, not semantics.

Model theory is about semantics.

https://en.wikipedia.org/wiki/Proof_theory