Re: My reviewers think that halt deciders must report on the behavior of their caller

On 7/8/25 12:19 PM, olcott wrote:

On 7/8/2025 11:07 AM, joes wrote:

Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:

On 7/8/2025 6:13 AM, Richard Damon wrote:

On 7/7/25 10:38 PM, olcott wrote:

On 7/7/2025 9:18 PM, Richard Damon wrote:

On 7/7/25 7:52 PM, olcott wrote:

On 7/7/2025 5:41 PM, Richard Damon wrote:

On 7/7/25 2:38 PM, olcott wrote:

On 7/7/2025 2:36 AM, Fred. Zwarts wrote:

Op 07.jul.2025 om 05:12 schreef olcott:

On 7/6/2025 9:09 PM, Richard Damon wrote:

On 7/6/25 4:06 PM, olcott wrote:

On 7/6/2025 12:00 PM, Richard Damon wrote:

>

And there is no way for HHH to correctly simulate its input
and return an answer
>

You insistence that a non-terminating input be simulated until
non-existent completion is especially nuts because you have
been told about this dozens of times.
What the F is wrong with you?
>

It seems you don't understand those words.
I don't say that the decider needs to simulate the input to
completion, but that it needs to be able to actually PROVE that
if this exact input WAS given to a correct simultor (which
won't be itself, since it isn't doing the complete simulation)
will run for an unbounded number of steps.
>

No decider is ever allowed to report on anything besides the
actual behavior that its input actually specifies.

Ah, but your HHH does report on a *hypothetical* input that wouldn't
call the aborting simulator HHH, but instead a *different* (possibly
similar) simulator that would *not* abort.
>

And HHH does not do that. The input specifies a halting program,
because it includes the abort code. But HHH gives up before it
reaches that part of the specification and the final halt state.

>
I have corrected you on this too many times.
You have sufficiently proven that you are dishonest or
incompetent.
*This code proves that you are wrong*
https://github.com/plolcott/x86utm/blob/master/Halt7.c That you
are too F-ing stupid to see this is less than no rebuttal at all.
>

No, that code proves that HHH, as defined, always aborts its
simulation of DDD and returns 0,

That is counter-factual and you would know this if you had good C++
skills.
>

How is it "Counter-Factual"?
It is YOU that is just counter-factual.
>

"No, that code proves that HHH, as defined,
   always aborts its simulation of DDD"
That is a false statement. If you understood the code you would know
your error.
>

Really, so how does that code NOT aboft its simulation of DDD?

>
You have a reading comprehension problem.
When critique words you are strictly not allowed to change even a single
word without being dishonest.
"No, that code proves that HHH as defined
     always aborts its simulation of DDD"
If you can't figure how how that is false we have conclusively proved
your lack of sufficient technical competence.

 

Wow. Can't you just answer the question?

 I made a statement that another word-for-word statement
is false. Richard changes the words and then asks how
this changed statement is false.
 *DON'T F-ING CHANGE THE WORDS*

But that is the only thing you know how to do.
After all, you have tried to change the meaning of most of the terms-of-art that you use, like Program, Input, Halting, Proof, Truth, Turing Machine/

It is far too easy for mindless idiots to baselessly
claim that I am wrong. That it why I am forcing
Richard to find his own mistake.

Right, because you ARE wrong, because you can't provide and facts to back up your claim.

 If I were to simply tell him the answer he could
simply baselessly deny it. When I make him figure
the answer out for himself then he either uses
actual reasoning or his question is never answered.

 

Also, "we" and "proved"? Not
being understood isn't very convincing. So how does HHH not abort?
>

 If you could understand the code you would know
that my claims are proven.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
 That you cannot understand that code is less than no
rebuttal at all.