Re: Deciders are ONLY accountable for their actual inputs ---

On 6/3/24 9:09 AM, olcott wrote:

On 6/3/2024 3:47 AM, Mikko wrote:

On 2024-06-02 17:23:00 +0000, Richard Damon said:
>

On 6/2/24 9:46 AM, olcott wrote:

On 6/2/2024 2:56 AM, Mikko wrote:

On 2024-06-01 14:44:50 +0000, olcott said:
>

On 6/1/2024 2:56 AM, Mikko wrote:

On 2024-05-31 14:25:40 +0000, olcott said:
>

On 5/31/2024 2:50 AM, Fred. Zwarts wrote:

Op 31.mei.2024 om 00:01 schreef olcott:

On 5/30/2024 4:54 PM, joes wrote:

Am Thu, 30 May 2024 09:55:24 -0500 schrieb olcott:
>

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
>
The left hand-side are line numbers of correct C code.
This code does compile and does conform to c17.
>
Everyone with sufficient knowledge of C can easily determine that D
correctly emulated by any *pure function* H (using an x86 emulator)
cannot possibly reach its own simulated final state at line 06 and halt.

Yeah, of course not, if H doesn’t halt.
>

>
To actually understand my words (as in an actual honest dialogue)
you must pay careful attention to every single word. Maybe you
had no idea that *pure functions* must always halt.
>
Or maybe you did not know that every computation that never reaches
its own final state *DOES NOT HALT* even if it stops running because
it is no longer simulated.

>
Since the claim is that H is also a computation, it holds for H, as well. That means that H *DOES NOT HALT* even if it stops running because it is no longer simulated.
>

>
*pure function H definitely halts you are confused*

>
A pure function does not halt (in C that means that a pure function
does not call exit). A pure function returns.
>

>
When a pure function returns this is the equivalent of the theory
of computation halting.

>
In ceratin sense, yes. But the term "pure function" is mainly used
in a different context where the word "halting" has a more specific
meaning.
>

>
I need to maintain a constant mapping between theory of computation
terminology and software engineering terminology.
>
Computable Function(comp sci) <is equivalent to> Pure function(SE)
I want it to be easy for software engineers to understand my proof.

>
Nope. In Computation Theory, a "Computable Function" is just a mathematical concept of a Mapping (a, normally infinite, set of tuples of unique input values and output values) which happens to have a realizable algroith (aka Turing Machine) that can compute it.
>
The closest equivalent to a SE "Pure Function" is a Turing Machine or Equivalent, or an "Algorithm"
>
SE, to my knowledge, doesn't really have the equvalent of the Computation Theory "Computable Function", but something like it might be expressed in the requirements for the function. It is the specification of what outputs a given input SHOULD generate for the SE function to be correct.

>
Much of sofware engineering attempts to produce a computable function
that solves a particular problem. Usually the requirement is stronger
that mere computablity: there limits to the time and memory, sometimes
to electricity. There are also constraints on hardware.
>
For example, often the requirement is not that the computation halts
but that it halts in 100 microseconds (or in some other time).
>

  On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed this verbatim paragraph is correct
(He has neither reviewed nor agreed to anything else in this paper)
 <Professor Sipser agreed>
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then
 H can abort its simulation of D and correctly report that D specifies a
non-halting sequence of configurations.
</Professor Sipser agreed>
 

Right, once H can CORRECTLY determine that the CORRECT (which to him mean complete) simulation will not halt. H can't do that, and H doesn't do a correct simulation so H can't use its own simulation to justify its error.

*Thus for the following HH(DD,DD) the input must be aborted*

The decider may need to be programmed to abort it simulation, since the input was designed after it, in order to return an answer, but that doesn't mean that a correct and complete simulation of the input can't reach the final state without aborting.
The problem is your logic tries to ignore the "pathological" relationship to convince you it is right, but that just makes it wrong.
*THIS* input, since it is based on a decider that DOES abort, will be halting. It just turns out that it is designed so that THIS decider can't get the answer right. That doesn't make the problem "wrong", just that it make the problem uncomputable, which is perfectly fine.
After all, of the infinite number of mappings (Aleph_1 of them) that can exist, almost all of them (all but just Aleph_0 of them) are uncomputable, as there are only Aleph_0 computable mappings, since there are only Aleph_0 Turing Machines to do the computing.
When they figured out how to count the infinite sets, it became clear why some mappings being uncomputable wasn't that big of a surprize, what is more surprising in many ways is how many useful things ARE computable.

 typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
 _DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax        ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx        ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342   ; call HH
[00001c33] 83c408     add esp,+08
[00001c36] 8945fc     mov [ebp-04],eax
[00001c39] 837dfc00   cmp dword [ebp-04],+00
[00001c3d] 7402       jz 00001c41
[00001c3f] ebfe       jmp 00001c3f
[00001c41] 8b45fc     mov eax,[ebp-04]
[00001c44] 8be5       mov esp,ebp
[00001c46] 5d         pop ebp
[00001c47] c3         ret
Size in bytes:(0038) [00001c47]