Simply defining Gödel Incompleteness and Tarski Undefinability away V35 (Semantically Incorrect Defined)

[olcott]

In classical logic a sentence in a language is true or false under (and
only under) an interpretation and is therefore a truth-bearer.

https://en.wikipedia.org/wiki/Truth-bearer#Sentences_in_languages_of_classical_logic


A semantically incorrect logic sentence φ will be defined as a closed
WFF having no interpretation that satisfies either φ or ¬φ.

Copyright 2020 Pete Olcott

These sources are used for the meaning of the term "interpretation"

Satisfiability
A formula is satisfiable if it is possible to find an interpretation
(model) that makes the formula true.
https://en.wikipedia.org/wiki/Satisfiability

Interpretation (logic)
An interpretation is an assignment of meaning to the
[non-logical] symbols of a formal language.
https://en.wikipedia.org/wiki/Interpretation_(logic)

https://mathworld.wolfram.com/Interpretation.html

http://www.princeton.edu/~hhalvors/teaching/phi201_s2004/handouts/semantics

http://www.phil.cmu.edu/projects/logicandproofs/alpha/htmltest/m11_pred_formal_sem/translated_chapter11.html


https://en.wikipedia.org/wiki/Interpretation_(logic)#Logical_constants


--
Copyright 2020 Pete Olcott

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> In classical logic a sentence in a language is true or false under
> (and only under) an interpretation and is therefore a truth-bearer.
>
> https://en.wikipedia.org/wiki/Truth-bearer#Sentences_in_languages_of_classical_logic
>
> A semantically incorrect logic sentence φ will be defined as a closed
> WFF having no interpretation that satisfies either φ or ¬φ.

Then there are none (see page 65 in Mendelson). You really should try
to learn the meaning of the words you use.

--
Ben.

[olcott]

On 8/4/2020 2:01 AM, André G. Isaak wrote:
> On 2020-08-04 00:26, olcott wrote:
>> On 8/4/2020 1:11 AM, André G. Isaak wrote:
>>> On 2020-08-03 22:29, olcott wrote:
>>>> On 8/3/2020 10:05 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/3/2020 8:45 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:

>>>>>>>> The easiest one to see is the one that Tarski's proof assumed.
>>>>>>>
>>>>>>> Saying those words does not alter the facts.  See page 65 of
>>>>>>> Mendelson.
>>>>>>
>>>>>> You are locked into thinking inside the box of assuming that all of
>>>>>> the aspects of mathematics have been infallibly connected together.
>>>>>
>>>>> You are stuck using words you don't understand.  By definition, every
>>>>> sentence of a theory is either true or false in every interpretation.
>>>>
>>>> Do you understand that a self-contradictory sentence would not
>>>> conform to this definition?
>>>
>>> Do you understand that the sort of "self-contradictory" sentences you
>>> keep talking about might occur in natural language, but they do not
>>> occur in the sorts of formal systems under consideration?
>>>
>>> André
>>>
>>
>> You are incorrect.
>  No, I am not. If I were, then presumably you would be able to provide
> an example of such a sentence, but you will not be able to. You have
> attempted this many times in the past, but never successfully.
>
> André
>


(1) x ∉ Pr if and only if p
(2) x ∈ Tr if and only if p;

This sentence is self-contradictory:
(3) x ∉ Pr if and only if x ∈ Tr.

(4) either x ∉ Tr or ¬x ∉ Tr;
(5) if x ∈ Pr, then x ∈ Tr;
(6) if ¬x ∈ Pr, then ¬x ∈ Tr;
(7) x ∈ Tr
(8) x ∉ Pr.
(9) ¬x ∉ Pr.

http://www.liarparadox.org/Tarski_Proof_275_276.pdf
Tarski, Alfred 1983. “The concept of truth in formalized languages” in
Logic Semantics, Metamathematics. Indianapolis: Hacket Publishing
Company, 275-276.

[André G. Isaak]

There's nothing self-contradictory about that sentence.

It's true if x is an element of Tr and not of Pr.
It's true if x is an element of Pr and not of Tr.
It's false otherwise.

Nor is there anything self-contradictory about the other 8 sentences you
give.

André

> (4) either x ∉ Tr or ¬x ∉ Tr;
> (5) if x ∈ Pr, then x ∈ Tr;
> (6) if ¬x ∈ Pr, then ¬x ∈ Tr;
> (7) x ∈ Tr
> (8) x ∉ Pr.
> (9) ¬x ∉ Pr.
>
> http://www.liarparadox.org/Tarski_Proof_275_276.pdf
> Tarski, Alfred 1983. “The concept of truth in formalized languages” in
> Logic Semantics, Metamathematics. Indianapolis: Hacket Publishing
> Company, 275-276.
>
>


--

To email remove 'invalid' & replace 'gm' with well known Google mail
service.

[olcott]

When you lookup and see what being an element of Tr and Pr means thenn
(then and only then) you can see that it is self-contradictory.

> It's true if x is an element of Pr and not of Tr.
> It's false otherwise.
>
> Nor is there anything self-contradictory about the other 8 sentences you
> give.
>
> André
>
>> (4) either x ∉ Tr or ¬x ∉ Tr;
>> (5) if x ∈ Pr, then x ∈ Tr;
>> (6) if ¬x ∈ Pr, then ¬x ∈ Tr;
>> (7) x ∈ Tr
>> (8) x ∉ Pr.
>> (9) ¬x ∉ Pr.
>>
>> http://www.liarparadox.org/Tarski_Proof_275_276.pdf
>> Tarski, Alfred 1983. “The concept of truth in formalized languages” in
>> Logic Semantics, Metamathematics. Indianapolis: Hacket Publishing
>> Company, 275-276.
>>
>>
>
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

I'm aware of what Tarski's Tr and Pr are. There is still nothing
self-contradictory about the above.

Even if we were to accept your perverse idea that provability and truth
are equivalent notions (they aren't), the above would STILL not be a
self-contradictory sentence. In that case it would simply be false.

André

[olcott]

Provability (when done correctly) is merely the valid inference aspect
of sound deduction.

When this is understood then Tarski's proof merely concludes that untrue
sentences cannot be proven to be true.

[André G. Isaak]

And there are propositions where 'you can't get there from here' using
valid inference. That's what incompleteness is all about.

> When this is understood then Tarski's proof merely concludes that untrue
> sentences cannot be proven to be true.

Even if this were true, what does it have to do with
'self-contradictory' sentences?

[olcott]

Tarski "proved" that not all true propositions can be defined on the
basis of failing to prove that a self-contradictory sentence is true.
He failed to prove that an untrue sentence is true.

[André G. Isaak]

On 2020-08-04 23:59, olcott wrote:

> Tarski "proved" that not all true propositions can be defined on the
> basis of failing to prove that a self-contradictory sentence is true.
> He failed to prove that an untrue sentence is true.

And which 'self-contradictory' sentence was that?

If he failed to prove that this sentence was true, then in what sense
would it be self-contradictory as opposed to simply false?

[olcott]

On 8/5/2020 1:44 AM, André G. Isaak wrote:
> On 2020-08-04 23:59, olcott wrote:
>
>> Tarski "proved" that not all true propositions can be defined on the
>> basis of failing to prove that a self-contradictory sentence is true.
>> He failed to prove that an untrue sentence is true.
>
> And which 'self-contradictory' sentence was that?
>

It would then be possible to reconstruct the antinomy of the liar in the
metalanguage, by forming in the language itself a sentence x such that
the sentence of the metalanguage which is correlated with x asserts that
x is not a true sentence. http://www.liarparadox.org/247_248.pdf

Everywhere, both in the formulation of the theorem and in its proof, we
replace the symbol 'Tr' by the symbol 'Pr' which denotes the class of
all provable sentences of the theory
http://www.liarparadox.org/Tarski_275_276.pdf

transforming this: x ∉ Tr if and only if x ∈ Tr.
into this: (3) x ∉ Pr if and only if x ∈ Tr.

> If he failed to prove that this sentence was true, then in what sense
> would it be self-contradictory as opposed to simply false?
>
> André
>

All logical propositions have distinctly different separate parts that
make the evaluation of their truth conditions impossible when these
parts are conflated together.

(a) Proposition assertion
(b) Satisfaction of Proposition assertion
(c) Satisfaction of Proposition

"This sentence is not true" is neither true nor false.

(a) S.Assertion = ~True(S)
(b) Satisfied(S.Assertion) == TRUE
(c) Satisfied(S) == FALSE

The fact that its assertion is satisfied makes it not false, the
sentence is indeed not true.

The truth of its assertion cannot be applied to the whole sentence
because this forms self-contradiction.

https://www.researchgate.net/publication/307442489_Formalizing_the_logical_self-reference_error_of_the_Liar_Paradox

[André G. Isaak]

On 2020-08-05 12:04, olcott wrote:
> On 8/5/2020 1:44 AM, André G. Isaak wrote:
>> On 2020-08-04 23:59, olcott wrote:
>>
>>> Tarski "proved" that not all true propositions can be defined on the
>>> basis of failing to prove that a self-contradictory sentence is true.
>>> He failed to prove that an untrue sentence is true.
>>
>> And which 'self-contradictory' sentence was that?
>>
>
> It would then be possible to reconstruct the antinomy of the liar in the
> metalanguage, by forming in the language itself a sentence x such that
> the sentence of the metalanguage which is correlated with x asserts that
> x is not a true sentence.  http://www.liarparadox.org/247_248.pdf
>
> Everywhere, both in the formulation of the theorem and in its proof, we
> replace the symbol 'Tr' by the symbol 'Pr' which denotes the class of
> all provable sentences of the theory
> http://www.liarparadox.org/Tarski_275_276.pdf
>
> transforming this: x ∉ Tr if and only if x ∈ Tr.
> into this: (3) x ∉ Pr if and only if x ∈ Tr.

You're failing to indicate where the alleged contradiction occurs in
(3). You can call it 'self-contradictory' to your hearts content, but
unless you can actually demonstrate that there is something
contradictory about the above you're not making your case.

>> If he failed to prove that this sentence was true, then in what sense
>> would it be self-contradictory as opposed to simply false?
>>
>> André
>>
>
> All logical propositions have distinctly different separate parts that
> make the evaluation of their truth conditions impossible when these
> parts are conflated together.
>
> (a) Proposition assertion
> (b) Satisfaction of Proposition assertion
> (c) Satisfaction of Proposition

AFAICT, the above is simply gibberish.

André

> "This sentence is not true" is neither true nor false.
>
> (a) S.Assertion = ~True(S)
> (b) Satisfied(S.Assertion) == TRUE
> (c) Satisfied(S) == FALSE
>
> The fact that its assertion is satisfied makes it not false, the
> sentence is indeed not true.
>
> The truth of its assertion cannot be applied to the whole sentence
> because this forms self-contradiction.
>
> https://www.researchgate.net/publication/307442489_Formalizing_the_logical_self-reference_error_of_the_Liar_Paradox
>
>
>


--

[olcott]

You have decided that you want to pretend to not understand.
I have zero patience for that.

> André
>
>> "This sentence is not true" is neither true nor false.
>>
>> (a) S.Assertion = ~True(S)
>> (b) Satisfied(S.Assertion) == TRUE
>> (c) Satisfied(S) == FALSE
>>
>> The fact that its assertion is satisfied makes it not false, the
>> sentence is indeed not true.
>>
>> The truth of its assertion cannot be applied to the whole sentence
>> because this forms self-contradiction.
>>
>> https://www.researchgate.net/publication/307442489_Formalizing_the_logical_self-reference_error_of_the_Liar_Paradox
>>
>>
>>
>
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

I am not pretending. How am I supposed to understand when you haven't
defined what 'proposition assertion' means, nor what 'satisfaction of
proposition assertion' means, nor what 'satisfaction of proposition'
means? These are your terms, not standard ones, and I am not telepathic.

You also have failed to indicate how these relate to the proposition in (3).

André

[olcott]

YOU SKIPPED THE PART WHERE I EXPLAINED IT.

How am I supposed to understand when you haven't
> defined what 'proposition assertion' means, nor what 'satisfaction of
> proposition assertion' means, nor what 'satisfaction of proposition'
> means? These are your terms, not standard ones, and I am not telepathic.
>
> You also have failed to indicate how these relate to the proposition in
> (3).
>
> André
>


--

Copyright 2020 Pete Olcott

[olcott]

On 8/5/2020 8:57 PM, André G. Isaak wrote:
> On 2020-08-05 12:04, olcott wrote:
>> On 8/5/2020 1:44 AM, André G. Isaak wrote:
>>> On 2020-08-04 23:59, olcott wrote:
>>>
>>>> Tarski "proved" that not all true propositions can be defined on the
>>>> basis of failing to prove that a self-contradictory sentence is true.
>>>> He failed to prove that an untrue sentence is true.
>>>
>>> And which 'self-contradictory' sentence was that?
>>>
>>
>> It would then be possible to reconstruct the antinomy of the liar in
>> the metalanguage, by forming in the language itself a sentence x such
>> that the sentence of the metalanguage which is correlated with x
>> asserts that x is not a true sentence.
>> http://www.liarparadox.org/247_248.pdf
>>
>> Everywhere, both in the formulation of the theorem and in its proof,
>> we replace the symbol 'Tr' by the symbol 'Pr' which denotes the class
>> of all provable sentences of the theory
>> http://www.liarparadox.org/Tarski_275_276.pdf
>>
>> transforming this: x ∉ Tr if and only if x ∈ Tr.
>> into this: (3) x ∉ Pr if and only if x ∈ Tr.
>
> You're failing to indicate where the alleged contradiction occurs

IF YOU ARE GOING TO PRETEND TO NOT UNDERSTAND THAT THE LIAR PARADOX IS
SELF-CONTRADICTORY YOU SHOULD JUST S THE F UP !!!

Copyright 2020 Pete Olcott

[André G. Isaak]

I see no part where you explained it. If such a part exists, please
point it out.

[olcott]

On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/9/2020 11:27 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>

>>> This is PO from two years ago, pretending to have a Turing machine:
>>>
>>>>>>> I now have an actual H that decides actual halting for an
>>>>>>> actual (Ĥ, Ĥ) input pair. I have to write the UTM to execute
>>>>>>> this code, that should not take very long. The key thing is
>>>>>>> the H and Ĥ are 100% fully encoded as actual Turing machines.
>>>>>
>>>>> Will you admit that at the very least you mislead everyone by using the
>>>>> term in a way that no one else does? An apology for that would be in
>>>>> order.
>>>>
>>>> No because the "c" version of H_Hat so perfectly corresponds to the
>>>> Linz diagram the "c" level abstraction of H_Hat is totally apt.
>>>
>>> The diagrams use and refer to states. That's because they are about
>>> Turing machines. If you have C, you don't have the states referred to
>>> in the diagrams because you don't have a Turing machine. At best you
>>> have interpreted the H to H^ transform correctly, but your track record
>>> of understanding an interpreting is not encouraging.
>>
>> So, in practical terms, you can consider your computer to be a Turing
>> machine instead of a finite state machine.
>>
>> https://cs.stackexchange.com/questions/16729/are-real-computers-finite-state-machines
>
> What "practical terms"? A Turing machine is mathematical object -- it's
> an ordered sequence of sets. TMs have, as a result, easily provable
> properties. My computer has no bearing on the matter.
>
> I am struck by the fact that until a few days ago you did not know what
> a function was and a function is essentially all the TM is. You can
> deduce or define as standard all the other parts the so many authors
> fuss over. It's just one big function. Given that, it's hardly
> surprising that don't know what a TM is. The essence of it is something
> you were baffled by until a few days ago.
>
> You don't have, and have never had, a Turing machine with the properties
> you claim. It would be good if you admitted that and moved on because
> attempting to defend the indefensible is taking up a lot of your time.
>

I have a finite state machine that implements computationally equivalent
code to the Peter Linz H_Hat such that this computational equivalent
correctly decides halting on itself showing exactly how the standard
self-referential halting problem counter-example can be defeated.

[Keith Thompson]

olcott <No...@NoWhere.com> writes:
> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:

[...]

>> You don't have, and have never had, a Turing machine with the properties
>> you claim. It would be good if you admitted that and moved on because
>> attempting to defend the indefensible is taking up a lot of your time.
>
> I have a finite state machine that implements computationally
> equivalent code to the Peter Linz H_Hat such that this computational
> equivalent correctly decides halting on itself showing exactly how the
> standard self-referential halting problem counter-example can be
> defeated.

As I recall, you've claimed to have pseudocode that you were going
to translate into working software. Did you ever actually get it
written and running?

Do you have a finite state machine, or do you merely have an *idea*
for a finite state machine?

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[olcott]

On 8/9/2020 4:44 PM, Keith Thompson wrote:
> olcott <No...@NoWhere.com> writes:
>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
> [...]
>>> You don't have, and have never had, a Turing machine with the properties
>>> you claim. It would be good if you admitted that and moved on because
>>> attempting to defend the indefensible is taking up a lot of your time.
>>
>> I have a finite state machine that implements computationally
>> equivalent code to the Peter Linz H_Hat such that this computational
>> equivalent correctly decides halting on itself showing exactly how the
>> standard self-referential halting problem counter-example can be
>> defeated.
>
> As I recall, you've claimed to have pseudocode that you were going
> to translate into working software. Did you ever actually get it
> written and running?
>
> Do you have a finite state machine, or do you merely have an *idea*
> for a finite state machine?
>

I translated the finite state equivalent of the same self-referential
counter-example that all the Halting Problem proofs are based on into
"C". I am using a very excellent x86 interpreter to run the machine code
of this "C" function. It turns out that Visual "C++" generates machine
code that is easier to understand than g++.

The machine code examines itself and decides halting on itself.
The key part that I have been working on for the last week is building
the context switching aspect of the master UTM such that one UTM can
execute another UTM and this can be to arbitrary depth. I am guessing
that this will be done very soon. Although this is the most difficult
part that remains it is standard operating system software engineering.

Converting an x86 interpreter into a UTM that can execute a chain of
UTMs of arbitrary depth has taken most of my time. Half of this time was
learning the internals of the x86 interpreter well enough that I can
make the changes needed. Less that 10% of my time was spent on anything
directly related to halt deciding.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>> olcott <No...@NoWhere.com> writes:
>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>> [...]
>>>> You don't have, and have never had, a Turing machine with the properties
>>>> you claim. It would be good if you admitted that and moved on because
>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>
>>> I have a finite state machine

How many states does it have? What are the domain and co-domain of the
state transition function?

>>> that implements computationally
>>> equivalent code to the Peter Linz H_Hat such that this computational
>>> equivalent correctly decides halting on itself showing exactly how the
>>> standard self-referential halting problem counter-example can be
>>> defeated.

So you've had "an actual Turing machine", "an algorithm", "an actual
pair of virtual machines", "pseudo code", "c code" and "a finite state
machine" and goodness knows what else at various stages. And nothing at
all has ever been posted. Not a peep in over two years of boasting.
You can appreciate why this is hard to believe.

>> As I recall, you've claimed to have pseudocode that you were going
>> to translate into working software. Did you ever actually get it
>> written and running?
>>
>> Do you have a finite state machine, or do you merely have an *idea*
>> for a finite state machine?
>
> I translated the finite state equivalent of the same self-referential
> counter-example that all the Halting Problem proofs are based on into
> "C". I am using a very excellent x86 interpreter to run the machine
> code of this "C" function. It turns out that Visual "C++" generates
> machine code that is easier to understand than g++.
>
> The machine code examines itself and decides halting on itself. The
> key part that I have been working on for the last week is building the
> context switching aspect of the master UTM such that one UTM can
> execute another UTM and this can be to arbitrary depth. I am guessing
> that this will be done very soon. Although this is the most difficult
> part that remains it is standard operating system software
> engineering.
>
> Converting an x86 interpreter into a UTM that can execute a chain of
> UTMs of arbitrary depth has taken most of my time. Half of this time
> was learning the internals of the x86 interpreter well enough that I
> can make the changes needed. Less that 10% of my time was spent on
> anything directly related to halt deciding.

Do you think anyone cares about this almighty pile of guff? Do you
think anyone will wade through it all to find your mistake? I suppose
that's the purpose. The original claim -- that you had "an actual
Turing machine" "fully encoded" was interesting because a TM is simple
and unambiguous. Your error would be obvious. It's taken you two years
to obfuscate a simple claim with enough cruft that no one cares.

--
Ben.

[Keith Thompson]

olcott <No...@NoWhere.com> writes:
> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>> olcott <No...@NoWhere.com> writes:
>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>> [...]
>>>> You don't have, and have never had, a Turing machine with the properties
>>>> you claim. It would be good if you admitted that and moved on because
>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>
>>> I have a finite state machine that implements computationally
>>> equivalent code to the Peter Linz H_Hat such that this computational
>>> equivalent correctly decides halting on itself showing exactly how the
>>> standard self-referential halting problem counter-example can be
>>> defeated.
>>
>> As I recall, you've claimed to have pseudocode that you were going
>> to translate into working software. Did you ever actually get it
>> written and running?
>>
>> Do you have a finite state machine, or do you merely have an *idea*
>> for a finite state machine?
>
> I translated the finite state equivalent of the same self-referential
> counter-example that all the Halting Problem proofs are based on into
> "C". I am using a very excellent x86 interpreter to run the machine
> code of this "C" function. It turns out that Visual "C++" generates
> machine code that is easier to understand than g++.

So now you have a "C" function.

The quotation marks around C seem odd. Are they significant, and if
so, what's the difference between a "C" function and a C function?
I presume you're referring to the C programming language.

How many lines of C code are in this function? I presume posting
that number wouldn't harm its "trade secret" status. (I'm not
interested in any answer to this question that isn't a specific
positive integer.)

Does this function conform to the C language standard? Which edition
(C90, C99, C11, ...)?

Does this "C" function exist in the context of a C program that
you can compile, link, and execute? Have you done so?

Why do you need an x86 interpreter to "run the machine code of this
"C" function"? Why can't you just compile it with an ordinary C
compiler and execute it? I understand that the goal is to feed
your program its own machine code as input (correct?), but are you
able to create an executable that can be run with, for example,
empty input? (I understand that it might fail with empty input,
but the ability to run the program *at all* is a significant step.)

> The machine code examines itself and decides halting on itself.
> The key part that I have been working on for the last week is building
> the context switching aspect of the master UTM such that one UTM can
> execute another UTM and this can be to arbitrary depth. I am guessing
> that this will be done very soon. Although this is the most difficult
> part that remains it is standard operating system software
> engineering.
>
> Converting an x86 interpreter into a UTM that can execute a chain of
> UTMs of arbitrary depth has taken most of my time. Half of this time
> was learning the internals of the x86 interpreter well enough that I
> can make the changes needed. Less that 10% of my time was spent on
> anything directly related to halt deciding.

--

[olcott]

On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

> You don't have, and have never had, a Turing machine with the properties
> you claim. It would be good if you admitted that and moved on because
> attempting to defend the indefensible is taking up a lot of your time.

I will strengthen my prior answer. What I have nearly completed is about
the closest thing to a UTM that can be conceived where the Turing
Machine description language is the x86 language.

I only actually use a tiny subset of this language.

[olcott]

I can't finish the halt decider until its master UTM is complete.
The details of the greatly enhanced halt decider have been designed for
many months.

> Does this function conform to the C language standard? Which edition
> (C90, C99, C11, ...)?
>
> Does this "C" function exist in the context of a C program that
> you can compile, link, and execute? Have you done so?
>

It can only be correctly executed inside the master UTM and this is not
quite built yet.

> Why do you need an x86 interpreter to "run the machine code of this
> "C" function"? Why can't you just compile it with an ordinary C

I need to function to examine its own machine code because the control
flow of machine code is straight forward. I need an x86 interpreter as
the basis of the master UTM.

> compiler and execute it? I understand that the goal is to feed
> your program its own machine code as input (correct?), but are you
> able to create an executable that can be run with, for example,
> empty input? (I understand that it might fail with empty input,
> but the ability to run the program *at all* is a significant step.)
>
>> The machine code examines itself and decides halting on itself.
>> The key part that I have been working on for the last week is building
>> the context switching aspect of the master UTM such that one UTM can
>> execute another UTM and this can be to arbitrary depth. I am guessing
>> that this will be done very soon. Although this is the most difficult
>> part that remains it is standard operating system software
>> engineering.
>>
>> Converting an x86 interpreter into a UTM that can execute a chain of
>> UTMs of arbitrary depth has taken most of my time. Half of this time
>> was learning the internals of the x86 interpreter well enough that I
>> can make the changes needed. Less that 10% of my time was spent on
>> anything directly related to halt deciding.
>


--

Copyright 2020 Pete Olcott

[Keith Thompson]

Nothing you've written actually responds to anything I asked.

I'll just conclude that you have a vague "design" for some code that
you eventually intend to write, and that you haven't yet written
an actual C function of any kind.

[olcott]

If you understand what the x86 language is and you understand what a UTM
is then you can put them together and know what I have. If you don't
understand what these are then you cannot begin to understand what I have.

[Keith Thompson]

Nonsense.

[olcott]

On 8/9/2020 11:26 PM, André G. Isaak wrote:
> On 2020-08-09 21:32, olcott wrote:

>> On 8/9/2020 9:08 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/9/2020 6:16 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>> [...]
>>>>>>>>> You don't have, and have never had, a Turing machine with the
>>>>>>>>> properties
>>>>>>>>> you claim.  It would be good if you admitted that and moved on
>>>>>>>>> because
>>>>>>>>> attempting to defend the indefensible is taking up a lot of
>>>>>>>>> your time.
>>>>>>>>
>>>>>>>> I have a finite state machine
>>>>
>>>>> How many states does it have?  What are the domain and co-domain of
>>>>> the
>>>>> state transition function?
>>>>

>>>> That depends on how the states are counted.
>>>> Every time that memory changes can be counted as a state change.
>>>
>>> Ah, so you don't have a state machine either.  You have real trouble
>>> with the names of things.  What /do/ you have, and what did you have in
>>> Dec 2018?  I'd like conventional descriptions if possible.  If it's a C
>>> program, don't call it Pascal because they are "computationally
>>> equivalent".
>>>
>>
>> It is just about the closest thing to a UTM that anyone could ever
>> create where the Turing machine Description language is x86 machine
>> language.
>
> x86 machine language is not a 'Turing Machine Description Language'.
>
> Do you actually understand what a UTM is?

Do you understand what a UTM would be if it had x86 as its Turing
Machine Description language?

>
> What is the actual expected input for your program?
>
> André
>

It it very easy to write "C" programs and have them translated into very
simple x86 programs using the Visual C++ compiler. The g++/gcc compiler
does not do as well.

When a program needs to examine the control flow of a program it is much
easier in machine language because everything is tied together with
integer addresses.

The whole purpose of this x86 UTM is to run what is essentially the
Peter Linz H_Hat as x86 machine language with itself as its own input as
x86 machine language. When the master UTM is based on the x86 language
we no longer need to make the distinction between a TM and its
description they are one and the same thing.

[olcott]

That is exactly the answer that would be expected from someone that does
not know the underlying subject matter. I have been working with the x86
language since the early 1980's. This was back when 64K was the maximum
segment size. Boy is it a relief to have 4 GB segments, switching
between 64K segments was so tedious.

[Keith Thompson]

Resorting to insults means you don't have to explain anything, right?

I've noticed you tend to do that when someone pushes you to answer a
simple question.

Here's an easy one. You've used the phrase
a "C" function
Is there any significant difference in meaning between that and
a C function
?

I'm just asking you to explain the quotation marks. If they don't
mean anything, that's fine.

[André G. Isaak]

That's not an answer to my question. Do you understand what a UTM is?
Can you explain what you think a UTM is in simple English without any
links to webpages?

>>
>> What is the actual expected input for your program?

And again, none of what you write below is an answer to this question.
What is the *input* which your program expects?

Do you understand how questions work?

To make this question clearer, assuming that your program looks like this:

int main (int argc, const char * argv[]) {

...

}

explain exactly what argv[] consists of.

>> André
>>
>
> It it very easy to write "C" programs and have them translated into very
> simple x86 programs using the Visual C++ compiler. The g++/gcc compiler
> does not do as well.


> When a program needs to examine the control flow of a program it is much
> easier in machine language because everything is tied together with
> integer addresses.
>
> The whole purpose of this x86 UTM is to run what is essentially the
> Peter Linz H_Hat as x86 machine language with itself as its own input as
> x86 machine language. When the master UTM is based on the x86 language
> we no longer need to make the distinction between a TM and its
> description they are one and the same thing.
>
>


--

[olcott]

Merely an objective assessment.

> I've noticed you tend to do that when someone pushes you to answer a
> simple question.
>
> Here's an easy one. You've used the phrase
> a "C" function
> Is there any significant difference in meaning between that and
> a C function
> ?

No, it is merely easier to read.

>
> I'm just asking you to explain the quotation marks. If they don't
> mean anything, that's fine.
>


--

Copyright 2020 Pete Olcott

[olcott]

Yes I can.

>>>
>>> What is the actual expected input for your program?
>
> And again, none of what you write below is an answer to this question.
> What is the *input* which your program expects?
>

I already answered that in great depth.
The input of my x86 version of the Peter Linz H_Hat is its own x86 code.

> Do you understand how questions work?
>
> To make this question clearer, assuming that your program looks like this:
>
> int main (int argc, const char * argv[]) {
>
> ...
>
> }
>
> explain exactly what argv[] consists of.
>
>>> André
>>>
>>
>> It it very easy to write "C" programs and have them translated into
>> very simple x86 programs using the Visual C++ compiler. The g++/gcc
>> compiler does not do as well.
>
>
>> When a program needs to examine the control flow of a program it is
>> much easier in machine language because everything is tied together
>> with integer addresses.
>>
>> The whole purpose of this x86 UTM is to run what is essentially the
>> Peter Linz H_Hat as x86 machine language with itself as its own input
>> as x86 machine language. When the master UTM is based on the x86
>> language we no longer need to make the distinction between a TM and
>> its description they are one and the same thing.
>>
>>
>
>


--

Copyright 2020 Pete Olcott

[Keith Thompson]

Whatever. I'm not going to follow that particular digression any further.

>> I've noticed you tend to do that when someone pushes you to answer a
>> simple question.
>>
>> Here's an easy one. You've used the phrase
>> a "C" function
>> Is there any significant difference in meaning between that and
>> a C function
>> ?
>
> No, it is merely easier to read.

Great.

Is there a number of times I have to ask a straightforward question
before you'll answer it? Would it help if I just ask it that
many times in a single post? (This doesn't imply I'd be willing
to do that.) Yes, I'm being a bit sarcastic, but if you'll read
the quoted material in this post, I think you'll see that you've
been extraordinarily unwilling to answer simple questions (and
that has led me to make certain inferences that I won't get into
for the moment).

FWIW, putting quotation marks around C does not make it easier
to read. As you can see my my response, all it does is make me
think that there's some significance to them. But now that I know
that there isn't:

You've referred to a C function. Have you written this C function?
Is it, or is it intended to be, in standard C? Which edition of the
standard does it attempt to conform to? How many lines long is it?
(If you were willing to share the function itself that would be
great, but I presume you won't do that.)

I'll leave questions about what the function is supposed to do
for later.

I've already asked you these questions, and you ignored them.
I presume that it's important *to you* to communicate something
about what you're working on. It's less important to me. So I'm
not going to be as persistent about getting you to answer these
simple questions.

>> I'm just asking you to explain the quotation marks. If they don't
>> mean anything, that's fine.

--

[olcott]

I can't write the function yet because its operating system is not
finished. The function itself is in very standard very simple c.
It is the same c since the first ansi c. I began writing c back when it
was K&R c.

>
> I've already asked you these questions, and you ignored them.
> I presume that it's important *to you* to communicate something
> about what you're working on. It's less important to me. So I'm
> not going to be as persistent about getting you to answer these
> simple questions.
>

I told you that I can't write the function because its operating system
is not finished.

>>> I'm just asking you to explain the quotation marks. If they don't
>>> mean anything, that's fine.
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

Normally, such an answer would be followed by such an explanation. You
really should read up on Grice's Maxims of cooperative conversation.

A UTM is...

>>>>
>>>> What is the actual expected input for your program?
>>
>> And again, none of what you write below is an answer to this question.
>> What is the *input* which your program expects?
>>
>
> I already answered that in great depth.
> The input of my x86 version of the Peter Linz H_Hat is its own x86 code.

That is entirely unclear.

Does this mean that the input is x86 code?

Or does it mean that it is specifically its own x86 code and that it
will refuse to run given any other input?

>> Do you understand how questions work?
>>
>> To make this question clearer, assuming that your program looks like
>> this:
>>
>> int main (int argc, const char * argv[]) {
>>
>> ...
>>
>> }
>>
>> explain exactly what argv[] consists of.
>>
>>>> André
>>>>
>>>
>>> It it very easy to write "C" programs and have them translated into
>>> very simple x86 programs using the Visual C++ compiler. The g++/gcc
>>> compiler does not do as well.
>>
>>
>>> When a program needs to examine the control flow of a program it is
>>> much easier in machine language because everything is tied together
>>> with integer addresses.
>>>
>>> The whole purpose of this x86 UTM is to run what is essentially the
>>> Peter Linz H_Hat as x86 machine language with itself as its own input
>>> as x86 machine language. When the master UTM is based on the x86
>>> language we no longer need to make the distinction between a TM and
>>> its description they are one and the same thing.
>>>
>>>
>>
>>
>
>


--

[Keith Thompson]

So you have no C function. Got it.

> The function itself is in very standard very simple c.

You mean it *will be* in very standard very simple C.

> It is the same c since the first ansi c. I began writing c back when
> it was K&R c.

Great, so did I. I'm not sure what you mean by "the same c".
If you mean that this C function that you haven't written yet will
be compatible with the first ANSI C standard and with all later
standards, that's fine. If you mean that the language itself hasn't
changed, that's simply incorrect. I'll explain further if and only
if you ask me to.

>> I've already asked you these questions, and you ignored them.
>> I presume that it's important *to you* to communicate something
>> about what you're working on. It's less important to me. So I'm
>> not going to be as persistent about getting you to answer these
>> simple questions.
>
> I told you that I can't write the function because its operating
> system is not finished.
>
>>>> I'm just asking you to explain the quotation marks. If they don't
>>>> mean anything, that's fine.

You claimed to have a C function. You don't. You acknowledge that
you haven't written it. No doubt you have some design or idea, or
perhaps something written down in some kind of pseudocode, and
we could discuss that if you like, but you don't have a C function.

I *think* you've said or implied that this C function is the same
thing as the "fully encoded Turing Machine" you've been making
claims about (because C is Turing-complete, and you therefore think
you can call any chunk of C code a "fully encoded Turing machine").
Is that correct? So you never had your Turing machine either.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> I will strengthen my prior answer. What I have nearly completed is
> about the closest thing to a UTM that can be conceived where the
> Turing Machine description language is the x86 language.

Why do you think anyone would be interested in this claim? It shows up
a few misconceptions, but I can't interpret it in any way that makes it
interesting.

--
Ben.

[Wasell]

On Sun, 9 Aug 2020 16:30:58 -0500, in article <woGdnUPdH5WK9q3CnZ2dnUU7-
V3N...@giganews.com>, olcott wrote:

[snip]

> I have a finite state machine that implements computationally equivalent
> code to the Peter Linz H_Hat such that this computational equivalent
> correctly decides halting on itself showing exactly how the standard
> self-referential halting problem counter-example can be defeated.

You are, I hope, aware of the fact that Finite State Machines are (in
general) much, *much* weaker than Turing Machines. Actually, FSMs are
exactly those TMs that have a transition function that *always* move to
the right.

This means that an FSM can never refer to "earlier" (i.e. leftward) parts
of the "tape".

This, in turn, means that anything you prove about FSMs doesn't
*necessarily* carry over to TMs. Therefore, if you want to prove something
about TMs, and you manages to prove that something about FSMs, you still
need to provide a proof that it carries over to TMs.

You having "a finite state machine that implements computationally
equivalent code <blargh>" is entirely pointless, unless you supply an
actual *proof* that the relevant properties of your FSM carries over to
*all* TMs. (Also, if you want to claim "computational equivalence", you
need to supply an actual *proof* of that. Otherwise it's just impotent
posturing.)

[olcott]

I can but refuse to do so the question was disrespectful.

>
>>>>>
>>>>> What is the actual expected input for your program?
>>>
>>> And again, none of what you write below is an answer to this
>>> question. What is the *input* which your program expects?
>>>
>>
>> I already answered that in great depth.
>> The input of my x86 version of the Peter Linz H_Hat is its own x86 code.
>
> That is entirely unclear.
>
> Does this mean that the input is x86 code?

I just said that the input in this specific case is x86 code.
More specifically it is the input of a specific x86 program.
More specifically it is the program at the bottom of page 319.
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

The UTM can handle input of any 32-bit memory block up to 4GB and it can
address elements in this block as 32-bit, 16-bit and 8-bit signed or
unsigned integers.

> Or does it mean that it is specifically its own x86 code and that it
> will refuse to run given any other input?

The UTM is in every way a generic x86 based operating system and can run
any x86 software that does not need I/O. All of the data that it uses
must already be specified on its tape. The x86 emulator fully emulates
all of the x86 instructions except those of a math coprocessor.

>>> Do you understand how questions work?
>>>
>>> To make this question clearer, assuming that your program looks like
>>> this:
>>>
>>> int main (int argc, const char * argv[]) {
>>>
>>> ...
>>>
>>> }
>>>
>>> explain exactly what argv[] consists of.
>>>
>>>>> André
>>>>>
>>>>
>>>> It it very easy to write "C" programs and have them translated into
>>>> very simple x86 programs using the Visual C++ compiler. The g++/gcc
>>>> compiler does not do as well.
>>>
>>>
>>>> When a program needs to examine the control flow of a program it is
>>>> much easier in machine language because everything is tied together
>>>> with integer addresses.
>>>>
>>>> The whole purpose of this x86 UTM is to run what is essentially the
>>>> Peter Linz H_Hat as x86 machine language with itself as its own
>>>> input as x86 machine language. When the master UTM is based on the
>>>> x86 language we no longer need to make the distinction between a TM
>>>> and its description they are one and the same thing.
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--

Copyright 2020 Pete Olcott

[olcott]

Some of the code is written and executing.

>> It is the same c since the first ansi c. I began writing c back when
>> it was K&R c.
>
> Great, so did I. I'm not sure what you mean by "the same c".
> If you mean that this C function that you haven't written yet will
> be compatible with the first ANSI C standard and with all later
> standards, that's fine.

I can't write the halt deciding aspects of the code until after I have
added heap allocation and process context switching support. Their
detailed design has been complete for many months. This has been very
significanlty augmented from the 2018_12_13 initial specification.

> If you mean that the language itself hasn't
> changed, that's simply incorrect. I'll explain further if and only
> if you ask me to.

It is and has been the x86 language for many months. When I finish
adding minimal operating system support it will be a UTM having the x86
language as its Turing Machine Description language. with at least two
(build from scratch) operating system functions that can be invoked from
this language: (1) Allocation for the heap (2) Process context switching
from one UTM to another.

>>> I've already asked you these questions, and you ignored them.
>>> I presume that it's important *to you* to communicate something
>>> about what you're working on. It's less important to me. So I'm
>>> not going to be as persistent about getting you to answer these
>>> simple questions.
>>
>> I told you that I can't write the function because its operating
>> system is not finished.
>>
>>>>> I'm just asking you to explain the quotation marks. If they don't
>>>>> mean anything, that's fine.
>
> You claimed to have a C function. You don't. You acknowledge that
> you haven't written it. No doubt you have some design or idea, or
> perhaps something written down in some kind of pseudocode, and
> we could discuss that if you like, but you don't have a C function.

I have a c function that is fully executable except for those aspects
that depends on operating system support.

> I *think* you've said or implied that this C function is the same
> thing as the "fully encoded Turing Machine" you've been making
> claims about (because C is Turing-complete, and you therefore think
> you can call any chunk of C code a "fully encoded Turing machine").
> Is that correct? So you never had your Turing machine either.

All c code is Turing complete except for processes such as counting to
infinity and storing the result. If a machine had x-bit relative
addressing and no direct memory addressing then c could be easily mapped
to an actual Turing machine.

[André G. Isaak]

That is not even remotely what a UTM is, which is why I asked you above
to define what you mean by UTM. It is clear you mean something entirely
different from the standard meaning of UTM, but without knowing your
private definition of UTM, nothing you write is even interpretable.

André

[olcott]

On 8/10/2020 9:01 AM, Wasell wrote:
> On Sun, 9 Aug 2020 16:30:58 -0500, in article <woGdnUPdH5WK9q3CnZ2dnUU7-
> V3N...@giganews.com>, olcott wrote:
>
> [snip]
>
>> I have a finite state machine that implements computationally equivalent
>> code to the Peter Linz H_Hat such that this computational equivalent
>> correctly decides halting on itself showing exactly how the standard
>> self-referential halting problem counter-example can be defeated.
>
> You are, I hope, aware of the fact that Finite State Machines are (in
> general) much, *much* weaker than Turing Machines. Actually, FSMs are
> exactly those TMs that have a transition function that *always* move to
> the right.
>

I was using the term: finite state machine based on the ordinary meaning
of the terms "finite" + "state" + "machine" and not their idiomatic
terms of the art meaning. https://en.wikipedia.org/wiki/Finite-state_machine

> This means that an FSM can never refer to "earlier" (i.e. leftward) parts
> of the "tape".
>
> This, in turn, means that anything you prove about FSMs doesn't
> *necessarily* carry over to TMs. Therefore, if you want to prove something
> about TMs, and you manages to prove that something about FSMs, you still
> need to provide a proof that it carries over to TMs.
>

What I am really referring to is this machine architecture
https://en.wikipedia.org/wiki/Random-access_stored-program_machine
as implemented by the x86 programming language.

Apparently all that we need to do to convert the x86 programming
language into a Turing complete language is get rid of direct memory
addressing and replace it with x-bit relative addressing.

In any case the x86 language is apparently already Turing complete for
the set of computations that do not need unlimited memory.

> You having "a finite state machine that implements computationally
> equivalent code <blargh>" is entirely pointless, unless you supply an
> actual *proof* that the relevant properties of your FSM carries over to
> *all* TMs. (Also, if you want to claim "computational equivalence", you
> need to supply an actual *proof* of that. Otherwise it's just impotent
> posturing.)
>

[olcott]

On 8/10/2020 10:12 AM, Andy Walker wrote:
> On 10/08/2020 15:35, olcott wrote:
>> If we envision a very slight modification to the x86 language such
>> that this language only has x-bit relative adressing and had no
>> direct memory addressing then the x86 language would be fully Turing
>> complete. A very slight adaptation of standard "C" compilers could
>> generate this code. Now people could write Turing complete machine
>> code in "C".
>
>     You don't need to alter C or C compilers *at* *all* in order
> to have a Turing-complete language.  All that is necessary is for a
> perfectly-ordinary C program to say "Please replace the current USB
> stick by the next/previous one" and to use the sticks as auxiliary
> storage to implement an unbounded tape [which may, of course, thereby
> need an unbounded number of USB sticks].  This actually updates
> Turing's original concept of a [human] computer with a sufficient
> [and extensible] stack of paper.  You could need to go to the shop
> from time to time to buy a new USB stick.
>

Great I really appreciate your support on this very crucial key element.

>> The reason why this system is interesting is that it shows every
>> detail of the steps required for the standard self-referential
>> halting problem counter-example to decide halting on itself in a very
>> small amount of finite memory in very few steps.
>
>     The system you are currently describing is not in the least
> interesting for the purpose you have been espousing.  If what you
> are claiming can be done by a small program in X86 machine code, then
> it can equally be done by a small C program, which would equally use
> "a very small amount of finite memory in very few steps".  Many people
> here would be much more interested in such a C program than in machine
> code and perhaps even than in a probably-botched TM description.
>

I had to do it in machine code because the control flow of machine code
is precisely specified state transitions that are tied together with
integer machine addresses. I really needed that directed graph as the
basis of halt deciding.

[olcott]

I mean the standard conventional idea of a UTM that had been adapted
such that the x86 language is its Turing Machine description language.

[André G. Isaak]

And what exactly do you mean by the 'standard conventional idea of a UTM'?

Again, can you explain this in your own words without simply copying a
web address. I do not believe that what you mean is actually the
conventional meaning of the term.

[olcott]

Yes I can.

> I do not believe that what you mean is actually the
> conventional meaning of the term.
>
> André
>
>

I really don't care what you believe.

[André G. Isaak]

Clearly, then, you have absolutely no interest in communicating whatever
it is that you are trying to claim.

What you describe above is not even remotely a UTM according to the
'standard conventional idea of a UTM', so unless you actually explain
what *you* mean by a UTM you have no hope of being understood.

Since x86 assembly language is also not even remotely a "Turing Machine
description language", the phrase "a UTM that had been adapted such that
the x86 language is its Turing Machine description language" is an
entirely meaningless phrase without clarification on your part.

I am not the only one who has asked for your definition of "(Universal)
Turing Machine" so clearly I am not the only one who wants to know what
exactly it is that you mean by this. If you were using this term as it
is conventionally understood, no one would be asking this question.

[olcott]

On 8/10/2020 10:42 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/10/2020 9:02 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/9/2020 9:08 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/9/2020 6:16 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/9/2020 4:44 PM, Keith Thompson wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>> On 8/9/2020 3:57 PM, Ben Bacarisse wrote:
>>>>>>>>> [...]
>>>>>>>>>>> You don't have, and have never had, a Turing machine with the properties
>>>>>>>>>>> you claim. It would be good if you admitted that and moved on because
>>>>>>>>>>> attempting to defend the indefensible is taking up a lot of your time.
>>>>>>>>>>
>>>>>>>>>> I have a finite state machine
>>>>>>
>>>>>>> How many states does it have? What are the domain and co-domain of the
>>>>>>> state transition function?
>>>>>>
>>>>>> That depends on how the states are counted.
>>>>>> Every time that memory changes can be counted as a state change.
>>>>>
>>>>> Ah, so you don't have a state machine either. You have real trouble
>>>>> with the names of things. What /do/ you have, and what did you have in
>>>>> Dec 2018? I'd like conventional descriptions if possible. If it's a C
>>>>> program, don't call it Pascal because they are "computationally
>>>>> equivalent".
>>>>

>>>> I said much more exactly what I have in the part that you ignored.
>>>> You apparently don't know that an x86 machine is a finite state
>>>> machine.
>>>
>>> This is comp.theory. A finite state machine is an abstract mathematical
>>> object, just like a Turing machine is an abstract mathematical object.
>>
>> I never ever mean the idiomatic meaning:
>> https://en.wikipedia.org/wiki/Finite-state_machine
>> A finite state machine is literally any machine that has finite states.
>> The term-of-the-art is a figurative idsiomatic meaning.
>
> So you are deliberately being vague. You might as say you have a
> "thing". The point of technical terms is to be able to convey accurate
> information. That appears not to be your purpose here. It's a cover-up.
>

I said that I did not mean the idiomatic term-of-the-art meaning how it
that vague?

>>> It is quite clear you have neither. If you have a C program, "I have a
>>> C program" is the clearest answer -- no duplicitous games pretending
>>> that that's a Turing machine. If you have x86 assembler or machine code
>>> then "I have x86 code" is the clear answer. Saying, instead, that you
>>> have a finite state machine (because an x86 is a bit like an FSM
>>> realised in hardware) is a deliberate attempt to deceive. You are
>>> clearly doing your best to obscure what you have. My guess is because
>>> you have nothing at all.
>>>
>>> And now in other posts you have altered your claim to make it banal in
>>> the extreme. It's likely that you have no idea what you've said
>>> recently since you use so many words without understanding them, but at
>>> the moment I have no reason to be interested in your claims.
>>>
>>> The original claim, from way back in 2018 was very precise (though you
>>> kept having trouble stating it). It was that you have a pair of TMs, P
>>> and P^, say, that are related by the ^ construction as in Linz. A pair
>>> with the property that P(<[P^], [P^]>) is "correct". You were at pains
>>> to point out that P is not a halt decider (in the general sense) but
>>> only that it is correct about this one case. Normally, a single-case of
>>> an undecidable problem is not interesting (because all finite sets are
>>> decidable) but this one case is special because of the relationship
>>> between the two TMs.
>>>
>>> Since then, you have done your best to avoid being clear about any of
>>> this. I would appreciate bullshit free answers to some questions:
>>>
>>> 1. Is this still your claim, given that you now know that a TM is a
>>> specific mathematical object and not some code written in a more-or-less
>>> Turing complete language?
>
> No answer. If you don't understand, you can say you don't know.

I have never been referring to the math. I have always been referring to
the computer science.

>>> 2. Recent posts have said that you really do claim to have a halting
>>> decider. Have you extended your claim or was that a misunderstanding?
>>

I really do have the complete detailed design of a halting decider that
would decide all of the conventional self-referential halting problem
counter-examples. Since you have little coding experience you are unable
to appreciate that sufficiently detailed pseudo-code fully encodes every
detail of an algorithm.

>> The most important aspect of my claim is that the program for a fully
>> operational halt decider that decides the conventional
>> self-referential halting problem counter-examples is almost fully
>> encoded in x86 machine language. 95% of the work of encoding required
>> building an x86 based UTM.
>
> Not an answer.
>
>>> 3. What was it you really had by Dec 15th 2018? The closest you've come
>>> to saying is that it was something sufficiently like a TM for you to
>>> think you could call it one without it being a lie.
>>>
>>> You have worked really hard to avoid being clear about point 3. You
>>> have variously said you had "an actual Turing machine", "an algorithm",
>>> "pseudo code", "a finite state machine" and more. And you've spoken of
>>> C code and then said you have not yet written the C. The fact that it's
>>> a simple question, unanswered for so long, suggests you either don't
>>> know what you had or you don't dare say.
>>
>> On 2018-12-13 I was thinking that I would have to build a subset of a
>> "C" compiler from scratch and a subset of a machine language from
>> scratch, and a simple operating system from scratch. I spent three
>> months working in building the "c" compiler.
>
> Nothing here answers the question. Your replies read more like a
> cover-up rather than an explanation. What are you hiding?
>
>>> Looking at the old discussion along wih the new posts it seems clear
>>> that you are misusing the term UTM. I suggest you stop using that
>>> acronym and use plain words instead until you understand exactly what a
>>> UTM is.
>>
>> It is very nearly the closest possible thing to a UTM that can
>> possibly exist when the UTM has the x86 language as its Turing machine
>> description language.
>
> I hope you don't know what a UTM is. If you do, you have wasted your time.
>

It is better than a mere UTM it is a UTM that executes a chain of other
UTMs of arbitrary depth. The master UTM executes H_Hat that executes
itself.

[olcott]

All beliefs are distractions away from Truth.

> What you describe above is not even remotely a UTM according to the
> 'standard conventional idea of a UTM', so unless you actually explain
> what *you* mean by a UTM you have no hope of being understood.
>
> Since x86 assembly language is also not even remotely a "Turing Machine
> description language", the phrase "a UTM that had been adapted such that
> the x86 language is its Turing Machine description language" is an
> entirely meaningless phrase without clarification on your part.
>
> I am not the only one who has asked for your definition of "(Universal)
> Turing Machine" so clearly I am not the only one who wants to know what
> exactly it is that you mean by this. If you were using this term as it
> is conventionally understood, no one would be asking this question.
>
> André
>

My master UTM can execute a chain of UTM's of arbitrary depth. It
executes H_Hat that executes itself as H_Hat's basis for deciding
halting on itself. All of the memory is a single contiguous block that
can be dynamically extended during run-time again and again.

[André G. Isaak]

None of that addresses my question. I am asking you to provide *your*
definition of UTM. Not what your UTM does, but what you think a UTM
actually is.

[olcott]

How many times do I have to tell you that this question is disrespectful
and will not be answered?

[Keith Thompson]

You said "I can't write the function yet". "Some of the code" could
mean anything. You don't have a C function.

> >> It is the same c since the first ansi c. I began writing c back when
>>> it was K&R c.
>>
>> Great, so did I. I'm not sure what you mean by "the same c".
>> If you mean that this C function that you haven't written yet will
>> be compatible with the first ANSI C standard and with all later
>> standards, that's fine.
>
> I can't write the halt deciding aspects of the code until after I have
> added heap allocation and process context switching support. Their
> detailed design has been complete for many months. This has been very
> significanlty augmented from the 2018_12_13 initial specification.
>
>> If you mean that the language itself hasn't
>> changed, that's simply incorrect. I'll explain further if and only
>> if you ask me to.
>
> It is and has been the x86 language for many months. When I finish
> adding minimal operating system support it will be a UTM having the
> x86 language as its Turing Machine Description language. with at least
> two (build from scratch) operating system functions that can be
> invoked from this language: (1) Allocation for the heap (2) Process
> context switching from one UTM to another.

You were talking about C. I responded with more information about C.
In response, you talk about "the x86 language".

What exactly do you mean by "the x86 language"? Please don't assume
I'm ignorant (I'm not), merely that I don't know just what you mean
by the phrase.

>>>> I've already asked you these questions, and you ignored them.
>>>> I presume that it's important *to you* to communicate something
>>>> about what you're working on. It's less important to me. So I'm
>>>> not going to be as persistent about getting you to answer these
>>>> simple questions.
>>>
>>> I told you that I can't write the function because its operating
>>> system is not finished.
>>>
>>>>>> I'm just asking you to explain the quotation marks. If they don't
>>>>>> mean anything, that's fine.
>>
>> You claimed to have a C function. You don't. You acknowledge that
>> you haven't written it. No doubt you have some design or idea, or
>> perhaps something written down in some kind of pseudocode, and
>> we could discuss that if you like, but you don't have a C function.
>
> I have a c function that is fully executable except for those aspects
> that depends on operating system support.

In other words you don't have an executable C function.

Your goal is to solve the halting problem, right? *Almost* solving the
halting problem is easy (and uninteresting).

>> I *think* you've said or implied that this C function is the same
>> thing as the "fully encoded Turing Machine" you've been making
>> claims about (because C is Turing-complete, and you therefore think
>> you can call any chunk of C code a "fully encoded Turing machine").
>> Is that correct? So you never had your Turing machine either.
>
> All c code is Turing complete except for processes such as counting to
> infinity and storing the result. If a machine had x-bit relative
> addressing and no direct memory addressing then c could be easily
> mapped to an actual Turing machine.

I think you mean the C language, not "All c code".

This is C code:

int main(void) { }

As you know, it is not Turing complete. My point is that precision is
important, and if you write "All c code" when you really mean "The C
programming language", it's impossible to to know what else you've
written that means something else.

[olcott]

I have to break what I say down into simpler steps or you get confused.

>
>> >> It is the same c since the first ansi c. I began writing c back when
>>>> it was K&R c.
>>>
>>> Great, so did I. I'm not sure what you mean by "the same c".
>>> If you mean that this C function that you haven't written yet will
>>> be compatible with the first ANSI C standard and with all later
>>> standards, that's fine.
>>
>> I can't write the halt deciding aspects of the code until after I have
>> added heap allocation and process context switching support. Their
>> detailed design has been complete for many months. This has been very
>> significanlty augmented from the 2018_12_13 initial specification.
>>
>>> If you mean that the language itself hasn't
>>> changed, that's simply incorrect. I'll explain further if and only
>>> if you ask me to.
>>
>> It is and has been the x86 language for many months. When I finish
>> adding minimal operating system support it will be a UTM having the
>> x86 language as its Turing Machine Description language. with at least
>> two (build from scratch) operating system functions that can be
>> invoked from this language: (1) Allocation for the heap (2) Process
>> context switching from one UTM to another.
>
> You were talking about C. I responded with more information about C.
> In response, you talk about "the x86 language".
>
> What exactly do you mean by "the x86 language"? Please don't assume
> I'm ignorant (I'm not), merely that I don't know just what you mean
> by the phrase.

In this particular case I mean every single detail of the actual x86
language. The x86 language is the machine language of most desktop
computers. https://www.cs.virginia.edu/~evans/cs216/guides/x86.html
The x86 emulator fully implements that whole set.

>>>>> I've already asked you these questions, and you ignored them.
>>>>> I presume that it's important *to you* to communicate something
>>>>> about what you're working on. It's less important to me. So I'm
>>>>> not going to be as persistent about getting you to answer these
>>>>> simple questions.
>>>>
>>>> I told you that I can't write the function because its operating
>>>> system is not finished.
>>>>
>>>>>>> I'm just asking you to explain the quotation marks. If they don't
>>>>>>> mean anything, that's fine.
>>>
>>> You claimed to have a C function. You don't. You acknowledge that
>>> you haven't written it. No doubt you have some design or idea, or
>>> perhaps something written down in some kind of pseudocode, and
>>> we could discuss that if you like, but you don't have a C function.
>>
>> I have a c function that is fully executable except for those aspects
>> that depends on operating system support.
>
> In other words you don't have an executable C function.
>
> Your goal is to solve the halting problem, right? *Almost* solving the
> halting problem is easy (and uninteresting).

I refuted all of the conventional halting problem counter-examples ever
since 2018-12-13. In previous years I called this goal solving the
halting problem. It is not. Solving the halting problem would require
having a halt decider for every program of the set of all programs.

>>> I *think* you've said or implied that this C function is the same
>>> thing as the "fully encoded Turing Machine" you've been making
>>> claims about (because C is Turing-complete, and you therefore think
>>> you can call any chunk of C code a "fully encoded Turing machine").
>>> Is that correct? So you never had your Turing machine either.
>>
>> All c code is Turing complete except for processes such as counting to
>> infinity and storing the result. If a machine had x-bit relative
>> addressing and no direct memory addressing then c could be easily
>> mapped to an actual Turing machine.
>
> I think you mean the C language, not "All c code".

Yes that way of saying it is more correct.

>
> This is C code:
>
> int main(void) { }
>
> As you know, it is not Turing complete. My point is that precision is
> important, and if you write "All c code" when you really mean "The C
> programming language", it's impossible to to know what else you've
> written that means something else.
>

Science has shown that analytical abilitlity and communication ability
are significantly mutually exclusive.

The creator of the Snobol programming language wrote a text book about
his language. Key elements of chapter one could not be understood until
after reading chapter three. The same gestalt "everything at once"
mindset that is great for designing programming languages is not very
good as exaplaining things as one logical step at a time.

[Ben Bacarisse]

Still not an answer. We all know why. You now know that you can't
still claims to have a pair of "actual Turing machines" but you have the
usual crank inability to admit that you were ever wrong. I won't press
the point. Your not answering speaks volumes.

>>>> 2. Recent posts have said that you really do claim to have a halting
>>>> decider. Have you extended your claim or was that a misunderstanding?

> I really do have the complete detailed design of a halting decider
> that would decide all of the conventional self-referential halting
> problem counter-examples. Since you have little coding experience you
> are unable to appreciate that sufficiently detailed pseudo-code fully
> encodes every detail of an algorithm.

I'd like to be generous here but you can't possibly think this is an
answer to the question. OK, so you won't say. Let's leave it at that.

>>> The most important aspect of my claim is that the program for a fully
>>> operational halt decider that decides the conventional
>>> self-referential halting problem counter-examples is almost fully
>>> encoded in x86 machine language. 95% of the work of encoding required
>>> building an x86 based UTM.
>>
>> Not an answer.
>>
>>>> 3. What was it you really had by Dec 15th 2018? The closest you've come
>>>> to saying is that it was something sufficiently like a TM for you to
>>>> think you could call it one without it being a lie.
>>>>
>>>> You have worked really hard to avoid being clear about point 3. You
>>>> have variously said you had "an actual Turing machine", "an algorithm",
>>>> "pseudo code", "a finite state machine" and more. And you've spoken of
>>>> C code and then said you have not yet written the C. The fact that it's
>>>> a simple question, unanswered for so long, suggests you either don't
>>>> know what you had or you don't dare say.
>>>
>>> On 2018-12-13 I was thinking that I would have to build a subset of a
>>> "C" compiler from scratch and a subset of a machine language from
>>> scratch, and a simple operating system from scratch. I spent three
>>> months working in building the "c" compiler.
>>
>> Nothing here answers the question. Your replies read more like a
>> cover-up rather than an explanation. What are you hiding?

And on the key point of what is was you really had way be in 2018 (now
that you know it's not what you said it was)... silence. I'm not sure
if you dare not say or if you can not say, but the effect is the same.

You purpose here is not to explain what you have (or had) but to cover
up the fact that you never had what you claimed. You don't want anyone
to know the truth.

>>>> Looking at the old discussion along wih the new posts it seems clear
>>>> that you are misusing the term UTM. I suggest you stop using that
>>>> acronym and use plain words instead until you understand exactly what a
>>>> UTM is.
>>>
>>> It is very nearly the closest possible thing to a UTM that can
>>> possibly exist when the UTM has the x86 language as its Turing machine
>>> description language.
>>
>> I hope you don't know what a UTM is. If you do, you have wasted your time.
>
> It is better than a mere UTM it is a UTM that executes a chain of
> other UTMs of arbitrary depth. The master UTM executes H_Hat that
> executes itself.

I think every sentence you have ever written that includes the letters
UTM shows that you don't know what a UTM is. I would have thought that
your desire to be honest (really?) would stop you using words
incorrectly, at least once it was pointed out. That you continue to
misuse the term suggest you are intend to be deliberately misleading.
That's more lying.

I think we should cut this sub-thread off. You don't want to (or can't)
say what you really had back then, I think you've posted enough evasive
non-answer to make you intent clear to anyone who might come across this
thread in the years to come.

--
Ben.

[olcott]

Yes I was very sloppy in my wording.

>
> This is C code:
>
> int main(void) { }
>
> As you know, it is not Turing complete. My point is that precision is
> important, and if you write "All c code" when you really mean "The C
> programming language", it's impossible to to know what else you've
> written that means something else.
>


--

Copyright 2020 Pete Olcott

[olcott]

On 8/10/2020 9:49 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

> You have annoying split the thread with your replies. Please don't do
> that. I've put them back together again.
>

It is more effective to address one point at a time.

>> On 8/10/2020 9:02 AM, Ben Bacarisse wrote:

> <cut>

>>> The original claim, from way back in 2018 was very precise (though you
>>> kept having trouble stating it). It was that you have a pair of TMs, P
>>> and P^, say, that are related by the ^ construction as in Linz. A pair
>>> with the property that P(<[P^], [P^]>) is "correct". You were at pains
>>> to point out that P is not a halt decider (in the general sense) but
>>> only that it is correct about this one case. Normally, a single-case of
>>> an undecidable problem is not interesting (because all finite sets are
>>> decidable) but this one case is special because of the relationship
>>> between the two TMs.
>>>
>>> Since then, you have done your best to avoid being clear about any of
>>> this. I would appreciate bullshit free answers to some questions:
>>>
>>> 1. Is this still your claim, given that you now know that a TM is a
>>> specific mathematical object and not some code written in a more-or-less
>>> Turing complete language?
>

>> I think of Turing machines as a model of actual computation. Most
>> people from a computer science background would seem to think of them
>> this way.
>
> Of course I (and other computer scientists) do. That's exactly what they
> are.
>

Good. Then there are all the different ways that the term: "model" can
be used.
https://en.wikipedia.org/wiki/Conceptual_model_(computer_science)

>> In other words they are not hypothetical abstractions that
>> cannot possibly exist.
>
> There is nothing hypothetical about them and the certainly exist. They
> exist in the same way that the prime numbers exist.

Cannot possibly physically exist.

>> If you insist on thinking of them as hypothetical abstractions that
>> cannot possibly physically exist [...]
>
> Of course they can't physically exist in any literal sense, but they can
> be physically realised or simulated.

Yes. Simulated to varying degrees. A perfect simulation is called Turing
complete.

>
>> [...] then it is no wonder that you thought my claim to have one of
>> these was false.
>
> I know your claim to be false because you changed it as soon as you
> realised what you'd said (certainly by January 2019).

I clarified the degrees of subjective leeway in the interpretations that
could be made. I had the Peter Linz H_Hat fully encoded such that anyone
of ordinary skill in the art of "C" programming could create a fully
operational H_Hat that correctly decides halting on itself.

Whether or not this would be a Turing Machine or not is the only issue.

>>> 2. Recent posts have said that you really do claim to have a halting
>>> decider. Have you extended your claim or was that a misunderstanding?
>>

>> I really do have a halting decider.
>
> Yes, I thought you had extended your claim but since you misuse the term
> "decider" a lot, no one knows what the extended claim might be. There's
> some vague waffle about it in your reply to the third question.

Intuitively, a decider should be a Turing machine that given an input,
halts and either accepts or rejects...
https://cs.stackexchange.com/questions/84433/what-is-decider

> Unfortunately you appear not to be talking about deciding the abstract
> mathematical notion of computation (as modelled by the lambda calculus
> and other abstractions) but about something that might (at least in
> principle) "physically exist" (scare quotes because I don't know what
> you mean by that). Since you are not talking about the TMs computer
> scientists talk about, it's hard to know what you are really saying. In
> effect you are claiming to have a PO-decider for PO-machine computations
> of some unspecified sort. <shurg>

>>> 3. What was it you really had by Dec 15th 2018? The closest you've come
>>> to saying is that it was something sufficiently like a TM for you to
>>> think you could call it one without it being a lie.
>>

>> I really had a halt decider that correctly decided halting for exactly
>> one instance of the conventional self-referential halting problem
>> counter-examples.
>
> I am sure you think you did have such a thing. That you were really
> thought you did was never in question. The question was not the claimed
> functionality of whatever you had, the question was what kind of
> computation/machine/model it was. We know it was not a Turing machine,
> but that's about all we know.
>

Every language that is Turing complete can be thought of as defining a
Turing machine because any lanaguage that is Turing complete precisely
maps to thus totally specifies a Turing Machine.

A "C" program is a fully encoded Turing machine because it can be
directly translated into a Turing machine by an automated process.

>> Since then I have augmented this so that it correctly decides halting
>> two classes of different kinds of instances.
>
> Still no idea of what the "it" is. Not a Turing machine, that's for
> sure. And I no longer know if "it" is even interesting. Your original
> lie was arresting interesting because it claimed something impossible.
>
> And "correctly decides halting two classes of different kinds of
> instances" is so fantastically vague it could mean almost anything.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:

<cut>

>> I know your claim to be false because you changed it as soon as you
>> realised what you'd said (certainly by January 2019).
>
> I clarified the degrees of subjective leeway in the interpretations
> that could be made.

You changed your claim when you realised you did not have an actual
Turing machine. You've changed it many times since. No one knows what
you are now prepared to claim to have or have had, but I for one, don't
care anymore. But if you repeat the lie -- now that you know what a
Turing machine is -- I'll call you out on it. If you ever want to say
what you really did have in Dec 2018 -- plainly stated without all this
equivocation -- I will welcome that turn of honesty.

But I can't care about all the guff you appear to need in order to delay
actually showing anyone anything. As soon as you want to know what
you've got wrong, just post some code.

--
Ben.

[olcott]

On 8/11/2020 4:53 PM, Keith Thompson wrote:
> olcott <No...@NoWhere.com> writes:

>> On 8/11/2020 4:16 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:
>>> <cut>
>>>>> I know your claim to be false because you changed it as soon as you
>>>>> realised what you'd said (certainly by January 2019).
>>>>
>>>> I clarified the degrees of subjective leeway in the interpretations
>>>> that could be made.
>>>
>>> You changed your claim when you realised you did not have an actual
>>> Turing machine.
>>

>> When we understand that a program written in "C" directly maps to a
>> corresponding Turing Machine then we understand that this program
>> written in "C" fully encodes the corresponding Turing machine.
>>
>> Apparently you are unable to understand this.
>
> You don't have this program written in C. You talked about a
> function rather than a program, but you've made it clear that you
> don't even have that.
>

I had the halt deciding aspect of this written 2018-12-13.

> (I'd appreciate it if you'd drop the quotation marks from "C"
> since you've acknowledged that they don't mean anything.)

I like those quotation marks.

> An actual C program that, when executed, demonstrates your claim
> would be potentially impressive. (Verifying that it does so would
> require additional work that I'm probably not qualified to do.)
> Long-running claims that you *almost* have such a program are
> worth nothing.

I have had one instance of the halt deciding code since 2018-12-13.
The greatly enhanced halt deciding code has had its detailed design
completed for many months and is waiting for the HeapSpace allocator to
be coded before it can be implemented.

Between 90 to 95% of my time is converting a superbly excellent x86
emulator into a master UTM. That work is almost complete. Quite a few
weeks of that time was getting its "C" code to run on Windows as a C++
based DLL. It also runs only Linux as a shared library. The emulator is
fully 32-bit thus the emulated code can have up to 4GB of total memory.

The trickiest part of this whole UTM system is providing a way for the
master UTM to execute another UTM that in turn executes another UTM to
an arbitrary depth of UTMs. This is needed so that H_Hat can execute
itself with itself as input.

> I have a C program that performs FizzBuzz. I could send you the
> source code, and you could compile it on your system and verify
> the output.
>
> You could not do the same with your alleged C program.
>
> Let us know when you can.

I will probably publish the UTM code in a code repository.
I would ultimately like to have this code run on a webserver.

Web servers with dedicated processor cores and 512MB to 1GB of dedicated
RAM cost $5 per month. I have two of them, one of each.

[olcott]

On 8/11/2020 6:53 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/11/2020 4:16 PM, Ben Bacarisse wrote:

>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:
>>> <cut>
>>>>> I know your claim to be false because you changed it as soon as you
>>>>> realised what you'd said (certainly by January 2019).
>>>>
>>>> I clarified the degrees of subjective leeway in the interpretations
>>>> that could be made.
>>>
>>> You changed your claim when you realised you did not have an actual
>>> Turing machine.
>>

>> When we understand that a program written in "C" directly maps to a
>> corresponding Turing Machine then we understand that this program
>> written in "C" fully encodes the corresponding Turing machine.
>

> You did not have a C program when you claimed to have a Turing machine,
> did you? No, you didn't, so this does not excuse your lying.
>

I never lie because I am convinced that this is the path to eternal
damnation.

> I wonder what the most charitable explanation for you refusal to say
> what you had back then is.

That is certainly an inaccurate thing for you to say within the context
of our prior dialogue. I don't anticipate that I will ever accuse you of
lying ever again because you have consistently proven to not be a liar.
Every single time that I accused you of lying I was proved wrong.

> Maybe just that didn't know what to call it?
> Anyway, for some reason or other you determined not to say.
>

What I will soon have is an x86 encoding of the Linz H_hat executed with
itself as input correctly deciding halting on itself.

By the Church-Turing thesis the x86 code is computable by a Turing
Machine thus the x86 halt decider also applies to Turing Machines.

[André G. Isaak]

On 2020-08-11 14:31, olcott wrote:
> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:

<snip>

>> Of course they can't physically exist in any literal sense, but they can
>> be physically realised or simulated.
>
> Yes. Simulated to varying degrees. A perfect simulation is called Turing
> complete.

That's not what 'Turing Complete' means.

<cnip>

>
> Every language that is Turing complete can be thought of as defining a
> Turing machine because any lanaguage that is Turing complete precisely
> maps to thus totally specifies a Turing Machine.
>
> A "C" program is a fully encoded Turing machine because it can be
> directly translated into a Turing machine by an automated process.

Do you actually have evidence supporting the claim that there exists
some fully automated process for translating an arbitrary C program into
a Turing Machine?

Even if such a process did exist, calling a C program a 'Turing Machine'
makes no more sense than calling a Pascal program a C program on the
grounds that it could have been programmed in C, or calling a PDP-11
executable an x86 executable on the grounds that the source code could
presumably have been compiled for x86.

André

<snip>

[Jeff Barnett]

On 8/11/2020 7:04 PM, olcott wrote:
> I never lie because I am convinced that this is the path to eternal
> damnation.

To be charitable, if I were you, I'd pay some poor people to pray for my
soul. Your undeserved arrogance leads to constant lying: Step 1 - total
lack of knowledge leads to stupid claims; Step 2 - your idiocies are
brought to your attention by the people you were trying to impress; 3)
your arrogance keeps you from admitting your error or learning better so
you lie your ass of to an amused crowd. I guess it's the only attention
you get. But oh you do lie your ass off over and over and over again.
--
Jeff Barnett

[olcott]

On 8/11/2020 9:48 PM, André G. Isaak wrote:
> On 2020-08-11 14:31, olcott wrote:
>> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:
>
> <snip>
>
>>> Of course they can't physically exist in any literal sense, but they can
>>> be physically realised or simulated.
>>
>> Yes. Simulated to varying degrees. A perfect simulation is called
>> Turing complete.
>
> That's not what 'Turing Complete' means.
>

Turing reduction.
In computability theory, a system of data-manipulation rules (such as a
computer's instruction set, a programming language, or a cellular
automaton) is said to be Turing-complete or computationally universal if
it can be used to simulate any Turing machine. This means that this
system is able to recognize or decide other data-manipulation rule sets.
Turing completeness is used as a way to express the power of such a
data-manipulation rule set. Virtually all programming languages today
are Turing-complete. https://en.wikipedia.org/wiki/Turing_completeness

So if we take this literally then the "C" language implemented on a 64K
machine would be Turing Complete. Since this cannot possibly be correct
I adapted the definition to correct it.

I couldn't find any other more credible sources. The three theory of
computation texts: {Linz, Sipser and Kozen} that I have don't seem to
cover it.

> <cnip>
>
>>
>> Every language that is Turing complete can be thought of as defining a
>> Turing machine because any lanaguage that is Turing complete precisely
>> maps to thus totally specifies a Turing Machine.
>>
>> A "C" program is a fully encoded Turing machine because it can be
>> directly translated into a Turing machine by an automated process.
>
> Do you actually have evidence supporting the claim that there exists
> some fully automated process for translating an arbitrary C program into
> a Turing Machine?
>

It doesn't really matter taking the Church-Turing thesis as a premise we
can conclude that any "c" program specifies a Turing machine.

> Even if such a process did exist, calling a C program a 'Turing Machine'
> makes no more sense than calling a Pascal program a C program on the
> grounds that it could have been programmed in C, or calling a PDP-11
> executable an x86 executable on the grounds that the source code could
> presumably have been compiled for x86.
>
> André
>
> <snip>
>
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

On 2020-08-11 21:37, olcott wrote:
> On 8/11/2020 9:48 PM, André G. Isaak wrote:
>> On 2020-08-11 14:31, olcott wrote:
>>> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:
>>
>> <snip>
>>
>>>> Of course they can't physically exist in any literal sense, but they
>>>> can
>>>> be physically realised or simulated.
>>>
>>> Yes. Simulated to varying degrees. A perfect simulation is called
>>> Turing complete.
>>
>> That's not what 'Turing Complete' means.
>>
>
> Turing reduction.
> In computability theory, a system of data-manipulation rules (such as a
> computer's instruction set, a programming language, or a cellular
> automaton) is said to be Turing-complete or computationally universal if
> it can be used to simulate any Turing machine. This means that this
> system is able to recognize or decide other data-manipulation rule sets.
> Turing completeness is used as a way to express the power of such a
> data-manipulation rule set. Virtually all programming languages today
> are Turing-complete. https://en.wikipedia.org/wiki/Turing_completeness
>
> So if we take this literally then the "C" language implemented on a 64K
> machine would be Turing Complete. Since this cannot possibly be correct
> I adapted the definition to correct it.

Why can this not possibly be correct?

A language is Turing Complete if it can compute the same class of
problems that a Turing Machine can compute.

That has nothing to do with being a 'perfect simulation'. A simulation
of a Turing Machine is a program which implements the Turing Machine's
tape as a data structure, records the state of the Turing Machine, and
manipulates the tape according to the state-transition rules which
define that Turing Machine and which continues until the machine reaches
a final state.

From your description, your program doesn't do this at all. If it did,
you'd be able to identify the number of states which the machine has.

> I couldn't find any other more credible sources. The three theory of
> computation texts: {Linz, Sipser and Kozen} that I have don't seem to
> cover it.
>
>> <cnip>
>>
>>>
>>> Every language that is Turing complete can be thought of as defining
>>> a Turing machine because any lanaguage that is Turing complete
>>> precisely maps to thus totally specifies a Turing Machine.
>>>
>>> A "C" program is a fully encoded Turing machine because it can be
>>> directly translated into a Turing machine by an automated process.
>>
>> Do you actually have evidence supporting the claim that there exists
>> some fully automated process for translating an arbitrary C program
>> into a Turing Machine?
>>
>
> It doesn't really matter taking the Church-Turing thesis as a premise we
> can conclude that any "c" program specifies a Turing machine.

The Church-Turing thesis is not something that has been proven. It is a
hypothesis. It certainly makes no claims about there being a automated
process for translating arbitrary C programs into Turing Machines.

>> Even if such a process did exist, calling a C program a 'Turing
>> Machine' makes no more sense than calling a Pascal program a C program
>> on the grounds that it could have been programmed in C, or calling a
>> PDP-11 executable an x86 executable on the grounds that the source
>> code could presumably have been compiled for x86.

You don't address the above. Do you think a Pascal program can
legitimately called a C program? Or that a PDP-11 executable can
legitimately be called an x86 executable? If not, then why should an
arbitrary C program legitimately be called a Turing Machine if it isn't
something that actually emulates a TM as described above?

André

[olcott]

Yes that seems to be the best defitinion.

> That has nothing to do with being a 'perfect simulation'. A simulation

That is what I mean by perfect simulation.

> of a Turing Machine is a program which implements the Turing Machine's
> tape as a data structure, records the state of the Turing Machine, and
> manipulates the tape according to the state-transition rules which
> define that Turing Machine and which continues until the machine reaches
> a final state.
>
> From your description, your program doesn't do this at all. If it did,
> you'd be able to identify the number of states which the machine has.

Apparently the only reason that the x86 language (and every other
physically existing computer) is not Turing complete is the lack of
unlimited memory. On this basis we can augment the definition of Turing
complete so that partial Turing completeness can be defined.

Or we can start from the other end and say on the basis of the
assumption of the Church-Turing thesis any computation that can be
performed by the RASP architecture of the x86 language can be performed
by a Turing machine.

My whole point with all of this is to firmly establish the theoretical
foundation that an instance of the Linz H_Hat encoded in the x86
language can be contrued as applying to Turing machines as long as this
computation can be performed in limited memory and this memory
limitation has no impact what-so-ever on computability.

>> I couldn't find any other more credible sources. The three theory of
>> computation texts: {Linz, Sipser and Kozen} that I have don't seem to
>> cover it.
>>
>>> <cnip>
>>>
>>>>
>>>> Every language that is Turing complete can be thought of as defining
>>>> a Turing machine because any lanaguage that is Turing complete
>>>> precisely maps to thus totally specifies a Turing Machine.
>>>>
>>>> A "C" program is a fully encoded Turing machine because it can be
>>>> directly translated into a Turing machine by an automated process.
>>>
>>> Do you actually have evidence supporting the claim that there exists
>>> some fully automated process for translating an arbitrary C program
>>> into a Turing Machine?
>>>
>>
>> It doesn't really matter taking the Church-Turing thesis as a premise
>> we can conclude that any "c" program specifies a Turing machine.
>
> The Church-Turing thesis is not something that has been proven. It is a
> hypothesis. It certainly makes no claims about there being a automated
> process for translating arbitrary C programs into Turing Machines.

Right and that detail is moot.

>>> Even if such a process did exist, calling a C program a 'Turing
>>> Machine' makes no more sense than calling a Pascal program a C
>>> program on the grounds that it could have been programmed in C, or
>>> calling a PDP-11 executable an x86 executable on the grounds that the
>>> source code could presumably have been compiled for x86.
>
> You don't address the above. Do you think a Pascal program can
> legitimately called a C program? Or that a PDP-11 executable can
> legitimately be called an x86 executable? If not, then why should an
> arbitrary C program legitimately be called a Turing Machine if it isn't
> something that actually emulates a TM as described above?
>
> André

I would say that was a very clever example of Strawman because none of
the languages that you specified are directly used as any measure of
theoretical limits of computation.

A "c" program precisely maps (byte for bytes) to a single x86 program
for a specific "c" compiler. If the Church-Turing hypothesis is correct
then there would exist at least one corresponding Turing Machine for
every x86 program. The original "c" program that precisely specifies its
corresponding x86 program for a specific compiler must have some
compiler that translates this x86 code into an equivalent Turing machine
description, otherwise Church-Turing is incorrect.

[Keith Thompson]

olcott <No...@NoWhere.com> writes:
> On 8/11/2020 6:53 PM, Ben Bacarisse wrote:

[...]

>> I wonder what the most charitable explanation for you refusal to say
>> what you had back then is.
>
> That is certainly an inaccurate thing for you to say within the
> context of our prior dialogue.

What, you think he doesn't wonder?

> I don't anticipate that I will ever
> accuse you of lying ever again because you have consistently proven to
> not be a liar. Every single time that I accused you of lying I was
> proved wrong.

Just an observation: Unless I missed something, you never actually
apologized. (Ben didn't ask you to. In his place, I would have.)

[Keith Thompson]

That's not what "perfect simulation" means.

An abacus can compute a certain class of problems. I wouldn't call
something a perfect simulation of an abacus unless it simulated the
beads on wires that make up an abacus. An electro-mechanical calculator
can compute all the same things an abacus can, but not by simulating it.

> I would say that was a very clever example of Strawman because none of
> the languages that you specified are directly used as any measure of
> theoretical limits of computation.

You're using C for that purpose. Why would Pascal or PDP-11 machine
language not be equally valid?

Regardless of whether you think it's a strawman or not (I know, you like
the capital S for some reason), do you think a Pascal program can
legitimately be called a C program? Both languages are Turing-complete,
but they're different languages, and neither is a simulation of the
other.

You're calling something a Turing machine that isn't one.

> A "c" program precisely maps (byte for bytes) to a single x86 program
> for a specific "c" compiler.

No, it doesn't. The C standard (the document that defines what C is)
says nothing about x86 instructions. A particular compiler might map a
C program to an x86 program, but the language doesn't.

> If the Church-Turing hypothesis is
> correct then there would exist at least one corresponding Turing
> Machine for every x86 program. The original "c" program that precisely
> specifies its corresponding x86 program for a specific compiler must
> have some compiler that translates this x86 code into an equivalent
> Turing machine description, otherwise Church-Turing is incorrect.

But of course this C program doesn't actually exist, so there's no point
in discussing what it could be translated into. No, I don't care what
you *almost* have finished and won't show to anyone.

[André G. Isaak]

But that's not what anyone else means by 'perfect simulation'. Words
mean things. If you continuously use your own idiosyncratic definitions

you have no hope of being understood.

>> of a Turing Machine is a program which implements the Turing Machine's
>> tape as a data structure, records the state of the Turing Machine, and
>> manipulates the tape according to the state-transition rules which
>> define that Turing Machine and which continues until the machine
>> reaches a final state.
>>
>> From your description, your program doesn't do this at all. If it did,
>> you'd be able to identify the number of states which the machine has.
>
> Apparently the only reason that the x86 language (and every other
> physically existing computer) is not Turing complete is the lack of
> unlimited memory. On this basis we can augment the definition of Turing
> complete so that partial Turing completeness can be defined.
>
> Or we can start from the other end and say on the basis of the
> assumption of the Church-Turing thesis any computation that can be
> performed by the RASP architecture of the x86 language can be performed
> by a Turing machine.
>
> My whole point with all of this is to firmly establish the theoretical
> foundation that an instance of the Linz H_Hat encoded in the x86
> language can be contrued as applying to Turing machines as long as this
> computation can be performed in limited memory and this memory
> limitation has no impact what-so-ever on computability.

None of this has anything to do with the point you appear to be
responding to which was my explanation of what a 'simulation' is
normally taken to be.

Since Linz's H_Hat is a Turing Machine, you can't possibly be simulating
it unless your program accepts as its input a description of a Turing
Machine, that is a 7-tuple, and then manipulates some representation of
that TM. A C program which accepts another C program or an X86
executable as input doesn't do that.

>>> I couldn't find any other more credible sources. The three theory of
>>> computation texts: {Linz, Sipser and Kozen} that I have don't seem to
>>> cover it.
>>>
>>>> <cnip>
>>>>
>>>>>
>>>>> Every language that is Turing complete can be thought of as
>>>>> defining a Turing machine because any lanaguage that is Turing
>>>>> complete precisely maps to thus totally specifies a Turing Machine.
>>>>>
>>>>> A "C" program is a fully encoded Turing machine because it can be
>>>>> directly translated into a Turing machine by an automated process.
>>>>
>>>> Do you actually have evidence supporting the claim that there exists
>>>> some fully automated process for translating an arbitrary C program
>>>> into a Turing Machine?
>>>>
>>>
>>> It doesn't really matter taking the Church-Turing thesis as a premise
>>> we can conclude that any "c" program specifies a Turing machine.
>>
>> The Church-Turing thesis is not something that has been proven. It is
>> a hypothesis. It certainly makes no claims about there being a
>> automated process for translating arbitrary C programs into Turing
>> Machines.
>
> Right and that detail is moot.

Why is it moot?

>>>> Even if such a process did exist, calling a C program a 'Turing
>>>> Machine' makes no more sense than calling a Pascal program a C
>>>> program on the grounds that it could have been programmed in C, or
>>>> calling a PDP-11 executable an x86 executable on the grounds that
>>>> the source code could presumably have been compiled for x86.
>>
>> You don't address the above. Do you think a Pascal program can
>> legitimately called a C program? Or that a PDP-11 executable can
>> legitimately be called an x86 executable? If not, then why should an
>> arbitrary C program legitimately be called a Turing Machine if it
>> isn't something that actually emulates a TM as described above?
>>
>> André
>
> I would say that was a very clever example of Strawman because none of
> the languages that you specified are directly used as any measure of
> theoretical limits of computation.

And a C program which doesn't emulate a Turing Machine cannot be used to
discuss computation in terms of Turing Machines. People use Turing
Machines because they provide a precise way of discussing computation. C
doesn't provide this.

> A "c" program precisely maps (byte for bytes) to a single x86 program
> for a specific "c" compiler.  If the Church-Turing hypothesis is correct
> then there would exist at least one corresponding Turing Machine for
> every x86 program. The original "c" program that precisely specifies its
> corresponding x86 program for a specific compiler must have some
> compiler that translates this x86 code into an equivalent Turing machine
> description, otherwise Church-Turing is incorrect.

But unless you actually know what this hypothetical Turing Machine
actually is, you are not actually talking about Turing Machines. You are
talking about C programs, just as you can't talk about a Pascal program
as a C program.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 8/11/2020 6:53 PM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 8/11/2020 4:16 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 8/10/2020 9:49 PM, Ben Bacarisse wrote:
>>>> <cut>
>>>>>> I know your claim to be false because you changed it as soon as you
>>>>>> realised what you'd said (certainly by January 2019).
>>>>>
>>>>> I clarified the degrees of subjective leeway in the interpretations
>>>>> that could be made.
>>>>
>>>> You changed your claim when you realised you did not have an actual
>>>> Turing machine.
>>>
>>> When we understand that a program written in "C" directly maps to a
>>> corresponding Turing Machine then we understand that this program
>>> written in "C" fully encodes the corresponding Turing machine.
>>
>> You did not have a C program when you claimed to have a Turing machine,
>> did you? No, you didn't, so this does not excuse your lying.
>
> I never lie because I am convinced that this is the path to eternal
> damnation.

I don't believe you. I may find it easier to accept that you were just
mistaken if you said what you really had on Dec 13 2018. You now know
it was not a Turning machine, but you keep refusing to say what it
really was. That refusal, along with the fact you kept changing your
story whilst simultaneously trying to justify the original incorrect
description is very suspicious.

Anyway, you won't ever say you had a Turing machine ever again, will
you? You won't because you now know that /would/ be a lie because you
now know the words "Turing machine" don't just mean anything
computationally equivalent to a TM.

>> I wonder what the most charitable explanation for you refusal to say
>> what you had back then is.
>
> That is certainly an inaccurate thing for you to say within the
> context of our prior dialogue.

You won't say what you had. It's a simple as that. I think you won't
say because the truth will embarrass you, though it could be that you
don't know the right words. You said elsewhere you have it "written" so
just say how it was expressed. A thought written in English? 13 lines
of vague pseudo code? 96 pages of Snobol code? What? The only thing I
know for sure is that it was no an "actual Turning machine" because
you've explained that you have been misusing that term.

>> Maybe just that didn't know what to call it?
>> Anyway, for some reason or other you determined not to say.
>

> What I will soon have...

You see? I want to know what you had when you... inaccurately described
it as a Turing machine, not what you don't yet have. You keep not
saying. Suspicious.

--
Ben.

[olcott]

That is what I meant by perfect simulation. In this case Andre's words
were much better.

I am not using C for that purpose. I am measuring the computational
limits of C on the basis of Turing Machines. I am not measuring the
computational limits of Turing Machines on the basis of C.

> Regardless of whether you think it's a strawman or not (I know, you like
> the capital S for some reason), do you think a Pascal program can
> legitimately be called a C program? Both languages are Turing-complete,
> but they're different languages, and neither is a simulation of the
> other.
>
> You're calling something a Turing machine that isn't one.

I will soon have an x86 based UTM that implements the standard
self-referential halting problem counter-example in x86 code and

correctly decides halting on itself.

Because this code is functionally identical to a Turing Machine for this
computation and the Church-Turing thesis my code applies to the Turing
machine counter examples thus refuting them.

>> A "c" program precisely maps (byte for bytes) to a single x86 program
>> for a specific "c" compiler.
>
> No, it doesn't. The C standard (the document that defines what C is)
> says nothing about x86 instructions. A particular compiler might map a
> C program to an x86 program, but the language doesn't.

>> for a specific "c" compiler.
>> for a specific "c" compiler.
>> for a specific "c" compiler.
>> for a specific "c" compiler.
>> for a specific "c" compiler.

>
>> If the Church-Turing hypothesis is
>> correct then there would exist at least one corresponding Turing
>> Machine for every x86 program. The original "c" program that precisely
>> specifies its corresponding x86 program for a specific compiler must
>> have some compiler that translates this x86 code into an equivalent
>> Turing machine description, otherwise Church-Turing is incorrect.
>
> But of course this C program doesn't actually exist, so there's no point
> in discussing what it could be translated into. No, I don't care what
> you *almost* have finished and won't show to anyone.

It exists as some "c" / x86 code that is fully operational and the rest
of it exists as a complete detailed design that someone of ordinary
skill in the art of "c" programming and x86 programming would be able to
fully implement. The "c" code examines the x86 version of itself to
decide halting on itself.

To get to the point where the "C" code can be fully implemented only
requires ordinary skill in the art of operating system programming.

[olcott]

What I meant by perfect simulation is that any machine having less than
unlimited memory is not a perfect simulation.

I think that your definition is best yet I can not find any scholarly
support for it. I had one guy disagree with me about a definition like
yours.

Any x86 program that fully implements the standard self-referential
halting problem counter-example and correctly decides halting on itself
such that its lack of unlimited memory has no effect on this computation
specifies all of the details required for the standard self-referential
halting problem Turing machine counter-examples to correctly decide
halting on themselves.

The brand new concept of Turing Complete computations as opposed to and
contrast with Turing Complete language and Turing Complete machines
provides for this. I will anchor this new concept in conventional terms:
(a) Turing complete
(b) Computability
(c) Decider

Formal definitions
In computability theory, several closely related terms are used to
describe the computational power of a computational system (such as an
abstract machine or programming language):

Turing completeness
A computational system that can compute every Turing-computable function
is called Turing-complete
https://en.wikipedia.org/wiki/Turing_completeness
-----------------

Computability is the ability to solve a problem in an effective manner.

Problems
A central idea in computability is that of a (computational) problem,
which is a task whose computability can be explored.

A decision problem fixes a set S, which may be a set of strings, natural
numbers, or other objects taken from some larger set U. A particular
instance of the problem is to decide, given an element u of U, whether u
is in S. https://en.wikipedia.org/wiki/Computability
--------------------

The term decider doesn't really have a standard meaning. In fact, it is
lamentable that Sipser chose the terms decider and recognizer, since
they seem to confuse students.

Intuitively, a decider should be a Turing machine that given an input,

halts and either accepts or rejects,
https://cs.stackexchange.com/questions/84433/what-is-decider
-----------------

A computation system (such as a language or an abstract machine) can be
understood to be Turing Complete for a subset of the class of problems

that a Turing Machine can compute.

The class of RASP machines is Turing complete for the set of problems
that are computable by a RASP machine.

Now we must move away from the theoretical and delve into the concrete:
A specific instance of a RASP machine (with for example 4GB RAM) defined
by the x86 language is Turing complete for the class of problems that
are decidable within its 4GB RAM and the lack of unlimited memory has no
effect on the computability of this problem.

>> A "c" program precisely maps (byte for bytes) to a single x86 program
>> for a specific "c" compiler.  If the Church-Turing hypothesis is
>> correct then there would exist at least one corresponding Turing
>> Machine for every x86 program. The original "c" program that precisely
>> specifies its corresponding x86 program for a specific compiler must
>> have some compiler that translates this x86 code into an equivalent
>> Turing machine description, otherwise Church-Turing is incorrect.
>
> But unless you actually know what this hypothetical Turing Machine
> actually is, you are not actually talking about Turing Machines. You are
> talking about C programs, just as you can't talk about a Pascal program
> as a C program.
>
> André
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

<snip>

>
> Any x86 program that fully implements the standard self-referential
> halting problem counter-example and correctly decides halting on itself
> such that its lack of unlimited memory has no effect on this computation
> specifies all of the details required for the standard self-referential
> halting problem Turing machine counter-examples to correctly decide
> halting on themselves.

Above you claimed to agree with my definition of a simulation, yet you
are still insisting that your C program still constitutes a TM. So what
definition were you agreeing with?

<snip>

> The brand new concept of Turing Complete computations as opposed to and
> contrast with Turing Complete language and Turing Complete machines
> provides for this. I will anchor this new concept in conventional terms:

What brand new concept of 'Turing Complete'? Turing Complete is already
defined.

André

[olcott]

I explain exactly what [Turing complete computations] are in great depth

in the part that you ignored.

Copyright 2020 Pete Olcott

[André G. Isaak]

On 2020-08-12 08:55, olcott wrote:
> On 8/12/2020 9:40 AM, André G. Isaak wrote:

>> What brand new concept of 'Turing Complete'? Turing Complete is
>> already defined.
>>
>
> I explain exactly what [Turing complete computations] are in great depth
> in the part that you ignored.
>
> >> A computation system (such as a language or an abstract machine) can
> >> be understood to be Turing Complete for a subset of the class of
> >> problems that a Turing Machine can compute.

That isn't a definition. I have no idea what it is supposed to mean.
What subset are you talking about?

More importantly, what is wrong with the standard definition definition
of Turing Complete which makes no reference to some undefined subset?

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:
<cut>

> The brand new concept of Turing Complete computations as opposed to
> and contrast with Turing Complete language and Turing Complete
> machines provides for this.

What are you babbling about? What new concept? Do you mean you've just
heard about it? This is a settled topic. The details need more care
than you are willing to take, but the equivalence of various notions of
"effective procedure" is not in question here.

--
Ben.

[olcott]

On 8/12/2020 10:00 AM, André G. Isaak wrote:
> On 2020-08-12 08:55, olcott wrote:
>> On 8/12/2020 9:40 AM, André G. Isaak wrote:
>
>>> What brand new concept of 'Turing Complete'? Turing Complete is
>>> already defined.
>>>
>>
>> I explain exactly what [Turing complete computations] are in great
>> depth in the part that you ignored.
>>
>>  >> A computation system (such as a language or an abstract machine) can
>>  >> be understood to be Turing Complete for a subset of the class of
>>  >> problems that a Turing Machine can compute.
>
> That isn't a definition. I have no idea what it is supposed to mean.
> What subset are you talking about?

You have to actually read the rest of I said

[André G. Isaak]

I did read the rest of what you said. Nowhere in there was anything
which clarified what you mean above.

Turing Complete is well-defined. It doesn't need a new definition.

[olcott]

If you paid attention you would realize that I was not defining Turing
complete. You really cannot understand what I am saying when you only
glance at a few words before forming your rebuttal.

[olcott]

On 8/12/2020 1:25 PM, Kaz Kylheku wrote:
> On 2020-08-12, olcott <No...@NoWhere.com> wrote:
>> On 8/12/2020 11:47 AM, Kaz Kylheku wrote:
>>> On 2020-08-12, olcott <No...@NoWhere.com> wrote:
>>>> I have most of the coding and nearly all of the detailed design
>>>
>>> Can you provide a 100 line sample?
>>
>> It is best not to release any of this code until it is in its final
>> form.
>
> You can't provide a 100 line lsnapshot of a much larger
> work-in-progress? That's amazing.
>
> It's just a swipe with the mouse, then copy and paste.
>
> Pretty much any developer out there can show a work-in-progress to the
> people to whom he or she claims to be making progress.
>

Almost all of my current coding is mundane ordinary programming of
adapting an x86 emulator written in "C" under Linux to become an
emulator written in C++ as a Windows DLL.

The only key aspect of the conversion of this x86 emulator into a UTM
that can execute a chain of UTM's is its "C" level interface to three
operating system functions:

void AllocateHeapSpace(uint32_t* Space);
void SaveProcessState(uint32_t* p);
void LoadProcessState(uint32_t* p);
I just finished this interface a few minutes ago.

The prior version was an embedded assembly language interface.
I am still not sure which one that I am going with.

The "C" level interface is easier to understand at the "C" level.
The embedded assembly language interface is much easier to understand in
the x86 execution trace because the "C" compiler generates more
complicated code than necessary.

uint32_t* memory_block;
memory_block = (uint32_t*) 0xffff;
AllocateHeapSpace(memory_block);
Allocate a 64K block of memory from the heap and assign this to
memory_block or assign zero to memory_block indicating that the
allocation failed.

uint32_t* p;
SaveProcessState(p);
Saves the machine registers to an allocated memory block. Then saves
this address to p or assigns zero to p on failure.

LoadProcessState(p);
Loads the machine registers from the memory pointed to by p.

[olcott]

On 8/12/2020 1:25 PM, Kaz Kylheku wrote:
> On 2020-08-12, olcott <No...@NoWhere.com> wrote:
>> On 8/12/2020 11:47 AM, Kaz Kylheku wrote:
>>> On 2020-08-12, olcott <No...@NoWhere.com> wrote:
>>>> I have most of the coding and nearly all of the detailed design
>>>
>>> Can you provide a 100 line sample?
>>
>> It is best not to release any of this code until it is in its final
>> form.
>
> You can't provide a 100 line lsnapshot of a much larger
> work-in-progress? That's amazing.
>
> It's just a swipe with the mouse, then copy and paste.
>
> Pretty much any developer out there can show a work-in-progress to the
> people to whom he or she claims to be making progress.

This is as much as I have coded of the interesting part of the UTM.
I also know exactly how to code the function bodies.

I redesigned the interface between the master UTM and its slave UTMs
more than a dozen times. This will probably be the final interface for
these operating system interface functions.

int main()
{
uint32_t* S1;
S1 = (uint32_t*) 16;
AllocateHeap(S1); // Allocates 16 uint32_t
SaveState(S1); // Saves 16 registers to S1
RestoreState(S1); // Restores 16 registers from S1
__asm hlt // x86 has an actual Halt State
}

b4: 55 push ebp
b5: 8BEC mov ebp, esp
b7: 51 push ecx
b8: C745FC10000000 mov dword ptr [ebp-0x4], 0x10
bf: 8B45FC mov eax, dword ptr [ebp-0x4]
c2: 50 push eax
c3: E852000000 call 0x11a
c8: 83C404 add esp, 0x4
cb: 8B4DFC mov ecx, dword ptr [ebp-0x4]
ce: 51 push ecx
cf: E850000000 call 0x124
d4: 83C404 add esp, 0x4
d7: 8B55FC mov edx, dword ptr [ebp-0x4]
da: 52 push edx
db: E83F000000 call 0x11f
e0: 83C404 add esp, 0x4
e3: F4 hlt
e4: 8BE5 mov esp, ebp
e6: 5D pop ebp
e7: C3 ret

[olcott]

On 8/12/2020 1:25 PM, Kaz Kylheku wrote:
> On 2020-08-12, olcott <No...@NoWhere.com> wrote:
>> On 8/12/2020 11:47 AM, Kaz Kylheku wrote:
>>> On 2020-08-12, olcott <No...@NoWhere.com> wrote:
>>>> I have most of the coding and nearly all of the detailed design
>>>
>>> Can you provide a 100 line sample?
>>
>> It is best not to release any of this code until it is in its final
>> form.
>
> You can't provide a 100 line lsnapshot of a much larger
> work-in-progress? That's amazing.
>
> It's just a swipe with the mouse, then copy and paste.
>
> Pretty much any developer out there can show a work-in-progress to the
> people to whom he or she claims to be making progress.
>

The last one was incorrect. This is the actual (final?)
interface to the master UTM operating system functions.

int main()
{
uint32_t* S1;
S1 = (uint32_t*) 16;

AllocateHeap(&S1); // Allocates 16 uint32_t
SaveState(&S1); // Saves 16 32-bit registers
RestoreState(&S1); // Process context switch
__asm hlt

}

b4: 55 push ebp
b5: 8BEC mov ebp, esp
b7: 51 push ecx
b8: C745FC10000000 mov dword ptr [ebp-0x4], 0x10

bf: 8D45FC lea eax, ptr [ebp-0x4]

c2: 50 push eax
c3: E852000000 call 0x11a
c8: 83C404 add esp, 0x4

cb: 8D4DFC lea ecx, ptr [ebp-0x4]

ce: 51 push ecx
cf: E850000000 call 0x124
d4: 83C404 add esp, 0x4

d7: 8D55FC lea edx, ptr [ebp-0x4]

da: 52 push edx
db: E83F000000 call 0x11f
e0: 83C404 add esp, 0x4
e3: F4 hlt
e4: 8BE5 mov esp, ebp
e6: 5D pop ebp
e7: C3 ret

[olcott]

On 8/12/2020 6:39 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/12/2020 4:51 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>

>>>> So it is commonly understood that a language or abstract machine can
>>>> be considered Turing complete for a subset of problems?
>>>
>>> Can compute a subset of problems, yes. There's no need to add another
>>> misuse of the technical phrase "Turing complete". Misusing the term
>>> does not create a "brand new concept", it just incorrectly describes a
>>> conventional one.
>>>
>>> I really can't stress enough the value that education can have in cases
>>> like this. There are many books out there that might enable you to know
>>> what others already know.
>>
>> I want to establish the theoretical foundation that an x86 based
>> refutation of the convetional halting problem counter-examples would
>> immediately and directy apply to Turing Machines.
>
> I can't think of a better way to be sure no one takes you seriously.
> Since (details aside) all programming notations are just as good for
> this purpose,

OK great then everyone simply assumes Church-Turing.

One thing that other mere programming notations are not good for is
providing an actual execution trace. "C" is too high of a level to
directly see each individual state transition (changes to the
instruction pointer). Also "C" does not have each one of its lines of
code tied together into a directed graph of memory addresses. I need
this to analyze control flow to decide halting.

This is the interprocess communication protocol that I have established
for a slave UTM to request three different kinds of operating system
functions. The code for these three functions is fully designed. I only
need to code the "spawn process" code and then the master UTM will be
essentially complete.

int main()
{
uint32_t* S1;
S1 = (uint32_t*) 16; // size param passed to AllocateHeap

AllocateHeap(&S1); // Allocates 16 uint32_t
SaveState(&S1); // Saves 16 32-bit registers
RestoreState(&S1); // Process context switch
__asm hlt
}

b4: 55 push ebp
b5: 8BEC mov ebp, esp
b7: 51 push ecx
b8: C745FC10000000 mov dword ptr [ebp-0x4], 0x10
bf: 8D45FC lea eax, ptr [ebp-0x4]
c2: 50 push eax
c3: E852000000 call 0x11a
c8: 83C404 add esp, 0x4
cb: 8D4DFC lea ecx, ptr [ebp-0x4]
ce: 51 push ecx
cf: E850000000 call 0x124
d4: 83C404 add esp, 0x4
d7: 8D55FC lea edx, ptr [ebp-0x4]
da: 52 push edx
db: E83F000000 call 0x11f
e0: 83C404 add esp, 0x4
e3: F4 hlt
e4: 8BE5 mov esp, ebp
e6: 5D pop ebp
e7: C3 ret

[olcott]

On 8/12/2020 7:21 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 8/12/2020 5:00 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:

>>>> On 8/12/2020 3:36 PM, Ben Bacarisse wrote:
>>> <cut>

>>>>> You babbled. Throwing terms around that you don't understand is not a
>>>>> good look for anyone. That whole post was a dog's dinner.
>>>>
>>>> Let me break it down for you using more precise terms:
>>>
>>> No. I know what you are saying because it's not at all complex, unusual
>>> or new. Your response stems the same problem that leads you to think
>>> people are mad or lying or playing mind games. Sometimes people think
>>> you are babbling, not because they don't understand, but because you are
>>> tossing a word salad.
>>>
>>>> A precise degree of partial Turing completeness can be defined as:
>>>> The subset of Turing-computable functions that are computable on an
>>>> abstract machine or programming language.
>>>
>>> The second sentence is fine. It's standard fare in computability
>>> theory, though we go a bit further by not limiting ourselves to Turing
>>> computable functions.
>>>
>>> The babbling comes from using phrases like Turing completeness
>>> inappropriately. The latest, "partial Turing completeness", is of
>>> course an oxymoron. Were you aiming for some archaic rhetorical effect?

>>
>> I want to establish the theoretical foundation that an x86 based

>> refutation of the conventional halting problem counter-examples would
>> immediately and directly apply to Turing Machines.
>
> <screeching of brakes> Reality check: what does what you call "partial
> Turing completeness" have to do with your claim? Are you planning to
> demonstrate something about a computational model that can't compute all
> the functions a Turing machine can? Do you plan to extrapolate that up
> to Turing computability?
>

I want to explicitly account for the cases that may be computable in
finite memory that are not computable in unlimited memory. It was
proposed that such cases can possibly exist.

>> To do this it must be universally understood that the computability of
>> an x86 based machine is identical to the computability of a Turing
>> machine on a subset of functions.
>
> Two years ago, when you were still lying about having a Turing machine,
> people (certainly me but I think others too) counselled you to use
> anything but a Turing machine because, due to computational equivalence,
> there was no need for the mess that is an actual Turing machine.
>

Apparently some people believe that there is a difference between Turing
complete and Turing equivalent
https://scienceblogs.com/goodmath/2007/01/05/turing-equivalent-vs-turing-co

Maybe they are using some screwy term-of-the art such as calling a
machine that does nothing besides immediately halt a "Decider".

> But you, being you, have managed to pick the worst possible alternative.
> I an not sure that this is an accident. A pile of x86 is a great place
> to hide.

Not in this case. I did it this way to make my solution as easy as
possible to fully understand. I could have buried it in a few billion
Turing Machine interpreter instructions where simply accessing the
memory location @ 0xffff takes 65,0000 steps.

>> Someone on another forum proposed that halting is alway decidable on a
>> machine with finite memory because it eventually runs out of
>> combinations to test.
>
> That is true. And memory is always finite. But even that does not
> matter as halting is not about actual hardware. All actual programs on
> actual hardware eventually stop, so the answer is trivial.
>
> But high-level programming languages have a meaning that is not
> connected to hardware. A program in, for example, Haskell or Common
> Lisp is a well-defined computation, independent of any hardware
> constraints. These notations are therefore ideal for expressing what
> would be unbelievably complicated as an actual Turing machine.
>
> x86 code is a hopeless choice for a number of reasons. Perhaps the most
> significant being that it is defined to be finite. x86 plus some
> abstract OS might just about pass muster, but what a mess when you could
> express your error so much more clearly in a high-level language.

It boils down to this: If Turing, Gödel and Tarski are correct then
truth itself is fundamentally broken. Since truth itself cannot possibly
be broken human understanding of the nature of truth is necessarily
incorrect.

Since provability is an aspect of satisfiability true and provable
cannot possibly diverge.

[Keith Thompson]

olcott <No...@NoWhere.com> writes:
[...]

> It boils down to this: If Turing, Gödel and Tarski are correct then
> truth itself is fundamentally broken. Since truth itself cannot
> possibly be broken human understanding of the nature of truth is
> necessarily incorrect.
>
> Since provability is an aspect of satisfiability true and provable
> cannot possibly diverge.

According to some stories (I don't know whether this is 100%
accurate), the Pythagoreans were horrified to discover that the
length of the diagonal of a square cannot be expressed as the ratio
of two integers. In modern terms, sqrt(2) is irrational. This fact
attacked their concept of mathematical reality. They might have
said that truth itself is fundamentally broken.

But there was a rigorous proof of this disturbing fact, and they
could not refute it. (Supposedly one person was murdered for
divulging it.)

They were deeply offended by the irrationality of sqrt(2).
(Note that "irrational" here merely means that it's not a ratio,
not that it's in any way insane.) And today mathmaticians simply
accept that not all numbers are rational.

https://en.wikipedia.org/wiki/Square_root_of_2#History

The idea that there are statements that are true within a system
but cannot be proven (or disproven) within that system is perhaps
equally disturbing. But again, there is a rigorous proof,
and mathematicians have no choice but to accept it. Gödel was
right, and the world has not collapsed. Mathematical truth is not
controlled by our prejudices.

You might as well dedicate your life to proving that sqrt(2) is
rational.

[olcott]

It is simply impossible because satisfiability has provability as an
aspect of itself. It it like adding integers together without using any
numbers. Since integers <are> numbers this is impossble.

> equally disturbing. But again, there is a rigorous proof,
> and mathematicians have no choice but to accept it. Gödel was
> right, and the world has not collapsed. Mathematical truth is not
> controlled by our prejudices.
>
> You might as well dedicate your life to proving that sqrt(2) is
> rational.
>


--

Copyright 2020 Pete Olcott

[Ben Bacarisse]

No they don't. That was my (detail aside). There are notations known
to be weaker than TMs (but you won't know any). There are others that are
stringer (but you won't know any). And there are some not yet proved to
be equivalent (but you won't know any).

In other words, as far as you are concerned, all high-level programming
languages have been proven to be equivalent to TMs. Note proven.

> One thing that other mere programming notations are not good for is
> providing an actual execution trace.

Nonsense.

> int main()
> {
> uint32_t* S1;
> S1 = (uint32_t*) 16; // size param passed to AllocateHeap
> AllocateHeap(&S1); // Allocates 16 uint32_t
> SaveState(&S1); // Saves 16 32-bit registers
> RestoreState(&S1); // Process context switch
> __asm hlt
> }

Shocking. But then you are not a programmer are you?

--
Ben.

[Ben Bacarisse]

There are no such cases.

>>> To do this it must be universally understood that the computability of
>>> an x86 based machine is identical to the computability of a Turing
>>> machine on a subset of functions.
>>
>> Two years ago, when you were still lying about having a Turing machine,
>> people (certainly me but I think others too) counselled you to use
>> anything but a Turing machine because, due to computational equivalence,
>> there was no need for the mess that is an actual Turing machine.
>
> Apparently some people believe that there is a difference between
> Turing complete and Turing equivalent

Of course there is. Essentially it's the difference between X >= Y and
X = Y. But it does not matter for what you claim.

> https://scienceblogs.com/goodmath/2007/01/05/turing-equivalent-vs-turing-co

Not a good article in my opinion.

>> But you, being you, have managed to pick the worst possible alternative.
>> I an not sure that this is an accident. A pile of x86 is a great place
>> to hide.
>
> Not in this case. I did it this way to make my solution as easy as
> possible to fully understand. I could have buried it in a few billion
> Turing Machine interpreter instructions where simply accessing the
> memory location @ 0xffff takes 65,0000 steps.

I was suggesting a high-level language. Of course even there you could
bury your error, but it would be harder.

> It boils down to this: If Turing, Gödel and Tarski are correct then
> truth itself is fundamentally broken.

You mean mathematical truth is not what you always thought it was.

> Since truth itself cannot possibly be broken human understanding of
> the nature of truth is necessarily incorrect.

Mathematics does not bend to your pronouncements. Mathematical truth is
what it is, and your declaring it broken has no effect at all.

> Since provability is an aspect of satisfiability true and provable
> cannot possibly diverge.

PO-provability may be an aspect of PO-satisfiability and PO-truth and
PO-provable may not diverge, but the sentence as you wrote it (with
words you don't yet understand) is just wrong.

--
Ben.

[olcott]

If a proposition is true you must have some basis to know that it is
true besides a wild guess or a hunch. What-so-ever definitive basis that
you have to show that a proposition is definitely true is the proof of
this proposition. THERE IS NO WAY OUT OF THIS

[André G. Isaak]

On 2020-08-12 21:39, olcott wrote:

> If a proposition is true you must have some basis to know that it is
> true besides a wild guess or a hunch. What-so-ever definitive basis that
> you have to show that a proposition is definitely true is the proof of
> this proposition. THERE IS NO WAY OUT OF THIS

You are conflating truth with knowledge. They are not the same thing.
There are many propositions which must either be true or false but which
we don't know which. For example 'Tachyons exist.' is either true or it
is false since there are no things which both exist and do not exist.
But we do not know whether 'tachyons exist' is true.

[André G. Isaak]

On 2020-08-12 18:54, olcott wrote:

> It boils down to this: If Turing, Gödel and Tarski are correct then
> truth itself is fundamentally broken. Since truth itself cannot possibly
> be broken human understanding of the nature of truth is necessarily
> incorrect.

None of these people claim that truth is 'fundamentally broken'. They
simply point out the limitations of what certain types of systems are
able to achieve.

The fact that something has limitations doesn't mean it is fundamentally
broken. Your car, for example, cannot travel at 1000 mph. That's a
limitation. It doesn't mean your car is broken.

> Since provability is an aspect of satisfiability true and provable
> cannot possibly diverge.

Not according to standard definitions of those terms.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 8/12/2020 10:25 PM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:

<cut>

>>> It boils down to this: If Turing, Gödel and Tarski are correct then
>>> truth itself is fundamentally broken.
>>
>> You mean mathematical truth is not what you always thought it was.
>>
>>> Since truth itself cannot possibly be broken human understanding of
>>> the nature of truth is necessarily incorrect.
>>
>> Mathematics does not bend to your pronouncements. Mathematical truth is
>> what it is, and your declaring it broken has no effect at all.
>>
>>> Since provability is an aspect of satisfiability true and provable
>>> cannot possibly diverge.
>>
>> PO-provability may be an aspect of PO-satisfiability and PO-truth and
>> PO-provable may not diverge, but the sentence as you wrote it (with
>> words you don't yet understand) is just wrong.
>
> If a proposition is true you must have some basis to know that it is
> true besides a wild guess or a hunch.

Every arithmetical formula is either true or false. Not every
arithmetical formula is provable or refutable. Deal with it.

> What-so-ever definitive basis that you have to show that a proposition
> is definitely true is the proof of this proposition.

In a sound system, if you have a proof, the proposition is true. No one
doubts that. But in the absence of a proof every proposition P
corresponds to one as yet unknown truth: either P or ~P.

> THERE IS NO WAY OUT OF THIS

Yes there is: education. You don't have to keep use words you don't
understand.

--
Ben.

[olcott]

On 8/13/2020 2:45 AM, Kaz Kylheku wrote:
> On 2020-08-12, olcott <No...@NoWhere.com> wrote:

>> I want to establish the theoretical foundation that an x86 based

>> refutation of the convetional halting problem counter-examples would
>> immediately and directy apply to Turing Machines.
>

> Your idea for this is intellectually dishonest, invalid, and
> frankly, stupid.
>

This is statement presumptuous.

> The impossibility of determining halting for all machines is
> demonstrated by proofs involving a trick which breaks the halting
> detector by embedding it in a machine, which applies it to itself.
>

That is very well put. It is indeed a trick. A smart halt decider can
see through this trick using a key insight that no one ever noticed before.

> Your plan is, evidently, to make the halting detector unavailable to
> researchers (through trade secrets and denial of licensing) for
> that sort of embedding. Only running it a stand-alone black box will
> be permitted. Or perhaps even as a remote service over a network,
> with no access to the technology. That's likely why you're hinting at
> IPC mechanisms in your vague descriptions.

This statement is preposterous. I am merely refraining from releasing my
most significant results until the quality of these results is in their
best form. I will most likely release my results as an open source code
repository. My whole idea all along is to provide a complete execution
trace of every step of the halt deciding process.

I might also port my x86 based UTM to a webservice. My UTM directly
executes the COFF object files produced by the Microsoft Visual C++
compiler with some caveats. The Microsoft compiler generates code that
is much easier to understand than the gcc/g++ compiler code.

> But the halting theorem is an assertion about all machines. Machines
> that you disallow researchers to have still exist, mathematically.
>
> The following does not fly: "Halting is solved for the machines you're
> allowed to test with; believe me that it also works for the secret ones
> you're not allowed to test." That is not science; it is intellectual
> fraud.
>
> One small problem is also that you're not capable of developing a
> halting detector of such a pedigree that testers will actually *have* to
> resort to self-referential test casees to break it. It will either give
> the wrong answer or else itself fail to halt on all sorts of ordinary
> inputs that do not perpetrate any trickery.
>

I have decided to release the code repository of the x86 based UTM long
before I release my halting problem results because there is nothing
about the x86 based UTM that need be kept secret.The little bit of code
that I posted yesterday is all the code that is complete. I spend about
90% of my time on design 5% on coding and 5% on debugging. Back in the
bad old days it was 5% on design 15% on coding and 80% on debugging.

[olcott]

On 8/13/2020 5:50 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 8/12/2020 10:25 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
> <cut>
>>>> It boils down to this: If Turing, Gödel and Tarski are correct then
>>>> truth itself is fundamentally broken.
>>>
>>> You mean mathematical truth is not what you always thought it was.
>>>
>>>> Since truth itself cannot possibly be broken human understanding of
>>>> the nature of truth is necessarily incorrect.
>>>
>>> Mathematics does not bend to your pronouncements. Mathematical truth is
>>> what it is, and your declaring it broken has no effect at all.
>>>
>>>> Since provability is an aspect of satisfiability true and provable
>>>> cannot possibly diverge.
>>>
>>> PO-provability may be an aspect of PO-satisfiability and PO-truth and
>>> PO-provable may not diverge, but the sentence as you wrote it (with
>>> words you don't yet understand) is just wrong.
>>
>> If a proposition is true you must have some basis to know that it is
>> true besides a wild guess or a hunch.
>
> Every arithmetical formula is either true or false. Not every
> arithmetical formula is provable or refutable. Deal with it.

The only possible way to correctly conclude that a WFF is true or false
is some kind of proof. If anyone concludes that a WFF is true or false
without some kind of proof this is necessarily mere presumption.

>
>> What-so-ever definitive basis that you have to show that a proposition
>> is definitely true is the proof of this proposition.
>
> In a sound system, if you have a proof, the proposition is true. No one
> doubts that. But in the absence of a proof every proposition P
> corresponds to one as yet unknown truth: either P or ~P.
>

Sure that is correct, That that is not what is asserted by the Gödel
proof. The Gödel proof asserts that G is definitely true and definitely
unprovable. That is the same thing as calculating the sum of two
integers without using any numbers (integers are numbers).

>> THERE IS NO WAY OUT OF THIS
>
> Yes there is: education. You don't have to keep use words you don't
> understand.
>


--

Copyright 2020 Pete Olcott

[olcott]

On 8/13/2020 5:16 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> In other words you don't understand the code.
>
> Says the person who had to post a correction to their own code because
> they got the levels of pointer indirection wrong! As far as I know you
> /still/ haven't posted a correct declaration for AllocateHeap (not that
> anyone cares).
>

That preliminary code has bugs is why I refrain from posting preliminary
code. The trickiest code is SpawnProcess(). I think that I have that
totally figured out. I will not post that code until I publish my whole
UTM to a code repository.

[olcott]

On 8/13/2020 3:56 AM, André G. Isaak wrote:
> On 2020-08-12 21:39, olcott wrote:
>
>> If a proposition is true you must have some basis to know that it is
>> true besides a wild guess or a hunch. What-so-ever definitive basis
>> that you have to show that a proposition is definitely true is the
>> proof of this proposition. THERE IS NO WAY OUT OF THIS
>
> You are conflating truth with knowledge. They are not the same thing.
> There are many propositions which must either be true or false but which
> we don't know which. For example 'Tachyons exist.' is either true or it
> is false since there are no things which both exist and do not exist.
> But we do not know whether 'tachyons exist' is true.
>
> André
>

That Gödel's G can be known to be definititely true and known to be
definitely unprovable is just as impossible as determining the sum of a
pair of integers without using any numbers (integers are numbers).

[olcott]

On 8/13/2020 4:00 AM, André G. Isaak wrote:
> On 2020-08-12 18:54, olcott wrote:
>
>> It boils down to this: If Turing, Gödel and Tarski are correct then
>> truth itself is fundamentally broken. Since truth itself cannot
>> possibly be broken human understanding of the nature of truth is
>> necessarily incorrect.
>
> None of these people claim that truth is 'fundamentally broken'.

Of course they don't. If they understood that this is the logical result
of their work they would have the insight to know that their work cannot
possibly be correct.

> They
> simply point out the limitations of what certain types of systems are
> able to achieve.
>
> The fact that something has limitations doesn't mean it is fundamentally
> broken. Your car, for example, cannot travel at 1000 mph. That's a
> limitation. It doesn't mean your car is broken.

The only possible way that we can know that any analytical expression is
true is through an analytical proof that applies truth preserving
operations to true premises.

>> Since provability is an aspect of satisfiability true and provable
>> cannot possibly diverge.
>
> Not according to standard definitions of those terms.
>
> André

Maybe these terms of the art are defined in absurd ways such as the way
that a Turing Machine that only immediately halts is called a decider.

[André G. Isaak]

You should probably learn what Gödel's proof actually says and address
that rather than what you think it says.

Gödel's G is a statement such that neither G nor ¬G can be proven.

That entails that there is *some* true statement which cannot be proven.
We do not know, however, whether that true statement is G or ¬G. But one
of those two statements must be true.

[olcott]

If it was as simple as that there would not be a problem.
What is actually meant by "true and unprovable" is that it is true that
G is unprovable yet it is not provable that G is unprovable.

The only possible way to know for sure that G is definitely unprovable
is a proof that G is unprovable anything less than this is not definite.

Gödel: I know for sure that G is unprovable!
Pete: Can you prove that?
Gödel: No
Pete: Then your "knowledge" about G is mere presumption.

[André G. Isaak]

It is as simple as that.

> What is actually meant by "true and unprovable" is that it is true that
> G is unprovable yet it is not provable that G is unprovable.

Where on earth do you get that idea from? Gödel proves that both G and
¬G are unprovable.

> The only possible way to know for sure that G is definitely unprovable
> is a proof that G is unprovable anything less than this is not definite.
>
> Gödel: I know for sure that G is unprovable!
> Pete:  Can you prove that?
> Gödel: No

Except that Gödel's answer would be yes.

> Pete:  Then your "knowledge" about G is mere presumption.

Your correct response would be 'then I obviously don't understand what
your proof really says and I should probably go and actually read *and
understand* it before pontificating about it'

[Keith Thompson]

olcott <No...@NoWhere.com> writes:
[...]

> This is the interprocess communication protocol that I have
> established for a slave UTM to request three different kinds of
> operating system functions. The code for these three functions is
> fully designed. I only need to code the "spawn process" code and then
> the master UTM will be essentially complete.
>
> int main()
> {
> uint32_t* S1;
> S1 = (uint32_t*) 16; // size param passed to AllocateHeap
> AllocateHeap(&S1); // Allocates 16 uint32_t
> SaveState(&S1); // Saves 16 32-bit registers
> RestoreState(&S1); // Process context switch
> __asm hlt
> }

[assembly code snipped]

OK, let's go over this C program.

What you've written above is of course not a complete program.
Your functions AllocateHeap, SaveState, and RestoreState are
not declared, and as of C99 calling an undeclared function is a
constraint violation. The type name uint32_t is not visible unless
you have a #include directive for <stdint.h> (or <inttypes.h>).
(And the fact that you're using uint32_t, which was introduced in
C99, implies that you're not using C90, which did allow calls to
undeclared functions.)

S1 = (uint32_t*) 16; // size param passed to AllocateHeap

This makes S1 point to a uint32_t object at address 16. That's
... odd. Converting a constant integer value to a pointer is
rarely meaningful, unless you're on some kind of embedded system
where you know the exact memory layout. I suppose if you intend to
run this code on your x86 simulator, you can guarantee that there
is addressable memory at address 16. Why 16? Is some known value
stored at that location by some other mechanism? But the following
lines make me think that's not what you intended.

AllocateHeap(&S1); // Allocates 16 uint32_t

I presume you have reasons not to use the standard malloc function.
If I understand the comment correctly, this is intended to allocate
16 uint32_t objects (i.e., 64 contiguous 8-bit bytes, aligned
for 4-byte elements). If the argument is intended to specify the
number of uint32_t elements to allocate, why on Earth would you
pass a uint32_t** argument rather than just a uint32_t (or an int,
or a size_t)?

Can you describe what's stored at address 16, and why AllocateHeap
doesn't take a simple integer argument? And why does it not return a
result? (Or if it does, you discard it.) Allocation functions
typically return a pointer to the allocated memory.

I'm fairly sure I've misunderstood your code because I can only
see what you've written, not what you think it's supposed to mean.

Given the above, I won't try to guess how SaveState and RestoreState
are supposed to work. They both take arguments of type uint32_t**,
but it's hard to imagine what they'd do with them.

Whatever you're doing, it's unlikely that the code you've shown is
the right way to do it. Frankly, it looks like it was written by
someone who doesn't yet understand what "*" and "&" mean, and who has
just been adding arbitrary symbols to make the code look plausible.
(I would have said it looks like you added arbitrary symbols until
it compiled, which is a particularly dangerous approach in C,
but it doesn't even compile.)

Or am I missing something?