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

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

On 2024-05-03 11:38:43 +0000, olcott said:
 

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.

 WHat I said is true. Perhaps some people fail to notice the
ambiguity and answer to one of possible interpretations. If
their interpretation is not known it is not possible to know
what they really answered.
 

"(D) simulated by H" can only mean that H is a C interpreter that interprets the C source code of D or H uses an x86 emulator to emulate
the x86 machine-code of D.
What else did you think that it meant?
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer