On 7/14/24 10:13 AM, olcott wrote:
On 7/14/2024 3:40 AM, Mikko wrote:
On 2024-07-13 12:22:24 +0000, olcott said:
On 7/13/2024 3:00 AM, Mikko wrote:
On 2024-07-12 13:20:53 +0000, olcott said:
On 7/12/2024 3:03 AM, Mikko wrote:
On 2024-07-11 14:10:24 +0000, olcott said:
On 7/11/2024 1:25 AM, Mikko wrote:
On 2024-07-10 17:53:38 +0000, olcott said:
On 7/10/2024 12:45 PM, Fred. Zwarts wrote:
Op 10.jul.2024 om 17:03 schreef olcott:
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
}
int main()
{
HHH(DDD);
}
Unneeded complexity. It is equivalent to:
int main()
{
return HHH(main);
}
Every time any HHH correctly emulates DDD it calls the
x86utm operating system to create a separate process
context with its own memory virtual registers and stack,
thus each recursively emulated DDD is a different instance.
However, each of those instances has the same sequence of
instructions
that the x86 language specifies the same operational meaning.
*That is counter-factual*
When DDD is correctly emulated by HHH according to the
semantics of the x86 programming language HHH must abort
its emulation of DDD or both HHH and DDD never halt.
There is not "must" anywhere in the semantics of the programming
language.
The semantics of the language specifies the behavior of
the machine code thus deriving the must.
How can one derive "must" from the semantics of the machine code?
Deciders are required to (thus must) halt.
The semantics of the x86 language does not require that, nor that any of
the programs is a decider.
The subject our our conversion is a simulating termination
analyzer AKA partial halt decider that accepts a finite string
But a "Termination Analyzer" isn't a "Partial Halt Decider" per standard definitions, so you are just admitting you don't understand what you are talking about, but just lying by making up meaning for words that sound reasonable but don't actually match the real meaning of them.
of x86 code as specifying halting behavior or rejects this
finite string. Deciders are required to halt thus must abort
the emulation of any input that would prevent this.
And the x86 code must be COMPLETE, and thus your input string DDD is
just INVALID for that purpose.
*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.
Right, but "Must be aborted" is tested by giving the EXACT SAME INPUT
(which must include ALL the code of the input) to an unconditional
emulatior (at least if you want to try to stay in the field of
Computation Theory, which I am not sure you can keep in it with you errors)l
Technically any program that halts is a decider.
In the early days simply halting was acceptance of the input.
The input was rejected by getting stuck in an infinite loop.
Any program that halts for ALL INPUTS is a decider.
A program that halts in the acceptance state for a class of inputs, and
for others either halts in a rejection state or never halts is called a recognizer. Some recognizers do not have a rejection final state.
In computability theory, a decider is a Turing machine that
halts for every input.
https://en.wikipedia.org/wiki/Decider_(Turing_machine)
*Here the the definition that I go by*
Intuitively, a decider should be a Turing machine that given
an input, halts and either accepts or rejects, relaying its
answer in one of many equivalent ways, such as halting at
an ACCEPT or REJECT state, or leaving its answer on the output
tape. https://cs.stackexchange.com/questions/84433/what-is-decider
Right.
And, to be an XXX Decider, that Accept/Reject condition needs to match
the definition of the function/language it is trying to decide on.
Halting, is SPECIFICALLY defined, to be whether the input program+input represented by the input to the decider will halt when it is run.
It is NOT whether on not the decider can simulate the input to a final
state.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)