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

On 5/3/24 11:20 PM, olcott wrote:

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

On 5/3/24 7:38 AM, olcott wrote:

On 5/3/2024 3:54 AM, Mikko wrote:

On 2024-05-02 14:22:12 +0000, olcott said:
>

On 5/2/2024 4:55 AM, Mikko wrote:

On 2024-05-01 15:45:04 +0000, olcott said:
>

On 5/1/2024 4:43 AM, Mikko wrote:

On 2024-04-30 15:36:00 +0000, olcott said:
>

On 4/30/2024 3:52 AM, Mikko wrote:

On 2024-04-29 15:40:18 +0000, olcott said:
>

On 4/29/2024 10:16 AM, Mikko wrote:

On 2024-04-29 14:26:59 +0000, olcott said:
>

On 4/29/2024 4:11 AM, Mikko wrote:

On 2024-04-28 13:13:48 +0000, olcott said:
>

On 4/28/2024 3:40 AM, Mikko wrote:

On 2024-04-27 17:51:17 +0000, olcott said:
>

When you agree that H(D,D) is a correct termination analyzer within
my definition then we can proceed to the next point about whether
my definition is correct or diverges from the standard definition.

>
Nobody will agree that H(D,D) is a correct termination analyzer
until you post a definition of "termination analyzer" and compare
H(D,D) to that definition. And nut even then if the comparison is
insufficient or erronous.

>
Unless they go through every single slight nuance of the details
of my reasoning they won't be able to see that I am correct.

>
Then the expected result is that they will never see that you are correct.
>

Unless I insist that they go through every single slight nuance of the
details of my reasoning THEY ALWAYS LEAP TO THE CONCLUSION THAT I AM
WRONG SIMPLY IGNORING WHAT I SAY.

>
Is there any reason to expect a differen result if you do insist?

>
I now have an airtight proof that I am correct.

>
That does not matter unless you post a pointer to that proof (either
a web page or a publication).
>

>
*That does not work*
At best people simply misinterpret what I say and then conclude
that I must be wrong based on their misinterpretation.

>
That is unavoidable if your presentation is broken to separately
posted parts. Readers may miss some parts or read the parts in a
wrong order, which inevitably affects how they interpret it.
>

Here is the most updated version of my paper.
>
There are single sentences in this paper that require long dialogues
to be fully understood.

>
A paper should be written so that it can be understood without any
dialogue. If a dialogue is needed that indicates that the paper needs
an improvement.
>

>
That is impossible. I tried to have it analyzed on that basis and then
people misconstrue a dozen different points at once and have no idea
what I am saying.

>
If it is impossible to say what you want to say then there is
no point to try.
>

>
It is impossible to say what I need to say in such a way that people
cannot intentionally misconstrue what I say as their rebuttal tactic.

>
It is possible to write clearly enough that no attempt to intentionally
misconstrue is convincing.
>

When I insist that we go over all of the details of each key point
then it is no longer possible to intentionally misconstrue what I
say without it being dead obvious that the misconstrual is intentional.

>
Insisting does not help. You only need to go over all the details
that are pointed out and keep fixing until no remaining misconstrual
is convincing.
>

However, one failure is not a proof of impossibility. Improve the
text and ask again.
>

*Termination Analyzer H is Not Fooled by Pathological Input D*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

>
You should post a link to that page whenever you are talking about
anything explained on that page (unless, of course, you post a link
to a page that has a better explanation).
>

>
When I do that people very carefully glance at a few words and
then leap to the conclusion that I must be wrong.
>
The only way around that it to require people to go over my ideas
one at a time until we reach mutual agreement on each idea.

>
I don't think that is the way. You have already tried so many times
that if that could work it would have worked already.

>
I tried this on another forum with great success. After 150 messages
and replies we got 100% perfect mutual agreement on one key point.
It is a lot like this:

>
Your success rate here is much lower.
>

>
Only because people here seem to really want to intentionally misconstrue what has been perfectly understood on other forums.

>
You must either adapt or wait until the situation has changed.
>

Socratic questioning
https://en.wikipedia.org/wiki/Socratic_questioning

>
Only works if one can find the right questions, which is not always
easy although sometimes it is.

>
The key aspect is the granularity of the questions such that
leaping to conclusion becomes impossible because of the tiny
scope of each question.

>
Yes. However, the granularity must not be too fine or the respondent
goes away before all qustions are answered.
>
But this approach does not work if you want argue against an author
who is not present and can't be asked questions.
>

We have never tried that going completely through every single detail
of reasoning here. My reviews here are mostly you are wrong you don't
know logic you are just a stupid liar.

>
If you don't want to be called "mostly wrong" you must put more effort
to correcting your arguments, and keep posting pointers to your most
recent relevant corrections.

>
We need to go at a very low level of granularity.
The first level of granularity seeks mutual agreement
on the pure software engineering aspect of this:
>
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.
>
No aspect of computer science can be discussed until after
all of the software engineering has mutual agreement.

>
If you could achieve that you would have achieved alredy.
>

If you don't wnat to be called "ignorant of logic" you must be more
careful with the logical validity of your inferences and proofs and
avoid saying anything that could sound like ingnorance of logic.
>
If you don't want to be called "stupid" you should avoid saying
anytingh stupid, and you should more often show that you understand
at least something.
>
If you don't want to be called a "liar" you must not say anything
false or possibly false about what other people have done or said.

>
I have been correct all along so all of the adjectives are incorrect.

>
You havn't but that is not relevant. The point is that you are seen
as incorrect more often and about more topics as correct.
>

When we go over all of the tiny details then I will be understood to
have been correct all along.

>
Unlikely to ever happen.
>

I must insist that we go over these details otherwise people
only glance at a few words and leap to the conclusion that
I must be wrong.

>
They will do the same anyway.
>

The software engineering aspects of this are like arithmetic
in that they do have a 100% objective correct versus incorrect
assessment with zero subjective judgement calls inbetween.

>
Those that the most important things to get right. Not the
software engineering aspects but arithmetic and similar.
Validity of a formal proof is like syntactic correctness
of a program: it can be checked with a computer.
>

So far most people here have disagreed with the basic facts
of software engineering so that they could have some basis
for rebuttal.

>
As sofware engineering is less relevant than the basic theory
you should use the latter. Analogies from software engineering
can be helpful but not convincing.
>

By insisting that we attain mutual agreement on this before
proceeding on to any other point it becomes much more difficult
for people to disagree with basic facts of software engineering.

>
No, it does not. People can agree anyway, just like you do.
>

(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether H
aborts its simulation or not.

>
The expression "simulated D(D)" is too ambigous to perimit or
exploit any agreement.
>

>
That is not true otherwise four people would not have been
able to easily correctly answer.

>
Just anothor of your fallacies.
>
Since your answer is incorrect
>

>
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.
>
(a) It is a verified fact that D(D) simulated by H cannot
possibly reach past line 03 of D(D) simulated by H whether
H aborts its simulation or not.
>

Proven incorrect and you have decline to try to refute it, thus conceding it to be incorrect, and your restatement just a lie.
>

 "proven to be incorrect" by nonsense gibberish
That "D simulated by H" can mean "D NEVER simulated by H"

Nope, and you are just showing your utter stupidity. That example wasn't showing how your (a) wasn't true, but show how stupid your requirement, because it does allow for some very trivial versions of H that make virtually all input program properly called non-halting.

 Also you fail to understand that when the executed H(D,D)
aborts its simulated input that all of the nested simulations
(if any) immediately totally stop running. No simulated H ever
returns any value to any simulated D.

So? What you fail to understand is that aborting a simulation of a program does absolutly NOTHING to the actual behavior of the program that it was simulating, because the "behavior of the program" is what it does when run, not what some aborted simulaiton does.

 That is only ordinary software engineering with zero subjective
leeway of interpretation. It is just like I yank the power cord
from the wall and you don't understand that the program immediately
stops running.
 

Nope, it shows you don't know the difference between RUNNING a program and SIMULATING it. Aborting the simulation of a program has no affect on the behavior of that exact same program when it was run.

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.