On 6/5/22 10:14 PM, olcott wrote:
> On 6/5/2022 8:59 PM, Richard Damon wrote:
>> On 6/5/22 9:03 PM, olcott wrote:
>>> On 6/5/2022 7:40 PM, Ben wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>
>>>>>> The question right now is what you would call a TM which evaluates
>>>>>> the first 10 steps of a computation, and then does something else.
>>>>>> What is it doing while evaluating those 10 steps?
>>>>>
>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>
>>>> Credit where it's due... POOP is Richard's.  Mine was not as good.
>>>>
>>>
>>> That was the initial incorrect rebuttal that claimed the concept of a
>>> simulating halt decider is inherently invalid.
>>>
>>> When a simulating halt decider H correctly predicts that its complete
>>> simulation of its input finite string would never reach the final
>>> state of this machine description then H has correctly rejected this
>>> input as non-halting.
>>>
>>
>> No, its based on the fact that you are trying to define the "correct"
>> answer for H to be something different than what the Halting Problem
>> Requires.
>
> If that was true then one of these facts wold not be verified:
> (1) The relationship between H and P matches the pattern specified below:
>
> (2) H does correctly compute the mapping from the x86 machine code to
> its reject state on the basis

No definition of what "Correct computes the mapping"

Remember the MAPPING that H needs to compute is that

H(<M>, w) accepts if M(w) Halts, and rejects if M(w) doesn't halt.
No mention of "simulations" here.

Since P(P) is shown to Halt if H(P,P) returns 0 (reject), that mapping
is NOT correctly computed.

>
>      For any program H that might determine if programs halt, a
> "pathological" >      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

Since you H didn't handle the case, because H(P,P) results in a
rejection, while P(P) Halts, you haven't show correctly computing of the
Halting Map.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>
>

Not even your broken trace?

Your slipping.

FAIL.

On 6/5/22 10:37 PM, olcott wrote:
> On 6/5/2022 9:20 PM, Richard Damon wrote:
>> On 6/5/22 10:11 PM, olcott wrote:
>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>> <..snip..>>>
>>>>>> Sure.
>>>>>> The question right now is what you would call a TM which evaluates
>>>>>> the first 10 steps of a computation, and then does something else.
>>>>>> What is it doing while evaluating those 10 steps?
>>>>>
>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>>
>>>>
>>>> But PO didn't invent the concept of (partially) simulating a
>>>> computation in order to compute certain properties of that
>>>> computation!  It's been around since Turing's days, and is very useful.
>>>>
>>>> Mike.
>>>
>>> That is true. I am apparently the first one that ever thought this
>>> through well enough so that machine descriptions matching the
>>> following pattern could be correctly determined to be non-halting:
>>>
>>>       For any program H that might determine if programs halt, a
>>> "pathological"
>>>       program P, called with some input, can pass its own source and
>>> its input to
>>>       H and then specifically do the opposite of what H predicts P
>>> will do. No H
>>>       can exist that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> In that a partial simulation does correctly predict the behavior of a
>>> complete simulation it can be used to recognize infinite behavior
>>> patterns.
>>>
>>
>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by
>> the DEFINITION of the requirements of the Halting Problem, H(P,P)
>> needs to accept (return 1) if P(P) Halts,
> This seems to be brand new computer science that I just discovered.
>
> Previously no one understood that it was possible for the correct
> simulation of the input to H(P,P) to be computationally distinct (thus
> not equivalent) to the direct execution of P(P).

By what definition of "Correct" are you using?

That is like says I can be correct at saying 1+2 = 4 if I just redefine
1+2 to be 4.

Note, if you correct deviates IN ANY WAY, from the UTM definition, you
can't use it in your definiton of the Halting Problem.

>
> Because of this all of the computer science textbooks refer to the
> halting behavior of P(P) as what must be decided by the halt decider.

Because that IS what must be decided by the Halt Decider.

>
> This same computer science also knows that a decider must compute the
> mapping of its input finite string to an accept or reject state on the
> basis of a property of this input encoded in this finite string.

Right, and the property is the Halting status of UTM(P,P).

That is a FULLY DEFINED property.

>
> THE FOLLOWING CRITERIA ALWAYS WORKS
> H computes the mapping from its input finite strings to its accept or
> reject state on the basis of the actual behavior specified by the actual
> input as measured by the correct UTM simulation of this input by H.

Right, UTM simulation, and UTM simulation of its input is DEFINED to
match the behavior of the machine its input represents.

Thus BY DEFINITON UTM(<M>, w) matches the behavior of M(w). It isn't
"computationall distinct" as you tried to claim above.

So UTM(P,P) matches P(P), and you answer is proved incorrect, since P(P)
Halts if H(P,P) returns 0, and thus UTM(P,P) will halt, and thus H(P,P)
needed to accept (return 1), which it didn't so it is wrong.

>
> It has been completely proven that partial simulations do correctly
> predict the behavior of some complete simulations.
>

yes, SOME, but not this one.

FALLICY of proof by example.

1st grade error.

On 6/5/2022 9:52 PM, Richard Damon wrote:
>
> On 6/5/22 10:37 PM, olcott wrote:
>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>> On 6/5/22 10:11 PM, olcott wrote:
>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>> <..snip..>>>
>>>>>>> Sure.
>>>>>>> The question right now is what you would call a TM which
>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>
>>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>>>
>>>>>
>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>> computation in order to compute certain properties of that
>>>>> computation!  It's been around since Turing's days, and is very
>>>>> useful.
>>>>>
>>>>> Mike.
>>>>
>>>> That is true. I am apparently the first one that ever thought this
>>>> through well enough so that machine descriptions matching the
>>>> following pattern could be correctly determined to be non-halting:
>>>>
>>>>       For any program H that might determine if programs halt, a
>>>> "pathological"
>>>>       program P, called with some input, can pass its own source and
>>>> its input to
>>>>       H and then specifically do the opposite of what H predicts P
>>>> will do. No H
>>>>       can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> In that a partial simulation does correctly predict the behavior of
>>>> a complete simulation it can be used to recognize infinite behavior
>>>> patterns.
>>>>
>>>
>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which,
>>> by the DEFINITION of the requirements of the Halting Problem, H(P,P)
>>> needs to accept (return 1) if P(P) Halts,
>> This seems to be brand new computer science that I just discovered.
>>
>> Previously no one understood that it was possible for the correct
>> simulation of the input to H(P,P) to be computationally distinct (thus
>> not equivalent) to the direct execution of P(P).
>
> By what definition of "Correct" are you using?

Ordinary software engineering proves that a correct and complete x86
emulation of the input to H(P,P) never reaches its "ret" instruction.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/5/22 11:03 PM, olcott wrote:
> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>
>> On 6/5/22 10:37 PM, olcott wrote:
>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>> <..snip..>>>
>>>>>>>> Sure.
>>>>>>>> The question right now is what you would call a TM which
>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>>
>>>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>
>>>>>>
>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>> computation in order to compute certain properties of that
>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>> useful.
>>>>>>
>>>>>> Mike.
>>>>>
>>>>> That is true. I am apparently the first one that ever thought this
>>>>> through well enough so that machine descriptions matching the
>>>>> following pattern could be correctly determined to be non-halting:
>>>>>
>>>>>       For any program H that might determine if programs halt, a
>>>>> "pathological"
>>>>>       program P, called with some input, can pass its own source
>>>>> and its input to
>>>>>       H and then specifically do the opposite of what H predicts P
>>>>> will do. No H
>>>>>       can exist that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> In that a partial simulation does correctly predict the behavior of
>>>>> a complete simulation it can be used to recognize infinite behavior
>>>>> patterns.
>>>>>
>>>>
>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which,
>>>> by the DEFINITION of the requirements of the Halting Problem, H(P,P)
>>>> needs to accept (return 1) if P(P) Halts,
>>> This seems to be brand new computer science that I just discovered.
>>>
>>> Previously no one understood that it was possible for the correct
>>> simulation of the input to H(P,P) to be computationally distinct
>>> (thus not equivalent) to the direct execution of P(P).
>>
>> By what definition of "Correct" are you using?
>
>
> Ordinary software engineering proves that a correct and complete x86
> emulation of the input to H(P,P) never reaches its "ret" instruction.
>

So, I guess this just shows that you don't actually know a definition
that shows this, so this is just another of your lies.

Also, it is shown that P(P) Halts if H(P,P) returns 0, and even YOU have
accepted that fact, so that also shows that you must be lying, since
Ordinary Software Engineering doesn't 'prove' lies.

Remember, correct and complete x86 emulation behaves exactly like the
x86 program that is being emulated, in this case, P(P).

Maybe YOUR knowledge of software engineering says that, but that says
more about your (lack of) knowledge of real software engineering.

> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>

On 6/5/2022 10:26 PM, Richard Damon wrote:
> On 6/5/22 11:03 PM, olcott wrote:
>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>
>>> On 6/5/22 10:37 PM, olcott wrote:
>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>> <..snip..>>>
>>>>>>>>> Sure.
>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>>>
>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>
>>>>>>>
>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>> computation in order to compute certain properties of that
>>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>>> useful.
>>>>>>>
>>>>>>> Mike.
>>>>>>
>>>>>> That is true. I am apparently the first one that ever thought this
>>>>>> through well enough so that machine descriptions matching the
>>>>>> following pattern could be correctly determined to be non-halting:
>>>>>>
>>>>>>       For any program H that might determine if programs halt, a
>>>>>> "pathological"
>>>>>>       program P, called with some input, can pass its own source
>>>>>> and its input to
>>>>>>       H and then specifically do the opposite of what H predicts P
>>>>>> will do. No H
>>>>>>       can exist that handles this case.
>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> In that a partial simulation does correctly predict the behavior
>>>>>> of a complete simulation it can be used to recognize infinite
>>>>>> behavior patterns.
>>>>>>
>>>>>
>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which,
>>>>> by the DEFINITION of the requirements of the Halting Problem,
>>>>> H(P,P) needs to accept (return 1) if P(P) Halts,
>>>> This seems to be brand new computer science that I just discovered.
>>>>
>>>> Previously no one understood that it was possible for the correct
>>>> simulation of the input to H(P,P) to be computationally distinct
>>>> (thus not equivalent) to the direct execution of P(P).
>>>
>>> By what definition of "Correct" are you using?
>>
>>
>> Ordinary software engineering proves that a correct and complete x86
>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>
>
> So, I guess this just shows that you don't actually know a definition
> that shows this, so this is just another of your lies.

Ordinary software engineering proves that a correct and complete x86
emulation of the input to H(P,P) never reaches its "ret" instruction.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/5/22 11:41 PM, olcott wrote:
> On 6/5/2022 10:26 PM, Richard Damon wrote:
>> On 6/5/22 11:03 PM, olcott wrote:
>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>
>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>>> <..snip..>>>
>>>>>>>>>> Sure.
>>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>>>>
>>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>>> computation in order to compute certain properties of that
>>>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>>>> useful.
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>
>>>>>>> That is true. I am apparently the first one that ever thought
>>>>>>> this through well enough so that machine descriptions matching
>>>>>>> the following pattern could be correctly determined to be
>>>>>>> non-halting:
>>>>>>>
>>>>>>>       For any program H that might determine if programs halt, a
>>>>>>> "pathological"
>>>>>>>       program P, called with some input, can pass its own source
>>>>>>> and its input to
>>>>>>>       H and then specifically do the opposite of what H predicts
>>>>>>> P will do. No H
>>>>>>>       can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> In that a partial simulation does correctly predict the behavior
>>>>>>> of a complete simulation it can be used to recognize infinite
>>>>>>> behavior patterns.
>>>>>>>
>>>>>>
>>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0,
>>>>>> which, by the DEFINITION of the requirements of the Halting
>>>>>> Problem, H(P,P) needs to accept (return 1) if P(P) Halts,
>>>>> This seems to be brand new computer science that I just discovered.
>>>>>
>>>>> Previously no one understood that it was possible for the correct
>>>>> simulation of the input to H(P,P) to be computationally distinct
>>>>> (thus not equivalent) to the direct execution of P(P).
>>>>
>>>> By what definition of "Correct" are you using?
>>>
>>>
>>> Ordinary software engineering proves that a correct and complete x86
>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>>
>>
>> So, I guess this just shows that you don't actually know a definition
>> that shows this, so this is just another of your lies.
>
> Ordinary software engineering proves that a correct and complete x86
> emulation of the input to H(P,P) never reaches its "ret" instruction.

Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
returns 0 that P(P) will halt.

Good engineering NEVER contradicts actual facts.

>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>

Maybe to you, but it is wrong (which might be why it is obvious to you).

Let us start by assuming that H doesn't just abort its simulation until
it has enough information to be obviously wrong.

H(P,P) will first emulate the first 7 instructions of P as you say.

Then it emulates the result of the call to H, so it emulates the start
of the emulation of the input to this H, which is also P,P.

That proceeds, as you almost say through the emulation of the emulaiton
of the first 7 instructions of P. While doing this, the outer emulation
will notice that the machine it has been emulating has been checking
conditions along the way.

We then get to the point that the emulation of the emulation reaches the
2nd level call to H, and the top level emulator will see that emulator
it is emulating checking if things have recursed too far.

At this point, the outer H has seen enough that it can see that if it
has aborted its simulation as soon as it say P calling H(P,P) and
matching that input to H to the input IT had, and calling that an
infinite repeat pattern, it would have been wrong, as a correct
emulation of that input would have continued and reached THIS point
where the H it was emulating made that same decision.

In fact, if the decider was smart enough, it could see that if it
simulates N levels of calls, and decides that this was enough to call
the input infinitely recursive, that at the N+1 call (that it won't get
to but a CORRECT COMPLETE emulator would), the emulator it is emulating
would reach N calls and do the same as it is, and thus showing that it
was wrong to make that decision.

The ONLY way that the correct emulation of the input never reaches the
ret instruction is if H actually never aborts its emulation, and thus
never actually gives the answer that the input is non-halting.

So, the ONLY H that creates a non-halting input is the H that fails to
give the answer that is only correct for that H.

Your brain just doesn't seem to be able to keep enough information to
handle the levels that happen in this problem.

On 2022-06-05 19:19:36 +0000, Mr Flibble said:

> On Sun, 5 Jun 2022 18:07:46 -0000 (UTC)
> Alan Mackenzie <acm@muc.de> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>> On Sun, 5 Jun 2022 12:57:56 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>> [ .... ]
>>
>>>> So 1/3 isn't an exact value?
>>
>>> 1/3 is 0.1 in base 3 so does have an exact value.
>>
>>> Let me rephrase: for the purposes of this discussion an exact value
>>> is a real number that either terminates in some base or has a
>>> repetend in other (non-irrational) bases.
>>
>> So what you seem to be saying is that an exact value is a rational
>> number. That, somehow, irrational numbers are inexact. There is no
>> basis in modern maths for that last assertion. But for that rider -
>> "for the purposes of this discussion" shows that you wish to have a
>> discussion based on falsehood and superstition.
>
> That would be a fair conclusion: irrational numbers are inexact as it
> is impossible to evaluate them to infinite precision as infinite
> precision is meaningless.

A real expression is well defined and exact if for every rational number
it is possible to determine whether it is smaller than the value of the
real expression.

Mikko

On 2022-06-05 20:23:19 +0000, Mr Flibble said:

> On Sun, 5 Jun 2022 16:09:13 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 6/5/22 3:56 PM, Mr Flibble wrote:
>>> On Sun, 5 Jun 2022 15:47:30 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 6/5/22 3:33 PM, Mr Flibble wrote:
>>>>> On Sun, 5 Jun 2022 15:30:45 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 6/5/22 3:17 PM, Mr Flibble wrote:
>>>>>>> On Sun, 5 Jun 2022 14:17:29 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 6/5/22 1:22 PM, Mr Flibble wrote:
>>>>>>>>> On Sun, 5 Jun 2022 13:05:09 -0400
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 6/5/22 12:56 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sun, 5 Jun 2022 12:50:13 -0400
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 6/5/22 12:28 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sun, 5 Jun 2022 12:22:45 -0400
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/5/22 11:49 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 15:44:32 -0000 (UTC)
>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 16:28:05 +0100
>>>>>>>>>>>>>>>>> Andy Walker <anw@cuboid.co.uk> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 05/06/2022 14:47, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 07:58:42 -0400
>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>> [...] Sort of like how the number Pi has an
>>>>>>>>>>>>>>>>>>>> exact value, but you can never actually express it
>>>>>>>>>>>>>>>>>>>> (because it takes an infinite number of digits).
>>>>>>>>>>>>>>>>>>> PI does not have an exact value; no irrational
>>>>>>>>>>>>>>>>>>> number has an exact value.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Of course "pi" has an exact value; as
>>>>>>>>>>>>>>>>>> do [eg] "sqrt(2)", "e", and all the other computable
>>>>>>>>>>>>>>>>>> real [and complex] numbers. Whether that value can be
>>>>>>>>>>>>>>>>>> expressed in finite terms in some particular
>>>>>>>>>>>>>>>>>> representation is quite another matter. That in turn
>>>>>>>>>>>>>>>>>> depends on the representation; standard decimals is
>>>>>>>>>>>>>>>>>> merely one [common] choice. Note that in symbolic
>>>>>>>>>>>>>>>>>> computer systems, those computable reals are
>>>>>>>>>>>>>>>>>> typically written "pi" [or whatever], and the
>>>>>>>>>>>>>>>>>> computer works with that exactly, so that [eg]
>>>>>>>>>>>>>>>>>> "sin^2 (pi/3) == 3/4", not 0.7499...; and also that
>>>>>>>>>>>>>>>>>> in decimal-type notations most rationals equally
>>>>>>>>>>>>>>>>>> have no terminating expansion. Numbers such as "pi"
>>>>>>>>>>>>>>>>>> and "sqrt(2)" are not defined as decimal expansions
>>>>>>>>>>>>>>>>>> but via their properties [eg that "sqrt(2)" is the
>>>>>>>>>>>>>>>>>> unique positive real whose square is 2, or
>>>>>>>>>>>>>>>>>> equivalently that it is the ratio of the diagonal of
>>>>>>>>>>>>>>>>>> a square to its side, and "pi" is the least positive
>>>>>>>>>>>>>>>>>> real whose sine is zero]. Those properties are
>>>>>>>>>>>>>>>>>> exact, and tell you all you ever need to know about
>>>>>>>>>>>>>>>>>> those numbers.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What has decimal (base 10) expansion got to do with
>>>>>>>>>>>>>>>>> anything? An irrational number has a non-terminating
>>>>>>>>>>>>>>>>> sequence in ANY base. I am sorry but you are simply
>>>>>>>>>>>>>>>>> mistaken: irrational numbers do NOT have an exact
>>>>>>>>>>>>>>>>> value; this is obvious to anyone who understands
>>>>>>>>>>>>>>>>> logic and uses a sane definition for infinity.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That irrational numbers are exact values is clear to
>>>>>>>>>>>>>>>> anybody with a degree in maths. Definitions of
>>>>>>>>>>>>>>>> "infinity" (of which there are many) have nothing to do
>>>>>>>>>>>>>>>> with this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are wrong and fractally so so your degree in maths
>>>>>>>>>>>>>>> appears to be worthless. An irrational number's
>>>>>>>>>>>>>>> sequence is statistically random, has no fixed point on
>>>>>>>>>>>>>>> the number line ergo has no exact representation. Any
>>>>>>>>>>>>>>> number with no exact representation has, by definition,
>>>>>>>>>>>>>>> no exact value, only an approximation. Infinity has
>>>>>>>>>>>>>>> everything to do with this as an irrational's sequence
>>>>>>>>>>>>>>> ("digits") never terminates (i.e. it is an INFINITELY
>>>>>>>>>>>>>>> long sequence).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. Irrational numbers DO have exact points on the
>>>>>>>>>>>>>> number line.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And what does representation have to do with exact value?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, irrational numbers sequence of digits are not
>>>>>>>>>>>>>> necessarily statistically random, in some
>>>>>>>>>>>>>> representations, they can be VERY predictible for some
>>>>>>>>>>>>>> numbers.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One simple construction to show exact position, draw a
>>>>>>>>>>>>>> box with sides exactly 1.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Draw a line though opposite corners and make one point
>>>>>>>>>>>>>> the value 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The other corner will be EXACTLY at the point sqrt(2), so
>>>>>>>>>>>>>> that irrational number has an exact point on the number
>>>>>>>>>>>>>> line.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You just don't understand what an exact value means,
>>>>>>>>>>>>>> likely because you can't understand things that are
>>>>>>>>>>>>>> somewhat abstract.
>>>>>>>>>>>>>
>>>>>>>>>>>>> An irrational number does not have an exact point on the
>>>>>>>>>>>>> number line as it will move about as you "zoom in", you
>>>>>>>>>>>>> can keep "zooming in" forever (i.e. infinitely) and it
>>>>>>>>>>>>> will keep moving about because the number never
>>>>>>>>>>>>> terminates.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I couldn't understand things that are somewhat abstract
>>>>>>>>>>>>> then I wouldn't have a computer science degree (BSc Hons)
>>>>>>>>>>>>> and 30 years of industry experience.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Then why do you think irrational numbers don't have an
>>>>>>>>>>>> exact location?
>>>>>>>>>>>>
>>>>>>>>>>>> I know people with degrees (even with honors) and industry
>>>>>>>>>>>> experiance that still show that they don't really
>>>>>>>>>>>> understand what they are talking about.
>>>>>>>>>>>>
>>>>>>>>>>>> The "width" of the point representing the location of an
>>>>>>>>>>>> irrational number is just as much "0" as that of a rational
>>>>>>>>>>>> number, so specifies just as exact of a location.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that we can't write it in a rational base with a
>>>>>>>>>>>> finite number of digits doesn't actally mean anything.
>>>>>>>>>>>
>>>>>>>>>>> 3.1415xxxxxxxxx (a)
>>>>>>>>>>> 3.14159xxxxxxxx (b)
>>>>>>>>>>>
>>>>>>>>>>> (b) is nearer to 3.14160 than 3.14150 that (a) indicates
>>>>>>>>>>> hence its value "moves about" as accuracy increases.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But (a) and (b) aren't "pi"
>>>>>>>>>
>>>>>>>>> No, they are approximations of pi. The value of the
>>>>>>>>> approximation changes up to a factor of 1/base as you evaluate
>>>>>>>>> it at increasing accuracy.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All you are showing is that approximations to numbers get
>>>>>>>>>> better as they get better, which is just a strange
>>>>>>>>>> tautology.
>>>>>>>>>
>>>>>>>>> Yes and therefor they jump about on the number line as
>>>>>>>>> accuracy increases.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The number PI, has only one precise value, the exact ratio of
>>>>>>>>>> the circumference of a circle to its diameter on a flat plane
>>>>>>>>>> (which will always be the same).
>>>>>>>>>
>>>>>>>>> pi cannot have a precise value as it neither terminates nor
>>>>>>>>> has a repetend in any base.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The fact that it can't be expressed, isn't an issue on
>>>>>>>>>> exactness, but of finite representation.
>>>>>>>>>
>>>>>>>>> We can only ever have a finite representation.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note, that the set of numbers with finite representation is a
>>>>>>>>>> countable set, so it isn't surprising that the uncountable
>>>>>>>>>> infinity of the reals (that includes the irrationals) is not
>>>>>>>>>> all finitely expressible.
>>>>>>>>>
>>>>>>>>> Stating the obvious.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> So you DO have problems with abstractions.
>>>>>>>>
>>>>>>>> The problem is, we don't actually need the finite numerical
>>>>>>>> representation of a number if we have the definition of what
>>>>>>>> the number is (which is another sort of abstract finite
>>>>>>>> representation).
>>>>>>>>
>>>>>>>> The "finite representation" of pi is the ratio of the
>>>>>>>> circumference to the diameter of a circle on a plane.
>>>>>>>
>>>>>>> No, instead if you use logic you must come to the conclusion
>>>>>>> that there is no ratio of the circumference to the diameter of a
>>>>>>> circle: rational numbers describe ratios, irrational numbers do
>>>>>>> not. QED.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Then you don't understand what is a ratio. Rational numbers are
>>>>>> the ratio of INTEGERS, not all ratios. Ratios define the relative
>>>>>> magnatude of one number to another, ANY number.
>>>>>>
>>>>>> Since it is clear you don't understand the meaning of the basic
>>>>>> terms, your OPINION about the weightier things becomes suspect.
>>>>>
>>>>> Prove that there is a ratio between the circumference and diameter
>>>>> of a circle. Hint: you can't.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> Ratio of numbers A and B is defined as A / B (assuming B is not 0)
>>>>
>>>> The circumference of the circle is a length of the arc all the way
>>>> around the circle, so is a real number.
>>>>
>>>> The diameter of the circle is the length of the line from one side
>>>> of the circle to the other through the center, so is a real number.
>>>> Assuming the circle is not degenerate to a point, that number is
>>>> not zero.
>>>>
>>>> Thus we have two real numbers, the second not zero, so by closure,
>>>> the first divided by the second is a real number.
>>>>
>>>> Thus those numbers have a ratio.
>>>
>>> But at least one of those numbers must be irrational otherwise the
>>> ratio would be a rational number ergo at least one of those numbers
>>> is inexact ergo the resulting ratio between the circumference
>>> and diameter of a circle must also be inexact which as an irrational
>>> number it is. QED.
>>>
>>> /Flibble
>>>
>>
>> You are ASSUMING that irrational numbers are inexact, and that is a
>> false statement so you logic is unsound.
>>
>> Note, the square root of 2 can be proved exact by simple geometric
>> construction, thus disproving your claim that irrational numbers are
>> inexact.
>>
>
> Lets not change the subject and stick with pi shall we?
>
> (1) You have defined a ratio to be A/B.
> (2) You have defined a rational number to be the ratio
> between two integers.
> (3) You have defined pi as the ratio between circumference, C and
> diameter, D, of a circle
> (4) pi is defined to be an irrational number.

On 6/5/2022 11:17 PM, Richard Damon wrote:
>
> On 6/5/22 11:41 PM, olcott wrote:
>> On 6/5/2022 10:26 PM, Richard Damon wrote:
>>> On 6/5/22 11:03 PM, olcott wrote:
>>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>>>> <..snip..>>>
>>>>>>>>>>> Sure.
>>>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>>>> something else. What is it doing while evaluating those 10
>>>>>>>>>>> steps?
>>>>>>>>>>
>>>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>>>> computation in order to compute certain properties of that
>>>>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>>>>> useful.
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>
>>>>>>>> That is true. I am apparently the first one that ever thought
>>>>>>>> this through well enough so that machine descriptions matching
>>>>>>>> the following pattern could be correctly determined to be
>>>>>>>> non-halting:
>>>>>>>>
>>>>>>>>       For any program H that might determine if programs halt, a
>>>>>>>> "pathological"
>>>>>>>>       program P, called with some input, can pass its own source
>>>>>>>> and its input to
>>>>>>>>       H and then specifically do the opposite of what H predicts
>>>>>>>> P will do. No H
>>>>>>>>       can exist that handles this case.
>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> In that a partial simulation does correctly predict the behavior
>>>>>>>> of a complete simulation it can be used to recognize infinite
>>>>>>>> behavior patterns.
>>>>>>>>
>>>>>>>
>>>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0,
>>>>>>> which, by the DEFINITION of the requirements of the Halting
>>>>>>> Problem, H(P,P) needs to accept (return 1) if P(P) Halts,
>>>>>> This seems to be brand new computer science that I just discovered.
>>>>>>
>>>>>> Previously no one understood that it was possible for the correct
>>>>>> simulation of the input to H(P,P) to be computationally distinct
>>>>>> (thus not equivalent) to the direct execution of P(P).
>>>>>
>>>>> By what definition of "Correct" are you using?
>>>>
>>>>
>>>> Ordinary software engineering proves that a correct and complete x86
>>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>>>
>>>
>>> So, I guess this just shows that you don't actually know a definition
>>> that shows this, so this is just another of your lies.
>>
>> Ordinary software engineering proves that a correct and complete x86
>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>
> Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
> returns 0 that P(P) will halt.
>
> Good engineering NEVER contradicts actual facts.
>
>>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>> It is completely obvious that when H(P,P) correctly emulates its input
>> that it must emulate the first seven instructions of P. Because the
>> seventh instruction of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>
> Maybe to you, but it is wrong (which might be why it is obvious to you).
>

Software engineers competent in C and the x86 language will verify that
when H(P,P) correctly emulates its input with an x86 emulator that this
emulation would never stop running. This provides the basis for H(P,P)
to correctly reject its input as non-halting.

> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of
> what H predicts P will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

H determines the halt status of its input by watching the behavior of
this input when it is correctly simulated by H using an x86 emulator.
When H correctly matches an infinite behavior pattern it aborts the
emulation of this input and returns 0.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Mon, 6 Jun 2022 16:10:28 +0300
Mikko <mikko.levanto@iki.fi> wrote:

> On 2022-06-05 20:23:19 +0000, Mr Flibble said:
>
> > On Sun, 5 Jun 2022 16:09:13 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 6/5/22 3:56 PM, Mr Flibble wrote:
> >>> On Sun, 5 Jun 2022 15:47:30 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 6/5/22 3:33 PM, Mr Flibble wrote:
> >>>>> On Sun, 5 Jun 2022 15:30:45 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>
> >>>>>> On 6/5/22 3:17 PM, Mr Flibble wrote:
> >>>>>>> On Sun, 5 Jun 2022 14:17:29 -0400
> >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>
> >>>>>>>> On 6/5/22 1:22 PM, Mr Flibble wrote:
> >>>>>>>>> On Sun, 5 Jun 2022 13:05:09 -0400
> >>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/5/22 12:56 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sun, 5 Jun 2022 12:50:13 -0400
> >>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/5/22 12:28 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sun, 5 Jun 2022 12:22:45 -0400
> >>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/5/22 11:49 AM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sun, 5 Jun 2022 15:44:32 -0000 (UTC)
> >>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
> >>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 16:28:05 +0100
> >>>>>>>>>>>>>>>>> Andy Walker <anw@cuboid.co.uk> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 05/06/2022 14:47, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Sun, 5 Jun 2022 07:58:42 -0400
> >>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>>>> [...] Sort of like how the number Pi has an
> >>>>>>>>>>>>>>>>>>>> exact value, but you can never actually express
> >>>>>>>>>>>>>>>>>>>> it (because it takes an infinite number of
> >>>>>>>>>>>>>>>>>>>> digits).
> >>>>>>>>>>>>>>>>>>> PI does not have an exact value; no irrational
> >>>>>>>>>>>>>>>>>>> number has an exact value.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Of course "pi" has an exact value; as
> >>>>>>>>>>>>>>>>>> do [eg] "sqrt(2)", "e", and all the other
> >>>>>>>>>>>>>>>>>> computable real [and complex] numbers. Whether
> >>>>>>>>>>>>>>>>>> that value can be expressed in finite terms in
> >>>>>>>>>>>>>>>>>> some particular representation is quite another
> >>>>>>>>>>>>>>>>>> matter. That in turn depends on the
> >>>>>>>>>>>>>>>>>> representation; standard decimals is merely one
> >>>>>>>>>>>>>>>>>> [common] choice. Note that in symbolic computer
> >>>>>>>>>>>>>>>>>> systems, those computable reals are typically
> >>>>>>>>>>>>>>>>>> written "pi" [or whatever], and the computer works
> >>>>>>>>>>>>>>>>>> with that exactly, so that [eg] "sin^2 (pi/3) ==
> >>>>>>>>>>>>>>>>>> 3/4", not 0.7499...; and also that in decimal-type
> >>>>>>>>>>>>>>>>>> notations most rationals equally have no
> >>>>>>>>>>>>>>>>>> terminating expansion. Numbers such as "pi" and
> >>>>>>>>>>>>>>>>>> "sqrt(2)" are not defined as decimal expansions
> >>>>>>>>>>>>>>>>>> but via their properties [eg that "sqrt(2)" is the
> >>>>>>>>>>>>>>>>>> unique positive real whose square is 2, or
> >>>>>>>>>>>>>>>>>> equivalently that it is the ratio of the diagonal
> >>>>>>>>>>>>>>>>>> of a square to its side, and "pi" is the least
> >>>>>>>>>>>>>>>>>> positive real whose sine is zero]. Those
> >>>>>>>>>>>>>>>>>> properties are exact, and tell you all you ever
> >>>>>>>>>>>>>>>>>> need to know about those numbers.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [ .... ]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> What has decimal (base 10) expansion got to do with
> >>>>>>>>>>>>>>>>> anything? An irrational number has a non-terminating
> >>>>>>>>>>>>>>>>> sequence in ANY base. I am sorry but you are simply
> >>>>>>>>>>>>>>>>> mistaken: irrational numbers do NOT have an exact
> >>>>>>>>>>>>>>>>> value; this is obvious to anyone who understands
> >>>>>>>>>>>>>>>>> logic and uses a sane definition for infinity.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That irrational numbers are exact values is clear to
> >>>>>>>>>>>>>>>> anybody with a degree in maths. Definitions of
> >>>>>>>>>>>>>>>> "infinity" (of which there are many) have nothing to
> >>>>>>>>>>>>>>>> do with this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> You are wrong and fractally so so your degree in maths
> >>>>>>>>>>>>>>> appears to be worthless. An irrational number's
> >>>>>>>>>>>>>>> sequence is statistically random, has no fixed point
> >>>>>>>>>>>>>>> on the number line ergo has no exact representation.
> >>>>>>>>>>>>>>> Any number with no exact representation has, by
> >>>>>>>>>>>>>>> definition, no exact value, only an approximation.
> >>>>>>>>>>>>>>> Infinity has everything to do with this as an
> >>>>>>>>>>>>>>> irrational's sequence ("digits") never terminates
> >>>>>>>>>>>>>>> (i.e. it is an INFINITELY long sequence).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nope. Irrational numbers DO have exact points on the
> >>>>>>>>>>>>>> number line.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> And what does representation have to do with exact
> >>>>>>>>>>>>>> value?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Also, irrational numbers sequence of digits are not
> >>>>>>>>>>>>>> necessarily statistically random, in some
> >>>>>>>>>>>>>> representations, they can be VERY predictible for some
> >>>>>>>>>>>>>> numbers.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> One simple construction to show exact position, draw a
> >>>>>>>>>>>>>> box with sides exactly 1.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Draw a line though opposite corners and make one point
> >>>>>>>>>>>>>> the value 0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The other corner will be EXACTLY at the point sqrt(2),
> >>>>>>>>>>>>>> so that irrational number has an exact point on the
> >>>>>>>>>>>>>> number line.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You just don't understand what an exact value means,
> >>>>>>>>>>>>>> likely because you can't understand things that are
> >>>>>>>>>>>>>> somewhat abstract.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> An irrational number does not have an exact point on the
> >>>>>>>>>>>>> number line as it will move about as you "zoom in", you
> >>>>>>>>>>>>> can keep "zooming in" forever (i.e. infinitely) and it
> >>>>>>>>>>>>> will keep moving about because the number never
> >>>>>>>>>>>>> terminates.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If I couldn't understand things that are somewhat
> >>>>>>>>>>>>> abstract then I wouldn't have a computer science degree
> >>>>>>>>>>>>> (BSc Hons) and 30 years of industry experience.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Then why do you think irrational numbers don't have an
> >>>>>>>>>>>> exact location?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I know people with degrees (even with honors) and
> >>>>>>>>>>>> industry experiance that still show that they don't
> >>>>>>>>>>>> really understand what they are talking about.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The "width" of the point representing the location of an
> >>>>>>>>>>>> irrational number is just as much "0" as that of a
> >>>>>>>>>>>> rational number, so specifies just as exact of a
> >>>>>>>>>>>> location.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The fact that we can't write it in a rational base with a
> >>>>>>>>>>>> finite number of digits doesn't actally mean anything.
> >>>>>>>>>>>
> >>>>>>>>>>> 3.1415xxxxxxxxx (a)
> >>>>>>>>>>> 3.14159xxxxxxxx (b)
> >>>>>>>>>>>
> >>>>>>>>>>> (b) is nearer to 3.14160 than 3.14150 that (a) indicates
> >>>>>>>>>>> hence its value "moves about" as accuracy increases.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> But (a) and (b) aren't "pi"
> >>>>>>>>>
> >>>>>>>>> No, they are approximations of pi. The value of the
> >>>>>>>>> approximation changes up to a factor of 1/base as you
> >>>>>>>>> evaluate it at increasing accuracy.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> All you are showing is that approximations to numbers get
> >>>>>>>>>> better as they get better, which is just a strange
> >>>>>>>>>> tautology.
> >>>>>>>>>
> >>>>>>>>> Yes and therefor they jump about on the number line as
> >>>>>>>>> accuracy increases.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The number PI, has only one precise value, the exact ratio
> >>>>>>>>>> of the circumference of a circle to its diameter on a flat
> >>>>>>>>>> plane (which will always be the same).
> >>>>>>>>>
> >>>>>>>>> pi cannot have a precise value as it neither terminates nor
> >>>>>>>>> has a repetend in any base.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The fact that it can't be expressed, isn't an issue on
> >>>>>>>>>> exactness, but of finite representation.
> >>>>>>>>>
> >>>>>>>>> We can only ever have a finite representation.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Note, that the set of numbers with finite representation
> >>>>>>>>>> is a countable set, so it isn't surprising that the
> >>>>>>>>>> uncountable infinity of the reals (that includes the
> >>>>>>>>>> irrationals) is not all finitely expressible.
> >>>>>>>>>
> >>>>>>>>> Stating the obvious.
> >>>>>>>>>
> >>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> So you DO have problems with abstractions.
> >>>>>>>>
> >>>>>>>> The problem is, we don't actually need the finite numerical
> >>>>>>>> representation of a number if we have the definition of what
> >>>>>>>> the number is (which is another sort of abstract finite
> >>>>>>>> representation).
> >>>>>>>>
> >>>>>>>> The "finite representation" of pi is the ratio of the
> >>>>>>>> circumference to the diameter of a circle on a plane.
> >>>>>>>
> >>>>>>> No, instead if you use logic you must come to the conclusion
> >>>>>>> that there is no ratio of the circumference to the diameter
> >>>>>>> of a circle: rational numbers describe ratios, irrational
> >>>>>>> numbers do not. QED.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> Then you don't understand what is a ratio. Rational numbers are
> >>>>>> the ratio of INTEGERS, not all ratios. Ratios define the
> >>>>>> relative magnatude of one number to another, ANY number.
> >>>>>>
> >>>>>> Since it is clear you don't understand the meaning of the basic
> >>>>>> terms, your OPINION about the weightier things becomes
> >>>>>> suspect.
> >>>>>
> >>>>> Prove that there is a ratio between the circumference and
> >>>>> diameter of a circle. Hint: you can't.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Ratio of numbers A and B is defined as A / B (assuming B is not
> >>>> 0)
> >>>>
> >>>> The circumference of the circle is a length of the arc all the
> >>>> way around the circle, so is a real number.
> >>>>
> >>>> The diameter of the circle is the length of the line from one
> >>>> side of the circle to the other through the center, so is a real
> >>>> number. Assuming the circle is not degenerate to a point, that
> >>>> number is not zero.
> >>>>
> >>>> Thus we have two real numbers, the second not zero, so by
> >>>> closure, the first divided by the second is a real number.
> >>>>
> >>>> Thus those numbers have a ratio.
> >>>
> >>> But at least one of those numbers must be irrational otherwise the
> >>> ratio would be a rational number ergo at least one of those
> >>> numbers is inexact ergo the resulting ratio between the
> >>> circumference and diameter of a circle must also be inexact which
> >>> as an irrational number it is. QED.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You are ASSUMING that irrational numbers are inexact, and that is a
> >> false statement so you logic is unsound.
> >>
> >> Note, the square root of 2 can be proved exact by simple geometric
> >> construction, thus disproving your claim that irrational numbers
> >> are inexact.
> >>
> >
> > Lets not change the subject and stick with pi shall we?
> >
> > (1) You have defined a ratio to be A/B.
> > (2) You have defined a rational number to be the ratio
> > between two integers.
> > (3) You have defined pi as the ratio between circumference, C and
> > diameter, D, of a circle
> > (4) pi is defined to be an irrational number.
>
> No, pi is not defined to be an irrational number. It is proven to be
> irrational, i.e., it is proven that every rational number is either
> less than or greater than pi.
>
> > Given all of the above C, D, or both must be irrational for the
> > resultant ratio, pi, to also be irrational.
>
> If C and D are numbers. Not if they are just lengths. The question
> "is the distance from P to Q rational" is meaningless unless one
> postulates that distances are numbers.

On Sun, 5 Jun 2022 19:27:39 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/5/2022 6:59 PM, Mike Terry wrote:
> > On 05/06/2022 22:59, Jeff Barnett wrote:
> >> On 6/5/2022 2:07 PM, Mike Terry wrote:
> >>> On 05/06/2022 16:16, Alan Mackenzie wrote:
> >>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> >>>>> On 05/06/2022 13:14, Alan Mackenzie wrote:
> >>>>>> olcott <NoOne@nowhere.com> wrote:
> >>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
> >>>>>>>> olcott <NoOne@nowhere.com> wrote:
> >>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
> >>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
> >>>>
> >>>>>>>>>>> A Turing machine is said to halt whenever it reaches a
> >>>>>>>>>>> configuration for which δ is not defined; this is
> >>>>>>>>>>> possible because
> >>>>>>>>>>> δ is a partial function. In fact, we will assume that no
> >>>>>>>>>>> transitions are defined for any final state so the Turing
> >>>>>>>>>>> machine
> >>>>>>>>>>> will halt whenever it enters a final state.
> >>>>>>>>>>> (Linz:1990:234)
> >>>>
> >>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
> >>>>>>>>>>> Automata.
> >>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
> >>>>
> >>>>>>>>>>> When translated into ordinary software engineering terms
> >>>>>>>>>>> this means
> >>>>>>>>>>> terminated normally. In a C function this means reaching
> >>>>>>>>>>> the "ret"
> >>>>>>>>>>> instruction.
> >>>>
> >>>>>>>>>> The best equivalent to "not defined" is not "ret".
> >>>>>>>>>> Instead, "not defined" should include at least:
> >>>>>>>>>> - HLT or any other instruction that means 'halt'
> >>>>>>>>>> - any undefined op code
> >>>>>>>>>> - any return or pop instruction if the stack is empty
> >>>>>>>>>> - an instruction fetch from a location that is not
> >>>>>>>>>> specifiec by the
> >>>>>>>>>>      program
> >>>>>>>>>> That way the analogy to Linz' definition is much better.
> >>>>
> >>>>>>>>>> Mikko
> >>>>
> >>>>>>>>> Reaching a final state is merely the Turing machine way of
> >>>>>>>>> saying terminated normally. "ret" is the C way of saying
> >>>>>>>>> the same thing.
> >>>>
> >>>>>>>> Sophistry.  What would be the turing machine equivalent of an
> >>>>>>>> "abnormal termination" in C?
> >>>>
> >>>>>>> An aborted simulation.
> >>>>
> >>>>>> There's no such thing on a turing machine.  It either runs and
> >>>>>> halts, or it runs forever.
> >>>>
> >>>>>> Your aborted simulation is just one final state of a turing
> >>>>>> machine, which has thus halted.
> >>>>
> >>>>> A TM "aborting" a simulation is just the TM ceasing to calculate
> >>>>> computation steps for some computation, and going on to
> >>>>> calculate something else instead.  It does not mean:
> >>>>> a)  that the TM (doing the simulation) has halted
> >>>>> b)  that the simulated computation halts
> >>>>> c)  that the simulated computation never halts
> >>>>
> >>>> OK.  I've a feeling we're talking more about nice shades of
> >>>> words than computer science here, but ....
> >>>>
> >>>> If the simulation is the entire turing machine, aborting it will
> >>>> bring the TM to a halt state.  If that simulation is merely part
> >>>> of the TM, then the word "halt" has a different meaning when
> >>>> applied to that simulation part from when applied to the entire
> >>>> TM.  I'm not even sure what you mean when you say a part of a TM
> >>>> has halted or not halted.
> >>>
> >>> We are clearly talking at cross purposes - I never talked about
> >>> /part/ of a TM halting, and like you, I can't work out what that
> >>> would mean!  I used "halt" only with respect to a computation,
> >>> meaning that the computation halts [there is an n such that
> >>> computation step n is a TM final state].
> >>>
> >>> Reading what you say very carefully, I think that by your
> >>> definition of simulation, the simulating TM must be a "pure"
> >>> simulator that does nothing but simulate computation steps until
> >>> the simulation halts, at which point the simulating TM halts
> >>> (like a UTM).  I get that with that interpretation what you said:
> >>>
> >>> <copied from above>
> >>>  >>> Your aborted simulation is just one final state of a turing
> >>> machine,
> >>>  >>> which has thus halted.
> >>>
> >>>   makes sense and is correct.  I'd just say I don't think that
> >>> usage of "simulation" is very useful, and is DEFINITELY not what
> >>> PO is talking about (so it would be wrong if applied PO's
> >>> posts...)
> >>>
> >>> My use of "simulation" is broader: it's simply the activity
> >>> performed by a TM which consists of calculating computation steps
> >>> of some given computation.  As such it's just a part of the TM
> >>> logic. A TM's typical use of simulation might be something like
> >>> "..the TM simulates the computation for n steps, and if the
> >>> simulation halts during those n steps, the TM [blah blah],
> >>> /otherwise/ the TM [blah blah blah]...". Just about every
> >>> reference in the literature I can recall is something like that.
> >>>
> >>> So... to be 100% clear on what I said:
> >>>
> >>> <copied from above>
> >>>  >> A TM "aborting" a simulation is just the TM ceasing to
> >>> calculate >> computation steps for some computation, and going on
> >>> to calculate >> something else instead.
> >>>
> >>> E.g. in PO's P, after P aborts its simulation of P(P), the TM
> >>> either halts or enters an infinite loop.  (That logic is not part
> >>> of the simulation, IMO.)
> >>>
> >>>  >> It does *NOT* mean:
> >>>  >> a)  that the TM (doing the simulation) has halted
> >>>
> >>> obviously, because now P has gone on to something else...
> >>>
> >>>  >> b)  that the simulated computation halts
> >>>  >> c)  that the simulated computation never halts
> >>>
> >>> obviously - in general different exacmples of a simulated
> >>> computation P(I) might halt or never halt, and this is unaffected
> >>> by a simulator's decision to simulate no further computation
> >>> steps. [The TM may have spotted some pattern in the simulated
> >>> computation which implies P(I) never halts - that is a separate
> >>> matter, but for sure the mere act of "aborting" the simulation
> >>> doesn't imply P(I) never halts, or imply that it halts...
> >>>
> >>> Put yet another way, when a TM stops calculating TM steps (aka
> >>> aborts its simulation), NOTHING HALTS: not the simulating TM, not
> >>> the simulated computation, and NOT ANY PART OF EITHER OF THOSE.
> >>> (Like you say, what would part of a TM halting mean?)
> >>
> >> I think of a TM and an input string as defining a sequence (an
> >> ordered list). The elements of the sequence are pairs of a TM
> >> state name and a string representing the "tape" contents when the
> >> state was entered. Note that this view has no character of
> >> animation in it and makes the definition of the halt predicate (H)
> >> trivial:
> >>
> >> H(TM,STRING) = If length of TM(STRING) is finite then TRUE else
> >> FALSE.
> >
> > Yes, that's equivalent to what I said (or at least meant).  Your
> > sequence is my computation steps. Formally, these would be defined
> > inductively via the rule to go from step n to step n+1.  (Not an
> > animation, but the induction gives some /sense/ of step-by-step
> > calculation, and a simulator will follow this, starting at step 1,
> > then calculate step 2 and so on.  Still, I agree the entire
> > sequence [the "computation"] exists as one timeless structure.  Too
> > abstract for PO...)
>
> In other words when we make sure to conflate the program under test
> with the test program as a single computation then the whole idea of
> a halt decider becomes less coherent and

On 6/6/2022 11:49 AM, Mr Flibble wrote:
> On Sun, 5 Jun 2022 19:27:39 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/5/2022 6:59 PM, Mike Terry wrote:
>>> On 05/06/2022 22:59, Jeff Barnett wrote:
>>>> On 6/5/2022 2:07 PM, Mike Terry wrote:
>>>>> On 05/06/2022 16:16, Alan Mackenzie wrote:
>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>>>>> On 05/06/2022 13:14, Alan Mackenzie wrote:
>>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>>>>>
>>>>>>>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>>>> configuration for which δ is not defined; this is
>>>>>>>>>>>>> possible because
>>>>>>>>>>>>> δ is a partial function. In fact, we will assume that no
>>>>>>>>>>>>> transitions are defined for any final state so the Turing
>>>>>>>>>>>>> machine
>>>>>>>>>>>>> will halt whenever it enters a final state.
>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>
>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>>
>>>>>>>>>>>>> When translated into ordinary software engineering terms
>>>>>>>>>>>>> this means
>>>>>>>>>>>>> terminated normally. In a C function this means reaching
>>>>>>>>>>>>> the "ret"
>>>>>>>>>>>>> instruction.
>>>>>>
>>>>>>>>>>>> The best equivalent to "not defined" is not "ret".
>>>>>>>>>>>> Instead, "not defined" should include at least:
>>>>>>>>>>>> - HLT or any other instruction that means 'halt'
>>>>>>>>>>>> - any undefined op code
>>>>>>>>>>>> - any return or pop instruction if the stack is empty
>>>>>>>>>>>> - an instruction fetch from a location that is not
>>>>>>>>>>>> specifiec by the
>>>>>>>>>>>>      program
>>>>>>>>>>>> That way the analogy to Linz' definition is much better.
>>>>>>
>>>>>>>>>>>> Mikko
>>>>>>
>>>>>>>>>>> Reaching a final state is merely the Turing machine way of
>>>>>>>>>>> saying terminated normally. "ret" is the C way of saying
>>>>>>>>>>> the same thing.
>>>>>>
>>>>>>>>>> Sophistry.  What would be the turing machine equivalent of an
>>>>>>>>>> "abnormal termination" in C?
>>>>>>
>>>>>>>>> An aborted simulation.
>>>>>>
>>>>>>>> There's no such thing on a turing machine.  It either runs and
>>>>>>>> halts, or it runs forever.
>>>>>>
>>>>>>>> Your aborted simulation is just one final state of a turing
>>>>>>>> machine, which has thus halted.
>>>>>>
>>>>>>> A TM "aborting" a simulation is just the TM ceasing to calculate
>>>>>>> computation steps for some computation, and going on to
>>>>>>> calculate something else instead.  It does not mean:
>>>>>>> a)  that the TM (doing the simulation) has halted
>>>>>>> b)  that the simulated computation halts
>>>>>>> c)  that the simulated computation never halts
>>>>>>
>>>>>> OK.  I've a feeling we're talking more about nice shades of
>>>>>> words than computer science here, but ....
>>>>>>
>>>>>> If the simulation is the entire turing machine, aborting it will
>>>>>> bring the TM to a halt state.  If that simulation is merely part
>>>>>> of the TM, then the word "halt" has a different meaning when
>>>>>> applied to that simulation part from when applied to the entire
>>>>>> TM.  I'm not even sure what you mean when you say a part of a TM
>>>>>> has halted or not halted.
>>>>>
>>>>> We are clearly talking at cross purposes - I never talked about
>>>>> /part/ of a TM halting, and like you, I can't work out what that
>>>>> would mean!  I used "halt" only with respect to a computation,
>>>>> meaning that the computation halts [there is an n such that
>>>>> computation step n is a TM final state].
>>>>>
>>>>> Reading what you say very carefully, I think that by your
>>>>> definition of simulation, the simulating TM must be a "pure"
>>>>> simulator that does nothing but simulate computation steps until
>>>>> the simulation halts, at which point the simulating TM halts
>>>>> (like a UTM).  I get that with that interpretation what you said:
>>>>>
>>>>> <copied from above>
>>>>>  >>> Your aborted simulation is just one final state of a turing
>>>>> machine,
>>>>>  >>> which has thus halted.
>>>>>
>>>>>   makes sense and is correct.  I'd just say I don't think that
>>>>> usage of "simulation" is very useful, and is DEFINITELY not what
>>>>> PO is talking about (so it would be wrong if applied PO's
>>>>> posts...)
>>>>>
>>>>> My use of "simulation" is broader: it's simply the activity
>>>>> performed by a TM which consists of calculating computation steps
>>>>> of some given computation.  As such it's just a part of the TM
>>>>> logic. A TM's typical use of simulation might be something like
>>>>> "..the TM simulates the computation for n steps, and if the
>>>>> simulation halts during those n steps, the TM [blah blah],
>>>>> /otherwise/ the TM [blah blah blah]...". Just about every
>>>>> reference in the literature I can recall is something like that.
>>>>>
>>>>> So... to be 100% clear on what I said:
>>>>>
>>>>> <copied from above>
>>>>>  >> A TM "aborting" a simulation is just the TM ceasing to
>>>>> calculate >> computation steps for some computation, and going on
>>>>> to calculate >> something else instead.
>>>>>
>>>>> E.g. in PO's P, after P aborts its simulation of P(P), the TM
>>>>> either halts or enters an infinite loop.  (That logic is not part
>>>>> of the simulation, IMO.)
>>>>>
>>>>>  >> It does *NOT* mean:
>>>>>  >> a)  that the TM (doing the simulation) has halted
>>>>>
>>>>> obviously, because now P has gone on to something else...
>>>>>
>>>>>  >> b)  that the simulated computation halts
>>>>>  >> c)  that the simulated computation never halts
>>>>>
>>>>> obviously - in general different exacmples of a simulated
>>>>> computation P(I) might halt or never halt, and this is unaffected
>>>>> by a simulator's decision to simulate no further computation
>>>>> steps. [The TM may have spotted some pattern in the simulated
>>>>> computation which implies P(I) never halts - that is a separate
>>>>> matter, but for sure the mere act of "aborting" the simulation
>>>>> doesn't imply P(I) never halts, or imply that it halts...
>>>>>
>>>>> Put yet another way, when a TM stops calculating TM steps (aka
>>>>> aborts its simulation), NOTHING HALTS: not the simulating TM, not
>>>>> the simulated computation, and NOT ANY PART OF EITHER OF THOSE.
>>>>> (Like you say, what would part of a TM halting mean?)
>>>>
>>>> I think of a TM and an input string as defining a sequence (an
>>>> ordered list). The elements of the sequence are pairs of a TM
>>>> state name and a string representing the "tape" contents when the
>>>> state was entered. Note that this view has no character of
>>>> animation in it and makes the definition of the halt predicate (H)
>>>> trivial:
>>>>
>>>> H(TM,STRING) = If length of TM(STRING) is finite then TRUE else
>>>> FALSE.
>>>
>>> Yes, that's equivalent to what I said (or at least meant).  Your
>>> sequence is my computation steps. Formally, these would be defined
>>> inductively via the rule to go from step n to step n+1.  (Not an
>>> animation, but the induction gives some /sense/ of step-by-step
>>> calculation, and a simulator will follow this, starting at step 1,
>>> then calculate step 2 and so on.  Still, I agree the entire
>>> sequence [the "computation"] exists as one timeless structure.  Too
>>> abstract for PO...)
>>
>> In other words when we make sure to conflate the program under test
>> with the test program as a single computation then the whole idea of
>> a halt decider becomes less coherent and
>
> I asserted that it is erroneous to conflate the decider with that which
> is being decided several months ago. No such conflation occurs in the
> HP proofs you are attempting to refute; it is your conflation which is
> erroneous.
>
> /Flibble
>

On 6/6/22 11:28 AM, olcott wrote:
> On 6/5/2022 11:17 PM, Richard Damon wrote:
>>
>> On 6/5/22 11:41 PM, olcott wrote:
>>> On 6/5/2022 10:26 PM, Richard Damon wrote:
>>>> On 6/5/22 11:03 PM, olcott wrote:
>>>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>>>>> <..snip..>>>
>>>>>>>>>>>> Sure.
>>>>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>>>>> something else. What is it doing while evaluating those 10
>>>>>>>>>>>> steps?
>>>>>>>>>>>
>>>>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>>>>> computation in order to compute certain properties of that
>>>>>>>>>> computation!  It's been around since Turing's days, and is
>>>>>>>>>> very useful.
>>>>>>>>>>
>>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>> That is true. I am apparently the first one that ever thought
>>>>>>>>> this through well enough so that machine descriptions matching
>>>>>>>>> the following pattern could be correctly determined to be
>>>>>>>>> non-halting:
>>>>>>>>>
>>>>>>>>>       For any program H that might determine if programs halt,
>>>>>>>>> a "pathological"
>>>>>>>>>       program P, called with some input, can pass its own
>>>>>>>>> source and its input to
>>>>>>>>>       H and then specifically do the opposite of what H
>>>>>>>>> predicts P will do. No H
>>>>>>>>>       can exist that handles this case.
>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>
>>>>>>>>> In that a partial simulation does correctly predict the
>>>>>>>>> behavior of a complete simulation it can be used to recognize
>>>>>>>>> infinite behavior patterns.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0,
>>>>>>>> which, by the DEFINITION of the requirements of the Halting
>>>>>>>> Problem, H(P,P) needs to accept (return 1) if P(P) Halts,
>>>>>>> This seems to be brand new computer science that I just discovered.
>>>>>>>
>>>>>>> Previously no one understood that it was possible for the correct
>>>>>>> simulation of the input to H(P,P) to be computationally distinct
>>>>>>> (thus not equivalent) to the direct execution of P(P).
>>>>>>
>>>>>> By what definition of "Correct" are you using?
>>>>>
>>>>>
>>>>> Ordinary software engineering proves that a correct and complete
>>>>> x86 emulation of the input to H(P,P) never reaches its "ret"
>>>>> instruction.
>>>>>
>>>>
>>>> So, I guess this just shows that you don't actually know a
>>>> definition that shows this, so this is just another of your lies.
>>>
>>> Ordinary software engineering proves that a correct and complete x86
>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>
>> Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
>> returns 0 that P(P) will halt.
>>
>> Good engineering NEVER contradicts actual facts.
>>
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its
>>> input that it must emulate the first seven instructions of P. Because
>>> the seventh instruction of P repeats this process we can know with
>>> complete certainty that the emulated P never reaches its final “ret”
>>> instruction, thus never halts.
>>>
>>
>> Maybe to you, but it is wrong (which might be why it is obvious to you).
>>
>
>
> Software engineers competent in C and the x86 language will verify that
> when H(P,P) correctly emulates its input with an x86 emulator that this
> emulation would never stop running. This provides the basis for H(P,P)
> to correctly reject its input as non-halting.

Yes, when H is actually defined to correctly emulate its input, which
means, BY DEFINITON, that it doesn't stop its emulation until it reaches
a final state, then it can be shown that this emulation never stops running.

This can NOT be used to show that any other H is correct to say that the
P built on that other H is non-halting, as it is a different program P,
as the program P includes the H that it is built on.

That you keep missing this fact speaks of your mental ability (or lack
thereof)

>
> > For any program H that might determine if programs  halt, a
> > "pathological" program P, called with some  input, can pass its own
> > source and its input to H and  then specifically do the opposite of
> > what H predicts P  will do. No H can exist that handles this case.
> > https://en.wikipedia.org/wiki/Halting_problem
>
> H determines the halt status of its input by watching the behavior of
> this input when it is correctly simulated by H using an x86 emulator.
> When H correctly matches an infinite behavior pattern it aborts the
> emulation of this input and returns 0.

Except that is can't see a full correctly simulation of its input, and
the partial simulation that it sees never shows an actual correctly
defined infinite behavior pattern, as can be proved by the fact that if
you include that in H, then P(P) for the P built on the H that includes
that pattern and returns 0 for H(P,P) will Halt, when the h that it
calls returns that answer.

You can't use the partial simulation that H used, as partial simulation
do not, by themselves, prove non-halting, and for a pattern to be
correctly determined to be non-halting, ALL programs that show that
pattern must be non-halting, but as described above ANY pattern that H
sees in its simulation of its input to H(P,P), if added to its list of
patterns to call non-halting, will produce a Halting P(P), and thus is
proved not to be correct.

>
>     #include <stdint.h>
>     #define u32 uint32_t
>
>     void P(u32 x)
>     {
>       if (H(x, x))
>         HERE: goto HERE;
>       return;
>     }
>
>     int main()
>     {
>       Output("Input_Halts = ", H((u32)P, (u32)P));
>     }
>
>     _P()
>     [00001352](01)  55              push ebp
>     [00001353](02)  8bec            mov ebp,esp
>     [00001355](03)  8b4508          mov eax,[ebp+08]
>     [00001358](01)  50              push eax      // push P
>     [00001359](03)  8b4d08          mov ecx,[ebp+08]
>     [0000135c](01)  51              push ecx      // push P
>     [0000135d](05)  e840feffff      call 000011a2 // call H
>     [00001362](03)  83c408          add esp,+08
>     [00001365](02)  85c0            test eax,eax
>     [00001367](02)  7402            jz 0000136b
>     [00001369](02)  ebfe            jmp 00001369
>     [0000136b](01)  5d              pop ebp
>     [0000136c](01)  c3              ret
>     Size in bytes:(0027) [0000136c]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>

On 6/7/2022 7:05 PM, Mike Terry wrote:
> On 07/06/2022 21:51, Mr Flibble wrote:
>> On Tue, 7 Jun 2022 15:34:13 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
> <..snip..>
>>>
>>> How many times do I have to say this before you notice that I said it
>>> at least once? H (in the current process) always creates a new
>>> process context to emulate its its input with an x86 emulator.
>>
>> I will have to take your word for it as you refuse to publish source
>> code. Why not just stick your project on GitHub? Open source is de
>> rigueur these days. What are you trying to hide?
>>
>> If a new process context is made then how is nested simulation
>> detected?
>
> The code in x86utm.exe (his emulator) that emulates individual
> instructions also updates a global trace table, making it accessible to
> the emulated code.  So every instruction and any (nested, nested(nested)
> etc.) simulated instructions ALL get merged together in this one global
> trace.
>
> I imagine the global trace table to be much like the printed traces that
> PO posts over and over.  If YOU can recognise some pattern in those
> printed traces, then logically H can spot that same pattern in the
> global trace, as the info in both cases is more or less the same.
>

When a UTM simulates TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description
that invokes a UTM that simulates a TM description

All of this whole process is data belongs to the first UTM, thus global
data is not needed and the whole process is a computable function of the
original inputs to the outermost UTM.

> [Above is my best guess, based on previous PO answers before you were
> interested.]
>
>> I assume the data segment of each process is private...
>
> PO said "new process context.." and that would imply each has its own
> address space, and that is obviously how simulation is SUPPOSED to work
> (like a TM would perform) - so your assumption is totally reasonable!

My unlimited nested simulations could not function properly if I did not
know all of the details of how to do this.

> But you've made the basic mistake of assuming PO knows what a "process"
> is - PO is not a software engineer or computer scientist, although he
> does his utmost to give that impression!
>
> Anyhow, each PO-simulation is like a single-stepped thread within a
> SINGLE shared address space, so any globals in his H are shared by all
> his "independent" simulations.
>
> [Above is based on previous PO answers before you were interested.]
>
> Mike.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/7/22 9:04 PM, olcott wrote:
> On 6/7/2022 7:05 PM, Mike Terry wrote:
>> On 07/06/2022 21:51, Mr Flibble wrote:
>>> On Tue, 7 Jun 2022 15:34:13 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>> <..snip..>
>>>>
>>>> How many times do I have to say this before you notice that I said it
>>>> at least once? H (in the current process) always creates a new
>>>> process context to emulate its its input with an x86 emulator.
>>>
>>> I will have to take your word for it as you refuse to publish source
>>> code. Why not just stick your project on GitHub? Open source is de
>>> rigueur these days. What are you trying to hide?
>>>
>>> If a new process context is made then how is nested simulation
>>> detected?
>>
>> The code in x86utm.exe (his emulator) that emulates individual
>> instructions also updates a global trace table, making it accessible
>> to the emulated code.  So every instruction and any (nested,
>> nested(nested) etc.) simulated instructions ALL get merged together in
>> this one global trace.
>>
>> I imagine the global trace table to be much like the printed traces
>> that PO posts over and over.  If YOU can recognise some pattern in
>> those printed traces, then logically H can spot that same pattern in
>> the global trace, as the info in both cases is more or less the same.
>>
>
> When a UTM simulates TM description
> that invokes a UTM that simulates a TM description

Nope, it invoke a copy of H that simulates its input and then abort is.

> that invokes a UTM that simulates a TM description
> that invokes a UTM that simulates a TM description
> that invokes a UTM that simulates a TM description

This appears to be a flaw in your whole system design, you P changes to
call as H whatever you try to use to simulate it.

P needs to call the H that this P is designed to refute, and no others.

Remember, You need to pick *A* H that you are going to claim is a
correct decider, then you make *A* P based on that one, and run the
descion and test on THOSE SPECIIFIC machines.

>
> All of this whole process is data belongs to the first UTM, thus global
> data is not needed and the whole process is a computable function of the
> original inputs to the outermost UTM.

????

The input to the UTM is a description of a P that calls the H that you
claim is correct in aborting its simulation of the P built on it.

That UTM will simulate that input and generate the exact same results as
running that P.

That emulation will show the first 7 instructions of P, then the call to
H, and then H doing its emulations and eventually aborting its emulaton
and returning the 0 to P and P halting.

If the H doesn't do this, then your H never answered H(P,P) as 0, and
your whole premise is false, and shown to be a LIE.

>
>> [Above is my best guess, based on previous PO answers before you were
>> interested.]
>>
>>> I assume the data segment of each process is private...
>>
>> PO said "new process context.." and that would imply each has its own
>> address space, and that is obviously how simulation is SUPPOSED to
>> work (like a TM would perform) - so your assumption is totally
>> reasonable!
>
> My unlimited nested simulations could not function properly if I did not
> know all of the details of how to do this.

Then why do you think the UTM sees another UTM when it should see an H.

Remember, your LIE that the test was to REPLACE H with a UTM has been
discredited, or are you still claiming that is what needs to be done,
even though it doesn't match the test you define?

Or, do you not understand that the representation of P includes
EVERYTHING needed to run it, and thus does include the copy of H that it
calls, so it doesn't change when we give that input to the UTM?

>
>> But you've made the basic mistake of assuming PO knows what a
>> "process" is - PO is not a software engineer or computer scientist,
>> although he does his utmost to give that impression!
>>
>> Anyhow, each PO-simulation is like a single-stepped thread within a
>> SINGLE shared address space, so any globals in his H are shared by all
>> his "independent" simulations.
>>
>> [Above is based on previous PO answers before you were interested.]
>>
>> Mike.
>
>