On 6/2/25 11:13 AM, olcott wrote:
On 6/2/2025 1:56 AM, Fred. Zwarts wrote:
Op 02.jun.2025 om 07:12 schreef olcott:
On 6/1/2025 6:20 AM, Mikko wrote:
On 2025-05-31 19:21:10 +0000, olcott said:
On 5/31/2025 2:11 PM, Mr Flibble wrote:
Olcott is doing this:
int main()
{
DDD(); // DDD calls HHH
}
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no
execution
of DDD prior to the simulation of DDD.
Olcott should be doing this:
int main()
{
HHH(DDD);
}
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
But a finite recursion, because the input includes the code to abort
and halt. That HHH is unable to reach this final 'ret' only shows that
using a simulator for the analysis is in this case the wrong decision,
because it fails the whole specification of the input.
If Mike is having a hard time on this then it must
be really hard to understand. Mike has fully understood
every other detail of the architecture of HHH.
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
HHH sees its abort criteria just before it is about
to simulate itself simulating DDD a third time.
But the "abort criteria" is incrrect, an thus HHH gets the wrong answer.
Every nested simulation of HHH has this same behavior
because they all have the same machine code at
the same machine address.
Right, and thus the HHH that DDD calls will have that behvior, and thus
HHH will return to DDD and HHH is just wrong to have aborted, because it
should know that the recursion shouldn't be infinite, because it is
programmed to abort at that point.
The outermost HHH sees its abort criteria one whole
recursive emulation before the next inner one.
Right, but not the behavior of the program it represents.
That continues, that one more level, and then stops.
You just don't understand the definitions of what things represent.
This means that unless that outer HHH aborts
none-of-them abort.
Right, but since it does, they all do, and DDD halts.
You don't seem to understand that the code of the program *IS* the code
of the program, not something "idealized" that is different than what it is.
That is just your lie to yourself that you stupidly beleive.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When the outermost HHH aborts its DDD the entire
recursive emulation chain stops right where it is
never reaching past machine address [0000219a].
Right, THE SIMULATION stops, but not the behavior of the input, which is DEFINED to be the FULL behavior of the program the input represents,
which continues past that point to where the HHH that was being
simulated, and now just running or would be simulated if correctly
simulating this input with a proper simulator (not HHH), and then
returning 0 to DDD which halts.
You are just showing you don;t understand the meaning of the word you
are using because you INTENTIONALLY chose to not learn them, and are
trying very hard to ignore, as they prove you a liar.
So we end up with
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
It defines FINITE recursionve simulation that WILL reach its final
state, just after the PARTIAL simualation aborts.
Since HALTING is defined as the behavior of the actual program, and equivalently as the results of an actually correct (and thus complete) simulation of it, and that does reach that final state, it is HALTING.
Your confusion of the partial simulation with the correct simulation
just shows your stupidity.
Therefore it is wrong to say:
*Every rebuttal to this changes the words*
because explaining the words show the errors in the suggestion of
these words.
That was not a rebuttal it was a failure to sufficiently
understand the internal workings of HHH.
Which doesn't matter, as compuation are judged just on if they compute
the CORRECT mapping of their input to the output they give. Since DDD()
will Halt, the correct mapping of the input DDD to HHH would be to
halting (1), but it gives 0, so it is just wrong.
Doesn't matter what unsound logic you use to try to claim it is right,
The PROGRAM DDD, based on the PROGRAM HHH, where that HHH returns 0,
will always be halting, and you are just showing you don't understand
2what those words mean.
Sorry, you are just proving your stupidity.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)