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?

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

--
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 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.

Look up LOOP INVARIANT
https://www.google.com/search?q=loop+invariant

as 1 way of determining the halt values (without simulation)

====================
A better approach is that HALT only returns correct values when called from the top level
so D(d) doesnt even exist!

halt( PRO INP )
IF STACK>1 PRINT 'HALT CALLED OUT OF SCOPE'
ELSE
....
.... rest of halt function

When CHAT-GPT (AI) learns COMPUTER GRAMMARS
like it has mastered NAT-LANGUAGE GRAMMAR

you will be proven RIGHT in time !

On 4/6/23 12:09 PM, 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

Which fails to meet the requirement of that Halting Problem.

"Computations" produce "outputs" that can be taken as the "input" for
further computations.

That is EXACTLY what the Halting Problem is asking about, because that
is the need within the field to show what is needed.

This is why the problem is stated in terms of Turing Machines, because
such shenanigans can't be done with Turing Machines, as Turing Machine
are tightly coupled to the requirements of a "Computation"

>>
>> 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

But you H doesn't actually DO that so it doesn't matter.
FAIL

>
> 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 ...

No, *IF* correctly simulated, simulated D(D) will call simulated H(D,D)
which will start to simulated D(D) and then abort it simulation when it
gets to simulating the call to H(D,D) and then will be simulated to
return 0 to the simulated D(D) and then the simulated D(D) will return.

Yes, *H* can't create that simulation, because it aborts its simultion
too early, which is why H CAN'T DO a correct simulation.

All you talk about "other Hs" are just lies, as BY DEFINITION, H is, and
only is, the one exact program that is being claimed to give the right
answer, with its one and only one exact sequence of instructions that it
will perform.

All your "other H's" aren't actually H, but hypothetical constructs that
have no actual bearing on the problem, and their mention is but a Straw
man fallacy in the argument.

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

Right, and D(D) Halts

>
> 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.

No, since D(D) Halts, and a correctly simulated D(D) will also halt, it
is incorrect.

H is just confirming that it is using INVALID and UNSOUND logic

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

Right, and that code shows that D(D) Halts, as does a correct simulation
of the input to H(D,D). It also shows that H doesn't actually DO a
"Correct Simulation" per the required definition, and thus PROVES that
you are just a LYING IDIOT.

On 4/6/23 12:16 PM, Graham Cooper wrote:
> A better approach is that HALT only returns correct values when called from the top level
> so D(d) doesnt even exist!

Except it is impossible to write a computation like that as the behavior
of a computation is ONLY a function of the defined inputs, and who the
"caller" of it can't matter.

On Friday, April 7, 2023 at 2:25:41 AM UTC+10, Richard Damon wrote:
> On 4/6/23 12:09 PM, 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
> Which fails to meet the requirement of that Halting Problem.

Nope!

PRINT is just a TOP LEVEL OUTPUT
like checking if STACK=1

Given a function identifier and input as input
it can OUTPUT the correct value 100% of the time

>
> "Computations" produce "outputs" that can be taken as the "input" for
> further computations.

WRONG!

Functions and functions calls form a HIERARCHY
and you CAN STIPULATE the top level easily

>
> That is EXACTLY what the Halting Problem is asking about, because that
> is the need within the field to show what is needed.

Rubbish! your only objection was the TWIN PRIMES EXAMPLE which could be solved with a general purpose halt function (if that existed)
but could be solved using a SPECIFIC approach

>
> This is why the problem is stated in terms of Turing Machines, because
> such shenanigans can't be done with Turing Machines, as Turing Machine
> are tightly coupled to the requirements of a "Computation"

That is not the reason for anything, TURING MACHINES use CONVENTIONS
such as TRANSPOSE ENCODING of multiple arguments and hence we can
use a model within the turing machine to include the STACK (function call level)

On Friday, April 7, 2023 at 2:28:09 AM UTC+10, Richard Damon wrote:
> On 4/6/23 12:16 PM, Graham Cooper wrote:
> > A better approach is that HALT only returns correct values when called from the top level
> > so D(d) doesnt even exist!
> Except it is impossible to write a computation like that as the behavior
> of a computation is ONLY a function of the defined inputs, and who the
> "caller" of it can't matter.

its trivial!

your refusal to see this SIMPLE SIMPLE POINT over and over is your reason for 5 years of regurgitation failure

you keep swip swapping between NO GLOBAL OR SYSTEM VARIABLES and YEH GLOBAL VARIABLES TOO!

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.

>
> Look up LOOP INVARIANT
> https://www.google.com/search?q=loop+invariant
>
> as 1 way of determining the halt values (without simulation)
>
>
> =====================
>
> A better approach is that HALT only returns correct values when called from the top level
> so D(d) doesnt even exist!
>
>
> halt( PRO INP )
> IF STACK>1 PRINT 'HALT CALLED OUT OF SCOPE'
> ELSE
> ...
> ... rest of halt function
>

I merely stated verified facts, feel free to disagree thus conclusively
proving your own lack of comprehension.

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

On 4/6/23 12:33 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 2:25:41 AM UTC+10, Richard Damon wrote:
>> On 4/6/23 12:09 PM, 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
>> Which fails to meet the requirement of that Halting Problem.
>
> Nope!
>
> PRINT is just a TOP LEVEL OUTPUT
> like checking if STACK=1
>
> Given a function identifier and input as input
> it can OUTPUT the correct value 100% of the time
>
>

Read the ORIGINAL Halting Problem, the "Decider" needs to be a
Computation or a Turing Machine, not a "Program" (which is a poorly
defined term).

"PRINT" isn't a computation element.

Sure, maybe some alternate halting problem might be solvable, but Olcott
has ALWAYS been claiming the Halting Problem as shown by Turing, et al,
which is about Computability Theory.

>
>
>>
>> "Computations" produce "outputs" that can be taken as the "input" for
>> further computations.
>
> WRONG!
>
> Functions and functions calls form a HIERARCHY
> and you CAN STIPULATE the top level easily
>

But we AREN'T talking about arbitrary functions, we are talking about
COMPUTATIONS per Computabililty Theory,

>
>
>
>
>>
>> That is EXACTLY what the Halting Problem is asking about, because that
>> is the need within the field to show what is needed.
>
> Rubbish! your only objection was the TWIN PRIMES EXAMPLE which could be solved with a general purpose halt function (if that existed)
> but could be solved using a SPECIFIC approach
>

Nope,

>
>>
>> This is why the problem is stated in terms of Turing Machines, because
>> such shenanigans can't be done with Turing Machines, as Turing Machine
>> are tightly coupled to the requirements of a "Computation"
>
>
> That is not the reason for anything, TURING MACHINES use CONVENTIONS
> such as TRANSPOSE ENCODING of multiple arguments and hence we can
> use a model within the turing machine to include the STACK (function call level)
>
>

Nope.

>
>
>
>
>
>
>
>

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

On 4/6/23 12:35 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 2:28:09 AM UTC+10, Richard Damon wrote:
>> On 4/6/23 12:16 PM, Graham Cooper wrote:
>>> A better approach is that HALT only returns correct values when called from the top level
>>> so D(d) doesnt even exist!
>> Except it is impossible to write a computation like that as the behavior
>> of a computation is ONLY a function of the defined inputs, and who the
>> "caller" of it can't matter.
>
> its trivial!
>
> your refusal to see this SIMPLE SIMPLE POINT over and over is your reason for 5 years of regurgitation failure
>
> you keep swip swapping between NO GLOBAL OR SYSTEM VARIABLES and YEH GLOBAL VARIABLES TOO!
>
>

Because none of those exist in the field of COMPUTABILITY.

You are just working in the wrong problem domain.

The Halting Problem being mentioned is in the field of primative
computability theory, which is a field that is more a part of
Mathematics than what we think of as "Programming".

On Friday, April 7, 2023 at 2:44:03 AM UTC+10, Richard Damon wrote:
> On 4/6/23 12:33 PM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 2:25:41 AM UTC+10, Richard Damon wrote:
> >> On 4/6/23 12:09 PM, 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
> >> Which fails to meet the requirement of that Halting Problem.
> >
> > Nope!
> >
> > PRINT is just a TOP LEVEL OUTPUT
> > like checking if STACK=1
> >
> > Given a function identifier and input as input
> > it can OUTPUT the correct value 100% of the time
> >
> >
> Read the ORIGINAL Halting Problem, the "Decider" needs to be a
> Computation or a Turing Machine, not a "Program" (which is a poorly
> defined term).
>
> "PRINT" isn't a computation element.

any computation model can be extended to emulate a PRINT function
or read the function call STACK level

>
> Sure, maybe some alternate halting problem might be solvable, but Olcott
> has ALWAYS been claiming the Halting Problem as shown by Turing, et al,
> which is about Computability Theory.
> >
> >
> >>
> >> "Computations" produce "outputs" that can be taken as the "input" for
> >> further computations.
> >
> > WRONG!
> >
> > Functions and functions calls form a HIERARCHY
> > and you CAN STIPULATE the top level easily
> >
> But we AREN'T talking about arbitrary functions, we are talking about
> COMPUTATIONS per Computabililty Theory,

you seem to object that real computer languages are computer models too

> >
> >
> >
> >
> >>
> >> That is EXACTLY what the Halting Problem is asking about, because that
> >> is the need within the field to show what is needed.
> >
> > Rubbish! your only objection was the TWIN PRIMES EXAMPLE which could be solved with a general purpose halt function (if that existed)
> > but could be solved using a SPECIFIC approach
> >
> Nope,

a general purpose function HALT
that can be called by other functions
is not part of the original halt specification

the question is: can a TURING MACHINE input any function (and its input)
can compute the halt value correctly 100% of the time.

this is TRUE

> >
> >>
> >> This is why the problem is stated in terms of Turing Machines, because
> >> such shenanigans can't be done with Turing Machines, as Turing Machine
> >> are tightly coupled to the requirements of a "Computation"
> >
> >
> > That is not the reason for anything, TURING MACHINES use CONVENTIONS
> > such as TRANSPOSE ENCODING of multiple arguments and hence we can
> > use a model within the turing machine to include the STACK (function call level)
> >
> >
> Nope.

any computer model can emulate a stack function level

> >

On 4/6/23 12:40 PM, 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.

No, it doesn't, because you H doesn't accurately process its input,
because it sees the simulated H doing something that H doesn't actually do.

>
>>
>> Look up LOOP INVARIANT
>> https://www.google.com/search?q=loop+invariant
>>
>> as 1 way of determining the halt values (without simulation)
>>
>>
>> =====================
>>
>> A better approach is that HALT only returns correct values when called
>> from the top level
>> so D(d) doesnt even exist!
>>
>>
>> halt( PRO INP )
>> IF STACK>1 PRINT 'HALT CALLED OUT OF SCOPE'
>> ELSE
>> ...
>> ... rest of halt function
>>
>
> I merely stated verified facts, feel free to disagree thus conclusively
> proving your own lack of comprehension.
>

Verified, like that fact that D(D) does HALT, as you admit, but the
correct answer to that question you claim is that it doesn't.

You don't know what Truth even means.

IDIOT

On Friday, April 7, 2023 at 2:49:53 AM UTC+10, Richard Damon wrote:
> On 4/6/23 12:35 PM, Graham Cooper wrote:
> > On Friday, April 7, 2023 at 2:28:09 AM UTC+10, Richard Damon wrote:
> >> On 4/6/23 12:16 PM, Graham Cooper wrote:
> >>> A better approach is that HALT only returns correct values when called from the top level
> >>> so D(d) doesnt even exist!
> >> Except it is impossible to write a computation like that as the behavior
> >> of a computation is ONLY a function of the defined inputs, and who the
> >> "caller" of it can't matter.
> >
> > its trivial!
> >
> > your refusal to see this SIMPLE SIMPLE POINT over and over is your reason for 5 years of regurgitation failure
> >
> > you keep swip swapping between NO GLOBAL OR SYSTEM VARIABLES and YEH GLOBAL VARIABLES TOO!
> >
> >
> Because none of those exist in the field of COMPUTABILITY.
>
> You are just working in the wrong problem domain.
>
>
> The Halting Problem being mentioned is in the field of primative
> computability theory, which is a field that is more a part of
> Mathematics than what we think of as "Programming".

oh you've swip swapped back to

NO GLOBAL VARIABLES are computable

haha...... ur just dumb, for every model of computation an extension exists with global variables

On 4/6/23 12:51 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 2:44:03 AM UTC+10, Richard Damon wrote:
>> On 4/6/23 12:33 PM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 2:25:41 AM UTC+10, Richard Damon wrote:
>>>> On 4/6/23 12:09 PM, 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
>>>> Which fails to meet the requirement of that Halting Problem.
>>>
>>> Nope!
>>>
>>> PRINT is just a TOP LEVEL OUTPUT
>>> like checking if STACK=1
>>>
>>> Given a function identifier and input as input
>>> it can OUTPUT the correct value 100% of the time
>>>
>>>
>> Read the ORIGINAL Halting Problem, the "Decider" needs to be a
>> Computation or a Turing Machine, not a "Program" (which is a poorly
>> defined term).
>>
>> "PRINT" isn't a computation element.
>
> 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.

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.

>
>>
>> Sure, maybe some alternate halting problem might be solvable, but Olcott
>> has ALWAYS been claiming the Halting Problem as shown by Turing, et al,
>> which is about Computability Theory.
>>>
>>>
>>>>
>>>> "Computations" produce "outputs" that can be taken as the "input" for
>>>> further computations.
>>>
>>> WRONG!
>>>
>>> Functions and functions calls form a HIERARCHY
>>> and you CAN STIPULATE the top level easily
>>>
>> But we AREN'T talking about arbitrary functions, we are talking about
>> COMPUTATIONS per Computabililty Theory,
>
>
> you seem to object that real computer languages are computer models too

Not "Computer Model" but "Computation Models". Any model that give a
"program access to information that isn't defined to be an "input" is
incorrect or incomplete.

>
>
>
>
>
>
>
>
>>>
>>>
>>>
>>>
>>>>
>>>> That is EXACTLY what the Halting Problem is asking about, because that
>>>> is the need within the field to show what is needed.
>>>
>>> Rubbish! your only objection was the TWIN PRIMES EXAMPLE which could be solved with a general purpose halt function (if that existed)
>>> but could be solved using a SPECIFIC approach
>>>
>> Nope,
>
> a general purpose function HALT
> that can be called by other functions
> is not part of the original halt specification
>
> the question is: can a TURING MACHINE input any function (and its input)
> can compute the halt value correctly 100% of the time.
>
> this is TRUE

Then what answer does it give when given the H^ program with H^ input?

If it answers Halting, then it must give that same answer to H^ and H^
will loop and it will be wrong.

If it answers Non-Halting, then it must give that same answer to H& and
H^ will then Halt, and it will be wrong.

If it does something else, it has violated the requirement to do one of
the above.

Unless you can show a way for an ACTUAL TURING MACHINE to give two
different answers for the same input, you claim is false.

Remember, fundamentally, a Turing Machie is computing a mapping of its
input to an output, and ALWAYS computes the same output when given the
same input.

>
>
>
>
>>>
>>>>
>>>> This is why the problem is stated in terms of Turing Machines, because
>>>> such shenanigans can't be done with Turing Machines, as Turing Machine
>>>> are tightly coupled to the requirements of a "Computation"
>>>
>>>
>>> That is not the reason for anything, TURING MACHINES use CONVENTIONS
>>> such as TRANSPOSE ENCODING of multiple arguments and hence we can
>>> use a model within the turing machine to include the STACK (function call level)
>>>
>>>
>> Nope.
>
>
> any computer model can emulate a stack function level

Right, but it doesn't know about the "stack" used to call it, or it
isn't a "Computation", unless the call stack is specifically defined as
an input to the function.

Since the Halting Behavior of a Machine/Input is NOT a function of how
we call the decider, but ONLY of that machine and input, the decider
can't take as an input anything other than the description of the
Machine and the input, as that is ALL that the results can depend on.

>
>
>
>>>

On 4/6/23 12:54 PM, Graham Cooper wrote:
> On Friday, April 7, 2023 at 2:49:53 AM UTC+10, Richard Damon wrote:
>> On 4/6/23 12:35 PM, Graham Cooper wrote:
>>> On Friday, April 7, 2023 at 2:28:09 AM UTC+10, Richard Damon wrote:
>>>> On 4/6/23 12:16 PM, Graham Cooper wrote:
>>>>> A better approach is that HALT only returns correct values when called from the top level
>>>>> so D(d) doesnt even exist!
>>>> Except it is impossible to write a computation like that as the behavior
>>>> of a computation is ONLY a function of the defined inputs, and who the
>>>> "caller" of it can't matter.
>>>
>>> its trivial!
>>>
>>> your refusal to see this SIMPLE SIMPLE POINT over and over is your reason for 5 years of regurgitation failure
>>>
>>> you keep swip swapping between NO GLOBAL OR SYSTEM VARIABLES and YEH GLOBAL VARIABLES TOO!
>>>
>>>
>> Because none of those exist in the field of COMPUTABILITY.
>>
>> You are just working in the wrong problem domain.
>>
>>
>> The Halting Problem being mentioned is in the field of primative
>> computability theory, which is a field that is more a part of
>> Mathematics than what we think of as "Programming".
>
> oh you've swip swapped back to
>
> NO GLOBAL VARIABLES are computable
>
> haha...... ur just dumb, for every model of computation an extension exists with global variables
>
>
>

Nope. WITHIN the computation there can be "variables" that are global
with the computation.

The computation ITSELF, has no access to any "globals" except those
specifically defined as inputs.

And, as mentioned, for a Halt Decider, the ONLY allowed inputs are the
description of the machine to decide on and its input, as those are the
ONLY things that its behavior can depend on.

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

In other words you disagree with the notion of a UTM such that the
correct simulation of a machine description does derive the actual
behavior specified by this machine description.

I read a similar story today about a guy that remains convinced that the
Earth is flat.

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

On 4/6/23 1:11 PM, 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
>
> In other words you disagree with the notion of a UTM such that the
> correct simulation of a machine description does derive the actual
> behavior specified by this machine description.

Except that UTM(D,D) says it halts too.

You just don't understand what a UTM actually is, or how logic actually
works.

Your H ISN'T a UTM, and thus can't look at itself to see what a UTM
would actually do, unless it takes into account how it differs from a UTM.

>
> I read a similar story today about a guy that remains convinced that the
> Earth is flat.
>
>
>

> > 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!

>
> 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.

The specification is GIVEN A PROGRAM IDENTIFIER AND ITS INPUT
not GIVEN *ONLY* A PROGRAM IDENTIFIER AND ITS INPUT

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.

Even within the TM framework
a TM exists with emulated global variables (similar to emulating multiple inputs)
for every TM without global variables.

In non-extendible pure computer theory
not many things are possible, and you restrict the domain to this fruitless limited power.

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.

That is all the program will depend on, so if the functions depends on
something else, it MUST be wrong.

>
> 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.

Please explain how a CORRECT answer can use anything else?

>
>
> 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.

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

>
> 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

a general purpose pure function halt wont work
a top level function halt works and fulfills the requirements of its specification

> >
> > 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.
>
> 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

HALT is a TOP STACK LEVEL function

You cant seem to fathom this

> >
> >
> > 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
a DATABASE
a UTM ....... (it changes the definition of a unary input in order to parse 2 inputs with 1 unary number)

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.

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.

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.

>
>
>
>
>>>
>>> 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.
>>
>> 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.

>
> HALT is a TOP STACK LEVEL function
>
> You cant seem to fathom this

Then it isn't a "Computation", so not a valid answer.

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.
>
>
>
>
>
>>>
>>>
>>> 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.

> 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.

> 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.

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.

The correct simulation of D by H does necessarily provide the behavior
that simulating halt decider H must report on.

Without the key detail that H is a simulating halt decider we (and H)
lack sufficient information about the behavior of D to make any decision
about the halt status of D.

When we hypothesize that H is a simulating halt decider then and only
then we can see that D cannot possibly do the opposite of whatever H
decides. This key verified fact breaks the conventional counter-example.

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

On 4/6/23 3:00 PM, 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.

Except even your simulating Halt Decider doesn't get enough information
either.

That is why it says that D(D) is non-halting when D(D) Halts.

>
> The correct simulation of D by H does necessarily provide the behavior
> that simulating halt decider H must report on.

Only if H actually DOES a "Correct Simulation" (by the appropriate
definition, which it DOESN'T DO).

Note, the ACTUAL correct simulation of the input to H(D,D), i.e UTM(D,D)
shows that this input, which represents D(D) does Halt, and thus H was
incorrect, becuase it presumed that the H that D calls was going to get
stuck.

>
> Without the key detail that H is a simulating halt decider we (and H)
> lack sufficient information about the behavior of D to make any decision
> about the halt status of D.

Except that H INCORRECTLY presumed behavior of H that H doesn't do, so
it gets the wrong answer.

>
> When we hypothesize that H is a simulating halt decider then and only
> then we can see that D cannot possibly do the opposite of whatever H
> decides. This key verified fact breaks the conventional counter-example.
>
>

Your problem is you are working off false premises.

You start be ASSUMING that H can get the right answer and will do a
correct simulation, and then based on that you give an answer. Since H
never actually does this, the results its gets is wrong.

Your logic is basically:

If X then Y
Assume X
Thus Y
then do something that makes X false.

Thus, the assume X was a FALSE statement, and the logic of thus Y is
UNSOUND.

You can't base logic on the results of H doing something it doesn't
actually do.

YOU FAIL.

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

>
> 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

>
> 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

> >
> >
> >
> >
> >>>
> >>> 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

> >>
> >> 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

> >
> > 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

>
> 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

> >
> >
> >
> >
> >
> >>>
> >>>
> >>> 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

>
> > 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

> > 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

its

f( set_of_numbers ) -> number

which is the same as adding global or system variables