Re: The philosophy of computation reformulates existing ideas on a new basis ---

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

On 10/27/24 10:55 PM, olcott wrote:

 

On 10/27/2024 9:26 PM, Richard Damon wrote:

On 10/27/24 6:01 PM, olcott wrote:

On 10/27/2024 12:48 PM, Richard Damon wrote:

On 10/27/24 10:17 AM, olcott wrote:

I am keeping this post in both sci.logic and comp.theory
because it focuses on a similar idea to the Curry/Howard
correspondence between formal systems and computation.
>
Computation and all of the mathematical and logical operations
of mathematical logic can be construed as finite string
transformation rules applied to finite strings.
>
The semantics associated with finite string tokens can
be directly accessible to expression in the formal language.
It is basically an enriched type hierarchy called a knowledge
ontology.
>
A computation can be construed as the tape input to a
Turing machine and its tape output. All of the cases
where the output was construed as a set of final machine
states can be written to the tape.
>
I am not sure but I think that this may broaden the scope
of a computable function, or not.

>
Except that nothing you described related to what a "computabe function"

>
I intend to reply to other aspects of your reply later
on as long as your reply to this reply is not lame.
>
When a Turing machine transforms the contents of its
input tape into the contents of its output tape this
seems to necessarily always be a computable function
no matter what the TM does in-between.
>

>
Yes, a Turing Machine will always be computing the mapping from some computable function.
>
It is NOT the "Computable Function" itself, as that is a thing of a different ty[pe.
>
It just computed the mapping definied by that function.
>
Note, the mapping of the function might not be defined in terms of "finite-strings", but will be something that can be described by a finite string if we want to talk about it being computable.
>

>
Yes. We are getting somewhere now.
>

For instance, the Halting Function, that the Halting problem is about, is defined with Turing Machines as its input (not finite strings).
>

>
Not in the least little bit.
It seems totally crazy that you would say this.

>
>

>
It has always been finite string Turing Machine descriptions.

>
The machine being used to compute the Halting Function has taken a finite string description, the Halting Function itself always took a Turing Machine,
>

>
That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

>
Nope, read the problem you have quoted in the past.
>
The FUNCTION is the Halting Function, which is about Turing Machines,
>
The decider is what takes a finite string, and that string is described as a representation of the Turing Machine the Halting Function mapped.
>
It CAN'T be about the string, as every decider might take a different form of encoding.
>
So yes, the TURING MACH(INE DECIDER takes a string, but the HALTING FUNCTION takes a Turing Machine and its input.
>
Your problem is you don't understand what Computation Theory calls a "Function", and have guessed wrong.
>
>

>

These finite strings do have a specific semantics associated
with them and that is the semantics of Turing Machines.

>
No, the method of representing the Turing Machine is defined by the decider.
>
The "Semantics of Turing Machines" does have a finite string representation.

>
It may seem that way because there is no currently universal standard
like there is for the x86 language. For these thing to be properly
investigated we must begin with a standard language. The machine
merely conforms to that standard.

>
Nope, doesn't work that way, The is no rule that says the decider needs to uuse any particular form of encoding, and thus the Function that defines the mapping can't be based on one.
>
You are just proving your stupidity,
>

>

>
It defines a Turing Machine as having a "Set of States" (and "States" don't have a defined string representation
>

>
  A turing machine program consists of a list of 'quintuples', each one of which is a five-symbol turing machine instruction.  For example, the quintuple 'SCcsm' is executed by the machine if it is in state 'S' and is reading the symbol 'C' on the tape.  In that case, the instruction causes the machine to make a transition to state 's' and to overwrite the symbol 'C' on the tape with the symbol 'c'.  The last operation it performs under this instruction is to move the tape reading head one symbol to the left or right according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

>
And none of those have a defined finite-string encoding. Since you can't even know what the symbol set to encode into, that becomes a lot harder to define.
>
And, if you did limit it
>

>
SCcsm
current state number,
current symbol,
overwrite current symbol
next state number,
move tape head left or right

>
And how do you encode that into an arbitrary symbol set.
>
And, does it HAVE to be organized that way, NO.
>
If you limited it to that, you would only prove that you can't solve the problem with that particular encoding, which isn't good enougy to answer the question about computablility.
>
Which you are just showing you just don't undetstand.
>

>

>

The key point here is that different implementation of a attempted Turing Machines to try to compute this might use different ways of representing the machines, so the function can't just be thought of as taking the string.
>

>
A string that maps to the semantics of Turing Machines.
The bytes of x86 machine code have the precisely defined
semantics of the x86 language.

>
Right, so in the context of a decider defined to take an input encoded as an x86 binary, that is how you defined the form of the representation.
>

>
Yes.

>
So, why doesn't your input contain the x86 code for all of the program being given, like the code for HHH.
>
It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code for HHH, so it needs to be part of the input.
>

 *You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD
 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 At machine address 0000217a HHH emulates itself emulating
DDD without knowing that it is emulating itself.
 

Then how did it convert the call HHH into an emulation of DDD again?
Where in Intel's x86 documentation does it define the semantic of a "Call HHH" instruciton to start up another emulation of the input.\
You are just running yourself around in circles with your lies.
If, as 00000217A HHH does go into the memory at 000015D2, then you have to admit that is part of the input, and thus can not be changed.
Thus, since only a COMPLETE emualtion directly reveals the final behavior, and HHH doesn't do that, it never will get the needed proof.
And, if HHH does decide to abort, then we can prove it wrong by giving that exact same input (the DDD that calls the HHH that aborts) to the DIFFERENT version of HHH that HHH imagined itself to be to make its decision, which will need to be at a different memory address (because of your non-turing system of overlapping the two memory spaces) and we can show that it WILL be able to emulate that input to the end, just as your HHH1 did.
Thus, HHH is incorrect that a non-aborting version of itself wouldn't reach the final state, WHEN GIVEN THIS EXACT PROGRAM AS AN INPUT.
When you lie about the code of HHH not being part of the input, you are just proving you don't understand the meaning of the words of the problem, as only PROGRAM have this sort of behavior, not "C functions" when we exclude some of the functions they call.