On 8/13/25 5:00 PM, olcott wrote:
On 8/13/2025 3:39 PM, Mike Terry wrote:
On 13/08/2025 18:32, Kaz Kylheku wrote:
On 2025-08-12, olcott <[email protected]> wrote:
On 8/12/2025 2:50 PM, Kaz Kylheku wrote:
If you're trying to demonstrate your work using stateful
procedures, you
must be explicit about revealing the state, and ensure that two
instances of a computations which you are identifying as being of the >>>>> same computation have exactly the same initial state, same inputs,
and same subsequent state transitions. You cannot call two different >>>>> computations with different state transitions "DD" and claim they are >>>>> the same.
Simulating termination analyzer HHH1 is exactly the
same as HHH except that DD does not call HHH1.
Nope! If HHHH and HHH1 are exactly the same, it means,
mathematically, that those identifiers are just different
names for the same entity, which are interchangeable.
That means that DD does call HHH1, just using the name HHH.
Just like (2 + 2) and (3 + 1) are interchangeable, right?
DD simulated by HHH1 has the exact same behavior
as the directly executed DD().
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
If it so happens that HHH1 /isn't/ the same as HHH, (which
can easily be the case in a system which does invalid
things with backchannel communication via global variables
and whatnot) then, yes, HHH1 can correctly decide it.
I've explained to PO (several times) why HHH1 isn't a proper clone of
HHH, but he doesn't get any of it.
I just did a diff. HHH1 and HHH have identical source-code.
Then they aren't Pure funcitons, but use something that isn't part of
the input to decide on.
If they were identical, HHH1 would be using &HHH as the address it was
testing to see if the input calls itself.
Note, the "program counter" is not part of the input to a pure function,
unless you define it as such, in which case the call to HHH and HHH1 is
really of the form HHH(DD, HHH) and HHH1(DD, HHH1), which are differnt
inputs.
Sorry, all you are doing is proving you don't understand the meaning of
the words you are using.
Of course, you never fixed the error that made your HHH not a pure
funciton, so it never did meet that requirement, the justification that
it was the only way you could think of letting the simulator know the
state of the simulation is just a fabrication that shows that you don't understand the problem.>
HHH has mutable (local) static variables that are used to communicate
between different emulation levels. When HHH emulates HHH, the inner
HHH communicates back to the outer HHH through their shared static
variables. HHH1 has /its own/ versions of those static variables, so
inner nested HHHs do not communicate back to outer HHH1. That means
HHH1 never monitors its nested emulated DDs for so-called non-
termination patterns. So HHH1 emulates its (outer) DD until it halts,
and correctly decides "halts".
*This has nothing to do with DD correctly emulated by HHH*
Then why don't you fix it?
Any LIE makes a statement a LIE.
When HHH(DD) does report on the actual behavior that its
actual input actually specifies as measured by DD correctly
simulated by HHH that includes that HHH does simulate an
instance of itself simulating an instance of DD that does
call yet another instance of HHH(DD) then HHH(DD)==0 is
proven to be correct.
Except that you LIE about what the "behavior of the input" means,
because you try to lie about what a "correct simulation" means.
The point is that "DD correctly emulated by HHH" can NOT be the correct
meaning of the behavior of the input if THAT HHH doesn't do a correct
emulaiton of the input because it aborts.
All you are doing is claiming that using invalid logic is valid.
That you once said that DD correctly simulated by HHH
would eventually stop running on its own proves that
you have a terrible understanding of this one point
even though your understanding of other points seems
flawless.
When did anyone say that DD correctly simualted by HHH would halt?
The claim is that DD correctly simulated will halt if HHH aborts its
simulation and returns a value.
Since that *IS* the behavor of your given HHH, that IS the behavior of
the correct simulation of its input, something HHH doesn't do, and to
try to talk about it doing so is just a LIE.
So it's all down to PO's erroneous use of mutable static data. If PO
had designed this correctly, each emulation level would maintain its
own "local" trace table, agnostic regarding its depth in any emulation
hierarchy. Then HHH1 (directly copied from HHH) would be a genuine
clone of HHH, and their processing would match as it should/must, and
of course they would reach the same halting decision.
Or even if PO used a global (shared) variable for the
(mis)communication across emulation levels, at least that would mean
HHH and HHH1 logic was the same, making their behaviour the same...
Hmmm, sounds like PO is "doing invalid things with backchannel via
global variables" or something! :)
Mike.
DD simulated by HHH according to Kaz should be called
DD.HHH because it does not have the same state as DD.HHH1.
They seem to have the same initial state.
They both have no input.
*They do have different state transitions*
Well, That's a problem, isn't it.
You might think, but not for PO.
Mike.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)