Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved criteria is met

On 6/27/24 10:00 AM, olcott wrote:

On 6/27/2024 6:34 AM, Richard Damon wrote:

On 6/26/24 11:30 PM, olcott wrote:

On 6/26/2024 10:15 PM, Richard Damon wrote:

On 6/26/24 10:56 PM, olcott wrote:

On 6/26/2024 9:39 PM, Richard Damon wrote:

>
Nope, they use virtual memory provided by the UTM.
>

>
That *is* what it *is* doing.
The UTM gets this from x86utm.
The slaves use the already allocated memory.

>
But they don't get to use the same memory that the simulator simulating them is using, as that leaks information that they don't get to know.
>

>
The information flow is only upward.

>
Obviously not if it affect the behavior of the inner layers to make them not allocate a new buffer.
>

THIS DOES NOT FREAKING CHANGE THE FREAKING COMPUTATION
SO IT DOES NOT FREAKING HAVE ANY FREAKING EFFECT ON COMPUTABILITY.

But you admitted it DID, as the inner ones do not allocate the buffer.
Why should we believe the claims of a liar that there isn't some other difference.

 

>

They have a memory buffer (as far as they see) that starts empty, and they put data in it, and they take data out, and only what they put in is ever there,
>

>
This is what is intended, and how it actually works.

>
Then how do they know not to create the buffer?
>

 With a real UTM the outer UTM would be the x86utm operating
system and there would never be any separate Allocate() function.
I don't think anyone ever bothered to figure out the details
of how this would work with a real UTM.

I.E., you couldn't figure out how to do it right, so you "cheated" and did it wrong and claimed you did it right.
Since you decider DOES use static memory, if fails to meet your definiton.

 Exactly which portion of its unlimited tape would it allocate
to its slave? The first infinity goes to the first slave, the
second infinity goes to the second slave?

Nope, you just don't understand how virtual memory works.

 I simply allocate 10,000 lines of code knowing that this
will be enough for each of my sample computations.
 

>

>

They write to what they consider to be their tape, and the UTM figures out how to store that on its tape to be able to give it back when requested.
>

That is already what it does.

>
But if the simulated machine can see that there is a layer outside them, then it isn't correct.
>

It need not see this and my algorithm still works.

>
Then take it out. That might help you get the output of just the simulation that the decider is doing, and not have it mixed in with the trace of that simulators execution, as you claim to have.
>

 I see no way to do this without making the code
100,000 times more complex. People smart enough
to comprehend that it does not effect computability
will understand that it makes no difference.

That just shows you are an incompentent programmer.

 People not smart enough to understand this are outside
the scope of my target audience.

I guess you are outside your target audience.

 

>

>

Of course, you never understood the need for putting the simulated machine in its own virtual memory space.

>
I have been doing that for 3.5 years.
It has its own stack registers and RAM.
>
The machine code is the same code, yet executed
as a separate process.
>

>
Then what does the "global" comment mean, every simulator should think it is the globally top level simulator, and be simulating the simulator

>
That was so that humans could see the level in an
output message. I don't use that anymore. It is disabled.

>
But what we need to see is the simulation done by the top level decider, and it alone.
>

 I have a version that already does that.
The current H(D,D) can see that it is about to call itself with
its same input on the basis of knowing its own machine address.

Which doesn't work.

 Because this non-halting criteria is over-the-head of most people
here I switched back to the version that does not need to know
its own address and can see that the infinite recursion behavior
pattern is met. This requires one recursive invocation to be seen.
 

Except that is proven to not be a non-halting criteria, by D(D) itself.
So, you are just stuck with your lies.

>

of the next level down (not doing that simulators simulation), so no simulator has "levels" in it for its own simulation.

>
 From the master UTM's perspective there is one more level
before it sees the infinite recursion behavior pattern.
>

>
Nope. Your "Master UTM" isn't doing its job right if it is doing that.

 void Infinite_Recursion()
{
   Infinite_Recursion();
}
 This is simply a stupid thing to say.
That is like saying that the infinite recursion behavior
pattern is impossible to see.

Nope, but a UTM that doesn't loop infinitely on an infinitly looping input isn't doing the job of a UTM, which is to EXACTLY repoduce the behavior of the machine represented to it.

 

Its job is to just run the machine it was given. That machine needs to do the job IT was given, and so on.

 That is a stupid thing to say, as if no termination
analyzer can possibly see infinite recursion.

Not what I said, but the job of a UTM is NOT to be termination analyzer, but to exactly repoduce the behavior of the machine given to it.

 

The lower level emulators can't use the "master UTM", as they can't know it exists,

 They never do and never have.

All the emulators call "Debug Step" which was a part of the master UTM by what you said.

 

so they need to use there own instance of the same code (it may be physically the same code, but with a TOTALLY new data space (and no shared statics).

 I can add sufficient purely extraneous complexity that no
one can possibly ever understand what I am saying. Good
software engineers always do the opposite of that.

Right, so you don't add extraneous complexity, but Dwrite the code to meet the specifications.
Part of the problem seems to be that you are not a very good programmer, and do many things inefficently.
Your code is HORRIBLY complicated for the task that you are trying to do, especially since you do it so badly.

 Removing all inessential complexity maximizes the quality
of the resulting system.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month#No_silver_bullet
 

Yes, but you still need to write the program to do the correct job, which yours doesn't.
For instance, You "H" doesn't simulate an input described by a COFF file like you said your goal was. Your x86UTM simulates COFF files, but H simulates a program limited to be in its same memory space, and requires that programs can't make copies of it.
That makes its input not Turing Complete, so it fails to meet the first part of the specification.