On Friday, April 7, 2023 at 5:00:34 AM UTC+10, olcott wrote:
> On 4/6/2023 11:47 AM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 2:40:39 AM UTC+10, olcott wrote:
> >> On 4/6/2023 11:16 AM, Graham Cooper wrote:
> >>> On Friday, April 7, 2023 at 2:10:02 AM UTC+10, olcott wrote:
> >>>> On 4/6/2023 9:56 AM, Graham Cooper wrote:
> >>>>> like BOLT is the fastest runner
> >>>>>
> >>>>> OLD-COOT with GOD COMPLEX
> >>>>> never halts arguing with
> >>>>> DAMON
> >>>>>
> >>>>> GOD - VS- DAMON haha
> >>>>>
> >>>>> will it ever end....
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Your BOTH wrong!
> >>>>>
> >>>>>
> >>>>> ============================================================
> >>>>> does a function exist that given a ( program identifier and input ) as input
> >>>>> RETURNS *halts* or *loops* correctly
> >>>>>
> >>>>> NO
> >>>>> ============================================================
> >>>>> does a function exist that given a ( program identifier and input ) as input
> >>>>> PRINTS *halts* or *loops* correctly
> >>>>>
> >>>>> YES
> >>>>> ============================================================
> >>>>>
> >>>>>
> >>>>> PROGRAM C
> >>>>> 10 IF INF-LOOPS(C) BREAK
> >>>>> 20 GOTO 20
> >>>>>
> >>>>> PROGRAM INF-LOOPS(C)
> >>>>> 10 IF BAD(C) PRINT *HALTS*
> >>>>> 20 RETURN *LOOPS*
> >>>>>
> >>>>>
> >>>>>
> >>>>> INF-LOOPS ALWAYS gets it right!
> >>>>>
> >>>>> PROGRAM C cannot even SEE what INF-LOOPS prints
> >>>>> so how can it trick it?
> >>>> Perhaps like many of my reviewers you simply don't understand these
> >>>> things very well.
> >>>>
> >>>> 01 int D(int (*x)())
> >>>> 02 {
> >>>> 03 int Halt_Status = H(x, x);
> >>>> 04 if (Halt_Status)
> >>>> 05 HERE: goto HERE;
> >>>> 06 return Halt_Status;
> >>>> 07 }
> >>>> 08
> >>>> 09 void main()
> >>>> 10 {
> >>>> 11 H(D,D);
> >>>> 12 }
> >>>>
> >>>> D correctly simulated by H cannot possibly reach its own line 6 and halt
> >>>>
> >>>> main() calls H(D,D) that simulates D(D) at line 11
> >>>> keeps repeating: simulated D(D) calls simulated H(D,D) that simulates
> >>>> D(D) at line 03 ...
> >>>>
> >>>> computation that halts… “the Turing machine will halt whenever it enters
> >>>> a final state” (Linz:1990:234)
> >>>>
> >>>> When H(D,D) returns 0 it is merely affirming the verified fact that D
> >>>> correctly simulated by H cannot possibly reach its own last instruction
> >>>> (final state) at line 6 and halt.
> >>>>
> >>>>
> >>>> H and D are fully operational in the x86utm operating system:
> >>>> https://github.com/plolcott/x86utm
> >>>>
> >>>
> >>>
> >>> I think your half right but HALT *d e t e r m i n e s* a halt value of a given function
> >>> it doesnt have to *s i m u l a t e* anything.
> >>>
> >> After 12 years of research (2004-2016) I discovered that when H is a
> >> simulating halt decider then every halting problem counter-example
> >> template presents recursive simulation to its corresponding halt
> >> decider. [simulating halt decider] is proven to be my idea.
> >
> > sorry Pete but degerming whether a program halts has virtually NOTHING to do with simulation
> >
> Although it is not required that H be a simulating halt decider, unless
> H is a simulating halt decider H never has enough information to
> determine the halt status of D.

Rubbish! We did 100 proofs of termination.

Just calculate the LOOP INVARIANT and EXIT CONDITION

and solve simultaneous equations.

In fact, simulation NEVER WORKS for any program that infinite loops

So your HALT SPECIFICATION is

HALT(P I) = *halts*
if simulated long enuff

you NEVER GET

HALT(P I) = *loops*

so you only have HALF a function

On 4/6/2023 5:37 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 5:00:34 AM UTC+10, olcott wrote:
>> On 4/6/2023 11:47 AM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 2:40:39 AM UTC+10, olcott wrote:
>>>> On 4/6/2023 11:16 AM, Graham Cooper wrote:
>>>>> On Friday, April 7, 2023 at 2:10:02 AM UTC+10, olcott wrote:
>>>>>> On 4/6/2023 9:56 AM, Graham Cooper wrote:
>>>>>>> like BOLT is the fastest runner
>>>>>>>
>>>>>>> OLD-COOT with GOD COMPLEX
>>>>>>> never halts arguing with
>>>>>>> DAMON
>>>>>>>
>>>>>>> GOD - VS- DAMON haha
>>>>>>>
>>>>>>> will it ever end....
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Your BOTH wrong!
>>>>>>>
>>>>>>>
>>>>>>> ============================================================
>>>>>>> does a function exist that given a ( program identifier and input ) as input
>>>>>>> RETURNS *halts* or *loops* correctly
>>>>>>>
>>>>>>> NO
>>>>>>> ============================================================
>>>>>>> does a function exist that given a ( program identifier and input ) as input
>>>>>>> PRINTS *halts* or *loops* correctly
>>>>>>>
>>>>>>> YES
>>>>>>> ============================================================
>>>>>>>
>>>>>>>
>>>>>>> PROGRAM C
>>>>>>> 10 IF INF-LOOPS(C) BREAK
>>>>>>> 20 GOTO 20
>>>>>>>
>>>>>>> PROGRAM INF-LOOPS(C)
>>>>>>> 10 IF BAD(C) PRINT *HALTS*
>>>>>>> 20 RETURN *LOOPS*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> INF-LOOPS ALWAYS gets it right!
>>>>>>>
>>>>>>> PROGRAM C cannot even SEE what INF-LOOPS prints
>>>>>>> so how can it trick it?
>>>>>> Perhaps like many of my reviewers you simply don't understand these
>>>>>> things very well.
>>>>>>
>>>>>> 01 int D(int (*x)())
>>>>>> 02 {
>>>>>> 03 int Halt_Status = H(x, x);
>>>>>> 04 if (Halt_Status)
>>>>>> 05 HERE: goto HERE;
>>>>>> 06 return Halt_Status;
>>>>>> 07 }
>>>>>> 08
>>>>>> 09 void main()
>>>>>> 10 {
>>>>>> 11 H(D,D);
>>>>>> 12 }
>>>>>>
>>>>>> D correctly simulated by H cannot possibly reach its own line 6 and halt
>>>>>>
>>>>>> main() calls H(D,D) that simulates D(D) at line 11
>>>>>> keeps repeating: simulated D(D) calls simulated H(D,D) that simulates
>>>>>> D(D) at line 03 ...
>>>>>>
>>>>>> computation that halts… “the Turing machine will halt whenever it enters
>>>>>> a final state” (Linz:1990:234)
>>>>>>
>>>>>> When H(D,D) returns 0 it is merely affirming the verified fact that D
>>>>>> correctly simulated by H cannot possibly reach its own last instruction
>>>>>> (final state) at line 6 and halt.
>>>>>>
>>>>>>
>>>>>> H and D are fully operational in the x86utm operating system:
>>>>>> https://github.com/plolcott/x86utm
>>>>>>
>>>>>
>>>>>
>>>>> I think your half right but HALT *d e t e r m i n e s* a halt value of a given function
>>>>> it doesnt have to *s i m u l a t e* anything.
>>>>>
>>>> After 12 years of research (2004-2016) I discovered that when H is a
>>>> simulating halt decider then every halting problem counter-example
>>>> template presents recursive simulation to its corresponding halt
>>>> decider. [simulating halt decider] is proven to be my idea.
>>>
>>> sorry Pete but degerming whether a program halts has virtually NOTHING to do with simulation
>>>
>> Although it is not required that H be a simulating halt decider, unless
>> H is a simulating halt decider H never has enough information to
>> determine the halt status of D.
>
> Rubbish! We did 100 proofs of termination.
>
> Just calculate the LOOP INVARIANT and EXIT CONDITION
>
> and solve simultaneous equations.
>
>
> In fact, simulation NEVER WORKS for any program that infinite loops
>
Making sure to not pay attention to what I say makes rebuttals seem much
easier than they actually are.

Simulating halt decider H correctly predicts whether or not D correctly
simulated by H can possibly reach its own final state in any finite
number of correctly simulated steps. It does this by correctly
recognizing several non-halting behavior patterns in a finite number of
steps of correct simulation. Inputs that do terminate are simply
simulated until they complete.

*correctly recognizing several non-halting behavior patterns*
*in a finite number of steps of correct simulation*

Unlike everyone else I have fully operational code that conclusively
proves that there are no gaps in my reasoning

H, H1 and D are fully operational in the x86utm operating system:
https://github.com/plolcott/x86utm

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

On Friday, April 7, 2023 at 8:55:01 AM UTC+10, olcott wrote:
> On 4/6/2023 5:37 PM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 5:00:34 AM UTC+10, olcott wrote:
> >> On 4/6/2023 11:47 AM, Graham Cooper wrote:
> >>> On Friday, April 7, 2023 at 2:40:39 AM UTC+10, olcott wrote:
> >>>> On 4/6/2023 11:16 AM, Graham Cooper wrote:
> >>>>> On Friday, April 7, 2023 at 2:10:02 AM UTC+10, olcott wrote:
> >>>>>> On 4/6/2023 9:56 AM, Graham Cooper wrote:
> >>>>>>> like BOLT is the fastest runner
> >>>>>>>
> >>>>>>> OLD-COOT with GOD COMPLEX
> >>>>>>> never halts arguing with
> >>>>>>> DAMON
> >>>>>>>
> >>>>>>> GOD - VS- DAMON haha
> >>>>>>>
> >>>>>>> will it ever end....
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Your BOTH wrong!
> >>>>>>>
> >>>>>>>
> >>>>>>> ============================================================
> >>>>>>> does a function exist that given a ( program identifier and input ) as input
> >>>>>>> RETURNS *halts* or *loops* correctly
> >>>>>>>
> >>>>>>> NO
> >>>>>>> ============================================================
> >>>>>>> does a function exist that given a ( program identifier and input ) as input
> >>>>>>> PRINTS *halts* or *loops* correctly
> >>>>>>>
> >>>>>>> YES
> >>>>>>> ============================================================
> >>>>>>>
> >>>>>>>
> >>>>>>> PROGRAM C
> >>>>>>> 10 IF INF-LOOPS(C) BREAK
> >>>>>>> 20 GOTO 20
> >>>>>>>
> >>>>>>> PROGRAM INF-LOOPS(C)
> >>>>>>> 10 IF BAD(C) PRINT *HALTS*
> >>>>>>> 20 RETURN *LOOPS*
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> INF-LOOPS ALWAYS gets it right!
> >>>>>>>
> >>>>>>> PROGRAM C cannot even SEE what INF-LOOPS prints
> >>>>>>> so how can it trick it?
> >>>>>> Perhaps like many of my reviewers you simply don't understand these
> >>>>>> things very well.
> >>>>>>
> >>>>>> 01 int D(int (*x)())
> >>>>>> 02 {
> >>>>>> 03 int Halt_Status = H(x, x);
> >>>>>> 04 if (Halt_Status)
> >>>>>> 05 HERE: goto HERE;
> >>>>>> 06 return Halt_Status;
> >>>>>> 07 }
> >>>>>> 08
> >>>>>> 09 void main()
> >>>>>> 10 {
> >>>>>> 11 H(D,D);
> >>>>>> 12 }
> >>>>>>
> >>>>>> D correctly simulated by H cannot possibly reach its own line 6 and halt
> >>>>>>
> >>>>>> main() calls H(D,D) that simulates D(D) at line 11
> >>>>>> keeps repeating: simulated D(D) calls simulated H(D,D) that simulates
> >>>>>> D(D) at line 03 ...
> >>>>>>
> >>>>>> computation that halts… “the Turing machine will halt whenever it enters
> >>>>>> a final state” (Linz:1990:234)
> >>>>>>
> >>>>>> When H(D,D) returns 0 it is merely affirming the verified fact that D
> >>>>>> correctly simulated by H cannot possibly reach its own last instruction
> >>>>>> (final state) at line 6 and halt.
> >>>>>>
> >>>>>>
> >>>>>> H and D are fully operational in the x86utm operating system:
> >>>>>> https://github.com/plolcott/x86utm
> >>>>>>
> >>>>>
> >>>>>
> >>>>> I think your half right but HALT *d e t e r m i n e s* a halt value of a given function
> >>>>> it doesnt have to *s i m u l a t e* anything.
> >>>>>
> >>>> After 12 years of research (2004-2016) I discovered that when H is a
> >>>> simulating halt decider then every halting problem counter-example
> >>>> template presents recursive simulation to its corresponding halt
> >>>> decider. [simulating halt decider] is proven to be my idea.
> >>>
> >>> sorry Pete but degerming whether a program halts has virtually NOTHING to do with simulation
> >>>
> >> Although it is not required that H be a simulating halt decider, unless
> >> H is a simulating halt decider H never has enough information to
> >> determine the halt status of D.
> >
> > Rubbish! We did 100 proofs of termination.
> >
> > Just calculate the LOOP INVARIANT and EXIT CONDITION
> >
> > and solve simultaneous equations.
> >
> >
> > In fact, simulation NEVER WORKS for any program that infinite loops
> >
> Making sure to not pay attention to what I say makes rebuttals seem much
> easier than they actually are.
>
> Simulating halt decider H correctly predicts whether or not D correctly
> simulated by H can possibly reach its own final state in any finite
> number of correctly simulated steps. It does this by correctly
> recognizing several non-halting behavior patterns in a finite number of
> steps

OK

> of correct simulation.

Nope! your using ANALYSE and SIMULATE as synonyms.

Wrong usage of term SIMULATE (EMULATE)

> Inputs that do terminate are simply
> simulated until they complete.

bWAHAHAHAHA!

that is NOT how a HALT() function works

how long do you wait? how do you KNOW it terminates?

SIMULATION is the poor mans halt function

On 4/6/2023 6:00 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 8:55:01 AM UTC+10, olcott wrote:
>> On 4/6/2023 5:37 PM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 5:00:34 AM UTC+10, olcott wrote:
>>>> On 4/6/2023 11:47 AM, Graham Cooper wrote:
>>>>> On Friday, April 7, 2023 at 2:40:39 AM UTC+10, olcott wrote:
>>>>>> On 4/6/2023 11:16 AM, Graham Cooper wrote:
>>>>>>> On Friday, April 7, 2023 at 2:10:02 AM UTC+10, olcott wrote:
>>>>>>>> On 4/6/2023 9:56 AM, Graham Cooper wrote:
>>>>>>>>> like BOLT is the fastest runner
>>>>>>>>>
>>>>>>>>> OLD-COOT with GOD COMPLEX
>>>>>>>>> never halts arguing with
>>>>>>>>> DAMON
>>>>>>>>>
>>>>>>>>> GOD - VS- DAMON haha
>>>>>>>>>
>>>>>>>>> will it ever end....
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Your BOTH wrong!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ============================================================
>>>>>>>>> does a function exist that given a ( program identifier and input ) as input
>>>>>>>>> RETURNS *halts* or *loops* correctly
>>>>>>>>>
>>>>>>>>> NO
>>>>>>>>> ============================================================
>>>>>>>>> does a function exist that given a ( program identifier and input ) as input
>>>>>>>>> PRINTS *halts* or *loops* correctly
>>>>>>>>>
>>>>>>>>> YES
>>>>>>>>> ============================================================
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PROGRAM C
>>>>>>>>> 10 IF INF-LOOPS(C) BREAK
>>>>>>>>> 20 GOTO 20
>>>>>>>>>
>>>>>>>>> PROGRAM INF-LOOPS(C)
>>>>>>>>> 10 IF BAD(C) PRINT *HALTS*
>>>>>>>>> 20 RETURN *LOOPS*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> INF-LOOPS ALWAYS gets it right!
>>>>>>>>>
>>>>>>>>> PROGRAM C cannot even SEE what INF-LOOPS prints
>>>>>>>>> so how can it trick it?
>>>>>>>> Perhaps like many of my reviewers you simply don't understand these
>>>>>>>> things very well.
>>>>>>>>
>>>>>>>> 01 int D(int (*x)())
>>>>>>>> 02 {
>>>>>>>> 03 int Halt_Status = H(x, x);
>>>>>>>> 04 if (Halt_Status)
>>>>>>>> 05 HERE: goto HERE;
>>>>>>>> 06 return Halt_Status;
>>>>>>>> 07 }
>>>>>>>> 08
>>>>>>>> 09 void main()
>>>>>>>> 10 {
>>>>>>>> 11 H(D,D);
>>>>>>>> 12 }
>>>>>>>>
>>>>>>>> D correctly simulated by H cannot possibly reach its own line 6 and halt
>>>>>>>>
>>>>>>>> main() calls H(D,D) that simulates D(D) at line 11
>>>>>>>> keeps repeating: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>>> D(D) at line 03 ...
>>>>>>>>
>>>>>>>> computation that halts… “the Turing machine will halt whenever it enters
>>>>>>>> a final state” (Linz:1990:234)
>>>>>>>>
>>>>>>>> When H(D,D) returns 0 it is merely affirming the verified fact that D
>>>>>>>> correctly simulated by H cannot possibly reach its own last instruction
>>>>>>>> (final state) at line 6 and halt.
>>>>>>>>
>>>>>>>>
>>>>>>>> H and D are fully operational in the x86utm operating system:
>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think your half right but HALT *d e t e r m i n e s* a halt value of a given function
>>>>>>> it doesnt have to *s i m u l a t e* anything.
>>>>>>>
>>>>>> After 12 years of research (2004-2016) I discovered that when H is a
>>>>>> simulating halt decider then every halting problem counter-example
>>>>>> template presents recursive simulation to its corresponding halt
>>>>>> decider. [simulating halt decider] is proven to be my idea.
>>>>>
>>>>> sorry Pete but degerming whether a program halts has virtually NOTHING to do with simulation
>>>>>
>>>> Although it is not required that H be a simulating halt decider, unless
>>>> H is a simulating halt decider H never has enough information to
>>>> determine the halt status of D.
>>>
>>> Rubbish! We did 100 proofs of termination.
>>>
>>> Just calculate the LOOP INVARIANT and EXIT CONDITION
>>>
>>> and solve simultaneous equations.
>>>
>>>
>>> In fact, simulation NEVER WORKS for any program that infinite loops
>>>
>> Making sure to not pay attention to what I say makes rebuttals seem much
>> easier than they actually are.
>>
>> Simulating halt decider H correctly predicts whether or not D correctly
>> simulated by H can possibly reach its own final state in any finite
>> number of correctly simulated steps. It does this by correctly
>> recognizing several non-halting behavior patterns in a finite number of
>> steps
>
> OK
>
>> of correct simulation.
>
> Nope! your using ANALYSE and SIMULATE as synonyms.
>
> Wrong usage of term SIMULATE (EMULATE)
>
>
>
>
>
>> Inputs that do terminate are simply
>> simulated until they complete.
>
> bWAHAHAHAHA!
>
> that is NOT how a HALT() function works
>
> how long do you wait? how do you KNOW it terminates?
>
>
>
> SIMULATION is the poor mans halt function
>
>
>

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

correctly recognizing several non-halting behavior patterns in a finite
number of steps

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

On Friday, April 7, 2023 at 9:33:02 AM UTC+10, olcott wrote:
> On 4/6/2023 6:00 PM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 8:55:01 AM UTC+10, olcott wrote:
> >> On 4/6/2023 5:37 PM, Graham Cooper wrote:
> >>> On Friday, April 7, 2023 at 5:00:34 AM UTC+10, olcott wrote:
> >>>> On 4/6/2023 11:47 AM, Graham Cooper wrote:
> >>>>> On Friday, April 7, 2023 at 2:40:39 AM UTC+10, olcott wrote:
> >>>>>> On 4/6/2023 11:16 AM, Graham Cooper wrote:
> >>>>>>> On Friday, April 7, 2023 at 2:10:02 AM UTC+10, olcott wrote:
> >>>>>>>> On 4/6/2023 9:56 AM, Graham Cooper wrote:
> >>>>>>>>> like BOLT is the fastest runner
> >>>>>>>>>
> >>>>>>>>> OLD-COOT with GOD COMPLEX
> >>>>>>>>> never halts arguing with
> >>>>>>>>> DAMON
> >>>>>>>>>
> >>>>>>>>> GOD - VS- DAMON haha
> >>>>>>>>>
> >>>>>>>>> will it ever end....
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Your BOTH wrong!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ============================================================
> >>>>>>>>> does a function exist that given a ( program identifier and input ) as input
> >>>>>>>>> RETURNS *halts* or *loops* correctly
> >>>>>>>>>
> >>>>>>>>> NO
> >>>>>>>>> ============================================================
> >>>>>>>>> does a function exist that given a ( program identifier and input ) as input
> >>>>>>>>> PRINTS *halts* or *loops* correctly
> >>>>>>>>>
> >>>>>>>>> YES
> >>>>>>>>> ============================================================
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> PROGRAM C
> >>>>>>>>> 10 IF INF-LOOPS(C) BREAK
> >>>>>>>>> 20 GOTO 20
> >>>>>>>>>
> >>>>>>>>> PROGRAM INF-LOOPS(C)
> >>>>>>>>> 10 IF BAD(C) PRINT *HALTS*
> >>>>>>>>> 20 RETURN *LOOPS*
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> INF-LOOPS ALWAYS gets it right!
> >>>>>>>>>
> >>>>>>>>> PROGRAM C cannot even SEE what INF-LOOPS prints
> >>>>>>>>> so how can it trick it?
> >>>>>>>> Perhaps like many of my reviewers you simply don't understand these
> >>>>>>>> things very well.
> >>>>>>>>
> >>>>>>>> 01 int D(int (*x)())
> >>>>>>>> 02 {
> >>>>>>>> 03 int Halt_Status = H(x, x);
> >>>>>>>> 04 if (Halt_Status)
> >>>>>>>> 05 HERE: goto HERE;
> >>>>>>>> 06 return Halt_Status;
> >>>>>>>> 07 }
> >>>>>>>> 08
> >>>>>>>> 09 void main()
> >>>>>>>> 10 {
> >>>>>>>> 11 H(D,D);
> >>>>>>>> 12 }
> >>>>>>>>
> >>>>>>>> D correctly simulated by H cannot possibly reach its own line 6 and halt
> >>>>>>>>
> >>>>>>>> main() calls H(D,D) that simulates D(D) at line 11
> >>>>>>>> keeps repeating: simulated D(D) calls simulated H(D,D) that simulates
> >>>>>>>> D(D) at line 03 ...
> >>>>>>>>
> >>>>>>>> computation that halts… “the Turing machine will halt whenever it enters
> >>>>>>>> a final state” (Linz:1990:234)
> >>>>>>>>
> >>>>>>>> When H(D,D) returns 0 it is merely affirming the verified fact that D
> >>>>>>>> correctly simulated by H cannot possibly reach its own last instruction
> >>>>>>>> (final state) at line 6 and halt.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> H and D are fully operational in the x86utm operating system:
> >>>>>>>> https://github.com/plolcott/x86utm
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I think your half right but HALT *d e t e r m i n e s* a halt value of a given function
> >>>>>>> it doesnt have to *s i m u l a t e* anything.
> >>>>>>>
> >>>>>> After 12 years of research (2004-2016) I discovered that when H is a
> >>>>>> simulating halt decider then every halting problem counter-example
> >>>>>> template presents recursive simulation to its corresponding halt
> >>>>>> decider. [simulating halt decider] is proven to be my idea.
> >>>>>
> >>>>> sorry Pete but degerming whether a program halts has virtually NOTHING to do with simulation
> >>>>>
> >>>> Although it is not required that H be a simulating halt decider, unless
> >>>> H is a simulating halt decider H never has enough information to
> >>>> determine the halt status of D.
> >>>
> >>> Rubbish! We did 100 proofs of termination.
> >>>
> >>> Just calculate the LOOP INVARIANT and EXIT CONDITION
> >>>
> >>> and solve simultaneous equations.
> >>>
> >>>
> >>> In fact, simulation NEVER WORKS for any program that infinite loops
> >>>
> >> Making sure to not pay attention to what I say makes rebuttals seem much
> >> easier than they actually are.
> >>
> >> Simulating halt decider H correctly predicts whether or not D correctly
> >> simulated by H can possibly reach its own final state in any finite
> >> number of correctly simulated steps. It does this by correctly
> >> recognizing several non-halting behavior patterns in a finite number of
> >> steps
> >
> > OK
> >
> >> of correct simulation.
> >
> > Nope! your using ANALYSE and SIMULATE as synonyms.
> >
> > Wrong usage of term SIMULATE (EMULATE)
> >
> >
> >
> >
> >
> >> Inputs that do terminate are simply
> >> simulated until they complete.
> >
> > bWAHAHAHAHA!
> >
> > that is NOT how a HALT() function works
> >
> > how long do you wait? how do you KNOW it terminates?
> >
> >
> >
> > SIMULATION is the poor mans halt function
> >
> >
> >
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps
>
> correctly recognizing several non-halting behavior patterns in a finite
> number of steps

On 4/6/2023 6:40 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 9:33:02 AM UTC+10, olcott wrote:
>> On 4/6/2023 6:00 PM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 8:55:01 AM UTC+10, olcott wrote:
>>>> On 4/6/2023 5:37 PM, Graham Cooper wrote:
>>>>> On Friday, April 7, 2023 at 5:00:34 AM UTC+10, olcott wrote:
>>>>>> On 4/6/2023 11:47 AM, Graham Cooper wrote:
>>>>>>> On Friday, April 7, 2023 at 2:40:39 AM UTC+10, olcott wrote:
>>>>>>>> On 4/6/2023 11:16 AM, Graham Cooper wrote:
>>>>>>>>> On Friday, April 7, 2023 at 2:10:02 AM UTC+10, olcott wrote:
>>>>>>>>>> On 4/6/2023 9:56 AM, Graham Cooper wrote:
>>>>>>>>>>> like BOLT is the fastest runner
>>>>>>>>>>>
>>>>>>>>>>> OLD-COOT with GOD COMPLEX
>>>>>>>>>>> never halts arguing with
>>>>>>>>>>> DAMON
>>>>>>>>>>>
>>>>>>>>>>> GOD - VS- DAMON haha
>>>>>>>>>>>
>>>>>>>>>>> will it ever end....
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Your BOTH wrong!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ============================================================
>>>>>>>>>>> does a function exist that given a ( program identifier and input ) as input
>>>>>>>>>>> RETURNS *halts* or *loops* correctly
>>>>>>>>>>>
>>>>>>>>>>> NO
>>>>>>>>>>> ============================================================
>>>>>>>>>>> does a function exist that given a ( program identifier and input ) as input
>>>>>>>>>>> PRINTS *halts* or *loops* correctly
>>>>>>>>>>>
>>>>>>>>>>> YES
>>>>>>>>>>> ============================================================
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> PROGRAM C
>>>>>>>>>>> 10 IF INF-LOOPS(C) BREAK
>>>>>>>>>>> 20 GOTO 20
>>>>>>>>>>>
>>>>>>>>>>> PROGRAM INF-LOOPS(C)
>>>>>>>>>>> 10 IF BAD(C) PRINT *HALTS*
>>>>>>>>>>> 20 RETURN *LOOPS*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> INF-LOOPS ALWAYS gets it right!
>>>>>>>>>>>
>>>>>>>>>>> PROGRAM C cannot even SEE what INF-LOOPS prints
>>>>>>>>>>> so how can it trick it?
>>>>>>>>>> Perhaps like many of my reviewers you simply don't understand these
>>>>>>>>>> things very well.
>>>>>>>>>>
>>>>>>>>>> 01 int D(int (*x)())
>>>>>>>>>> 02 {
>>>>>>>>>> 03 int Halt_Status = H(x, x);
>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 void main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11 H(D,D);
>>>>>>>>>> 12 }
>>>>>>>>>>
>>>>>>>>>> D correctly simulated by H cannot possibly reach its own line 6 and halt
>>>>>>>>>>
>>>>>>>>>> main() calls H(D,D) that simulates D(D) at line 11
>>>>>>>>>> keeps repeating: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>>>>> D(D) at line 03 ...
>>>>>>>>>>
>>>>>>>>>> computation that halts… “the Turing machine will halt whenever it enters
>>>>>>>>>> a final state” (Linz:1990:234)
>>>>>>>>>>
>>>>>>>>>> When H(D,D) returns 0 it is merely affirming the verified fact that D
>>>>>>>>>> correctly simulated by H cannot possibly reach its own last instruction
>>>>>>>>>> (final state) at line 6 and halt.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> H and D are fully operational in the x86utm operating system:
>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think your half right but HALT *d e t e r m i n e s* a halt value of a given function
>>>>>>>>> it doesnt have to *s i m u l a t e* anything.
>>>>>>>>>
>>>>>>>> After 12 years of research (2004-2016) I discovered that when H is a
>>>>>>>> simulating halt decider then every halting problem counter-example
>>>>>>>> template presents recursive simulation to its corresponding halt
>>>>>>>> decider. [simulating halt decider] is proven to be my idea.
>>>>>>>
>>>>>>> sorry Pete but degerming whether a program halts has virtually NOTHING to do with simulation
>>>>>>>
>>>>>> Although it is not required that H be a simulating halt decider, unless
>>>>>> H is a simulating halt decider H never has enough information to
>>>>>> determine the halt status of D.
>>>>>
>>>>> Rubbish! We did 100 proofs of termination.
>>>>>
>>>>> Just calculate the LOOP INVARIANT and EXIT CONDITION
>>>>>
>>>>> and solve simultaneous equations.
>>>>>
>>>>>
>>>>> In fact, simulation NEVER WORKS for any program that infinite loops
>>>>>
>>>> Making sure to not pay attention to what I say makes rebuttals seem much
>>>> easier than they actually are.
>>>>
>>>> Simulating halt decider H correctly predicts whether or not D correctly
>>>> simulated by H can possibly reach its own final state in any finite
>>>> number of correctly simulated steps. It does this by correctly
>>>> recognizing several non-halting behavior patterns in a finite number of
>>>> steps
>>>
>>> OK
>>>
>>>> of correct simulation.
>>>
>>> Nope! your using ANALYSE and SIMULATE as synonyms.
>>>
>>> Wrong usage of term SIMULATE (EMULATE)
>>>
>>>
>>>
>>>
>>>
>>>> Inputs that do terminate are simply
>>>> simulated until they complete.
>>>
>>> bWAHAHAHAHA!
>>>
>>> that is NOT how a HALT() function works
>>>
>>> how long do you wait? how do you KNOW it terminates?
>>>
>>>
>>>
>>> SIMULATION is the poor mans halt function
>>>
>>>
>>>
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>>
>> correctly recognizing several non-halting behavior patterns in a finite
>> number of steps
>
>
> you miss the OK ?
>
>
>
>>> recognizing several non-halting behavior patterns in a finite number of
>>> steps
>>
>> OK
>>
>>> of correct simulation.
>>
>> Nope!
>
>
> thats not SIMULATION
>

On 4/6/23 6:27 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 4:53:51 AM UTC+10, Richard Damon wrote:
>> On 4/6/23 2:34 PM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 4:21:18 AM UTC+10, Richard Damon wrote:
>>>> On 4/6/23 2:14 PM, Graham Cooper wrote:
>>>>>>> any computation model can be extended to emulate a PRINT function
>>>>>>> or read the function call STACK level
>>>>>>>
>>>>>> But only WITHIN a computation, and not to OUTSIDE the given computation.
>>>>>>
>>>>>> You don't seem to understand the FUNDAMENTAL part of the DEFINITION of a
>>>>>> compuation, that its COMPLETE set of inputs are specified.
>>>>>
>>>>>
>>>>> WRONG!
>>>>>
>>>>> you seem to equate pure function theory with computability
>>>>> and since TMs are directly equivalent to pure functions you conclude ET VOILA!
>>>> But Computability Theory IS about "Pure Functions" per the definition of
>>>> a specific mapping of inputs to outputs, and if such a mapping is
>>>> "Computable" by a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> yes, you COULD define as an input to the function if it is being called
>>>>>> at the top level or not. The problem is the "Halting" function, by its
>>>>>> DEFINITION, isn't given that as an input, so any program that needs that
>>>>>> input and its answer is dependent on it, CAN'T BE CORRECT.
>>>>>>
>>>>>
>>>>> WRONG! or WHO CARES whether HALT has 2 or 3 inputs.
>>>> How can it depend on more than the program and its input.
>>>
>>> just P & I arrives at contradictory programs
>>>
>> No, it just shows that Halting isn't compuational.
>>
>> Again, what actual program needs more than the program and its input to
>> figure what it will do?
>>
>> The fact we get the contradictory "results" says we could never actually
>> write a program to compute the functions.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> That is all the program will depend on, so if the functions depends on
>>>> something else, it MUST be wrong.
>>>
>>>
>>> HALT is given an EXTRA specification of scope at top level function call
>> No, remember, the input to Halt is a PROGRAM that is a complete
>> computation. The behavior of that is independent of how the decider is run.
>
> drivel
>

Accurate description of your comments.

It seems you don't understand the difference between Computability
Analysis and programming.

>
>
>
>
>
>>
>> Why does it need to know that it is the "top" level function. If it
>> does, then the program P just needs to also call it and say it want to
>> knwo the answer it will give when asked as the top level program, as
>> THAT is supposedly the correct answer.
>
>
> WRONG!
>
> STACK is a system variable and cannot be altered by the functions themselves
> READ ONLY and INCREMENTS every function call

Then your "functions" aren't able to be computations, and you system
becomes indivisable, so we need to treat the WHOLE computer as a single
omputation matchine.

>
>
>
>
>
>
>>
>> If its an input, it can be set to what is desired in the call.
>>>
>>> a general purpose pure function halt wont work
>> And thus the mapping isn't computable.
>>> a top level function halt works and fulfills the requirements of its specification
>>>
>>>
>> Nope, because if it can't be called by someone, it isn't a computation.
>
> Huh?
>
> No wonder you cannot understand the argument
>
> KEYBOARD> halt(d d) [ENTER]
> MONITOR> *halts*
>
> KEYBOARD> d(d) [ENTER]
> MONITOR> halt:: out of scope

So, you still show you don't understand what a COMPUTATION is in
computability theory.

Remember, this existed BEFORE "Computers" as you think of them existed.

At that point, a "Computer" was the name for a person who followed an
algorithmic scripts with a pad of note paper, following the instructions.

>
>
>
>
>
>
>>>
>>>
>>>
>>>
>>>>>
>>>>> The specification is GIVEN A PROGRAM IDENTIFIER AND ITS INPUT
>>>>> not GIVEN *ONLY* A PROGRAM IDENTIFIER AND ITS INPUT
>>>> But the answer depends only on that input, so any other input MUST be
>>>> irrelevent.
>
> Nope!
>
> You cannot write a FAIRY PROGRAM to solve prime-pairs is the only drawback

Nope, You still are just showing you don't understand what the field is
about.

It is about building a COMPUTATION, per the definition.

A Program is the sequence of steps needed to perform that compuation.

The Input is the data used with that sequence of steps.

>
>
>
>
>>>>
>>>> Please explain how a CORRECT answer can use anything else?
>>>
>>>
>>> The idea is to work out how a halt function can WORK
>>> Not to dismiss a workable notion because it SEEMS to rely on 2 inputs
>> No, the question is if a Halt Function that meets the requirements can
>> be designed.
>
> What are the requirements ?
>
> GIVEN PROG and INP (from the keyboard perhaps)
> can it return *halts* or *loops* for any input
>
> YES IT CAN

But they way you describe is NOT a "Computation" per the definition.

You just don't seem to understand what that is.

I guess you are just too dumb.

>
>
>
>
>
>>>
>>> HALT is a TOP STACK LEVEL function
>>>
>>> You cant seem to fathom this
>> Then it isn't a "Computation", so not a valid answer.
>
> drivel

yes, your ideas are.

You just don't understand what Computability Theory is about.

>
>
>
>
>
>
>>
>> IF it can't be made into a Turing Machine, and thus the input program
>> use copy of it and get the same answer, it doesn't meet the requirements.
>
> input program can use a copy of HALT and gets a "OUT OF SCOPE" BRK

Then the decier fails its requirement, as it needs to be able to accept
*ALL* "Programs", including ones that include copies of itself.

So, you just seem to have admitted you program doesn't meet its
requirements.

>
>>>
>>>
>>>
>>>
>>>
>>>>>
>>>>>
>>>>> Different computability models are equivalent if there is BIJECTION of equivalence from each function
>>>>> in one model to the some other function in the other model.
>>>> Right, so show how you can get a BIJECTION between the actual formal
>>>> definition and yours.
>>>>>
>>>>> Even within the TM framework
>>>>> a TM exists with emulated global variables (similar to emulating multiple inputs)
>>>>> for every TM without global variables.
>>>> And those globals thus become DEFINED as inputs, and thus are no longer
>>>> "globals"
>>>>>
>>>>> In non-extendible pure computer theory
>>>>> not many things are possible, and you restrict the domain to this fruitless limited power.
>>>>>
>>>> What actual computation can't be done by it?
>>>>
>>>> Try to name one.
>>>
>>> a HALT function
>> Which has been shown to not be a computation.
>
> poorly shown with no thought put into it
>

Nope, Well proven.

>
>
>
>
>
>
>>
>>> a DATABASE
>>
>> Not a computation, but a data structure. Name a COMPUTATION (even using
>> a database) that can't be done by one. Note, the Database likely ends up
>> as fully encoded as part of the input.
>
> Nope! SQL doesnt work that way. It does NOT use pure functions
>

On Friday, April 7, 2023 at 12:01:27 PM UTC+10, Richard Damon wrote:
> On 4/6/23 6:27 PM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 4:53:51 AM UTC+10, Richard Damon wrote:
> >> On 4/6/23 2:34 PM, Graham Cooper wrote:
> >>> On Friday, April 7, 2023 at 4:21:18 AM UTC+10, Richard Damon wrote:
> >>>> On 4/6/23 2:14 PM, Graham Cooper wrote:
> >>>>>>> any computation model can be extended to emulate a PRINT function
> >>>>>>> or read the function call STACK level
> >>>>>>>
> >>>>>> But only WITHIN a computation, and not to OUTSIDE the given computation.
> >>>>>>
> >>>>>> You don't seem to understand the FUNDAMENTAL part of the DEFINITION of a
> >>>>>> compuation, that its COMPLETE set of inputs are specified.
> >>>>>
> >>>>>
> >>>>> WRONG!
> >>>>>
> >>>>> you seem to equate pure function theory with computability
> >>>>> and since TMs are directly equivalent to pure functions you conclude ET VOILA!
> >>>> But Computability Theory IS about "Pure Functions" per the definition of
> >>>> a specific mapping of inputs to outputs, and if such a mapping is
> >>>> "Computable" by a
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> yes, you COULD define as an input to the function if it is being called
> >>>>>> at the top level or not. The problem is the "Halting" function, by its
> >>>>>> DEFINITION, isn't given that as an input, so any program that needs that
> >>>>>> input and its answer is dependent on it, CAN'T BE CORRECT.
> >>>>>>
> >>>>>
> >>>>> WRONG! or WHO CARES whether HALT has 2 or 3 inputs.
> >>>> How can it depend on more than the program and its input.
> >>>
> >>> just P & I arrives at contradictory programs
> >>>
> >> No, it just shows that Halting isn't compuational.
> >>
> >> Again, what actual program needs more than the program and its input to
> >> figure what it will do?
> >>
> >> The fact we get the contradictory "results" says we could never actually
> >> write a program to compute the functions.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> That is all the program will depend on, so if the functions depends on
> >>>> something else, it MUST be wrong.
> >>>
> >>>
> >>> HALT is given an EXTRA specification of scope at top level function call
> >> No, remember, the input to Halt is a PROGRAM that is a complete
> >> computation. The behavior of that is independent of how the decider is run.
> >
> > drivel
> >
> Accurate description of your comments.
>
> It seems you don't understand the difference between Computability
> Analysis and programming.
> >
> >
> >
> >
> >
> >>
> >> Why does it need to know that it is the "top" level function. If it
> >> does, then the program P just needs to also call it and say it want to
> >> knwo the answer it will give when asked as the top level program, as
> >> THAT is supposedly the correct answer.
> >
> >
> > WRONG!
> >
> > STACK is a system variable and cannot be altered by the functions themselves
> > READ ONLY and INCREMENTS every function call
> Then your "functions" aren't able to be computations, and you system
> becomes indivisable, so we need to treat the WHOLE computer as a single
> omputation matchine.
> >
> >
> >
> >
> >
> >
> >>
> >> If its an input, it can be set to what is desired in the call.
> >>>
> >>> a general purpose pure function halt wont work
> >> And thus the mapping isn't computable.
> >>> a top level function halt works and fulfills the requirements of its specification
> >>>
> >>>
> >> Nope, because if it can't be called by someone, it isn't a computation..
> >
> > Huh?
> >
> > No wonder you cannot understand the argument
> >
> > KEYBOARD> halt(d d) [ENTER]
> > MONITOR> *halts*
> >
> > KEYBOARD> d(d) [ENTER]
> > MONITOR> halt:: out of scope
> So, you still show you don't understand what a COMPUTATION is in
> computability theory.
>
> Remember, this existed BEFORE "Computers" as you think of them existed.
>
> At that point, a "Computer" was the name for a person who followed an
> algorithmic scripts with a pad of note paper, following the instructions.
> >
> >
> >
> >
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>>>>
> >>>>> The specification is GIVEN A PROGRAM IDENTIFIER AND ITS INPUT
> >>>>> not GIVEN *ONLY* A PROGRAM IDENTIFIER AND ITS INPUT
> >>>> But the answer depends only on that input, so any other input MUST be
> >>>> irrelevent.
> >
> > Nope!
> >
> > You cannot write a FAIRY PROGRAM to solve prime-pairs is the only drawback
> Nope, You still are just showing you don't understand what the field is
> about.
>
> It is about building a COMPUTATION, per the definition.
>
> A Program is the sequence of steps needed to perform that compuation.
>
> The Input is the data used with that sequence of steps.
> >
> >
> >
> >
> >>>>
> >>>> Please explain how a CORRECT answer can use anything else?
> >>>
> >>>
> >>> The idea is to work out how a halt function can WORK
> >>> Not to dismiss a workable notion because it SEEMS to rely on 2 inputs
> >> No, the question is if a Halt Function that meets the requirements can
> >> be designed.
> >
> > What are the requirements ?
> >
> > GIVEN PROG and INP (from the keyboard perhaps)
> > can it return *halts* or *loops* for any input
> >
> > YES IT CAN
> But they way you describe is NOT a "Computation" per the definition.
>
> You just don't seem to understand what that is.
>
> I guess you are just too dumb.
> >
> >
> >
> >
> >
> >>>
> >>> HALT is a TOP STACK LEVEL function
> >>>
> >>> You cant seem to fathom this
> >> Then it isn't a "Computation", so not a valid answer.
> >
> > drivel
> yes, your ideas are.
>
> You just don't understand what Computability Theory is about.
> >
> >
> >
> >
> >
> >
> >>
> >> IF it can't be made into a Turing Machine, and thus the input program
> >> use copy of it and get the same answer, it doesn't meet the requirements.
> >
> > input program can use a copy of HALT and gets a "OUT OF SCOPE" BRK
> Then the decier fails its requirement, as it needs to be able to accept
> *ALL* "Programs", including ones that include copies of itself.

haha pure RUBBISH!

>
> So, you just seem to have admitted you program doesn't meet its
> requirements.
> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>> Different computability models are equivalent if there is BIJECTION of equivalence from each function
> >>>>> in one model to the some other function in the other model.
> >>>> Right, so show how you can get a BIJECTION between the actual formal
> >>>> definition and yours.
> >>>>>
> >>>>> Even within the TM framework
> >>>>> a TM exists with emulated global variables (similar to emulating multiple inputs)
> >>>>> for every TM without global variables.
> >>>> And those globals thus become DEFINED as inputs, and thus are no longer
> >>>> "globals"
> >>>>>
> >>>>> In non-extendible pure computer theory
> >>>>> not many things are possible, and you restrict the domain to this fruitless limited power.
> >>>>>
> >>>> What actual computation can't be done by it?
> >>>>
> >>>> Try to name one.
> >>>
> >>> a HALT function
> >> Which has been shown to not be a computation.
> >
> > poorly shown with no thought put into it
> >
> Nope, Well proven.
> >
> >
> >
> >
> >
> >
> >>
> >>> a DATABASE
> >>
> >> Not a computation, but a data structure. Name a COMPUTATION (even using
> >> a database) that can't be done by one. Note, the Database likely ends up
> >> as fully encoded as part of the input.
> >
> > Nope! SQL doesnt work that way. It does NOT use pure functions
> >
> Internally, we don't need "pure functions", it is only ate the
> computaiton interface.
>
> Any database operation that qualifies as a "Computation" can be
> expressed as a "pure function" that takes in the original database, and
> the operation request, and outputs the operation results and the new
> database.
>
> Input -> Operation -> Output
> >
> >
> >>> a UTM ....... (it changes the definition of a unary input in order to parse 2 inputs with 1 unary number)
> >>>
> >>>
> >> Nope, A UTM takes as its input a REPERESENTATION of the "Program and
> >> Input", that representation can be a single string of the tape. Yes,
> >> that string can be encoded into a single number, but that isn't what the
> >> input necessrily represents.
> >
> >
> > Then its no longer
> >
> > f(number) -> number
> Who said the input was "a single numbrer"
>
> For a Turing Machine, the input is a tape with a finite number of
> symbols on it.
>
> Yes, you CAN convert such an input into a single number, since there are
> ony a countable infinity of such tapes, but we don't need to think of it
> as such.
> >
> > its
> >
> > f( set_of_numbers ) -> number
> or even f ( set_of_numbers) -> set_of_numbers (there is no requirement
> that the "output" of a computation be a single number.
> >
> > which is the same as adding global or system variables
> >
> Nope, globals transfer information from one operation to another via an
> implicit path.
>
> Computations make all inputs and output explicit, so they aren't what
> you are thinking of a "globals".

On 4/6/23 10:28 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 12:01:27 PM UTC+10, Richard Damon wrote:
Nope, globals transfer information from one operation to another via an
>> implicit path.
>>
>> Computations make all inputs and output explicit, so they aren't what
>> you are thinking of a "globals".
>
>
> You have no argument.
>
> In Every model of computation an equivalent model exists where a STACK
> system variable is readable.

And that stack is WRITABLE, and able to be set as needed to define what
it is as an input.

>
> HALT( P I )
> if STACK > 1 print OUT OF SCOPE / BREAK
> ...
>
> is all that is needed to fulfill the complete specification of the halt function

And FAILS to meet the requirments, as it has an "Input" that CAN'T
correctly influence the answer, but does infulence the answer, so NOT a
"function" of the proper form.

>
> You are MAKING UP total nonsense that halt has to be a pure function

Nope. Read up a bit about Computability Theory and what it works with.

It starts with the concept of pure mathematical functions, things that
map "inputs" to "outputs".

It is asking if we can make a "Computation" that generates the exact
same mapping as the "Halt" function, the function that maps a Machine
and its input to Halting/Non-Halting. Since that "Mathematical" Function
is a pure function, the Program that correctly computes it needs to be
one also, or it CAN'T be correct.

>
>
> The question is merely : CAN AN ALGORITHM DO THIS
> The answer is YES/POSSIBLE: but it cant be called from other functions
>
>

And since all algorithms built by the rules can be, it can't actually be
an algorithm.

On Friday, April 7, 2023 at 9:06:41 PM UTC+10, Richard Damon wrote:
> On 4/6/23 10:28 PM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 12:01:27 PM UTC+10, Richard Damon wrote:
> Nope, globals transfer information from one operation to another via an
> >> implicit path.
> >>
> >> Computations make all inputs and output explicit, so they aren't what
> >> you are thinking of a "globals".
> >
> >
> > You have no argument.
> >
> > In Every model of computation an equivalent model exists where a STACK
> > system variable is readable.
> And that stack is WRITABLE, and able to be set as needed to define what
> it is as an input.
> >
> > HALT( P I )
> > if STACK > 1 print OUT OF SCOPE / BREAK
> > ...
> >
> > is all that is needed to fulfill the complete specification of the halt function
> And FAILS to meet the requirments, as it has an "Input" that CAN'T
> correctly influence the answer, but does infulence the answer, so NOT a
> "function" of the proper form.
> >
> > You are MAKING UP total nonsense that halt has to be a pure function
> Nope. Read up a bit about Computability Theory and what it works with.
>
> It starts with the concept of pure mathematical functions, things that
> map "inputs" to "outputs".
>
> It is asking if we can make a "Computation" that generates the exact
> same mapping as the "Halt" function, the function that maps a Machine
> and its input to Halting/Non-Halting. Since that "Mathematical" Function
> is a pure function, the Program that correctly computes it needs to be
> one also, or it CAN'T be correct.
> >
> >
> > The question is merely : CAN AN ALGORITHM DO THIS
> > The answer is YES/POSSIBLE: but it cant be called from other functions
> >
> >
> And since all algorithms built by the rules can be, it can't actually be
> an algorithm.

there are no RULES they're in your head

Given the SET of TM# INPUT

---------- input
tm# 1 2 3 4
1 ... h l h h
2 ... h h h h
3 ... l l l l
4 ... h h h h

THAT is the OBJECTIVE to compute all h l values for every pair

d() is the ANTI-DIAGONAL TM

tm# 1 2 3 4
1 ... h l h h
2 ... h h h h
3 ... l l l l
4 ... h h h h
d ... l l h l ?

where the DIAGONAL is h h l h ?

halt is ALSO a TM

tm# 1 2 3 4
1 ... h l h h
2 ... h h h h
3 ... l l l l
4 ... h h h h
d ... l l h l ?
6 ... h h h h h
h ... h l h l h l

but WE SELECT which TM is h
its not FIXED by any rules

one reason we can select which TM is h
is because h has 2 inputs
so we need to INVENT CONVENTIONS

h(1) <=> h(1,1)
h(2) <=> h(2,1)
h(3) <=> h(1,2)
h(4) <=> h(3,1)
h(5) <=> h(2,2)
....

That is a TRANPOSE SORT of the input value on the tape in unary
Using unary on the input tape is ALSO a convention
Reading unary on the tape as its output is ALSO a convention

So you get to DESIGN the mechanisms of the TM how you want

On 4/7/23 10:09 AM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 9:06:41 PM UTC+10, Richard Damon wrote:
>> On 4/6/23 10:28 PM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 12:01:27 PM UTC+10, Richard Damon wrote:
>> Nope, globals transfer information from one operation to another via an
>>>> implicit path.
>>>>
>>>> Computations make all inputs and output explicit, so they aren't what
>>>> you are thinking of a "globals".
>>>
>>>
>>> You have no argument.
>>>
>>> In Every model of computation an equivalent model exists where a STACK
>>> system variable is readable.
>> And that stack is WRITABLE, and able to be set as needed to define what
>> it is as an input.
>>>
>>> HALT( P I )
>>> if STACK > 1 print OUT OF SCOPE / BREAK
>>> ...
>>>
>>> is all that is needed to fulfill the complete specification of the halt function
>> And FAILS to meet the requirments, as it has an "Input" that CAN'T
>> correctly influence the answer, but does infulence the answer, so NOT a
>> "function" of the proper form.
>>>
>>> You are MAKING UP total nonsense that halt has to be a pure function
>> Nope. Read up a bit about Computability Theory and what it works with.
>>
>> It starts with the concept of pure mathematical functions, things that
>> map "inputs" to "outputs".
>>
>> It is asking if we can make a "Computation" that generates the exact
>> same mapping as the "Halt" function, the function that maps a Machine
>> and its input to Halting/Non-Halting. Since that "Mathematical" Function
>> is a pure function, the Program that correctly computes it needs to be
>> one also, or it CAN'T be correct.
>>>
>>>
>>> The question is merely : CAN AN ALGORITHM DO THIS
>>> The answer is YES/POSSIBLE: but it cant be called from other functions
>>>
>>>
>> And since all algorithms built by the rules can be, it can't actually be
>> an algorithm.
>
> there are no RULES they're in your head

You just gave yourself a RED CARD, and disqualified yourself.

Problems have RULES, and denying them just shows you are ineligable to
refute anything based on logic.

>
> Given the SET of TM# INPUT
>
> ---------- input
> tm# 1 2 3 4
> 1 ... h l h h
> 2 ... h h h h
> 3 ... l l l l
> 4 ... h h h h
>
> THAT is the OBJECTIVE to compute all h l values for every pair

And what problem are you talking about? I though we were talking the
Halting Problem.

>
>
> d() is the ANTI-DIAGONAL TM
>
> tm# 1 2 3 4
> 1 ... h l h h
> 2 ... h h h h
> 3 ... l l l l
> 4 ... h h h h
> d ... l l h l ?
>
> where the DIAGONAL is h h l h ?
>
> halt is ALSO a TM

No, you need to SHOW that halt is actually a TM.

The HALT function is defined as a mapping of TM descriptions and inputs
to Halting or Non-Halting based on the actual behavior of the TM of that
desciption with that input.

>
>
> tm# 1 2 3 4
> 1 ... h l h h
> 2 ... h h h h
> 3 ... l l l l
> 4 ... h h h h
> d ... l l h l ?
> 6 ... h h h h h
> h ... h l h l h l
>
>
> but WE SELECT which TM is h
> its not FIXED by any rules

Nope, its input -> output mapping is PRECISELY fixed.

>
> one reason we can select which TM is h
> is because h has 2 inputs
> so we need to INVENT CONVENTIONS
>
> h(1) <=> h(1,1)
> h(2) <=> h(2,1)
> h(3) <=> h(1,2)
> h(4) <=> h(3,1)
> h(5) <=> h(2,2)
> ...

Nope, while you can define the inputs as "single numbers" that number is
actually just a defined mapping from the actual strings representing the
input to a fixed number.

You don't seem to understand that difference.

IF you read the papers more closely, you should find that they actually
talk about having the set of the Turing Machines and their inputs, and
that because the number of each is a countable infinity, we can assign
to each of them a number.

>
>
> That is a TRANPOSE SORT of the input value on the tape in unary
> Using unary on the input tape is ALSO a convention
> Reading unary on the tape as its output is ALSO a convention
>
>
> So you get to DESIGN the mechanisms of the TM how you want
>
>

Yes, you can DESIGN the mechanism of the TM how you want from the tool
kit provided.

The are limits though of which mappings are actually doable.

On Saturday, April 8, 2023 at 9:08:24 AM UTC+10, Richard Damon wrote:
> On 4/7/23 10:09 AM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 9:06:41 PM UTC+10, Richard Damon wrote:
> >> On 4/6/23 10:28 PM, Graham Cooper wrote:
> >>> On Friday, April 7, 2023 at 12:01:27 PM UTC+10, Richard Damon wrote:
> >> Nope, globals transfer information from one operation to another via an
> >>>> implicit path.
> >>>>
> >>>> Computations make all inputs and output explicit, so they aren't what
> >>>> you are thinking of a "globals".
> >>>
> >>>
> >>> You have no argument.
> >>>
> >>> In Every model of computation an equivalent model exists where a STACK
> >>> system variable is readable.
> >> And that stack is WRITABLE, and able to be set as needed to define what
> >> it is as an input.

consider a SUBSET of turing machines that all begin with SYSTEM CODE

--------------------------------
| s | 0 | s | 0 | 0 | 0 | 0 |
--------------------------------

The system code records the NUMBER OF FUNCTION CALLS
on every 2nd tape value

The rest of the turing machine always uses DOUBLE BRANCHES
so it can only write on every 2nd tape value (interspersed between system TAPE values)

IE
given a turing machine with

[STATE1] -->01R--> [STATE2]

use instead

[STATE1] -->01R--> [STATE2] --> 00R --> [STATE4]
[STATE1] -->01R--> [STATE3] --> 11R --> [STATE4]

................ ACTUAL ............... SKIP TAPE CELL ....

Then this SUBSET of turing machines can never write to the SYSTEM VARIABLE (STACK)

PRO: this subset of TMs is equivalent (or higher) to the whole set of TMs

(a computation model with READ-ONLY could be considered more powerful than READ/WRITE models)

CON: the original set of TMs cannot compute HALT

On 4/10/23 1:26 AM, Graham Cooper wrote:
> On Saturday, April 8, 2023 at 9:08:24 AM UTC+10, Richard Damon wrote:
>> On 4/7/23 10:09 AM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 9:06:41 PM UTC+10, Richard Damon wrote:
>>>> On 4/6/23 10:28 PM, Graham Cooper wrote:
>>>>> On Friday, April 7, 2023 at 12:01:27 PM UTC+10, Richard Damon wrote:
>>>> Nope, globals transfer information from one operation to another via an
>>>>>> implicit path.
>>>>>>
>>>>>> Computations make all inputs and output explicit, so they aren't what
>>>>>> you are thinking of a "globals".
>>>>>
>>>>>
>>>>> You have no argument.
>>>>>
>>>>> In Every model of computation an equivalent model exists where a STACK
>>>>> system variable is readable.
>>>> And that stack is WRITABLE, and able to be set as needed to define what
>>>> it is as an input.
>
> consider a SUBSET of turing machines that all begin with SYSTEM CODE

And thus you are only considering a SUBSET, which might not be Turing
Complete.

Since a "user prob

>
> --------------------------------
> | s | 0 | s | 0 | 0 | 0 | 0 |
> --------------------------------
>
> The system code records the NUMBER OF FUNCTION CALLS
> on every 2nd tape value

Except that Turing Machines don't HAVE "Function Calls", so there isn't
anything to record. They perform the equivalent by effectively expanding
the call in place.

>
> The rest of the turing machine always uses DOUBLE BRANCHES
> so it can only write on every 2nd tape value (interspersed between system TAPE values)
>
>
> IE
> given a turing machine with
>
> [STATE1] -->01R--> [STATE2]
>
>
> use instead
>
> [STATE1] -->01R--> [STATE2] --> 00R --> [STATE4]
> [STATE1] -->01R--> [STATE3] --> 11R --> [STATE4]
>
> ............... ACTUAL ............... SKIP TAPE CELL ....
>
>
> Then this SUBSET of turing machines can never write to the SYSTEM VARIABLE (STACK)
>
>
> PRO: this subset of TMs is equivalent (or higher) to the whole set of TMs
>
> (a computation model with READ-ONLY could be considered more powerful than READ/WRITE models) >
>
>
>
> CON: the original set of TMs cannot compute HALT

And thus the universe of what you are "allowed" to program in, can't
compute HALT, so either you admit that this universe isn't Turing
Complete, and thus it is a solved problem, or you admit that computing
Halt isn't doable as a computation.

>
>
>
>
>
>
>
>
>
>
>
>
>

On 4/10/23 1:26 AM, Graham Cooper wrote:
> consider a SUBSET of turing machines that all begin with SYSTEM CODE

Couple more quick comments:

Halting HAS BEEN SOLVED for many SUBSETS of compuations, so coming up
with another one isn't that big of a deal, and in fact, may well be just
repeating a known solution.

Also, just showing that the trivial counter example can't be written in
your subset doesn't show that you have actually solved the subset.

Also, as I pointed out, your "System Code" is worthless, as it was
defined to track "Calls", but "Calls" don't exist as something
identifiable in a Turing Machine, since there is no defined "Call Stack"
to store return values on.

IF you want to try to claim that your "read-only stack" version is just
as powerful as the Read-write version, then the Halt Decider that you
want to encode in the RW version can just be translated to the RO
version, and always called with its stack set to top most call (since
you are now just running in an emulated RW under RO version),