I found some of Olcott's papers, notably this one:
https://philpapers.org/archive/OLCDAD-2.pdf
where he says that "true" means "provable" and "false" means "the
inverse is provable".

Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt" and
claim there are some programs which don't halt and don't not halt.

On 1/12/24 16:08, immibis wrote:
> I found some of Olcott's papers, notably this one:
> https://philpapers.org/archive/OLCDAD-2.pdf
> where he says that "true" means "provable" and "false" means "the
> inverse is provable".
>
> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt" and
> claim there are some programs which don't halt and don't not halt.

olcott doesn't even understand what 'halt' means (I tried, he did not
answer). Not only this one, he gets lots of basic meaning of terms wrong
or defined in his way (actually not really defined, because his
definition can change depending on situation, he does not understand
'define' neither).

So, be careful, nothing he says means what is usually meant.

On 1/12/2024 6:23 AM, wij wrote:
> On 1/12/24 16:08, immibis wrote:
>> I found some of Olcott's papers, notably this one:
>> https://philpapers.org/archive/OLCDAD-2.pdf
>> where he says that "true" means "provable" and "false" means "the
>> inverse is provable".
>>
>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>> and claim there are some programs which don't halt and don't not halt.
>
> olcott doesn't even understand what 'halt' means (I tried, he did not
> answer). Not only this one, he gets lots of basic meaning of terms wrong
> or defined in his way (actually not really defined, because his
> definition can change depending on situation, he does not understand
> 'define' neither).
>
> So, be careful, nothing he says means what is usually meant.
>

computation that halts… “the Turing machine will halt whenever it enters
a final state” (Linz:1990:234)

Halting means reaching a final state and terminating normally.

Halting does not mean that the simulated input stops running because its
simulation has been aborted.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

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

On 1/12/2024 2:08 AM, immibis wrote:
> I found some of Olcott's papers, notably this one:
> https://philpapers.org/archive/OLCDAD-2.pdf
> where he says that "true" means "provable" and "false" means "the
> inverse is provable".
>
> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt" and
> claim there are some programs which don't halt and don't not halt.

One of the greatest philosophers of logic agrees that
when P is unprovable in RS then P is simply untrue in RS.
https://www.liarparadox.org/Wittgenstein.pdf

It is a verified fact that D correctly simulated by H cannot possibly
halt. Changing the subject to some other computation is the fallacy of
equivocation error or the strawman error.

A decider must compute the mapping from an input finite string to an
accept or reject state on the basis of a property of this finite string
input. Referring to the properties of non-inputs is not allowed.

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

olcott <polcott2@gmail.com> wrote:
> On 1/12/2024 6:23 AM, wij wrote:
>> On 1/12/24 16:08, immibis wrote:
>>> I found some of Olcott's papers, notably this one:
>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>> where he says that "true" means "provable" and "false" means "the
>>> inverse is provable".

>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>> and claim there are some programs which don't halt and don't not halt..

>> olcott doesn't even understand what 'halt' means (I tried, he did not
>> answer). Not only this one, he gets lots of basic meaning of terms wrong
>> or defined in his way (actually not really defined, because his
>> definition can change depending on situation, he does not understand
>> 'define' neither).

>> So, be careful, nothing he says means what is usually meant.

> computation that halts… “the Turing machine will halt whenever it enters
> a final state” (Linz:1990:234)

> Halting means reaching a final state and terminating normally.

No, it means reaching a final state. Being aborted is such a final
state.

> Halting does not mean that the simulated input stops running because its
> simulation has been aborted.

Where do you get that from? Remember, the theory is about Turing
Machines, and there is no notion of "being aborted" or of terminating
"normally" on a Turing machine. It there were such things, they would
merely be final states.

> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)

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

--
Alan Mackenzie (Nuremberg, Germany).

On 1/12/2024 8:58 AM, acm@muc.de wrote:
> olcott <polcott2@gmail.com> wrote:
>> On 1/12/2024 6:23 AM, wij wrote:
>>> On 1/12/24 16:08, immibis wrote:
>>>> I found some of Olcott's papers, notably this one:
>>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>>> where he says that "true" means "provable" and "false" means "the
>>>> inverse is provable".
>
>>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>>> and claim there are some programs which don't halt and don't not halt.
>
>>> olcott doesn't even understand what 'halt' means (I tried, he did not
>>> answer). Not only this one, he gets lots of basic meaning of terms wrong
>>> or defined in his way (actually not really defined, because his
>>> definition can change depending on situation, he does not understand
>>> 'define' neither).
>
>>> So, be careful, nothing he says means what is usually meant.
>
>
>> computation that halts… “the Turing machine will halt whenever it enters
>> a final state” (Linz:1990:234)
>
>> Halting means reaching a final state and terminating normally.
>
> No, it means reaching a final state. Being aborted is such a final
> state.

01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }

Unless D correctly simulated by H can possibly reach its
own line 06 (final state) it never halts.

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

On 1/12/24 15:57, olcott wrote:
> On 1/12/2024 2:08 AM, immibis wrote:
>> I found some of Olcott's papers, notably this one:
>> https://philpapers.org/archive/OLCDAD-2.pdf
>> where he says that "true" means "provable" and "false" means "the
>> inverse is provable".
>>
>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>> and claim there are some programs which don't halt and don't not halt.
>
> One of the greatest philosophers of logic agrees that
> when P is unprovable in RS then P is simply untrue in RS.

So do you agree that there are some programs which don't halt and don't
not halt?

> https://www.liarparadox.org/Wittgenstein.pdf
>
> It is a verified fact that D correctly simulated by H cannot possibly
> halt. Changing the subject to some other computation is the fallacy of
> equivocation error or the strawman error.
>
> A decider must compute the mapping from an input finite string to an
> accept or reject state on the basis of a property of this finite string
> input.

> Referring to the properties of non-inputs is not allowed.

I don't know what you think this means, but it's wrong. A decider can
think about non-inputs if it's programmed to do that.

The divisible-by-6 decider, that returns 1 when n%6==0, refers to 6,
although 6 is a non-input.

On 1/12/24 17:22, olcott wrote:
> On 1/12/2024 8:58 AM, acm@muc.de wrote:
>> olcott <polcott2@gmail.com> wrote:
>>> On 1/12/2024 6:23 AM, wij wrote:
>>>> On 1/12/24 16:08, immibis wrote:
>>>>> I found some of Olcott's papers, notably this one:
>>>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>>>> where he says that "true" means "provable" and "false" means "the
>>>>> inverse is provable".
>>
>>>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>>>> and claim there are some programs which don't halt and don't not halt.
>>
>>>> olcott doesn't even understand what 'halt' means (I tried, he did not
>>>> answer). Not only this one, he gets lots of basic meaning of terms
>>>> wrong
>>>> or defined in his way (actually not really defined, because his
>>>> definition can change depending on situation, he does not understand
>>>> 'define' neither).
>>
>>>> So, be careful, nothing he says means what is usually meant.
>>
>>
>>> computation that halts… “the Turing machine will halt whenever it enters
>>> a final state” (Linz:1990:234)
>>
>>> Halting means reaching a final state and terminating normally.
>>
>> No, it means reaching a final state.  Being aborted is such a final
>> state.
>
> 01 int D(ptr x)  // ptr is pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
>
> Unless D correctly simulated by H can possibly reach its
> own line 06 (final state) it never halts.
>

it can because H can return 0

On 1/12/2024 10:30 AM, immibis wrote:
> On 1/12/24 15:57, olcott wrote:
>> On 1/12/2024 2:08 AM, immibis wrote:
>>> I found some of Olcott's papers, notably this one:
>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>> where he says that "true" means "provable" and "false" means "the
>>> inverse is provable".
>>>
>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>> and claim there are some programs which don't halt and don't not halt.
>>
>> One of the greatest philosophers of logic agrees that
>> when P is unprovable in RS then P is simply untrue in RS.
>
> So do you agree that there are some programs which don't halt and don't
> not halt?
>
>> https://www.liarparadox.org/Wittgenstein.pdf
>>
>> It is a verified fact that D correctly simulated by H cannot possibly
>> halt. Changing the subject to some other computation is the fallacy of
>> equivocation error or the strawman error.
>>
>> A decider must compute the mapping from an input finite string to an
>> accept or reject state on the basis of a property of this finite string
>> input.
>
>> Referring to the properties of non-inputs is not allowed.
>
> I don't know what you think this means, but it's wrong. A decider can
> think about non-inputs if it's programmed to do that.
>
> The divisible-by-6 decider, that returns 1 when n%6==0, refers to 6,
> although 6 is a non-input.
>
>

There are some decider/input pairs where the question
Does the input halt? has no correct yes/no answer in
the same way that the Liar Paradox is neither true nor false.

This is only the case where the halting problem contradicts
the definition of a decider that is required to compute the
mapping on the basis of a property of its input finite string
to its own accept or reject state.

The directly executed D(D) *IS NOT an input to H* It has
entirely different behavior than D correctly simulated by H
of the actual input.

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

On 1/12/2024 10:38 AM, immibis wrote:
> On 1/12/24 17:22, olcott wrote:
>> On 1/12/2024 8:58 AM, acm@muc.de wrote:
>>> olcott <polcott2@gmail.com> wrote:
>>>> On 1/12/2024 6:23 AM, wij wrote:
>>>>> On 1/12/24 16:08, immibis wrote:
>>>>>> I found some of Olcott's papers, notably this one:
>>>>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>>>>> where he says that "true" means "provable" and "false" means "the
>>>>>> inverse is provable".
>>>
>>>>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>>>>> and claim there are some programs which don't halt and don't not
>>>>>> halt.
>>>
>>>>> olcott doesn't even understand what 'halt' means (I tried, he did not
>>>>> answer). Not only this one, he gets lots of basic meaning of terms
>>>>> wrong
>>>>> or defined in his way (actually not really defined, because his
>>>>> definition can change depending on situation, he does not understand
>>>>> 'define' neither).
>>>
>>>>> So, be careful, nothing he says means what is usually meant.
>>>
>>>
>>>> computation that halts… “the Turing machine will halt whenever it
>>>> enters
>>>> a final state” (Linz:1990:234)
>>>
>>>> Halting means reaching a final state and terminating normally.
>>>
>>> No, it means reaching a final state.  Being aborted is such a final
>>> state.
>>
>> 01 int D(ptr x)  // ptr is pointer to int function
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>>
>> Unless D correctly simulated by H can possibly reach its
>> own line 06 (final state) it never halts.
>>
>
> it can because H can return 0

You must not be very good at software engineering if
you believe that D correctly simulated by H can return
any value to the simulated D.

What programming languages are you an expert of?
If the answer is {none} that explains your confusion.

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

On 1/12/24 11:38 AM, olcott wrote:
> On 1/12/2024 10:30 AM, immibis wrote:
>> On 1/12/24 15:57, olcott wrote:
>>> On 1/12/2024 2:08 AM, immibis wrote:
>>>> I found some of Olcott's papers, notably this one:
>>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>>> where he says that "true" means "provable" and "false" means "the
>>>> inverse is provable".
>>>>
>>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>>> and claim there are some programs which don't halt and don't not halt.
>>>
>>> One of the greatest philosophers of logic agrees that
>>> when P is unprovable in RS then P is simply untrue in RS.
>>
>> So do you agree that there are some programs which don't halt and
>> don't not halt?
>>
>>> https://www.liarparadox.org/Wittgenstein.pdf
>>>
>>> It is a verified fact that D correctly simulated by H cannot possibly
>>> halt. Changing the subject to some other computation is the fallacy of
>>> equivocation error or the strawman error.
>>>
>>> A decider must compute the mapping from an input finite string to an
>>> accept or reject state on the basis of a property of this finite string
>>> input.
>>
>>> Referring to the properties of non-inputs is not allowed.
>>
>> I don't know what you think this means, but it's wrong. A decider can
>> think about non-inputs if it's programmed to do that.
>>
>> The divisible-by-6 decider, that returns 1 when n%6==0, refers to 6,
>> although 6 is a non-input.
>>
>>
>
> There are some decider/input pairs where the question
> Does the input halt? has no correct yes/no answer in
> the same way that the Liar Paradox is neither true nor false.

Except that you have admtted that you "decider/input" pair that you are
talking about aren't actually programs.

You miss that for ever one of those decider/input pairs, there WAS a
correct answer, it just wasn't the one the decider gave.

There is no requirement that a given program can give the corrct answer
to every input

>
> This is only the case where the halting problem contradicts
> the definition of a decider that is required to compute the
> mapping on the basis of a property of its input finite string
> to its own accept or reject state.

But when you actually encode as actual programs and inputs, which one
doesn't have a correct mapping for the actual definition of Halting?

The input will represent a machine that halts, or not.

Thus there is a CORRECT answer, and thus a valid mapping.

Its just that the claimed decider that input was built on turns out to
not give the right answer, and thus shown not to be a correct decider.

>
> The directly executed D(D) *IS NOT an input to H* It has
> entirely different behavior than D correctly simulated by H
> of the actual input.
>

No, but it is the PROPERTY of the input to be decided on.

And that behavior is the behavior that a Correct Simulation of the input
will generate. The fact that H doesn't do that shows H is just not correct.

You are just proving you don't understand the meaning of the word "Correcct"

On 1/12/24 9:57 AM, olcott wrote:
> On 1/12/2024 2:08 AM, immibis wrote:
>> I found some of Olcott's papers, notably this one:
>> https://philpapers.org/archive/OLCDAD-2.pdf
>> where he says that "true" means "provable" and "false" means "the
>> inverse is provable".
>>
>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>> and claim there are some programs which don't halt and don't not halt.
>
> One of the greatest philosophers of logic agrees that
> when P is unprovable in RS then P is simply untrue in RS.
> https://www.liarparadox.org/Wittgenstein.pdf

Fallacy of proof by Authority.

>
> It is a verified fact that D correctly simulated by H cannot possibly
> halt. Changing the subject to some other computation is the fallacy of
> equivocation error or the strawman error.

It is a verified fact that an H that correct simulates its D will never
answer, and is thus not a decider.

>
> A decider must compute the mapping from an input finite string to an
> accept or reject state on the basis of a property of this finite string
> input. Referring to the properties of non-inputs is not allowed.
>

But the behavior of the program the finite-string represents IS a
property of that input.

You are trying to remove semantics from the system.

On 1/12/24 1:53 PM, olcott wrote:
> On 1/12/2024 10:38 AM, immibis wrote:
>> On 1/12/24 17:22, olcott wrote:
>>> On 1/12/2024 8:58 AM, acm@muc.de wrote:
>>>> olcott <polcott2@gmail.com> wrote:
>>>>> On 1/12/2024 6:23 AM, wij wrote:
>>>>>> On 1/12/24 16:08, immibis wrote:
>>>>>>> I found some of Olcott's papers, notably this one:
>>>>>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>>>>>> where he says that "true" means "provable" and "false" means "the
>>>>>>> inverse is provable".
>>>>
>>>>>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>>>>>> and claim there are some programs which don't halt and don't not
>>>>>>> halt.
>>>>
>>>>>> olcott doesn't even understand what 'halt' means (I tried, he did not
>>>>>> answer). Not only this one, he gets lots of basic meaning of terms
>>>>>> wrong
>>>>>> or defined in his way (actually not really defined, because his
>>>>>> definition can change depending on situation, he does not understand
>>>>>> 'define' neither).
>>>>
>>>>>> So, be careful, nothing he says means what is usually meant.
>>>>
>>>>
>>>>> computation that halts… “the Turing machine will halt whenever it
>>>>> enters
>>>>> a final state” (Linz:1990:234)
>>>>
>>>>> Halting means reaching a final state and terminating normally.
>>>>
>>>> No, it means reaching a final state.  Being aborted is such a final
>>>> state.
>>>
>>> 01 int D(ptr x)  // ptr is pointer to int function
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>>
>>> Unless D correctly simulated by H can possibly reach its
>>> own line 06 (final state) it never halts.
>>>
>>
>> it can because H can return 0
>
> You must not be very good at software engineering if
> you believe that D correctly simulated by H can return
> any value to the simulated D.
>
> What programming languages are you an expert of?
> If the answer is {none} that explains your confusion.
>

And you have failed at your software endineering if you think that an H
that DOES correctly simulate this input can ever answer the question and
be a correct decider.

An H can only answer based on a correct simulation if it isn't the H
that D was built on, since your assumption was that the H that D was
built on doesn't abort its simulaition.

You seem to forget the fundamental nature of programs that they do what
they are programmed to do, and don't have free-will to actually make a
free determination of what they will do.

On 1/12/24 11:22 AM, olcott wrote:
> On 1/12/2024 8:58 AM, acm@muc.de wrote:
>> olcott <polcott2@gmail.com> wrote:
>>> On 1/12/2024 6:23 AM, wij wrote:
>>>> On 1/12/24 16:08, immibis wrote:
>>>>> I found some of Olcott's papers, notably this one:
>>>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>>>> where he says that "true" means "provable" and "false" means "the
>>>>> inverse is provable".
>>
>>>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>>>> and claim there are some programs which don't halt and don't not halt.
>>
>>>> olcott doesn't even understand what 'halt' means (I tried, he did not
>>>> answer). Not only this one, he gets lots of basic meaning of terms
>>>> wrong
>>>> or defined in his way (actually not really defined, because his
>>>> definition can change depending on situation, he does not understand
>>>> 'define' neither).
>>
>>>> So, be careful, nothing he says means what is usually meant.
>>
>>
>>> computation that halts… “the Turing machine will halt whenever it enters
>>> a final state” (Linz:1990:234)
>>
>>> Halting means reaching a final state and terminating normally.
>>
>> No, it means reaching a final state.  Being aborted is such a final
>> state.
>
> 01 int D(ptr x)  // ptr is pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
>
> Unless D correctly simulated by H can possibly reach its
> own line 06 (final state) it never halts.
>

Except to BE a machine, D is built on a SPECIFIC H, and if that H aborts
its simulation, that H doesn't do a "Correct Simulation"

The ACTUAL correct simulation, as done by H1, IS *THE* correct
simulatoin, and shows it reachs the final state.

All you have done is proven the thing you are trying to refute, that we
can not create an H that gets the right answer to the input built on itself.

The Halting Question for that Input does have a correct answer, it just
isn't given by H.

On 1/12/24 9:42 AM, olcott wrote:
> On 1/12/2024 6:23 AM, wij wrote:
>> On 1/12/24 16:08, immibis wrote:
>>> I found some of Olcott's papers, notably this one:
>>> https://philpapers.org/archive/OLCDAD-2.pdf
>>> where he says that "true" means "provable" and "false" means "the
>>> inverse is provable".
>>>
>>> Olcott apparently rejects the fact "P(I) halts or P(I) doesn't halt"
>>> and claim there are some programs which don't halt and don't not halt.
>>
>> olcott doesn't even understand what 'halt' means (I tried, he did not
>> answer). Not only this one, he gets lots of basic meaning of terms wrong
>> or defined in his way (actually not really defined, because his
>> definition can change depending on situation, he does not understand
>> 'define' neither).
>>
>> So, be careful, nothing he says means what is usually meant.
>>
>
> computation that halts… “the Turing machine will halt whenever it enters
> a final state” (Linz:1990:234)
>
> Halting means reaching a final state and terminating normally.
>
> Halting does not mean that the simulated input stops running because its
> simulation has been aborted.

And it doesn't mean that it doesn't happen just because the simulator
gave up.

The machine continues to run, and if the machine will reach the final
state, it halts.

You can't "pull the plug" on a Turing Machine, or a "Correct Simulation"
(since to be correct, it needs to do what the machine did, and if the
machine didn't stop running, neither does the correct simulation).

>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>

On 1/12/24 19:53, olcott wrote:
> On 1/12/2024 10:38 AM, immibis wrote:
>>
>> it can because H can return 0
>
> You must not be very good at software engineering if
> you believe that D correctly simulated by H can return
> any value to the simulated D.

You must not be very good at software engineering if you think a correct
simulation can behave differently from a direct execution.

On 1/12/24 17:38, olcott wrote:
>
> There are some decider/input pairs where the question
> Does the input halt? has no correct yes/no answer

int H(ptr x, ptr y) {
begin_simulation(x, y);
abort_simulation();
return 0;
}

Every input that halts is incorrect to this decider and has no correct
yes/no answer

On 1/13/2024 6:10 AM, immibis wrote:
> On 1/12/24 19:53, olcott wrote:
>> On 1/12/2024 10:38 AM, immibis wrote:
>>>
>>> it can because H can return 0
>>
>> You must not be very good at software engineering if
>> you believe that D correctly simulated by H can return
>> any value to the simulated D.
>
> You must not be very good at software engineering if you think a correct
> simulation can behave differently from a direct execution.

01 int D(ptr x) // ptr is pointer to int function
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }

It is an easily verified fact the D correctly simulated by H
cannot possibly reach its own line 06 and terminate normally.

*NO AMOUNT OF BLUSTER OR DISHONEST DODGE CAN POSSIBLY AVOID THIS*

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

On 1/13/2024 6:20 AM, immibis wrote:
> On 1/12/24 17:38, olcott wrote:
>>
>> There are some decider/input pairs where the question
>> Does the input halt? has no correct yes/no answer
>
> int H(ptr x, ptr y) {
>     begin_simulation(x, y);
>     abort_simulation();
>     return 0;
> }
>
> Every input that halts is incorrect to this decider and has no correct
> yes/no answer

if begin_simulation(D, D) only simulates D
then abort_simulation() is never reached.

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

On 1/13/24 11:43 AM, olcott wrote:
> On 1/13/2024 6:10 AM, immibis wrote:
>> On 1/12/24 19:53, olcott wrote:
>>> On 1/12/2024 10:38 AM, immibis wrote:
>>>>
>>>> it can because H can return 0
>>>
>>> You must not be very good at software engineering if
>>> you believe that D correctly simulated by H can return
>>> any value to the simulated D.
>>
>> You must not be very good at software engineering if you think a
>> correct simulation can behave differently from a direct execution.
>
> 01 int D(ptr x)  // ptr is pointer to int function
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
>
> It is an easily verified fact the D correctly simulated by H
> cannot possibly reach its own line 06 and terminate normally.
>
> *NO AMOUNT OF BLUSTER OR DISHONEST DODGE CAN POSSIBLY AVOID THIS*
>

It is an easily verified fact that no H that actually correctly
simulates its input D ever answers.

So, H isn't a decider.

The H that answers, didn't do a correct simulation of its exact input,
and thus fails to be your H and your whole world just blew itself up.

On 1/13/24 17:47, olcott wrote:
> On 1/13/2024 6:20 AM, immibis wrote:
>> On 1/12/24 17:38, olcott wrote:
>>>
>>> There are some decider/input pairs where the question
>>> Does the input halt? has no correct yes/no answer
>>
>> int H(ptr x, ptr y) {
>>      begin_simulation(x, y);
>>      abort_simulation();
>>      return 0;
>> }
>>
>> Every input that halts is incorrect to this decider and has no correct
>> yes/no answer
>
> if begin_simulation(D, D) only simulates D
> then abort_simulation() is never reached.
>
begin_simulation only begins the simulation.

On 1/14/2024 12:15 PM, immibis wrote:
> On 1/13/24 17:47, olcott wrote:
>> On 1/13/2024 6:20 AM, immibis wrote:
>>> On 1/12/24 17:38, olcott wrote:
>>>>
>>>> There are some decider/input pairs where the question
>>>> Does the input halt? has no correct yes/no answer
>>>
>>> int H(ptr x, ptr y) {
>>>      begin_simulation(x, y);
>>>      abort_simulation();
>>>      return 0;
>>> }
>>>
>>> Every input that halts is incorrect to this decider and has no
>>> correct yes/no answer
>>
>> if begin_simulation(D, D) only simulates D
>> then abort_simulation() is never reached.
>>
> begin_simulation only begins the simulation.

I cannot correctly guess what your functions do.

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

On 1/14/24 19:29, olcott wrote:
> On 1/14/2024 12:15 PM, immibis wrote:
>> On 1/13/24 17:47, olcott wrote:
>>> On 1/13/2024 6:20 AM, immibis wrote:
>>>> On 1/12/24 17:38, olcott wrote:
>>>>>
>>>>> There are some decider/input pairs where the question
>>>>> Does the input halt? has no correct yes/no answer
>>>>
>>>> int H(ptr x, ptr y) {
>>>>      begin_simulation(x, y);
>>>>      abort_simulation();
>>>>      return 0;
>>>> }
>>>>
>>>> Every input that halts is incorrect to this decider and has no
>>>> correct yes/no answer
>>>
>>> if begin_simulation(D, D) only simulates D
>>> then abort_simulation() is never reached.
>>>
>> begin_simulation only begins the simulation.
>
> I cannot correctly guess what your functions do.
>
I named them begin_simulation and abort_simulation so you could guess
they begin the simulation and abort the simulation. If I wanted to make
them unguessable, I would have called them f1 and f2.