On 12/11/21 11:57 AM, olcott wrote:
> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>> On 2021-12-10 22:13, olcott wrote:
>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>> On 2021-12-10 16:47, olcott wrote:
>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>
>>>>>>>
>>>>>>> This definition has confused too many people into thinking that
>>>>>>> it is reporting on something besides the precise behavior that is
>>>>>>> stipulated by the actual input.
>>>>>>
>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>> behaviour of the computation represented by the input.
>>>>>>
>>>>>
>>>>> When the input to a halt decider is directly executable machine
>>>>> code then that halt status decision is based on the actual behavior
>>>>> of the actual execution of this input.
>>>>
>>>> The decision must describe the actual behaviour of the program
>>>> described by the input, but it cannot be based on the execution of
>>>> this input. If a putative halt decider simply executed its input it
>>>> wouldn't constitute a decider since it would not halt if its input
>>>> were a non-halting program. The input *describes* some program and
>>>> input, just as the input to a TM-based decider decribes a computation.
>>>>
>>>
>>> It has always been the case that a halt decider has only been
>>> accountable for the actual behavior specified by its actual input.
>>
>> The actual input is a string. Strings don't have actual behaviour.
>>
>
> An x86 machine code string does have behavior.

Only when converted into an an actual prorgram with context.

Note, the code for the function P does NOT have behavior until it is
called with a parameter.

You are

>
>>> The actual behavior specified by its actual input H(x,y) is most
>>> precisely defined as the pure simulation of the finite string pair
>>> input S(x,y) from the halt decider.
>>
>> By definition a halt decider describes the behaviour of the
>> computation *described* by its input. The input itself doesn't specify
>> any behaviour at all.
>
> An x86 machine code string does have behavior.

No, see above.

>
>>
>>> H is a decider; which is a type of computable function; which is a
>>> type of function; which only applies to its input parameters.
>>
>> Deciders are a type of Turing Machine (or Computer Program). Turing
>> Machines are *not* functions.
>
> The Church Turing thesis only applies to computable functions.

No, Church Turing thesis only applies to COMPUTATIONS and ALGORITHMS.

You still don't understand that a Computable Function is just a mapping
of inputs to outputs. It is NOT the algorithm used to compute it.

Just like the mathematical sin function is defined as the apping that
corresponds to the ratio of the opposite side of the triangle divided by
the hypotenuse, and NOT some numerical method that produces the
approximate value for a given input.

The fact that Programming defines a DIFFERENT thing that is calls a
'Function' shouldn't confuse you (but seems to). You need to use the
definition that applies for the field you are in.

Computation theory is a piece of the mathematics domain, so uses the
MATHEMATICAL definition of 'Function' not the programming definition.
This ESPECIALLY appies to the term 'Computable Function' as programming
has no need for that term, as by definition, any programming function is
by definition an algorithm to compute the value of a function.

>
>> They compute functions but they are not the same as the function they
>> compute. And the Halting Function is *not* a computable function so
>> referring to a halt decider as a "computable function" is even more
>> wrong than describing it as a "function".
>>
>
> If halting is not a computable function on some inputs then it is
> outside of the scope of computer science investigation.

OK, who said it was a computer science investigation.

Halting is a COMPUTATION THEORY concept.

And yes, the fact that Computation Theory shows that the Halting
Function (as a Mathematical concept of function) is not computable
really says that Halting isn't in the domain of Programming / Computer
Science, as it is impossible to actually write a program to do it.

This is what people have been telling you for YEARS.

>
> Computable function
> Computable functions are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given an input of the function domain it can return the
> corresponding output. https://en.wikipedia.org/wiki/Computable_function

Right 'Function' (as in Mathematics) is a 'Comutable Function' if there
EXISTS an ALGORITHM that computes it.

The 'program' that you write is the ALGORITHM, not the FUNCTION
(Mathematical).

You don't seem to understand the definition, perhaps because you keep
using the wrong definition of FUNCTION (Mathematical).

>
>> You really need to stop using these terms until you learn what they
>> mean. You embarrass yourself with every sentence you write.
>>
>>> No function is ever accountable for anything besides inputs in its
>>> domain. These inputs in its domain are explicitly specified as
>>> parameters.
>>
>> Functions have domains. Turing Machines/Computer programs have
>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>> elements of the domain of the function which that TM computes. The
>> domain of the
>
>
> int main() { P(P); } is not a to H thus has nothing to do with the
> correctness of H. H is only accountable for its actual input parameters.

And H(P,P) MEANS the behavior of the above program,

>
>> halting function is the set of all computations. The parameters passed
>
> computation
> The sequence of configurations leading to a halt state will be called a
> computation.  (Linz:1990:238)
>
> Not really that is far too vague. It is the set of all finite string
> descriptions of sequences of configurations. Because computation must
> halt when we restrict the domain to computations a correctly halt
> decider only needs to return true for every input.

What is vague about it?

You seem to be mixing the two variations in the field of Computing Theory.

One variation defines a 'Computation' as only those processing that DO
end in finite time, and for this version, the Halting Problem is to
detect if its input IS a Computation (because it Halts) or not. This
version has a notational difficulty of describing the applying of an
algorithm to an input, because it might not actually be a Computation.

The second version defines a Computation as ANY finite algorithm (finite
in length of description) and when processed might halt in finite time
or not, and the Halting Problem is to make a Halting Computation that
decides if the input Computation will halt or not.

For the first, the input ISN'T limited to just the representation of
Computations, but to ANY string that can represent an algorithm and its
input, and it needs to determine if it IS a Computation.

The second has a better bound on the domain of its input, as it must be
the representation of a Computation, and it needs to determine if this
Computation will Halt.

Mixing up variation specific definitions of these two variations will
lead to confusion. You really do need to understand what someone is
talking about an not just cut-and-pasting without understanding.

>
>> to a halt decider would be *DESCRIPTIONS* of elements in that domain,
>> i.e. the set of computations. The answer which it is expected to
>> return describes the behaviour of the actual computation described by
>> its input parameter, not the behaviour of the input string which is a
>> nonsensical claim.
>>
>
> According to Linz you are totally wrong on computations because
> computations always halt.

And Linz defines the input to be a representation of a Turing Machine,
which might NOT represent a Computation.

Which definition set are YOU going to use. If using the concept that all
computations halt, then the input to H is the description of an
algorithm and its input. In the case of H(P,P) it is the algorithm of P
applied to the representation of P.

The algorithm of P is the free running of the code of P (ie just calling
P with no restrictions) and the repentation of P is the code of P.

This is EXACTLY what main() { P(P); } does, so what that does exactly
defines what the right answer that H needs to return.

>
>>>
>>>>> The only reason that the word "representation" has ever been used
>>>>> is the mere convention that TM's cannot directly execute other
>>>>> TM's, there must be an intermediate TM description (essentially
>>>>> source-code) inbetween.
>>>>
>>>> This is simply wrong. It doesn't matter whether a halt decider is
>>>> expressed in terms of Turing Machines or x86 programs; one must
>>>> still make a distinction between the data which a halting decider
>>>> evaluates, which is a representation of some program, and the actual
>>>> executable program.
>>>
>>> Not if the data is x86 machine code
>>
>> Yes, one still must. Did you not read the bit below?
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> This input to HHH is directly executed by HHH
>
> int HHH(ptr x, ptr y)
> {
>   x(y);
>   return 1;
> }
>
>
> void PPP(ptr x)
> {
>   if (HHH(x, x))
>     HERE: goto HERE;
> }
>
>
> int main(void)
> {
>   PPP(PPP);
> }
>

And by your definitions, HHH is NOT a computation, since HHH never
returns. FA

You keep making this mistake, you claim H is CORRECT in returning 0, but
you keep on arguing with an H that doesn't do this.

If your H actually does return 0, then having P call some other thing
call H that doesn't behave that way says P doesn't meet the requirements
of Linz, and you are LYING that you have followed the requirements.

FAIL.

>
>>
>>>> The fact that the conversion between the representation and the
>>>> executable is relatively trivial doesn't make the distinction go away.
>>>>
>>>> A halt decider must be able to accept as input *any* possible
>>>> program, and that includes programs whose instructions overlap the
>>>> address range   of the decider itself, so the representation is not
>>>> going to be identical to the executable code.
>>>>
>>>> And earlier you'd claimed your H took a COFF file as an input,
>>>> though none of your code provides evidence of this. The contents of
>>>> a COFF file are not identical to the actual executable which is
>>>> loaded into memory from that file as anyone familiar with COFF files
>>>> should know.
>>>>
>>>> André
>>>>
>>>
>>> I transformed the COFF object file by patching relocatbale addresses
>>> to their actual file offset so that the COFF object file is directly
>>> excutable in my system. The link step is not allowed.
>>
>> So basically you never actually did this. You just thought about how
>> you might do it without actually testing to see if this would be
>> workable. It isn't.
>>
>> André
>>
>
> I did actually do this because it was too much of a hassle to do this
> manually all the time.
>
> //
> //  This function patches all of the relocatable data references
> //  to their file offset targets. This enables libx86emu to directly
> //  execute the patched object file.
> //
> //  The object file: *.obj is patched and written to: *.bin
> //
> u32 COFF_Reader::PatchAddress_Targets(Section_Header& Code_Section)
> {
>   for (int M = 0; M < Code_Section.Relocation_Count; M++)
>   {
>     Relocation_Entry Temp;
>     unsigned int Offset = Code_Section.Relocation_Offset +
> (RELOCATION_ENTRY_SIZE * M);
>     memcpy(&Temp, &ObjectCode[Offset], 10);
> //  printf("[%02d] Code_Offset[%08x] Symbol_Index(%04x) Type(%04x)\n",
> // M, (u32)Temp.Code_Offset, (u32)Temp.Symbol_Index, Temp.Type);
> //Symbols[Temp.Symbol_Index].out();
>
>     unsigned int Code_Segment   =
> Sections[CODE_SECTION_INDEX].Data_Offset;
>     unsigned int Patched_Code   = Code_Segment + Temp.Code_Offset;
>     unsigned int Target_Section =
> Symbols[Temp.Symbol_Index].Section_Number;
>     unsigned int Patch_Target   = Sections[Target_Section].Data_Offset +
>                                   Symbols[Temp.Symbol_Index].Value;
>
>     u32 Unpatched_Target        = (u32)ObjectCode[Patched_Code];
> #ifdef __linux__
>     Patch_Target += Unpatched_Target;
> #endif
>
> #ifdef DEBUG_MODE
>     if (Temp.Type == RELOC_ADDR32)
>       printf("ABSOLUTE:Patch_Target[%04x]  Patched_Code[%04x](%04x)
> Name(%s)\n",
>              Patch_Target, Patched_Code, Unpatched_Target,
>              Symbols[Temp.Symbol_Index].Name.c_str());
>     else if (Temp.Type == RELOC_REL32)
>       printf("RELATIVE:Patch_Target[%04x]  Patched_Code[%04x](%04x)
> Name(%s)\n",
>               Patch_Target, Patched_Code, Unpatched_Target,
>               Symbols[Temp.Symbol_Index].Name.c_str());
> #endif
>
>     if (Temp.Type == RELOC_REL32)
>       Patch_Target = (Patch_Target - (Patched_Code + 4));   // Make
> Relative to address of next instruction
>     else if (Temp.Type != RELOC_ADDR32 && Temp.Type != RELOC_REL32)
>     {
>       printf("FAILURE NOT PATCHED: Unknown Relocation_Entry.Type\n");
>       return 0; // Failure
>     }
>
>     unsigned int* Code2Patch = (unsigned int*) &ObjectCode[Patched_Code];
>     *Code2Patch  = (unsigned int) Patch_Target;
>   }
>   return 1;     // Success
> }
>

But this means that H is NOT taking a 'COFF File', as the COFF File is
NOT the input to H.

FAIL.