Re: D simulated by H never halts no matter what H does V3 ---

On 5/4/2024 9:49 PM, Richard Damon wrote:

On 5/4/24 9:30 PM, olcott wrote:

On 5/4/2024 8:05 PM, Richard Damon wrote:

On 5/4/24 8:49 PM, olcott wrote:

On 5/4/2024 7:44 PM, Richard Damon wrote:

On 5/4/24 8:20 PM, olcott wrote:

On 5/4/2024 7:07 PM, Richard Damon wrote:

On 5/4/24 7:51 PM, olcott wrote:

On 5/4/2024 6:32 PM, Richard Damon wrote:

On 5/4/24 7:01 PM, olcott wrote:

On 5/4/2024 5:36 PM, Richard Damon wrote:

On 5/4/24 6:08 PM, olcott wrote:

On 5/4/2024 4:43 PM, Richard Damon wrote:

On 5/4/24 5:18 PM, olcott wrote:

On 5/4/2024 3:40 PM, Richard Damon wrote:

On 5/4/24 2:46 PM, olcott wrote:

On 5/4/2024 12:15 PM, Richard Damon wrote:

On 5/4/24 12:31 PM, olcott wrote:

On 5/4/2024 10:52 AM, Richard Damon wrote:

On 5/4/24 10:48 AM, olcott wrote:

On 5/4/2024 9:39 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 5/4/2024 5:56 AM, Alan Mackenzie wrote:

[ Followup-To: set ]

>

In comp.theory olcott <polcott333@gmail.com> wrote:

>
[ .... ]
>

You are doing better than Alan on this though he doesn't
have a single clue about what execution traces are or how
they work.

>

You should read "How to make friends and influence people" by Dale
Carnegie.  You may not care about the former, but you sure are trying
the latter.  Hint: telling nasty lies about people is not effective.

>
>

The alternative of disparaging my work without even looking at
it is far worse because it meets the

>

https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html

>

required for libel and defamation cases.

>
No.  There have got to be limits on what one spends ones time on. You

>
None-the-less saying that I <am> wrong without looking at what
I said <is> defamatory. Saying that you believe that I am wrong
on the basis that I do not seem to have credibility is not defamatory.
>

have been maintaining false things over the years to such a degree that
it would be a waste of time suddenly to expect brilliant insights from
you.  For example, you insist that robustly proven mathematical theorems
are false, and your "reasoning" hardly merits the word.
>

>
Can D correctly simulated by H terminate normally?
00 int H(ptr x, ptr x)  // ptr is pointer to int function
01 int D(ptr 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 }
>
Execution Trace
Line 11: main() invokes H(D,D);
>
keeps repeating (unless aborted)
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 03.
>
Yet saying that the above is false <is> defamatory because anyone
with ordinary skill in the art of C programming can determine that
it is true by verifying that the execution trace is correct.
>
When you say it is false by either not verifying that the execution
trace is correct or not knowing what execution traces are <is>
defamatory.

>
But it HAS been proven incorrect and YOU are the one disregarding the evidence.
>
I guess I could file defamatory claims against you.
>

>
It may be the case that you did bury another rebuttal in all of
your rhetoric and ad hominem attacks that were vigorously attempting
to get away with the strawman deception change the subject "rebuttal".

>
But very close to my first part of the reply I indicated that there WAS a detailed description of this at the end, and you replied to that mention, saying that since your statement was categorically true it would be easy to refute, and then you just didn't do so.
>

>
If you post the time/date stamp I will carefully examine it.
Until you do that it seems safe to assume that it was only
the same ruse as this.
>
On 5/1/2024 7:28 PM, Richard Damon wrote:
 > On 5/1/24 11:51 AM, olcott wrote:
 >> *I HAVE SAID THIS AT LEAST 10,000 TIMES NOW*
 >> Every D simulated by H that cannot possibly stop running unless
 >> aborted by H does specify non-terminating behavior to H. When
 >> H aborts this simulation that does not count as D halting.
 >
 > Which is just meaningless gobbledygook by your definitions.
 >
 > It means that
 >
 > int H(ptr m, ptr d) {
 >     return 0;
 > }
 >
 > is always correct, because THAT H can not possible simulate
 > the input to the end before it aborts it, and that H is all
 > that that H can be, or it isn't THAT H.
>
*Every D NEVER simulated by H* (as shown above)
is definitely not *Every D simulated by H* (also shown above)
>

So. I guess you ADHD made you forget what you were talking about and made yourself just into a liar.
>
YOU choosing to ignore it, just shows that you are not really interested in an actual honest dialog.
>
I guess it doesn't matter to you what is actually true, as you are going to just assume what you want.
>

>
A reasonable person cannot be reasonably expected to wade through
all of that especially when one of these "rebuttals" interpreted
*D is simulated by H* to mean *D is NEVER simulated by H*

>
But that isn't what distracted you in that message.
>

>
On 5/1/2024 7:28 PM, Richard Damon wrote:
 >> *Every D simulated by H* that cannot possibly stop running unless
 >> aborted by H does specify non-terminating behavior to H. When
 >> H aborts this simulation that does not count as D halting.
 >
 > Which is just meaningless gobbledygook by your definitions.
 >
 > It means that
 >
 > int H(ptr m, ptr d) {
 >     return 0;
 > }
 >
 > is always correct, because THAT H can not possible simulate
 > the input to the end before it aborts it, and that H is all
 > that that H can be, or it isn't THAT H.
>
One shows a reckless-disregard-of-the-truth when they "interpret"
*D is simulated by H*
   to mean
*D is NEVER simulated by H*
>
>

>
But 0 steps is a number of steps.
>

>
*I did not say any number of steps*
>
 > On 5/1/24 11:51 AM, olcott wrote:
 >> *I HAVE SAID THIS AT LEAST 10,000 TIMES NOW*
 >> *Every D simulated by H* that cannot possibly stop running unless
 >> aborted by H does specify non-terminating behavior to H. When
 >> H aborts this simulation that does not count as D halting.
>
*Every D simulated by H* IS NOT *Any D NEVER simulated by H*
*Every D simulated by H* IS NOT *Any D NEVER simulated by H*
*Every D simulated by H* IS NOT *Any D NEVER simulated by H*
*Every D simulated by H* IS NOT *Any D NEVER simulated by H*

>
WITHOUT DEFINING EXACTLY WHAT "SIMULATED" means.
>

>
(1) You have already acknowledged that you what it means
by all the times that you did agree that D simulated by H
never reaches its own line 06 and halts.

>
No, D simulated by THIS H (and a very restricted family of related programs), as you have defined it, will not reach its own line 06.
>

>
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
>
I have said this many hundreds of times because this shell-game deception has been ridiculous https://en.wikipedia.org/wiki/Shell_game
>

This happens as either said H abort their simulation before the program gets there, or they create an H that just never returns an answer to H(D,D) and thus fail to be a decider. These are two distinct parts of your "family" of H that you like to talk about, that you need to be a bit imprecise about so you can try to mix them up.

>
When N steps of D are simulated by the directly executed H
where N is 1 to 1,000,000 no simulated D every reaches past
its own line 03.
>
When N steps of D are simulated by the directly executed H
where N is 1 to 1,000,000 and H aborts its simulation all of
the nested simulations (if any) immediately totally stop running.
No simulated H ever returns any value to any simulated D.
>

>
(2) What could simulated possibly mean besides the C source-code
of D being interpreted by a C interpreter or the machine-language
of D being emulated by an x86 emulator?

>
Ok, so why doesn't H do that?
>

>
We are not talking about my implemented H we are talking about
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
>

After all, H doesn't actually simulate the call H instruction, which should do what the instruction does, and enter H, or at least do the equivalent results of calling H(D,D) which is to return 0.
>
Typically, to simulate something means to determine what it will do when it is actually done, but you like to claim that H's simulation of the input doesn't need to match the actual behavior of the program described to it, so clearly you are not using simulate in the conventional meanings.
>
You have EXPLICITLY claimed that just becuase D(D) Halts, doesn't mean that H simulating the description of this machine can't be correct when it says it doesn't.
>
So, it is clear that you somehow have rejected some of the essential characteristic of what a "simulation" means, but refuse to actually define it. The likely cause is that you know you CAN'T precisely define it, as you can't make weasle words to allow the illogical conclusion that you make for the call to H being simulated, without makeing to too obvious that something is very broken with your system.
>

>
All of the above is based on the false assumption that we are talking about something other than this:
>
We are not talking about my implemented H we are talking about
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
*Every H/D pair (of the infinite set) where D is simulated by H*
>

>
But what do you mean be "Simulated".
>
What in the definition of simulated allows a call to H that will return 0 be simulated as "never returns"?
>

>
You already understand that infinite recursion never returns.

>
Right, trivially, since it isn't infinite if it does return.
>
So, a recursion call loop that has NOTHING in the loop that can break it, becomes infinite.
>
>

You already understand that recursive simulation is isomorphic to infinite recursion so I can't see how you can say that you don't understand these things an be sincere.

>
But only for UNCONDITIONAL simulation, which H doesn't do.
>

>
void Infinite_Recursion(u32 N)
{
   Infinite_Recursion(N);
   return;
}
>
OK we are down to one single point at a time, when that point is
divided into ten more points only one of them at a time we keep
dividing them until your rebuttal looks like ridiculous nonsense
to everyone including yourself.
>
The ONLY point right now is that H(Infinite_Recursion, (ptr)5));
is correct when it reports that Infinite_Recursion() never halts
on the basis that Infinite_Recursion simulated by H never reaches
its return statement.

>
Yes, since Infinite_Recursion has a full unconditional loop back to the original point, it will be a non-halting program and thus no correct simulation of it can reach an end, because the program it is simulating will never reach an end.
>

>
But H does not simulate it forever its simulation
of Infinite_Recursion() is conditional. How it is
that Infinite_Recursion() never halts when H stops
simulating it?

>
Becuase, as you don't seem to understand, the behavior of programs is what they do as ideal mathematical objects on the ideal mathematical machine they are concidered to be run on, NOT what some simulation of them shows.
>

>
Ah so you disagree with UTM's why do disagree with UTM's ?
We must stay on this single point until it is fully addressed.
If it is divided into subpoints the same thing goes for each subpoint.

>
Why do you say I disagree with UTMs?
>

>
The quoted paragraph that I am referring to.
If you disagree with yourself on this paragraph please elaborate.

 If H doesn't simulate it forever, it just isn't a UTM.
 

Whoa, Factorial of 5 must simulate forever?

Note, you CAN'T just "Stipulate" that a given machine IS a UTM except by defining that it works just like a UTM, which means, for one thing, it can NEVER abort its simulation, not even after determining that it will simulate this input forever.
 

None-the-less a TM that correctly simulates N steps
cannot be said to have simulated those N steps incorrectly
on the basis that it could have simulated N+1 steps.

You seem to have a trouble understanding that definitions actually define what they define, and something that doesn't meet the requirements can't be considered to be the thing it isn't.
 

I get into more nuances than the textbooks bother to discuss.
That I get into more nuances than the textbooks bother to discuss
does not make me wrong.

And, you H ISN'T a UTM if it aborts its simulation and answer.
 

>
I want you to specify all of the cases where a UTM simulation
of an input is wrong.
>

 A UTM simulation of the input CAN'T be wrong, because if a simulator differs from the actual behavior of the program described by the input, the simulator is NOT a UTM.
 You don't seem to understand the meaning of the terms, or presume that you can assume that something can be something it isn't.
 

I am trying to provide the basis for you to correctly extrapolate
beyond what the textbooks say. Many people act as if all new ideas
are always wrong because these new ideas do not precisely parrot
existing ideas. There really is a correct extrapolation from existing
ideas to new ideas and these new ideas are not inherently incorrect.

>

I UTM is DEFINED that it produces the exact same result as the direct execution of the machine. A machine is only a UTM if it does that (and you can't stipulate that a machine is a UTM if it doesn't do that)
>
A program is a UTM *IF AND ONLY IF* the results it produces ALWAYS exactly matches the behavior of the direct execution of the program descirbed to it.
>
Thus, BY DEFINITION, a UTM can not "abort" its simulation, as the UTM of a non-halting program must be non-halting (and not just saying "non-halting").
>
A UTM doesn't "describe" what the input program does, it recreates the behavior.
>
YOU seem to have a misunderstanding on this, as you like to call your H a "UTM" even though it fails to meet the definition.
>
Of course, that is because you don't understand the definition, of the definition of definitions.
>
>

>

As I have mentioned MAMY times, you seem to have a fundamental confusion between the RUNNING of the program, and the SIMULATION of it.
>
This seems to go back to your lack of understand what Truth actually is.
>
>
RUNNING is what happens when it is carried out completely correctly, as with a real correct processor which is left to run, or on the mathematical model, that runs until it finishes (even if never)
>
SIMULATING, in the proper case, means simulating the steps of the program until you can correctly determine the answer for what you are tying to do the simulation. IF it is about the behavior of actually running the program, as is the job of a Halt Decider, then it doesn't matter if the simulation is stopped at some point, but if the simulation was able to actually PROVE the behavior of the actual program.
>
With Infinite_Recursion, there ARE proof steps that can be do to atually formally prove that this program can NEVER reach a final state, and thus, a properly designed H can correctly abort it simulation and say the program represented by the input does not halt.
>
Note, This logic has NOTHING to do with "The input simulated by the Decideer" type questions, but is ALWAYS asking about the behavior of the original machine as run.
>
If you want to try to define some meaning into your gobbledygook of "D simulated by H", then YOU need to figure out what you can't figure out how to handle even these trivial cases, you have a LOT of work in front of you,
>
So, if YOU are questioning why H can be correct saying its simulation of Infinite-Recursion would be non-halting, why do you think it is correct about D?
>

>
All other points are ignored until this point is
fully addressed.

>
Yep, YOU need to decide how you want to define this,
>
If your criteria is NOT about the actual behavior of the actual program, YOU need to figure out what you want, and how to define it, THEN you can try to show why this new condition has any actual practical purpose.
>
Just makinging something very loosely related to halting decidable, isn't likely going to win many people over.
>

>

>
To go forward a step (ignore if you please, but I see where you are trying to go.
>
void Infinite_Simulation(ptr p)
{
     UTM(p, p);
     return;
}
>
will also be an "infinte behavior" program when looked at as
>
H(Infinite_Simulation, Infinite_Simulation)
>
as the FULL loop (including through the UTM) is unconditional.
>
>
BUT
>
void X(ptr p)
{
     H(p,p)
     return
}
>
is NOT the same if H(X,X) will ever decide to abort and return a decision, thinking it is like the Infinite_Simulation case, as the FULL Loop, which includes the code of H, is not unconditional.
>
And this is true as if we just run X(X), then it will call H(X,X) which, since you say H(X,X) will eventually decide to abort its simulation and return, so X(X) WILL reach its final state, and that says that one of my proposals could detect that and reach past the call.
>
Note, this is NOT the "imposible program", as it doesn't have the contray stuff at the end, but your H can't know that, so its logic must be wrong.
>

>

>

>

>

>

 

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