Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure

olcott <polcott333@gmail.com> wrote:

On 6/26/2024 11:03 AM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/26/2024 8:40 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 6/26/2024 3:10 AM, Mikko wrote:

[ .... ]

The relevant area of software engineering is testing. The usual
attitude of software engineers is that a program is accpted when it
has been sufficiently tested and passed all tests. Consequently, an
important part of sofware work is the design of tests.

In the current context the program to be tested is a halting decider.

*NO IT IS NOT. H0 IS ONLY AN X86 EMULATOR*
After you quit lying about the behavior of DDD correctly
emulated by H0 then we can move on to the next point.

I think the problem is rather your calling every program or function you
talk about H, or H^, or HH, or HHH, or H0, or H1.  Usually, in the past,
you have meant purported halting deciders by these names.  Now you're
saying that you mean an X86 emulator.  Where and when did this change
happen, and how is anybody else supposed to know what you mean by
particular uses of these names?

When I ask people to consider the behavior of DDD
correctly emulated by H0 according to the semantics
of the x86 programming language it really does seem
to be the strawman deception when they try to get away
with saying that it must be the behavior of the directly
executed DDD().

I don't think so.  People's eyes glaze over when they see yet another one
of your posts, virtually the same as so many others, and cannot
reasonably be expected to read and understand every last word.

Maybe if you restricted yourself to using E... when you mean an emulator,
and H... when you mean a purported halting decider, there would be less
confusion.

Emulating termination analyzer H is inherently an emulator.
It really should not be that hard to pay attention to that
unless one only cares about rebuttal and thus does not care
about truth.

Your posts are, in the main, tedious in the extreme.  When you repeat the
same thing 30 times over, you can't expect anybody to read each of the
repetitions as though it were fresh and new.

All the people you are debating with care about the truth.  That's why
they're in this group debating with you.

Given how most people here are mathematically trained, perhaps if you
started a typical post with "Suppose E is a code emulator ...", and other
prerequisites there would be less confusion still.

OK that sounds like a reasonable way to avoid information overload.

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

It is clear that the semantics of the x86 language specifies
that DDD correctly emulated by H0 at machine address 0000217a
will continue to repeat the first four instructions of DDD
until out-of-memory error.

It is not at all clear, given how murky the code at 15d2 is, and what you
mean by "correctly emulated".

Of course I must mean jumping up and down yelling and screaming
and not be referring to anything like what an x86 emulator does.

Anything "like" what an x86 emulator does is insufficiently precise.
There are plenty of different functions which could appear at 15d2, some
of them will return, some won't.  Some of them could be called emulators,
most couldn't.  And the "semantics of x86" don't specify anthing beyond
the meaning of x86 programs in general.

When we add that the outermost directly executed H0 can abort
its simulation as soon as the behavior of its input matches
the the infinite recursion behavior pattern it remains true
that the call from the emulated DDD to the emulated H0(DDD)
cannot possibly return.

It might do.  Convincing argument that this is the case (i.e. a proof)
has not been forthcoming.

We cannot prove differential calculus to anyone not knowing
how to count to ten.

Everybody else in this group knows differential calculus, and certainly
how to count up to ten.  They also know what a proof looks like, and how
necessary it is.

That DDD correctly emulated by H0 must continue to repeat
its first four instructions is self-evident true to anyone
knowing what an x86 emulator is and having sufficient basic
knowledge of the x86 programming language.

It is not self-evident.

I was very surprised to find out that one person having a PhD
in computer science said that they had hardly any experience
with programming.

Why?  Many architects won't have much experience of brick laying, either.

The CS courses that fulfilled the requirements for a BSCS degree
at my university had quite a bit of programming. One of the projects
for the data structures course was to write a LISP interpreter that
could do car, cdr and cons.
https://www.gnu.org/software/emacs/manual/html_node/eintr/car-cdr-_0026-cons.html

I'm familiar with that page, being a member of the Emacs maintenance
team.

These expressions could be arbitrarily complex. I was one of
two students out of fifty that got the project in on time. The
other one was my co-worker at the US Army Corps of engineers.
He and I got a 100% grade.

*That people consistently lie about this is quite annoying*
*yet not nearly so much when their lie is easily exposed*

I haven't seen other people here lying.

When they say that I am wrong knowing that they do not understand
what I am saying this would be a lie.

They say you are wrong because you are wrong.  They do understand what
you are saying, mostly, and understand that it is wrong, again mostly.

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--
Alan Mackenzie (Nuremberg, Germany).