XPost: sci.logic

On 6/21/24 7:27 PM, olcott wrote:

On 6/21/2024 4:46 PM, Richard Damon wrote:

On 6/21/24 5:25 PM, olcott wrote:

On 6/21/2024 4:10 PM, Richard Damon wrote:

On 6/21/24 4:52 PM, olcott wrote:

On 6/21/2024 3:00 PM, Richard Damon wrote:

On 6/21/24 3:45 PM, olcott wrote:

On 6/21/2024 2:33 PM, Richard Damon wrote:

On 6/21/24 3:19 PM, olcott wrote:

int sum(int x, int y){ return x + y; }
When this program is asked: sum(3,4) this maps to 7.
When this program is asked: sum(5,6) this DOES NOT map to 7.

Right.

When H is asked H(D,D) this maps to D correctly simulated by H. >>>>>>>>> When H is asked H(D,D) this DOES NOT map to behavior that halts. >>>>>>>>>

Nope. H(M,d) is DEFINED (if it is correct) to determine if M(d) >>>>>>>> will Halt.

If one "defines" that the input to H(D,D) maps to the behavior
of D(D) yet cannot show this because it does not actually
map to that behavior *THEN THE DEFINITION IS SIMPLY WRONG*

But we CAN show that it maps to the behavior of D(D) (at least
when the representation of D includes the H that is giving the 0
answer) by just runnig it and seeing what it does.

No you cannot show that the mapping for the input to
H(D,D) maps to the behavior of D(D).

The DEFINITION of a Halt Decider gives what H is SUPPOSED to do, if
it is one.

You claim it is a correct Halt decider

When we do not simply make false assumptions about the
behavior that the input to H(D,D) specifies:
   That the call from D correctly simulated by H to H(D,D) returns

What "False Assumption"?

You just are ignorant of the DEFINTION of the problem.

*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*
*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*
*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*

But DEFINITIONS DO.

To "define" that the call from the D correctly simulated
by H to H(D,D) returns when the actual facts prove that
this call *DOES NOT RETURN* is ultimately unreasonable
because *THERE IS NO REASONING* that supports this.

But that isn't the definition that we are using.

NOTHING talks about the correct simulation BY H, except the invalid and
broken Olcott-Computation theory, which we are not using here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Am Fri, 21 Jun 2024 22:16:55 -0500 schrieb olcott:

On 6/21/2024 6:38 PM, Richard Damon wrote:

On 6/21/24 7:27 PM, olcott wrote:

On 6/21/2024 4:46 PM, Richard Damon wrote:

On 6/21/24 5:25 PM, olcott wrote:

On 6/21/2024 4:10 PM, Richard Damon wrote:

On 6/21/24 4:52 PM, olcott wrote:

On 6/21/2024 3:00 PM, Richard Damon wrote:

On 6/21/24 3:45 PM, olcott wrote:

On 6/21/2024 2:33 PM, Richard Damon wrote:

On 6/21/24 3:19 PM, olcott wrote:

Nope. H(M,d) is DEFINED (if it is correct) to determine if M(d) >>>>>>>>>> will Halt.

But we CAN show that it maps to the behavior of D(D) (at least >>>>>>>> when the representation of D includes the H that is giving the 0 >>>>>>>> answer) by just runnig it and seeing what it does.

The DEFINITION of a Halt Decider gives what H is SUPPOSED to do, if >>>>>> it is one.
You claim it is a correct Halt decider

When we do not simply make false assumptions about the behavior that >>>>> the input to H(D,D) specifies:
   That the call from D correctly simulated by H to H(D,D) returns

What "False Assumption"?
You just are ignorant of the DEFINTION of the problem.

*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*

But DEFINITIONS DO.

To "define" that the call from the D correctly simulated by H to
H(D,D) returns when the actual facts prove that this call *DOES NOT
RETURN* is ultimately unreasonable because *THERE IS NO REASONING*
that supports this.

If H really is a decider, it returns.

But that isn't the definition that we are using.

NOTHING talks about the correct simulation of D ONLY because I am the
sole inventor of simulating halt deciders that no one ever thought ALL-THE-WAY through before.

Unlikely.
Again, the simulation shouldn't change anything.

The semantics of the x86 language conclusively proves as a verified fact
that the behavior that D specifies to H is different than the behavior
that D specifies to H1.

But D is the same in either case?!

You cannot simply correctly ignore that the pathological relationship
that D calls H(D,D) and does not call H1(D,D) changes the behavior of D between these two cases.

The behaviour changes only because of the called H.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/21/24 11:16 PM, olcott wrote:

On 6/21/2024 6:38 PM, Richard Damon wrote:

On 6/21/24 7:27 PM, olcott wrote:

On 6/21/2024 4:46 PM, Richard Damon wrote:

On 6/21/24 5:25 PM, olcott wrote:

On 6/21/2024 4:10 PM, Richard Damon wrote:

On 6/21/24 4:52 PM, olcott wrote:

On 6/21/2024 3:00 PM, Richard Damon wrote:

On 6/21/24 3:45 PM, olcott wrote:

On 6/21/2024 2:33 PM, Richard Damon wrote:

On 6/21/24 3:19 PM, olcott wrote:

int sum(int x, int y){ return x + y; }
When this program is asked: sum(3,4) this maps to 7.
When this program is asked: sum(5,6) this DOES NOT map to 7. >>>>>>>>>>

Right.

When H is asked H(D,D) this maps to D correctly simulated by H. >>>>>>>>>>> When H is asked H(D,D) this DOES NOT map to behavior that halts. >>>>>>>>>>>

Nope. H(M,d) is DEFINED (if it is correct) to determine if >>>>>>>>>> M(d) will Halt.

If one "defines" that the input to H(D,D) maps to the behavior >>>>>>>>> of D(D) yet cannot show this because it does not actually
map to that behavior *THEN THE DEFINITION IS SIMPLY WRONG*

But we CAN show that it maps to the behavior of D(D) (at least >>>>>>>> when the representation of D includes the H that is giving the 0 >>>>>>>> answer) by just runnig it and seeing what it does.

No you cannot show that the mapping for the input to
H(D,D) maps to the behavior of D(D).

The DEFINITION of a Halt Decider gives what H is SUPPOSED to do,
if it is one.

You claim it is a correct Halt decider

When we do not simply make false assumptions about the
behavior that the input to H(D,D) specifies:
   That the call from D correctly simulated by H to H(D,D) returns

What "False Assumption"?

You just are ignorant of the DEFINTION of the problem.

*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*
*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*
*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*

But DEFINITIONS DO.

To "define" that the call from the D correctly simulated
by H to H(D,D) returns when the actual facts prove that
this call *DOES NOT RETURN* is ultimately unreasonable
because *THERE IS NO REASONING* that supports this.

But that isn't the definition that we are using.

NOTHING talks about the correct simulation BY H, except the invalid
and broken Olcott-Computation theory, which we are not using here.

NOTHING talks about the correct simulation of D ONLY because
I am the sole inventor of simulating halt deciders that no one
ever thought ALL-THE-WAY through before.

Which means it CAN'T be the definition of the criteria for the Halting
Problem.

So, you are just ADMITTING that you are LYING about working on the
ACTUAL halting problem, but are just trying to fabricate a new
Olcott-Halting Problem, based on Olcott-Halting that no one else cares
about.

The semantics of the x86 language conclusively proves as a verified
fact that the behavior that D specifies to H is different than the
behavior that D specifies to H1.

Nope. Which instruction, correctly simulated was different between the
"Correct simulation by H" and the actual execution.

It seems, as I best understand your claim, that will you claim to be
actually simulating the actual x86 instructions, your "Correct
Simulation" somehow knows that the call H shouldn't actually simulate
the x86 instructions that it goes to, but instead, act like the
effective results of the function you want H to be. THAT is NOT "Correct
x86 simulation", or correct simulation of any form.

The key point is that even just a functional simulation need the
simulation of H(D,D) to do the same thing that H(D,D) does, which in
this case is to return 0.

You cannot simply correctly ignore that the pathological relationship
that D calls H(D,D) and does not call H1(D,D) changes the behavior of
D between these two cases.

But that relationship doesn't affect what a correct simulation is. It
might make it IMPOSSIBLE for H to completely correctly simulate its
input, or prove that such a simulation will actually go on forever, but
it doesn't change what a correct simulation is.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/22/24 12:31 AM, olcott wrote:

On 6/21/2024 11:24 PM, joes wrote:

Am Fri, 21 Jun 2024 22:16:55 -0500 schrieb olcott:

On 6/21/2024 6:38 PM, Richard Damon wrote:

On 6/21/24 7:27 PM, olcott wrote:

On 6/21/2024 4:46 PM, Richard Damon wrote:

On 6/21/24 5:25 PM, olcott wrote:

On 6/21/2024 4:10 PM, Richard Damon wrote:

On 6/21/24 4:52 PM, olcott wrote:

On 6/21/2024 3:00 PM, Richard Damon wrote:

On 6/21/24 3:45 PM, olcott wrote:

On 6/21/2024 2:33 PM, Richard Damon wrote:

On 6/21/24 3:19 PM, olcott wrote:

Nope. H(M,d) is DEFINED (if it is correct) to determine if M(d) >>>>>>>>>>>> will Halt.

But we CAN show that it maps to the behavior of D(D) (at least >>>>>>>>>> when the representation of D includes the H that is giving the 0 >>>>>>>>>> answer) by just runnig it and seeing what it does.

The DEFINITION of a Halt Decider gives what H is SUPPOSED to do, if >>>>>>>> it is one.
You claim it is a correct Halt decider

When we do not simply make false assumptions about the behavior that >>>>>>> the input to H(D,D) specifies:
    That the call from D correctly simulated by H to H(D,D) returns >>>>>>

What "False Assumption"?
You just are ignorant of the DEFINTION of the problem.

*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*

But DEFINITIONS DO.

To "define" that the call from the D correctly simulated by H to
H(D,D) returns when the actual facts prove that this call *DOES NOT
RETURN* is ultimately unreasonable because *THERE IS NO REASONING*
that supports this.

If H really is a decider, it returns.

But that isn't the definition that we are using.

NOTHING talks about the correct simulation of D ONLY because I am the
sole inventor of simulating halt deciders that no one ever thought
ALL-THE-WAY through before.

Unlikely.
Again, the simulation shouldn't change anything.

The semantics of the x86 language conclusively proves as a verified fact >>> that the behavior that D specifies to H is different than the behavior
that D specifies to H1.

But D is the same in either case?!

You cannot simply correctly ignore that the pathological relationship
that D calls H(D,D) and does not call H1(D,D) changes the behavior of D
between these two cases.

The behaviour changes only because of the called H.

void DDD()
{
  H0(DDD);
}

int main()
{
  H0(DDD);
  H1(DDD);
}

DDD correctly simulated by H1 halts.
DDD correctly simulated by H0 never halts.

And thus you prove that your criteria, "Correctly simulated by the
decider" is NOT a valid property of the input, because there is not a
mapping of (input) -> (output), but only a mapping of:

(input, decider) -> (output)

Thus, it is not a property of the input alone.

So, NOT a valid property to be a replacement for Halting.

Note, the problem is you are creating a SUBJECTIVE property when you
need an OBJECTIVE property. The fact we need to know who is being asked
to know what the right answer is makes the property subjective, and thus
not the sort of thing that the logical system talks about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/22/24 9:12 AM, olcott wrote:

On 6/22/2024 8:03 AM, Richard Damon wrote:

On 6/22/24 12:31 AM, olcott wrote:

On 6/21/2024 11:24 PM, joes wrote:

Am Fri, 21 Jun 2024 22:16:55 -0500 schrieb olcott:

On 6/21/2024 6:38 PM, Richard Damon wrote:

On 6/21/24 7:27 PM, olcott wrote:

On 6/21/2024 4:46 PM, Richard Damon wrote:

On 6/21/24 5:25 PM, olcott wrote:

On 6/21/2024 4:10 PM, Richard Damon wrote:

On 6/21/24 4:52 PM, olcott wrote:

On 6/21/2024 3:00 PM, Richard Damon wrote:

On 6/21/24 3:45 PM, olcott wrote:

On 6/21/2024 2:33 PM, Richard Damon wrote:

On 6/21/24 3:19 PM, olcott wrote:

Nope. H(M,d) is DEFINED (if it is correct) to determine if >>>>>>>>>>>>>> M(d)
will Halt.

But we CAN show that it maps to the behavior of D(D) (at least >>>>>>>>>>>> when the representation of D includes the H that is giving >>>>>>>>>>>> the 0
answer) by just runnig it and seeing what it does.

The DEFINITION of a Halt Decider gives what H is SUPPOSED to >>>>>>>>>> do, if
it is one.
You claim it is a correct Halt decider

When we do not simply make false assumptions about the behavior >>>>>>>>> that
the input to H(D,D) specifies:
    That the call from D correctly simulated by H to H(D,D) >>>>>>>>> returns

What "False Assumption"?
You just are ignorant of the DEFINTION of the problem.

*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*

But DEFINITIONS DO.

To "define" that the call from the D correctly simulated by H to >>>>>>> H(D,D) returns when the actual facts prove that this call *DOES NOT >>>>>>> RETURN* is ultimately unreasonable because *THERE IS NO REASONING* >>>>>>> that supports this.

If H really is a decider, it returns.

But that isn't the definition that we are using.

NOTHING talks about the correct simulation of D ONLY because I am the >>>>> sole inventor of simulating halt deciders that no one ever thought
ALL-THE-WAY through before.

Unlikely.
Again, the simulation shouldn't change anything.

The semantics of the x86 language conclusively proves as a verified
fact
that the behavior that D specifies to H is different than the behavior >>>>> that D specifies to H1.

But D is the same in either case?!

You cannot simply correctly ignore that the pathological relationship >>>>> that D calls H(D,D) and does not call H1(D,D) changes the behavior
of D
between these two cases.

The behaviour changes only because of the called H.

void DDD()
{
   H0(DDD);
}

int main()
{
   H0(DDD);
   H1(DDD);
}

DDD correctly simulated by H1 halts.
DDD correctly simulated by H0 never halts.

And thus you prove that your criteria, "Correctly simulated by the
decider" is NOT a valid property of the input, because there is not a
mapping of (input) -> (output), but only a mapping of:

(input, decider) -> (output)

Thus, it is not a property of the input alone.

So, NOT a valid property to be a replacement for Halting.

Note, the problem is you are creating a SUBJECTIVE property when you
need an OBJECTIVE property. The fact we need to know who is being
asked to know what the right answer is makes the property subjective,
and thus not the sort of thing that the logical system talks about.

It is a verified fact that the behavior that finite string DDD presents
to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that
this call DOES NOT RETURN.

It is a verified fact that the behavior that finite string DDD presents
to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that
this call DOES RETURN.

I don't get why people here insist on lying about verified facts.

The problem is that the "behavior" that the finite string DDD presents
to HH0, is DEFINED by the problem. And if that problem is the Halting
Problem, that behavior is the behavior of the machine the input
represents. If HH0 treats the input as having a different behavior, then
HH0 just isn't a Halting Decider, but something else.

If HH0 is supposed to be a Halting decider, but uses a method that makes
it see something other than that behavior, then it is just an incorrect
Halting Decider, and its algorithm just creates an incorrect recreation
of the property of the input it is supposed to be working on.


A bit of a side note, the actual "Input" to HH0, is a pointer to memory,
and as such it passes a reference to ALL of memory considering the
starting point to be that address, so your "Input" isn't actually the
few bytes of DDD, but ALL of memory and a starting point. If you
actually mean that the input is just those few bytes pointed to by the
address, then the input is improperly formed and is NOT a proper
representation of the input machine, becuase it is incomplete.

The fact you don't understand this, seems to imply you are lacking the
basic knowledge to be talking about this sort of thing.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)