Re: What it would take... TO GET MY REVIEWERS TO PAY COMPLETE ATTENTION?

On 5/12/25 8:16 PM, olcott wrote:

On 5/12/2025 6:58 PM, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:
>

On 12/05/2025 18:21, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:
>

The HHH code doesn't exactly invite confidence in its author, and his theory
is all over the place, but a thought experiment suggests itself.
>
If we were not all wasting our time bickering with a career bickerer... if
we were to really /really/ try, could we patch up his case and send him on
to his Turing Award? And if so, how?

Eh?

>
Do you know the term 'steelmanning'?
https://en.wikipedia.org/wiki/Straw_man#Steelmanning

>
Yes.  That is, as it happens, how I address cranks.  I don't usually
argue against them but try to get them to say, as clearly and as
unambiguously as possible, what they are trying to say.  After a lot of
back and forth I got PO to be clear and unambiguous about what he was
saying.  For example, I asked
>
| Here's the key question: do you still assert that H(P,P) == false is
| the "correct" answer even though P(P) halts?
>

 H is required to compute the mapping from its
finite string input to the behavior that this
finite string actually specifies.

Which IS the behavior of the program that input represents when run.

 All of the computer science textbooks say that
a halt decider is to report on the behavior of
input as if it was directly executed because
they never noticed that this behavior can possibly
diverge from the behavior that the finite string
input specifies.

I(n other words, you think that if x is defined to be 2, that x could be 3 if you didn't like the number 2.
The meaning of the input *IS* the defined meaning of the input.
That HHH can't figure out that behavior doesn't mean it isn't the acual behavior of the input.

 We can only correctly compute the mapping from the
finite string input to HHH(DD) to the behavior
that this finite string actually specifies by
having HHH simulate DD according to the rules
of the C/x86 language.

But it isn't about what behavior we can compute, it is about the behavior that the input sepecifies by its definition, which is what happens when we directly execute it.

 *We cannot correctly ignore these rules*
We cannot say that DD correctly simulated
by HHH jumps directly to its "return" statement
on the basis of some textbook quote.
 

The problem is "DD correctly emulated by HHH" is just an oxymoron unless HHH does that, an then it isn't a decider.
Sorry, all you are doing is showing that you don't understand the rules, and are trying to apply a 2-year-olds idea of "fairness" to the question.
The question doesn't need to be "fair" to the decider, and something it can easily asnwer. In fact, the REAL question of the problem was *IF* such a machine was possible. That fact that it was not was a great revelation to the world of Mathematics, stopping it from spinning its wheels trying to do what was shown to be impossible.
Something that seem to be beyond your understanding, as it seems you are at least a century behind in understanding.