Sujet : Re: Correcting the definition of the halting problem --- Computable functions
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theoryDate : 25. Mar 2025, 12:19:59
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <ef53fd089cff1e6ccaf814890df50f640a6a7b5e@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
User-Agent : Mozilla Thunderbird
On 3/24/25 9:33 PM, olcott wrote:
On 3/24/2025 7:00 PM, André G. Isaak wrote:
On 2025-03-24 17:42, olcott wrote:
On 3/24/2025 6:05 PM, André G. Isaak wrote:
On 2025-03-24 17:04, olcott wrote:
>
>
_III()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
>
When III is emulated by pure emulator EEE for any finite
number of steps of emulation according to the semantics
of the x86 language it never reaches its own "ret"
instruction final halt state THUS DOES NOT HALT.
>
When III is directly executed calls an EEE instance
that only emulates finite number of steps then this
directly executed III always reaches its own "ret"
instruction final halt state THUS HALTS.
>
And that has what, exactly, to do with the post you are allegedly responding to?
>
André
>
>
>
THE INPUT FINITE STRING DOES SPECIFY RECURSIVE EMULATION.
>
The behavior specified by the finite string input to a
computable function implemented on a model of computation
>
does differ from the direct execution of this same finite
string because the direct execution avoids the pathological
self-reference that causes the recursive emulation.
>
THE INPUT FINITE STRING DOES SPECIFY RECURSIVE EMULATION.
>
In the post you were responding to I pointed out that computable functions are mathematical objects.
https://en.wikipedia.org/wiki/Computable_function
Computable functions implemented using models of computation
would seem to be more concrete than pure math functions.
But are just a subset of them. Since the whole problem you are talking about is whether a given mathematical function (The Halting Property) CAN be computed, that difference is important.
The Mathematical Halting Property exists, as every program will either Halt or not (for a given input).
The Halting Decider program does not, as it turns out that the Halting Property is not computable, yet you keep on trying to claim it is, but do so by saying it must mean something different, just showing you don't understand about word meanings and logic.
For example pure math functions don't have any specific
storage like a tape or machine registers.
Because they don't need it.
This also would seem to mean that they would require
some actual input.
MAthematical functions don't?
It seems your problem is you don't understand what you are talking about, and can't understand abstract concepts.
The above copypasta doesn't address this.
>
I pointed out that the domain of a computable function needn't be a string. The above copypasta doesn't address this.
>
When implemented using an actual model of computation
some concrete form or input seems required.
So? We can convert a program into a concrete representation of it that fully expresses the program.
Just like you can't give a "number" to a physical model of computation, only a representation.
I pointed out that there is no bijection natural numbers and strings,
finite strings of decimal digits: [0123456789]
So, you accept representations for numbers, why not for programs?
but rather a one-to-many relation. The above copypasta doesn't address this.
"12579" would seem to have a bijective mapping to
a single natural number.
>
I pointed out that the exact same sort of one-to-many relation exists between computations and strings. The above copypasta doesn't address this.
>
I pointed out above that the finite string of x86
machine code correctly emulated by EEE DOES
NOT MAP TO THE BEHAVIOR OF ITS DIRECT EXECUTION.
> >
code of correctly
emulated by EEE machine code does not map to its direct
execution.
No, because your above code listing can NOT be correctly emulated, as it doesn't include the target of the call.
When you include it, then the input is different for each different EEE (or HHH) that is called.
When you fix that issue, then the correct emulation will EXACTLY match the behaviro of its direct execution.
All you are doing is proving that you don't know what correct emulation means, and have just always been lying about what yo are doing.
Sorry, TRUTH shows that you don't know him, but are just a pathological liar, so stupid that you can't understand your stupidity.