Re: What it would take... People to address my points with reasoning instead of rhetoric

Op 13.mei.2025 om 18:22 schreef olcott:

On 5/13/2025 11:01 AM, olcott wrote:

On 5/13/2025 10:47 AM, Mike Terry wrote:

On 13/05/2025 12:54, Fred. Zwarts wrote:

Op 13.mei.2025 om 07:06 schreef olcott:

On 5/12/2025 11:41 PM, André G. Isaak wrote:

On 2025-05-12 21:23, Mike Terry wrote:
>

Mind you it does seem to have gone mad the last month or so.  It seems there are only about 2 or 3 actual variations of what PO is saying and all the rest is several thousand repeats by both PO and responders...

>
Those who insist on responding to Olcott (of which I admit I have occasionally been one despite my better intuitions) would be well advised to adopt something like the rule of ko (in the game go) which prohibits one from returning to the exact same position. Simply repeating the same objection after olcott has ignored it is pointless. If he didn't get the objection the fiftieth time he's not going to get it the fifty-first time either.
>
If people adopted this policy most of the threads on this forum would be considerably shorter.
>
André
>

>
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.

>
If olcott would only stop ignoring everything that disturbs his dreams, he would see that his key points have been addresses and refuted many times already.

>
We might call that a disturbing ko.
>
Mike.

>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
>
*DD emulated by HHH according to*
*the rules of the x86 language*
>
has never been explained. The closest thing to
reasoning that was provided on this point is
"that is what textbooks say".
>

 ZFC reformulated set theory correcting its error
and the original set theory is now called naive
set theory.
 When we understand that a termination analyzer
must compute the mapping from its input to the
behavior that this input actually specifies
then all of the conventional halting problem
proof fail.
 How does it make sense to require a termination
analyzer to report on behavior that is not the
actual behavior that the input specifies?

The input specifies a halting program, as proven when exactly the same input is used for direct execution and in other simulators.
That the programmer of HHH made HHH blind for this part of the specification, does not mean that it is not specified. It is just a bug in HHH which skips that part of the specification by aborting too soon.

 Mike seems to have indicated that this has
been explained in full and I simply ignored
the explanation.