Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Detecting infinite recursion
78 views
Skip to first unread message
olcott
Feb 26, 2021, 2:53:48 PM2/26/21
to
(1) We know that every software function invoked with the same data must
have the same execution trace.
(2) When a software function invokes itself this is recursive invocation.
(3) When the second recursive invocation of a software function calls
itself with the same data as the prior invocation then it must have the
same execution trace as the prior invocation.
(4) When the second recursive invocation of a software function calls
itself with the same data has no conditional branch instructions
inbetween these two invocations then this is a case of infinite recursion.
(5) When the recursive invocation is replaced with a call to a software
system that simulates the execution of the calling function with its
same data, then this is equivalent to a recursive invocation.
// P has address of H_Hat
void H_Hat(u32 P)
{
Simulate(P, P);
}
Does everyone agree?
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
have the same execution trace.
(2) When a software function invokes itself this is recursive invocation.
(3) When the second recursive invocation of a software function calls
itself with the same data as the prior invocation then it must have the
same execution trace as the prior invocation.
(4) When the second recursive invocation of a software function calls
itself with the same data has no conditional branch instructions
inbetween these two invocations then this is a case of infinite recursion.
(5) When the recursive invocation is replaced with a call to a software
system that simulates the execution of the calling function with its
same data, then this is equivalent to a recursive invocation.
// P has address of H_Hat
void H_Hat(u32 P)
{
Simulate(P, P);
}
Does everyone agree?
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Siri Cruise
Feb 26, 2021, 3:48:39 PM2/26/21
to
In article <3LadneKdoK8jzKT9...@giganews.com>,
olcott <No...@NoWhere.com> wrote:
> Does everyone agree?
P = \a.P(succ(a))
P 0
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
When does a recursion use the same data?
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed
olcott <No...@NoWhere.com> wrote:
> Does everyone agree?
P = \a.P(succ(a))
P 0
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed
Mr Flibble
Feb 26, 2021, 4:37:43 PM2/26/21
to
On 26/02/2021 19:53, olcott wrote:
> (1) We know that every software function invoked with the same data must have
> the same execution trace.
>
> (2) When a software function invokes itself this is recursive invocation.
>
> (3) When the second recursive invocation of a software function calls itself
> with the same data as the prior invocation then it must have the same execution
> trace as the prior invocation.
>
> (4) When the second recursive invocation of a software function calls itself
> with the same data has no conditional branch instructions inbetween these two
> invocations then this is a case of infinite recursion.
>
> (5) When the recursive invocation is replaced with a call to a software system
> that simulates the execution of the calling function with its same data, then
> this is equivalent to a recursive invocation.
>
> // P has address of H_Hat
> void H_Hat(u32 P)
> {
> Simulate(P, P);
> }
>
> Does everyone agree?
No.
> (1) We know that every software function invoked with the same data must have
> the same execution trace.
>
> (2) When a software function invokes itself this is recursive invocation.
>
> (3) When the second recursive invocation of a software function calls itself
> with the same data as the prior invocation then it must have the same execution
> trace as the prior invocation.
>
> (4) When the second recursive invocation of a software function calls itself
> with the same data has no conditional branch instructions inbetween these two
> invocations then this is a case of infinite recursion.
>
> (5) When the recursive invocation is replaced with a call to a software system
> that simulates the execution of the calling function with its same data, then
> this is equivalent to a recursive invocation.
>
> // P has address of H_Hat
> void H_Hat(u32 P)
> {
> Simulate(P, P);
> }
>
> Does everyone agree?
(-1) In general for an algorithm or program to perform useful work its functions
contain branching logic.
(0) Only pure functions may not modify mutable state.
...
(6) ???
(7) ???
(8) ???
...
(???) ???
...
/Flibble
--
😎
Siri Cruise
Feb 26, 2021, 6:27:00 PM2/26/21
to
In article <tSd_H.261436$Wue5....@fx13.ams4>,
goldbachsum(n, 2, 2) -> goldbach(n+2);
true -> halt
]
goldbachsum = \n,r,s. [
r>=n -> false;
not prime(r, 2) -> goldbachsum(n, r+1, 2);
not prime(s, 2) -> goldbachsum(n, r, s+1);
r+s>n -> goldbachsum(n, r+1, 2);
r+s<n -> goldbachsum(n, r, s+1);
r+s=n -> true;
]
prime = \n,r.[
r*r>n -> true;
n mod r=0 -> false;
true -> prime(n, r+1)
]
Prove goldbach(2) halts or never halts and you win a Hero of the
Mathematics badge.
Mr Flibble <fli...@i42.REMOVETHISBIT.co.uk> wrote:
> (-1) In general for an algorithm or program to perform useful work its
> functions
> contain branching logic.
>
> (0) Only pure functions may not modify mutable state.
goldbach = \n.[
> (-1) In general for an algorithm or program to perform useful work its
> functions
> contain branching logic.
>
> (0) Only pure functions may not modify mutable state.
goldbachsum(n, 2, 2) -> goldbach(n+2);
true -> halt
]
goldbachsum = \n,r,s. [
r>=n -> false;
not prime(r, 2) -> goldbachsum(n, r+1, 2);
not prime(s, 2) -> goldbachsum(n, r, s+1);
r+s>n -> goldbachsum(n, r+1, 2);
r+s<n -> goldbachsum(n, r, s+1);
r+s=n -> true;
]
prime = \n,r.[
r*r>n -> true;
n mod r=0 -> false;
true -> prime(n, r+1)
]
Prove goldbach(2) halts or never halts and you win a Hero of the
Mathematics badge.
Kaz Kylheku
Feb 26, 2021, 8:59:05 PM2/26/21
to
On 2021-02-26, olcott <No...@NoWhere.com> wrote:
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
>
> (2) When a software function invokes itself this is recursive invocation.
>
> (3) When the second recursive invocation of a software function calls
> itself with the same data as the prior invocation then it must have the
> same execution trace as the prior invocation.
>
> (4) When the second recursive invocation of a software function calls
> itself with the same data has no conditional branch instructions
> inbetween these two invocations then this is a case of infinite recursion.
>
> (5) When the recursive invocation is replaced with a call to a software
> system that simulates the execution of the calling function with its
> same data, then this is equivalent to a recursive invocation.
>
> // P has address of H_Hat
> void H_Hat(u32 P)
> {
> Simulate(P, P);
> }
>
> Does everyone agree?
If Simulate(P, P) replaces P(P), and the simulation is a faithful
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
>
> (2) When a software function invokes itself this is recursive invocation.
>
> (3) When the second recursive invocation of a software function calls
> itself with the same data as the prior invocation then it must have the
> same execution trace as the prior invocation.
>
> (4) When the second recursive invocation of a software function calls
> itself with the same data has no conditional branch instructions
> inbetween these two invocations then this is a case of infinite recursion.
>
> (5) When the recursive invocation is replaced with a call to a software
> system that simulates the execution of the calling function with its
> same data, then this is equivalent to a recursive invocation.
>
> // P has address of H_Hat
> void H_Hat(u32 P)
> {
> Simulate(P, P);
> }
>
> Does everyone agree?
replica of the processor, then nothing has changed.
You have previosuly written about a scheme in which Simulate
contains provisions for monitoring the execution. An outer Simulate has
instruction stream information from all inner Simulate calls and is able
to impose the rule that the simulation will only go to some fixed number
of levels, like 3. Let's call that N.
Firstly, what that does is change H_Hat: H_Hat is no longer infinitely
recursive, because Simulate detects an internal halting condition and
stops.
Secondly, the different recursion levels of H_Hat are not equivalent
to each other.
The outer-most H_Hat goes to N levels of recursion/simulation nesting.
The next lower nesting, though ostensibly executing the same logic,
only has N-1 remaining levels available to it before it will be
terminated.
The one after that N-2.
A function that terminates after U nestings is not the same function
as a similar one which terminates after V nestings, for U != V.
We must treat each H_Hat invocation at every nesting level i as a
different function H_Hat_i.
--
TXR Programming Language: http://nongnu.org/txr
Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal
Jeff Barnett
Feb 26, 2021, 11:32:23 PM2/26/21
to
On 2/26/2021 12:53 PM, olcott wrote:
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
>
> (2) When a software function invokes itself this is recursive invocation.
>
> (3) When the second recursive invocation of a software function calls
> itself with the same data as the prior invocation then it must have the
> same execution trace as the prior invocation.
>
> (4) When the second recursive invocation of a software function calls
> itself with the same data has no conditional branch instructions
> inbetween these two invocations then this is a case of infinite recursion.
>
> (5) When the recursive invocation is replaced with a call to a software
> system that simulates the execution of the calling function with its
> same data, then this is equivalent to a recursive invocation.
>
> // P has address of H_Hat
> void H_Hat(u32 P)
> {
> Simulate(P, P);
> }
>
> Does everyone agree?
You took off all of this time to come up with this. Remember when you
> (1) We know that every software function invoked with the same data must
> have the same execution trace.
>
> (2) When a software function invokes itself this is recursive invocation.
>
> (3) When the second recursive invocation of a software function calls
> itself with the same data as the prior invocation then it must have the
> same execution trace as the prior invocation.
>
> (4) When the second recursive invocation of a software function calls
> itself with the same data has no conditional branch instructions
> inbetween these two invocations then this is a case of infinite recursion.
>
> (5) When the recursive invocation is replaced with a call to a software
> system that simulates the execution of the calling function with its
> same data, then this is equivalent to a recursive invocation.
>
> // P has address of H_Hat
> void H_Hat(u32 P)
> {
> Simulate(P, P);
> }
>
> Does everyone agree?
were pooping in the Lisp group without a clue of what you were talking
about or knowledge of any modern Lisp? Disgraceful! Consider a function
which accesses a variable bound outside its scope - there are many
variations here and this is why you should have learned some Lisp
instead of just pooping. Then the above is incorrect. Of course you have
something different in mind but are making a pig of terminology. Above
you say "software" function and that is what I'm talking about. If you
mean "mathematical" function, well do you remember the definition of a
mathematical function? In this case, you are correct but that has little
or nothing to do with software. I suggest another hiatus for you but
make it longer this time. Much longer.
--
Jeff Barnett
olcott
Feb 28, 2021, 2:08:50 PM2/28/21
to
On 2/28/2021 11:20 AM, Mr Flibble wrote:
> On 28/02/2021 16:34, olcott wrote:
>> On 2/28/2021 10:26 AM, Mr Flibble wrote:
>>> On 28/02/2021 14:34, olcott wrote:
>>>> On 2/28/2021 8:24 AM, Mr Flibble wrote:
>>>>> On 28/02/2021 04:10, olcott wrote:
>>>>>> By 35 years of software engineering I know that things are much
>>>>>> more easily understood at very high level abstractions and when
>>>>>> you present a myriad of details then things become utterly
>>>>>> incomprehensible.
>>>>>
>>>>> No, we want an implementation which WE can feed input (program and
>>>>> data) of OUR choosing in order to test YOUR claims. You won't do
>>>>> this because you know it doesn't work. You are selling snake oil,
>>>>> nothing more.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> As soon as it is universally agreed that I am hypothetically correct
>>>> then I will provide access to the system. If it is universally
>>>> agreed that within my assumptions H_Hat would be correctly decided
>>>> and this refutes the halting problem proofs then I will provide
>>>> access to my system.
>>>
>>> Why do we have to wait? What are you hiding? Are you hiding that you
>>> only have snake oil?
>>>
>>> /Flibble
>>>
>>
>> You have to wait primarily to provide the incentive for a thorough
>> review. Most people here have already rejected what I have said
>> out-of-hand without review. The rest rejected what I have said on the
>> basis of false assumptions that they were not ever aware were
>> assumptions.
>
> Part of the problem is what you post to these newsgroups is ambiguous
> and open to interpretation. Code is not open to interpretation and if we
> could run your implementation we could validate your claims ourselves.
> Publish now please unless of course you only have snake oil, which seems
> to be the case.
>
> /Flibble
>
This instance of H_Hat() is proved to be decidable and all the code is
provided. This H_Hat() calls Simulate() that returns true whenever its
input halts.
int Simulate(u32 P, u32 I)
{
((void(*)(int))P)(I);
return 1;
}
// P has the machine address of H_Hat()
void H_Hat(u32 P)
{
u32 Input_Halts = Simulate(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
_Simulate()
[00000478](01) 55 push ebp
[00000479](02) 8bec mov ebp,esp
[0000047b](03) 8b450c mov eax,[ebp+0c]
[0000047e](01) 50 push eax
[0000047f](03) ff5508 call dword [ebp+08]
[00000482](03) 83c404 add esp,+04
[00000485](05) b801000000 mov eax,00000001
[0000048a](01) 5d pop ebp
[0000048b](01) c3 ret
_H_Hat()
[00000858](01) 55 push ebp
[00000859](02) 8bec mov ebp,esp
[0000085b](01) 51 push ecx
[0000085c](03) 8b4508 mov eax,[ebp+08]
[0000085f](01) 50 push eax
[00000860](03) 8b4d08 mov ecx,[ebp+08]
[00000863](01) 51 push ecx
[00000864](05) e80ffcffff call 00000478
[00000869](03) 83c408 add esp,+08
[0000086c](03) 8945fc mov [ebp-04],eax
[0000086f](04) 837dfc00 cmp dword [ebp-04],+00
[00000873](02) 7402 jz 00000877
[00000875](02) ebfe jmp 00000875
[00000877](02) 8be5 mov esp,ebp
[00000879](01) 5d pop ebp
[0000087a](01) c3 ret
Because the execution trace shown below shows that H_Hat() invokes
Simulate() with the same data two times in sequence we can conclude that
H_Hat() is invoked in infinite recursion.
Push instructions have already pushed the value shown in their in the
third column. The two push instructions preceding the call to Simulate()
are its second and first parameters respectively.
Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Number of bytes of machine code
(5) Machine language bytes
(6) Assembly language text
...[00000858][000111c5][000111d1](01) 55 push ebp
...[00000859][000111c5][000111d1](02) 8bec mov ebp,esp
...[0000085b][000111c1][00000000](01) 51 push ecx
...[0000085c][000111c1][00000000](03) 8b4508 mov eax,[ebp+08]
...[0000085f][000111bd][00000858](01) 50 push eax
...[00000860][000111bd][00000858](03) 8b4d08 mov ecx,[ebp+08]
...[00000863][000111b9][00000858](01) 51 push ecx
; Call Simulate(0x858, 0x858);
...[00000864][000111b5][00000869](05) e80ffcffff call 00000478
...[00000858][000111a5][000111b1](01) 55 push ebp
...[00000859][000111a5][000111b1](02) 8bec mov ebp,esp
...[0000085b][000111a1][00000858](01) 51 push ecx
...[0000085c][000111a1][00000858](03) 8b4508 mov eax,[ebp+08]
...[0000085f][0001119d][00000858](01) 50 push eax
...[00000860][0001119d][00000858](03) 8b4d08 mov ecx,[ebp+08]
...[00000863][00011199][00000858](01) 51 push ecx
; Call Simulate(0x858, 0x858);
...[00000864][00011195][00000869](05) e80ffcffff call 00000478
> On 28/02/2021 16:34, olcott wrote:
>> On 2/28/2021 10:26 AM, Mr Flibble wrote:
>>> On 28/02/2021 14:34, olcott wrote:
>>>> On 2/28/2021 8:24 AM, Mr Flibble wrote:
>>>>> On 28/02/2021 04:10, olcott wrote:
>>>>>> By 35 years of software engineering I know that things are much
>>>>>> more easily understood at very high level abstractions and when
>>>>>> you present a myriad of details then things become utterly
>>>>>> incomprehensible.
>>>>>
>>>>> No, we want an implementation which WE can feed input (program and
>>>>> data) of OUR choosing in order to test YOUR claims. You won't do
>>>>> this because you know it doesn't work. You are selling snake oil,
>>>>> nothing more.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> As soon as it is universally agreed that I am hypothetically correct
>>>> then I will provide access to the system. If it is universally
>>>> agreed that within my assumptions H_Hat would be correctly decided
>>>> and this refutes the halting problem proofs then I will provide
>>>> access to my system.
>>>
>>> Why do we have to wait? What are you hiding? Are you hiding that you
>>> only have snake oil?
>>>
>>> /Flibble
>>>
>>
>> You have to wait primarily to provide the incentive for a thorough
>> review. Most people here have already rejected what I have said
>> out-of-hand without review. The rest rejected what I have said on the
>> basis of false assumptions that they were not ever aware were
>> assumptions.
>
> Part of the problem is what you post to these newsgroups is ambiguous
> and open to interpretation. Code is not open to interpretation and if we
> could run your implementation we could validate your claims ourselves.
> Publish now please unless of course you only have snake oil, which seems
> to be the case.
>
> /Flibble
>
This instance of H_Hat() is proved to be decidable and all the code is
provided. This H_Hat() calls Simulate() that returns true whenever its
input halts.
int Simulate(u32 P, u32 I)
{
((void(*)(int))P)(I);
return 1;
}
// P has the machine address of H_Hat()
void H_Hat(u32 P)
{
u32 Input_Halts = Simulate(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
_Simulate()
[00000478](01) 55 push ebp
[00000479](02) 8bec mov ebp,esp
[0000047b](03) 8b450c mov eax,[ebp+0c]
[0000047e](01) 50 push eax
[0000047f](03) ff5508 call dword [ebp+08]
[00000482](03) 83c404 add esp,+04
[00000485](05) b801000000 mov eax,00000001
[0000048a](01) 5d pop ebp
[0000048b](01) c3 ret
_H_Hat()
[00000858](01) 55 push ebp
[00000859](02) 8bec mov ebp,esp
[0000085b](01) 51 push ecx
[0000085c](03) 8b4508 mov eax,[ebp+08]
[0000085f](01) 50 push eax
[00000860](03) 8b4d08 mov ecx,[ebp+08]
[00000863](01) 51 push ecx
[00000864](05) e80ffcffff call 00000478
[00000869](03) 83c408 add esp,+08
[0000086c](03) 8945fc mov [ebp-04],eax
[0000086f](04) 837dfc00 cmp dword [ebp-04],+00
[00000873](02) 7402 jz 00000877
[00000875](02) ebfe jmp 00000875
[00000877](02) 8be5 mov esp,ebp
[00000879](01) 5d pop ebp
[0000087a](01) c3 ret
Because the execution trace shown below shows that H_Hat() invokes
Simulate() with the same data two times in sequence we can conclude that
H_Hat() is invoked in infinite recursion.
Push instructions have already pushed the value shown in their in the
third column. The two push instructions preceding the call to Simulate()
are its second and first parameters respectively.
Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Number of bytes of machine code
(5) Machine language bytes
(6) Assembly language text
...[00000858][000111c5][000111d1](01) 55 push ebp
...[00000859][000111c5][000111d1](02) 8bec mov ebp,esp
...[0000085b][000111c1][00000000](01) 51 push ecx
...[0000085c][000111c1][00000000](03) 8b4508 mov eax,[ebp+08]
...[0000085f][000111bd][00000858](01) 50 push eax
...[00000860][000111bd][00000858](03) 8b4d08 mov ecx,[ebp+08]
...[00000863][000111b9][00000858](01) 51 push ecx
; Call Simulate(0x858, 0x858);
...[00000864][000111b5][00000869](05) e80ffcffff call 00000478
...[00000858][000111a5][000111b1](01) 55 push ebp
...[00000859][000111a5][000111b1](02) 8bec mov ebp,esp
...[0000085b][000111a1][00000858](01) 51 push ecx
...[0000085c][000111a1][00000858](03) 8b4508 mov eax,[ebp+08]
...[0000085f][0001119d][00000858](01) 50 push eax
...[00000860][0001119d][00000858](03) 8b4d08 mov ecx,[ebp+08]
...[00000863][00011199][00000858](01) 51 push ecx
; Call Simulate(0x858, 0x858);
...[00000864][00011195][00000869](05) e80ffcffff call 00000478
Kaz Kylheku
Feb 28, 2021, 10:52:28 PM2/28/21
to
On 2021-02-28, olcott <No...@NoWhere.com> wrote:
> This instance of H_Hat() is proved to be decidable and all the code is
> provided. This H_Hat() calls Simulate() that returns true whenever its
> input halts.
Your eyes keep slipping off the carrot every once in a short while.
> This instance of H_Hat() is proved to be decidable and all the code is
> provided. This H_Hat() calls Simulate() that returns true whenever its
> input halts.
What's not decidable is universal halting, not any one specific program
and its input.
Any method by which you can decide a specific program and its input will
also work for some other programs/inputs, but not all of them.
olcott
Mar 1, 2021, 10:32:48 PM3/1/21
to
On 3/1/2021 9:05 PM, olcott wrote:
> On 3/1/2021 8:22 PM, Mike Terry wrote:
>> On 02/03/2021 01:31, olcott wrote:
>>> On 3/1/2021 7:00 PM, Mike Terry wrote:
>>>> On 01/03/2021 23:00, olcott wrote:
>>>>> On 3/1/2021 4:42 PM, Mike Terry wrote:
>>>>>> On 01/03/2021 20:22, olcott wrote:
>>>>>>> On 3/1/2021 1:39 PM, Kaz Kylheku wrote:
>>>>>>>> On 2021-03-01, olcott <No...@NoWhere.com> wrote:
>>>>>>>>> On 3/1/2021 12:25 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2021-03-01, olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>> On 3/1/2021 10:52 AM, Kaz Kylheku wrote:
>>>>>>>>>>> I already acknowledged this. When an equivalent computation
>>>>>>>>>>> is run on a
>>>>>>>>>>> machine without resource limits (such as a TM) then this
>>>>>>>>>>> computation is
>>>>>>>>>>> infinitely recursive.
>>>>>>>>>>
>>>>>>>>>> That depends on what you mean by "equivalent". Since you have
>>>>>>>>>> tied the
>>>>>>>>>> validity your work to the x86 representation, a Turing Machine
>>>>>>>>>> version
>>>>>>>>>> of your program, to be equivalent, has to contain the x86
>>>>>>>>>> program, and
>>>>>>>>>> the simulator, faithfully reproducing the same resource
>>>>>>>>>> limitations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A RASP machine is known to be equivalent to a UTM.
>>>>>>>>>
>>>>>>>>> Thus the RASP is to the RAM as the Universal Turing machine is
>>>>>>>>> to the
>>>>>>>>> Turing machine. The RASP is an example of the von Neumann
>>>>>>>>> architecture.
>>>>>>>>> https://en.wikipedia.org/wiki/Random-access_stored-program_machine
>>>>>>>>>
>>>>>>>>> The x86 language is another exapmle of the von Neumann
>>>>>>>>> architecture.
>>>>>>>>> All computations implemented using the von Neumann architecture
>>>>>>>>> are
>>>>>>>>> equivalent to one another as long as they do not require more
>>>>>>>>> memory
>>>>>>>>> than is available.
>>>>>>>>>
>>>>>>>>> Thus all computations implemented using the von Neumann
>>>>>>>>> architecture are
>>>>>>>>> equivalent UTM computations as long as they do not require more
>>>>>>>>> memory
>>>>>>>>> than is available.
>>>>>>>>
>>>>>>>> That is true; but an infinite recursion does require
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> When I say that the x86 emulator: Simulate() is functionally
>>>>>>>>>>> equivalent
>>>>>>>>>>> to this code:
>>>>>>>>>>> x86 emulator.
>>>>>>>>>>
>>>>>>>>>> Yes; then clearly, the H_Hat(P, P) call (with the right casts
>>>>>>>>>> put in)
>>>>>>>>>> denotes a runaway recursive call.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So we agree on this point?
>>>>>>>>
>>>>>>>> Why wouldn't we? It's obviously a runaway recursive call.
>>>>>>>>
>>>>>>>>> When we know that Simulate() is an x86 emulator that is
>>>>>>>>> functionally
>>>>>>>>> equivalent to direct execution of its input then from the
>>>>>>>>> execution
>>>>>>>>> trace of the execution of this input (including the inputs to
>>>>>>>>> functions
>>>>>>>>> stored on the stack) alone we can decide that H_Hat() is
>>>>>>>>> infinitely
>>>>>>>>> recursive.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> In a static call graph of a program, we can spot loops.
>>>>>>>>
>>>>>>>> For instance a simple infinite loop occurs when a basic block
>>>>>>>> jumps to
>>>>>>>> itself.
>>>>>>>>
>>>>>>>> A basic block has no branching instructions anywhere, except as
>>>>>>>> possibly
>>>>>>>> the last instruction. If that last instruction is an
>>>>>>>> unconditional jump
>>>>>>>> back to that block, that is an infinite loop.
>>>>>>>>
>>>>>>>> Compilers do this kind of control flow analysis to find loops,
>>>>>>>> where certain optimizations can be concentrated (e.g. giving more
>>>>>>>> registers to variables in nested loops).
>>>>>>>>
>>>>>>>> If we monitor the execution dynamically, we can likewise identify
>>>>>>>> "dynamic basic blocks" sequences of unconditionally executed
>>>>>>>> instructions with no branches, and we can detect infinite loops.
>>>>>>>> (Possibly ones that contain a stack push, if the jump is actually
>>>>>>>> a subroutine call.)
>>>>>>>>
>>>>>>>> If we simply identify the situation, but don't interfere in it,
>>>>>>>> then the
>>>>>>>> situation persists: there is runaway recursion.
>>>>>>>>
>>>>>>>
>>>>>>> When this same simulator monitors its own simulation it could
>>>>>>> figure out that the H_Hat() invocation of itself is infinitely
>>>>>>> recursive.
>>>>>>>
>>>>>>
>>>>>> I'm afraid that's "wrong-headed" thinking, because Simulate simply
>>>>>> DOES NOT monitor its own simulation, so you can't talk about when
>>>>>> it does something IT DOESN'T DO. :) The same mental confusion
>>>>>> underlies your ".. /would/ fail to terminate /if/ ABNHBD() didn't
>>>>>> abort the emulation", and other anthropomorphisms you make for TMs.
>>>>>>
>>>>>
>>>>> So in other words you cannot possibly begin to imagine that a
>>>>> software function could be adapted to add functionality.
>>>>>
>>>>>> /We/ can figure out that the above H_Hat is infinitely recursive,
>>>>>> but /we/ are not Simulate, so H_Hat is not our "We_hat", and this
>>>>>> says nothing about the Linz proof.
>>>>>>
>>>>>> The /Simulate/ as you've described it (pure emulation) /cannot/
>>>>>> "figure it out", because it fails to return and so doesn't
>>>>>> "figure" anything. Again, nothing much to say re HP proof.
>>>>>>
>>>>>> We could code a /new/ emulator routine Simulate2 (distinct from
>>>>>> H_Hat and Simulate above) which has monitoring logic, and use it
>>>>>> to examine a simulation of the H_Hat above calling Simulate(H_Hat)
>>>>>> (note: NOT calling Simulate2...), and this Simulate2 could
>>>>>> correctly decide that H_Hat(H_Hat) does not terminate.
>>>>>>
>>>>>> But H_Hat is not the "hatted" machine for Simulate2, so this also
>>>>>> is of little interest. Nobody claims that "no decider can
>>>>>> correctly decide halting for H_Hat", only that H does not
>>>>>> correctly decide halting for its own H_Hat.
>>>>>>
>>>>>> If we "update" H_Hat so that instead of calling Simulate, it calls
>>>>>> the new Simulate2, then we have a /new/ program H_Hat2, and a
>>>>>> /new/ calculation to consider. When H_Hat2 examines the
>>>>>> calculation H_Hat2(H_Hat2), with H_Hat2 calling Simulate2 etc.,
>>>>>> then H_Hat2 /*cannot*/ "figure out" that the calculation has
>>>>>> infinite recursion, BECAUSE IT DOESN'T. It can certainly /decide/
>>>>>> that H_Hat2 is infinitely recursive, but that would just be
>>>>>> Simulate2 deciding incorrectly. All in line with Linz proof.
>>>>>>
>>>>>> Remember, Simulate2 is not a "pure emulator" like Simulate, so the
>>>>>> fact that there may be two nested emulated calls to Simulate2 with
>>>>>> the same argument IS NOT PROOF OF INFINITE RECURSION.
>>>>>
>>>>> When Simulate2() is identical to Simulate() in every way except
>>>>> that it also examines the execution trace of its input to figure
>>>>> out that its input is calling Simulate2() in infinite recursion
>>>>> then by logical necessity H_Hat() is still infinitely recursive.
>>>>
>>>> ?
>>>>
>>>> H_Hat doesn't call Simulate2. Maybe you mean H_Hat2 ?
>>>>
>>>> Obviously the /H_Hat/ calculation is "still" infinitely recursive,
>>>> because that calculation has never changed - by definition it calls
>>>> Simulate (not Simulate2).
>>>>
>>>> Hmm, your phrase "figuring out" isn't a standard CS term - I've
>>>> guessed it to mean that Simulate2 returns some different rc (not 1)
>>>> when it detects the nested calls to Simulate2 with the same input
>>>> data, thus making a different decision to the rc=1 [halts] decision.
>>>> Maybe you mean something else?
>>>>
>>>>
>>>> Mike.
>>>>
>> >
>>> An x86 emulator could keep track of all of the details of the
>>> execution trace of any input. If the original Simulate() was adapted
>>> to have this feature and the names remain the same then H_Hat() would
>>> invoke this updated version of Simulate() and still be infinitely
>>> recursive.
>>
>> So was my guess right? Does "figuring out" mean that Simulate2
>> returns some different rc (not 1) when it detects the nested calls to
>> Simulate2 with the same input data, thus making a different decision
>> to the rc=1 [halts] decision? All you've done is replace "figuring
>> out" with "keep track of" which is no better.
>>
>>>
>>> When software engineers add features to existing functions they do
>>> not change the names.
>>
>> What they do is change the versions. But you are not a software
>> engineer, so maybe you don't know about version numbers.
>>
>> Software engineers use version control systems so that if required
>> they can recreate the software at whatever point in the development
>> cycle is required, so there will not be confusion over what code is
>> being used/discussed at any time.
>>
>
> This is the version number of the whole system at that point in time. I
> worked on defense projects using version control. The function almost
> always keep their original names and merely acquire additional
> functionality.
>
>> In contrast, /you/ habitually use the same name for different
>> programs, and different names for the same programs. I suspect this
>> is because in part your arguments rely on confusing different programs
>> as being the same thing, in various ways. So it seems to me that you
>> do this deliberately. This is the exact opposite to how a software
>> engineer or professional programmer would behave.
>>
>
> There are only three programs that I will be talking about:
> gradually be adapted step-by-step until it becomes Halts(P, P).
>
> There will not be any version numbers for Simulate() because Simulate()
> is merely a conversational convention used to construct complete
> understanding of Halts() in small incremental steps.
>
>
>> If it is not deliberate, I suggest you just affix versions to the end
>> of your programs e.g. "H_Hat2" when they change. That's easier than
>> full versions, e.g. "H_Hat (V2.1.0.0)" and more appropriate for
>> newsgroup discussions.
>>
>>
>> Mike.
int Simulate_1(u32 P, u32 I);
Emulates the x86 code pointed to by machine address P with data at
machine address I.
int Simulate_2(u32 P, u32 I);
Same as Simulate_1() except keeps track of the execution trace of its
input including the data passed to any function invocations.
int Simulate_3(u32 P, u32 I);
Same as Simulate_2() except examines the saved execution trace
immediately after emulating each x86 language instruction to determine
whether or not this input specifies infinite recursion.
It should be self-evident that whenever any of these versions is
substituted into the body of H_Hat() that H_Hat() remains infinitely
recursive.
It should be self-evident that Simulate_3() can easily determine the
infinite recursion of H_Hat() on the basis its execution trace.
> On 3/1/2021 8:22 PM, Mike Terry wrote:
>> On 02/03/2021 01:31, olcott wrote:
>>> On 3/1/2021 7:00 PM, Mike Terry wrote:
>>>> On 01/03/2021 23:00, olcott wrote:
>>>>> On 3/1/2021 4:42 PM, Mike Terry wrote:
>>>>>> On 01/03/2021 20:22, olcott wrote:
>>>>>>> On 3/1/2021 1:39 PM, Kaz Kylheku wrote:
>>>>>>>> On 2021-03-01, olcott <No...@NoWhere.com> wrote:
>>>>>>>>> On 3/1/2021 12:25 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2021-03-01, olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>> On 3/1/2021 10:52 AM, Kaz Kylheku wrote:
>>>>>>>>>>> I already acknowledged this. When an equivalent computation
>>>>>>>>>>> is run on a
>>>>>>>>>>> machine without resource limits (such as a TM) then this
>>>>>>>>>>> computation is
>>>>>>>>>>> infinitely recursive.
>>>>>>>>>>
>>>>>>>>>> That depends on what you mean by "equivalent". Since you have
>>>>>>>>>> tied the
>>>>>>>>>> validity your work to the x86 representation, a Turing Machine
>>>>>>>>>> version
>>>>>>>>>> of your program, to be equivalent, has to contain the x86
>>>>>>>>>> program, and
>>>>>>>>>> the simulator, faithfully reproducing the same resource
>>>>>>>>>> limitations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A RASP machine is known to be equivalent to a UTM.
>>>>>>>>>
>>>>>>>>> Thus the RASP is to the RAM as the Universal Turing machine is
>>>>>>>>> to the
>>>>>>>>> Turing machine. The RASP is an example of the von Neumann
>>>>>>>>> architecture.
>>>>>>>>> https://en.wikipedia.org/wiki/Random-access_stored-program_machine
>>>>>>>>>
>>>>>>>>> The x86 language is another exapmle of the von Neumann
>>>>>>>>> architecture.
>>>>>>>>> All computations implemented using the von Neumann architecture
>>>>>>>>> are
>>>>>>>>> equivalent to one another as long as they do not require more
>>>>>>>>> memory
>>>>>>>>> than is available.
>>>>>>>>>
>>>>>>>>> Thus all computations implemented using the von Neumann
>>>>>>>>> architecture are
>>>>>>>>> equivalent UTM computations as long as they do not require more
>>>>>>>>> memory
>>>>>>>>> than is available.
>>>>>>>>
>>>>>>>> That is true; but an infinite recursion does require
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> When I say that the x86 emulator: Simulate() is functionally
>>>>>>>>>>> equivalent
>>>>>>>>>>> to this code:
>>>>>>>>>>>
>>>>>>>>>>> int Simulate(u32 P, u32 I)
>>>>>>>>>>> {
>>>>>>>>>>> ((void(*)(int))P)(I);
>>>>>>>>>>> return 1;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> That is all that need be said about the capabilities of the
>>>>>>>>>>> int Simulate(u32 P, u32 I)
>>>>>>>>>>> {
>>>>>>>>>>> ((void(*)(int))P)(I);
>>>>>>>>>>> return 1;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> x86 emulator.
>>>>>>>>>>
>>>>>>>>>> Yes; then clearly, the H_Hat(P, P) call (with the right casts
>>>>>>>>>> put in)
>>>>>>>>>> denotes a runaway recursive call.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So we agree on this point?
>>>>>>>>
>>>>>>>> Why wouldn't we? It's obviously a runaway recursive call.
>>>>>>>>
>>>>>>>>> When we know that Simulate() is an x86 emulator that is
>>>>>>>>> functionally
>>>>>>>>> equivalent to direct execution of its input then from the
>>>>>>>>> execution
>>>>>>>>> trace of the execution of this input (including the inputs to
>>>>>>>>> functions
>>>>>>>>> stored on the stack) alone we can decide that H_Hat() is
>>>>>>>>> infinitely
>>>>>>>>> recursive.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> In a static call graph of a program, we can spot loops.
>>>>>>>>
>>>>>>>> For instance a simple infinite loop occurs when a basic block
>>>>>>>> jumps to
>>>>>>>> itself.
>>>>>>>>
>>>>>>>> A basic block has no branching instructions anywhere, except as
>>>>>>>> possibly
>>>>>>>> the last instruction. If that last instruction is an
>>>>>>>> unconditional jump
>>>>>>>> back to that block, that is an infinite loop.
>>>>>>>>
>>>>>>>> Compilers do this kind of control flow analysis to find loops,
>>>>>>>> where certain optimizations can be concentrated (e.g. giving more
>>>>>>>> registers to variables in nested loops).
>>>>>>>>
>>>>>>>> If we monitor the execution dynamically, we can likewise identify
>>>>>>>> "dynamic basic blocks" sequences of unconditionally executed
>>>>>>>> instructions with no branches, and we can detect infinite loops.
>>>>>>>> (Possibly ones that contain a stack push, if the jump is actually
>>>>>>>> a subroutine call.)
>>>>>>>>
>>>>>>>> If we simply identify the situation, but don't interfere in it,
>>>>>>>> then the
>>>>>>>> situation persists: there is runaway recursion.
>>>>>>>>
>>>>>>>
>>>>>>> When this same simulator monitors its own simulation it could
>>>>>>> figure out that the H_Hat() invocation of itself is infinitely
>>>>>>> recursive.
>>>>>>>
>>>>>>
>>>>>> I'm afraid that's "wrong-headed" thinking, because Simulate simply
>>>>>> DOES NOT monitor its own simulation, so you can't talk about when
>>>>>> it does something IT DOESN'T DO. :) The same mental confusion
>>>>>> underlies your ".. /would/ fail to terminate /if/ ABNHBD() didn't
>>>>>> abort the emulation", and other anthropomorphisms you make for TMs.
>>>>>>
>>>>>
>>>>> So in other words you cannot possibly begin to imagine that a
>>>>> software function could be adapted to add functionality.
>>>>>
>>>>>> /We/ can figure out that the above H_Hat is infinitely recursive,
>>>>>> but /we/ are not Simulate, so H_Hat is not our "We_hat", and this
>>>>>> says nothing about the Linz proof.
>>>>>>
>>>>>> The /Simulate/ as you've described it (pure emulation) /cannot/
>>>>>> "figure it out", because it fails to return and so doesn't
>>>>>> "figure" anything. Again, nothing much to say re HP proof.
>>>>>>
>>>>>> We could code a /new/ emulator routine Simulate2 (distinct from
>>>>>> H_Hat and Simulate above) which has monitoring logic, and use it
>>>>>> to examine a simulation of the H_Hat above calling Simulate(H_Hat)
>>>>>> (note: NOT calling Simulate2...), and this Simulate2 could
>>>>>> correctly decide that H_Hat(H_Hat) does not terminate.
>>>>>>
>>>>>> But H_Hat is not the "hatted" machine for Simulate2, so this also
>>>>>> is of little interest. Nobody claims that "no decider can
>>>>>> correctly decide halting for H_Hat", only that H does not
>>>>>> correctly decide halting for its own H_Hat.
>>>>>>
>>>>>> If we "update" H_Hat so that instead of calling Simulate, it calls
>>>>>> the new Simulate2, then we have a /new/ program H_Hat2, and a
>>>>>> /new/ calculation to consider. When H_Hat2 examines the
>>>>>> calculation H_Hat2(H_Hat2), with H_Hat2 calling Simulate2 etc.,
>>>>>> then H_Hat2 /*cannot*/ "figure out" that the calculation has
>>>>>> infinite recursion, BECAUSE IT DOESN'T. It can certainly /decide/
>>>>>> that H_Hat2 is infinitely recursive, but that would just be
>>>>>> Simulate2 deciding incorrectly. All in line with Linz proof.
>>>>>>
>>>>>> Remember, Simulate2 is not a "pure emulator" like Simulate, so the
>>>>>> fact that there may be two nested emulated calls to Simulate2 with
>>>>>> the same argument IS NOT PROOF OF INFINITE RECURSION.
>>>>>
>>>>> When Simulate2() is identical to Simulate() in every way except
>>>>> that it also examines the execution trace of its input to figure
>>>>> out that its input is calling Simulate2() in infinite recursion
>>>>> then by logical necessity H_Hat() is still infinitely recursive.
>>>>
>>>> ?
>>>>
>>>> H_Hat doesn't call Simulate2. Maybe you mean H_Hat2 ?
>>>>
>>>> Obviously the /H_Hat/ calculation is "still" infinitely recursive,
>>>> because that calculation has never changed - by definition it calls
>>>> Simulate (not Simulate2).
>>>>
>>>> Hmm, your phrase "figuring out" isn't a standard CS term - I've
>>>> guessed it to mean that Simulate2 returns some different rc (not 1)
>>>> when it detects the nested calls to Simulate2 with the same input
>>>> data, thus making a different decision to the rc=1 [halts] decision.
>>>> Maybe you mean something else?
>>>>
>>>>
>>>> Mike.
>>>>
>> >
>>> An x86 emulator could keep track of all of the details of the
>>> execution trace of any input. If the original Simulate() was adapted
>>> to have this feature and the names remain the same then H_Hat() would
>>> invoke this updated version of Simulate() and still be infinitely
>>> recursive.
>>
>> So was my guess right? Does "figuring out" mean that Simulate2
>> returns some different rc (not 1) when it detects the nested calls to
>> Simulate2 with the same input data, thus making a different decision
>> to the rc=1 [halts] decision? All you've done is replace "figuring
>> out" with "keep track of" which is no better.
>>
>>>
>>> When software engineers add features to existing functions they do
>>> not change the names.
>>
>> What they do is change the versions. But you are not a software
>> engineer, so maybe you don't know about version numbers.
>>
>> Software engineers use version control systems so that if required
>> they can recreate the software at whatever point in the development
>> cycle is required, so there will not be confusion over what code is
>> being used/discussed at any time.
>>
>
> This is the version number of the whole system at that point in time. I
> worked on defense projects using version control. The function almost
> always keep their original names and merely acquire additional
> functionality.
>
>> In contrast, /you/ habitually use the same name for different
>> programs, and different names for the same programs. I suspect this
>> is because in part your arguments rely on confusing different programs
>> as being the same thing, in various ways. So it seems to me that you
>> do this deliberately. This is the exact opposite to how a software
>> engineer or professional programmer would behave.
>>
>
> There are only three programs that I will be talking about:
>
> // P has the machine address of H_Hat()
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Simulate(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> return;
> }
>
> That calls Simulate(P, P) and as the conversation progresses will
> // P has the machine address of H_Hat()
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Simulate(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> return;
> }
>
> gradually be adapted step-by-step until it becomes Halts(P, P).
>
> There will not be any version numbers for Simulate() because Simulate()
> is merely a conversational convention used to construct complete
> understanding of Halts() in small incremental steps.
>
>
>> If it is not deliberate, I suggest you just affix versions to the end
>> of your programs e.g. "H_Hat2" when they change. That's easier than
>> full versions, e.g. "H_Hat (V2.1.0.0)" and more appropriate for
>> newsgroup discussions.
>>
>>
>> Mike.
int Simulate_1(u32 P, u32 I);
Emulates the x86 code pointed to by machine address P with data at
machine address I.
int Simulate_2(u32 P, u32 I);
Same as Simulate_1() except keeps track of the execution trace of its
input including the data passed to any function invocations.
int Simulate_3(u32 P, u32 I);
Same as Simulate_2() except examines the saved execution trace
immediately after emulating each x86 language instruction to determine
whether or not this input specifies infinite recursion.
It should be self-evident that whenever any of these versions is
substituted into the body of H_Hat() that H_Hat() remains infinitely
recursive.
It should be self-evident that Simulate_3() can easily determine the
infinite recursion of H_Hat() on the basis its execution trace.
olcott
Mar 2, 2021, 10:29:32 AM3/2/21
to
On 3/2/2021 6:02 AM, Ben Bacarisse wrote:
> what program you really mean. You should either write programs, or stop
> talking about them and talk about computations instead. I've
> illustrated both approaches below.
> that you will be arguing about things that don't matter every step of
> the way. It's really tedious waiting to find out what the trick is you
> are trying to pull this time around.
>
> What you need, but don't have, is a function H such that this program:
>
> #include <stdint.h>
>
> int H(intptr_t P, intptr_t I)
> {
> // Unknown code
> }
>
> void H_Hat(intptr_t P) { if (H(P, P)) while (1); }
>
> int main(void) { return H((intptr_t)H_Hat, (intptr_t)H_Hat); }
>
> correctly returns 1 or 0 indicating the halting or non-halting of this
> program:
>
> #include <stdint.h>
>
> int H(intptr_t P, intptr_t I)
> {
> // Unknown code exactly as in the previous program
> }
>
> void H_Hat(intptr_t P) { if (H(P, P)) while (1); }
>
> int main(void) { H_Hat((intptr_t)H_Hat); }
>
> Alternatively, you can have one program reflecting the two key
> computations:
>
> #include <stdint.h>
> #include <stdio.h>
>
> int H(intptr_t P, intptr_t I)
> {
> // Unknown code
> }
>
> void H_Hat(intptr_t P) { if (H(P, P)) while (1); }
>
> int main(void) {
> printf("%d\n", H((intptr_t)H_Hat, (intptr_t)H_Hat));
> H_Hat((intptr_t)H_Hat);
> }
>
> This program should either print 1 and terminate, or print 0 and fail to
> terminate. To everyone but you, this program will make it cryatal clear
> why you can't succeed without trickery.
>
> You have some combination of shared data, nested levels of simulation,
> or maybe just your old redefined criterion for "correctly" reporting
> halting that makes it look, to you, like you have something interesting.
> How long must we wait to see what sort of trickery it is this time?
>
> Most of the time you have wasted since apparently having it all sort out
> years ago, has been taking up building the smoke machines and polishing
> the mirrors. You now have yards of code and mile of traces in which you
> have buried the trick. Your original claim, stripped of the lies about
> having actual Turing machines, was simple and impossible. You've lost
> that clarity. Deliberately so, I imagine.
> where you move from something boring to something you'd like to boast
> about. That is the step at which you introduce the trick.
>
#include <stdint.h>
#define u8 uint8_t
#define u32 uint32_t
#define u16 uint16_t
u32 Halts(u32 P, u32 I)
{
((void(*)(int))P)(I);
return 1;
}
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
H_Hat() is invoked in infinite recursion entirely based on the execution
trace of H_Hat() and the assumption that Halts() does nothing besides
execute or emulate its input.
When Halts() is augmented so that it can see that H_Hat() invokes it two
times in sequence with the same data then Halts() can determine that
H_Hat() is infinitely recursive.
_Halts()
[000004af](01) 55 push ebp
[000004b0](02) 8bec mov ebp,esp
[000004b2](03) 8b450c mov eax,[ebp+0c]
[000004b5](01) 50 push eax
[000004b6](03) ff5508 call dword [ebp+08]
[000004b9](03) 83c404 add esp,+04
[000004bc](05) b801000000 mov eax,00000001
[000004c1](01) 5d pop ebp
[000004c2](01) c3 ret
_H_Hat()
[0000088f](01) 55 push ebp
[00000890](02) 8bec mov ebp,esp
[00000892](01) 51 push ecx
[00000893](03) 8b4508 mov eax,[ebp+08]
[00000896](01) 50 push eax ; 2nd Param
[00000897](03) 8b4d08 mov ecx,[ebp+08]
[0000089a](01) 51 push ecx ; 1st Param
[0000089b](05) e80ffcffff call 000004af ; Halts(P,P)
[000008a0](03) 83c408 add esp,+08
[000008a3](03) 8945fc mov [ebp-04],eax
[000008a6](04) 837dfc00 cmp dword [ebp-04],+00
[000008aa](02) 7402 jz 000008ae
[000008ac](02) ebfe jmp 000008ac
[000008ae](02) 8be5 mov esp,ebp
[000008b0](01) 5d pop ebp
[000008b1](01) c3 ret
_main()
[000008bf](01) 55 push ebp
[000008c0](02) 8bec mov ebp,esp
[000008c2](01) 51 push ecx
[000008c3](05) 688f080000 push 0000088f
[000008c8](05) 688f080000 push 0000088f
[000008cd](05) e8ddfbffff call 000004af
[000008d2](03) 83c408 add esp,+08
[000008d5](03) 8945fc mov [ebp-04],eax
[000008d8](03) 8b45fc mov eax,[ebp-04]
[000008db](01) 50 push eax
[000008dc](05) 680b030000 push 0000030b
[000008e1](05) e869faffff call 0000034f
[000008e6](03) 83c408 add esp,+08
[000008e9](02) 33c0 xor eax,eax
[000008eb](02) 8be5 mov esp,ebp
[000008ed](01) 5d pop ebp
[000008ee](01) c3 ret
Push instructions have already pushed the value shown in their in the
third column. The two push instructions preceding the call to Simulate()
are its second and first parameters respectively.
Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Number of bytes of machine code
(5) Machine language bytes
(6) Assembly language text
...[000008bf][00011208][00000000](01) 55 push ebp
...[000008c0][00011208][00000000](02) 8bec mov ebp,esp
...[000008c2][00011204][00000000](01) 51 push ecx
...[000008c3][00011200][0000088f](05) 688f080000 push 0000088f
...[000008c8][000111fc][0000088f](05) 688f080000 push 0000088f
...[000008cd][000111f8][000008d2](05) e8ddfbffff call 000004af
...[0000088f][000111e8][000111f4](01) 55 push ebp
...[00000890][000111e8][000111f4](02) 8bec mov ebp,esp
...[00000892][000111e4][00000000](01) 51 push ecx
...[00000893][000111e4][00000000](03) 8b4508 mov eax,[ebp+08]
...[00000896][000111e0][0000088f](01) 50 push eax ; 2nd Param
...[00000897][000111e0][0000088f](03) 8b4d08 mov ecx,[ebp+08]
...[0000089a][000111dc][0000088f](01) 51 push ecx ; 1st Param
Call Halts(0000088f, 0000088f);
...[0000089b][000111d8][000008a0](05) e80ffcffff call 000004af
...[0000088f][000111c8][000111d4](01) 55 push ebp
...[00000890][000111c8][000111d4](02) 8bec mov ebp,esp
...[00000892][000111c4][0000088f](01) 51 push ecx
...[00000893][000111c4][0000088f](03) 8b4508 mov eax,[ebp+08]
...[00000896][000111c0][0000088f](01) 50 push eax ; 2nd Param
...[00000897][000111c0][0000088f](03) 8b4d08 mov ecx,[ebp+08]
...[0000089a][000111bc][0000088f](01) 51 push ecx ;1st Param
Call Halts(0000088f, 0000088f);
...[0000089b][000111b8][000008a0](05) e80ffcffff call 000004af
It continues to execute the same portion of H_Hat() sequence above
> olcott <No...@NoWhere.com> writes:
>
>> There are only three programs that I will be talking about:
>>
>
>> There are only three programs that I will be talking about:
>>
>> // P has the machine address of H_Hat()
>> void H_Hat(u32 P)
>> {
>> u32 Input_Halts = Simulate(P, P);
>> if (Input_Halts)
>> HERE: goto HERE;
>> return;
>> }
>
> This is not a program. It's a function with hint in a comment as to
>> void H_Hat(u32 P)
>> {
>> u32 Input_Halts = Simulate(P, P);
>> if (Input_Halts)
>> HERE: goto HERE;
>> return;
>> }
>
> what program you really mean. You should either write programs, or stop
> talking about them and talk about computations instead. I've
> illustrated both approaches below.
>
>> That calls Simulate(P, P) and as the conversation progresses will
>> gradually be adapted step-by-step until it becomes Halts(P, P).
>
> This looks like a good strategy, but you make so many errors of detail
>> That calls Simulate(P, P) and as the conversation progresses will
>> gradually be adapted step-by-step until it becomes Halts(P, P).
>
> that you will be arguing about things that don't matter every step of
> the way. It's really tedious waiting to find out what the trick is you
> are trying to pull this time around.
>
> What you need, but don't have, is a function H such that this program:
>
> #include <stdint.h>
>
> int H(intptr_t P, intptr_t I)
> {
> // Unknown code
> }
>
> void H_Hat(intptr_t P) { if (H(P, P)) while (1); }
>
> int main(void) { return H((intptr_t)H_Hat, (intptr_t)H_Hat); }
>
> correctly returns 1 or 0 indicating the halting or non-halting of this
> program:
>
> #include <stdint.h>
>
> int H(intptr_t P, intptr_t I)
> {
> // Unknown code exactly as in the previous program
> }
>
> void H_Hat(intptr_t P) { if (H(P, P)) while (1); }
>
> int main(void) { H_Hat((intptr_t)H_Hat); }
>
> Alternatively, you can have one program reflecting the two key
> computations:
>
> #include <stdint.h>
> #include <stdio.h>
>
> int H(intptr_t P, intptr_t I)
> {
> // Unknown code
> }
>
> void H_Hat(intptr_t P) { if (H(P, P)) while (1); }
>
> int main(void) {
> printf("%d\n", H((intptr_t)H_Hat, (intptr_t)H_Hat));
> H_Hat((intptr_t)H_Hat);
> }
>
> This program should either print 1 and terminate, or print 0 and fail to
> terminate. To everyone but you, this program will make it cryatal clear
> why you can't succeed without trickery.
>
> You have some combination of shared data, nested levels of simulation,
> or maybe just your old redefined criterion for "correctly" reporting
> halting that makes it look, to you, like you have something interesting.
> How long must we wait to see what sort of trickery it is this time?
>
> Most of the time you have wasted since apparently having it all sort out
> years ago, has been taking up building the smoke machines and polishing
> the mirrors. You now have yards of code and mile of traces in which you
> have buried the trick. Your original claim, stripped of the lies about
> having actual Turing machines, was simple and impossible. You've lost
> that clarity. Deliberately so, I imagine.
>
>> There will not be any version numbers for Simulate() because
>> Simulate() is merely a conversational convention used to construct
>> complete understanding of Halts() in small incremental steps.
>
> You can find your mistake simply by finding the first of those steps
>> There will not be any version numbers for Simulate() because
>> Simulate() is merely a conversational convention used to construct
>> complete understanding of Halts() in small incremental steps.
>
> where you move from something boring to something you'd like to boast
> about. That is the step at which you introduce the trick.
>
#include <stdint.h>
#define u8 uint8_t
#define u32 uint32_t
#define u16 uint16_t
u32 Halts(u32 P, u32 I)
{
((void(*)(int))P)(I);
return 1;
}
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
int main()
HERE: goto HERE;
return;
}
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
Because the execution trace shown below shows that H_Hat() invokes
Halts() with the same data two times in sequence we can conclude that
Because the execution trace shown below shows that H_Hat() invokes
H_Hat() is invoked in infinite recursion entirely based on the execution
trace of H_Hat() and the assumption that Halts() does nothing besides
execute or emulate its input.
When Halts() is augmented so that it can see that H_Hat() invokes it two
times in sequence with the same data then Halts() can determine that
H_Hat() is infinitely recursive.
_Halts()
[000004af](01) 55 push ebp
[000004b0](02) 8bec mov ebp,esp
[000004b2](03) 8b450c mov eax,[ebp+0c]
[000004b5](01) 50 push eax
[000004b6](03) ff5508 call dword [ebp+08]
[000004b9](03) 83c404 add esp,+04
[000004bc](05) b801000000 mov eax,00000001
[000004c1](01) 5d pop ebp
[000004c2](01) c3 ret
_H_Hat()
[0000088f](01) 55 push ebp
[00000890](02) 8bec mov ebp,esp
[00000892](01) 51 push ecx
[00000893](03) 8b4508 mov eax,[ebp+08]
[00000896](01) 50 push eax ; 2nd Param
[00000897](03) 8b4d08 mov ecx,[ebp+08]
[0000089a](01) 51 push ecx ; 1st Param
[0000089b](05) e80ffcffff call 000004af ; Halts(P,P)
[000008a0](03) 83c408 add esp,+08
[000008a3](03) 8945fc mov [ebp-04],eax
[000008a6](04) 837dfc00 cmp dword [ebp-04],+00
[000008aa](02) 7402 jz 000008ae
[000008ac](02) ebfe jmp 000008ac
[000008ae](02) 8be5 mov esp,ebp
[000008b0](01) 5d pop ebp
[000008b1](01) c3 ret
_main()
[000008bf](01) 55 push ebp
[000008c0](02) 8bec mov ebp,esp
[000008c2](01) 51 push ecx
[000008c3](05) 688f080000 push 0000088f
[000008c8](05) 688f080000 push 0000088f
[000008cd](05) e8ddfbffff call 000004af
[000008d2](03) 83c408 add esp,+08
[000008d5](03) 8945fc mov [ebp-04],eax
[000008d8](03) 8b45fc mov eax,[ebp-04]
[000008db](01) 50 push eax
[000008dc](05) 680b030000 push 0000030b
[000008e1](05) e869faffff call 0000034f
[000008e6](03) 83c408 add esp,+08
[000008e9](02) 33c0 xor eax,eax
[000008eb](02) 8be5 mov esp,ebp
[000008ed](01) 5d pop ebp
[000008ee](01) c3 ret
Push instructions have already pushed the value shown in their in the
third column. The two push instructions preceding the call to Simulate()
are its second and first parameters respectively.
Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Number of bytes of machine code
(5) Machine language bytes
(6) Assembly language text
...[000008c0][00011208][00000000](02) 8bec mov ebp,esp
...[000008c2][00011204][00000000](01) 51 push ecx
...[000008c3][00011200][0000088f](05) 688f080000 push 0000088f
...[000008c8][000111fc][0000088f](05) 688f080000 push 0000088f
...[000008cd][000111f8][000008d2](05) e8ddfbffff call 000004af
...[0000088f][000111e8][000111f4](01) 55 push ebp
...[00000890][000111e8][000111f4](02) 8bec mov ebp,esp
...[00000892][000111e4][00000000](01) 51 push ecx
...[00000893][000111e4][00000000](03) 8b4508 mov eax,[ebp+08]
...[00000896][000111e0][0000088f](01) 50 push eax ; 2nd Param
...[00000897][000111e0][0000088f](03) 8b4d08 mov ecx,[ebp+08]
...[0000089a][000111dc][0000088f](01) 51 push ecx ; 1st Param
Call Halts(0000088f, 0000088f);
...[0000089b][000111d8][000008a0](05) e80ffcffff call 000004af
...[0000088f][000111c8][000111d4](01) 55 push ebp
...[00000890][000111c8][000111d4](02) 8bec mov ebp,esp
...[00000892][000111c4][0000088f](01) 51 push ecx
...[00000893][000111c4][0000088f](03) 8b4508 mov eax,[ebp+08]
...[00000896][000111c0][0000088f](01) 50 push eax ; 2nd Param
...[00000897][000111c0][0000088f](03) 8b4d08 mov ecx,[ebp+08]
...[0000089a][000111bc][0000088f](01) 51 push ecx ;1st Param
Call Halts(0000088f, 0000088f);
...[0000089b][000111b8][000008a0](05) e80ffcffff call 000004af
It continues to execute the same portion of H_Hat() sequence above
Otto J. Makela
Mar 2, 2021, 11:37:01 AM3/2/21
to
I'm a bit late to the discussion, but this sounds a lot like you're
trying to overturn Turing's proof that that a general algorithm to solve
the halting problem for all possible program-input pairs cannot exist.
--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */
trying to overturn Turing's proof that that a general algorithm to solve
the halting problem for all possible program-input pairs cannot exist.
--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */
olcott
Mar 2, 2021, 12:22:50 PM3/2/21
to
On 3/2/2021 10:36 AM, Otto J. Makela wrote:
> I'm a bit late to the discussion, but this sounds a lot like you're
> trying to overturn Turing's proof that that a general algorithm to solve
> the halting problem for all possible program-input pairs cannot exist.
>
Yes. The key brand new insight that I had about this proof is that the
> I'm a bit late to the discussion, but this sounds a lot like you're
> trying to overturn Turing's proof that that a general algorithm to solve
> the halting problem for all possible program-input pairs cannot exist.
>
actual execution trace never reaches the undecidable portion, thus
making the conventional halting problem counter-examples {Linz, Sipser,
Kozen} decidable.
// P has the machine address of H_Hat()
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
"It looks like the original specification provided in
if (Input_Halts)
HERE: goto HERE;
return;
}
the Linz text may be infinitely recursive in that each
TM requires its own input."
Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
(concrete example) August 2016
https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example
Infinitely Recursive input on HP Proofs (March 11, 2017)
https://groups.google.com/g/comp.theory/c/NcFS02hKs1U/m/PlBF-1LRBAAJ
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company (315-320)
Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (165-167)
Kozen, Dexter 1997. Automata and Computability. New York:
Springer-Verlag. (231-234).
Kaz Kylheku
Mar 2, 2021, 12:46:45 PM3/2/21
to
On 2021-03-02, olcott <No...@NoWhere.com> wrote:
> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>> I'm a bit late to the discussion, but this sounds a lot like you're
>> trying to overturn Turing's proof that that a general algorithm to solve
>> the halting problem for all possible program-input pairs cannot exist.
>>
>
> Yes. The key brand new insight that I had about this proof is that the
> actual execution trace never reaches the undecidable portion, thus
The program has no "undecidable portion". We know perfectly well
> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>> I'm a bit late to the discussion, but this sounds a lot like you're
>> trying to overturn Turing's proof that that a general algorithm to solve
>> the halting problem for all possible program-input pairs cannot exist.
>>
>
> Yes. The key brand new insight that I had about this proof is that the
> actual execution trace never reaches the undecidable portion, thus
whether it terminates or not, because it is trivial.
All that is undecidable, in the context of computability, is the problem
of determining whether any program whatsoever on any input terminates.
"Undecidable
> making the conventional halting problem counter-examples {Linz, Sipser,
> Kozen} decidable.
No example of anything even moderately hard to decide is ever presented
in the proofs.
> // P has the machine address of H_Hat()
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> return;
> }
senior year, that if Halts decides that it's a good idea to "decide"
halting by simply running the code, runaway recursion will occur.
When I first encountered the halting problem concept, I remember that
the text I was reading mentioned this: if the decision function jus
executes the function, it precipitates into infinite regress, and
therefore does not terminate, in which case there is no decision.
You have not discovered anything.
Also, the idea of an insruction stream that has no branches corresponds
to the well-known concept of a basic block in program control flow
analysis, used in compilers. Again, something even CS undergrads know by
the time they graduate.
olcott
Mar 2, 2021, 2:00:16 PM3/2/21
to
On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>> trying to overturn Turing's proof that that a general algorithm to solve
>>> the halting problem for all possible program-input pairs cannot exist.
>>>
>>
>> Yes. The key brand new insight that I had about this proof is that the
>> actual execution trace never reaches the undecidable portion, thus
>
> The program has no "undecidable portion". We know perfectly well
> whether it terminates or not, because it is trivial.
>
Daryl McCullough
> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>> trying to overturn Turing's proof that that a general algorithm to solve
>>> the halting problem for all possible program-input pairs cannot exist.
>>>
>>
>> Yes. The key brand new insight that I had about this proof is that the
>> actual execution trace never reaches the undecidable portion, thus
>
> The program has no "undecidable portion". We know perfectly well
> whether it terminates or not, because it is trivial.
>
https://groups.google.com/g/comp.theory/c/wgJjJR78FaU/m/_eWPqsSS8bEJ
I can finally give credit where credit is due. Daryl McCullough was the
one that originally came up with this analogy in March of 2012.
When we ask Bill: Is your answer to this question "no" ?
Bill cannot possibly provide a correct answer because both answers of
"yes" and "no" form a contradiction.
In this same way Halts() cannot possibly provide a correct return value
indicating halting / non halting to H_Hat().
// P has the machine address of H_Hat()
void H_Hat(u32 P)
{
if (Input_Halts)
HERE: goto HERE;
return;
}
The brand new insight that I documented that I came up with in 2016 was
HERE: goto HERE;
return;
}
that a halt decider that examines the simulation of its input as the
basis for its halting decision would never reach the point where it
returns any value to H_Hat().
Kaz Kylheku
Mar 2, 2021, 2:35:33 PM3/2/21
to
["Followup-To:" header set to comp.lang.c.]
answer when we decide whether the example terminates or not.
If the example terminates and gives a result, that result may have
the interpretation that it is wrong; i.e. a contradiction.
If the program's is taken to mean "I do not halt", than that is wrong;
That has no bearing on the fact that the program has halted, and
that our own answer "it has halted" is right.
The decider is only shown wrong on that one example, not that it's
on all inputs. The decider is not absolutely contradicted.
> The brand new insight that I documented that I came up with in 2016 was
> that a halt decider that examines the simulation of its input as the
> basis for its halting decision would never reach the point where it
> returns any value to H_Hat().
This is undergrad-level obvious that if the decider, instead of
implementing some actual decision algorithm, simply executes the input,
then if that input does not terminate, that "decision" will also not
terminate, and that it is victim to infinite regress.
The first time I learned about the halting problem, it was in a textbook
which noted this obvious fact.
You should be more humble in your claims that you have some brand new
result.
On 2021-03-02, olcott <No...@NoWhere.com> wrote:
> On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>>> trying to overturn Turing's proof that that a general algorithm to solve
>>>> the halting problem for all possible program-input pairs cannot exist.
>>>>
>>>
>>> Yes. The key brand new insight that I had about this proof is that the
>>> actual execution trace never reaches the undecidable portion, thus
>>
>> The program has no "undecidable portion". We know perfectly well
>> whether it terminates or not, because it is trivial.
>>
>
> Daryl McCullough
> https://groups.google.com/g/comp.theory/c/wgJjJR78FaU/m/_eWPqsSS8bEJ
> I can finally give credit where credit is due. Daryl McCullough was the
> one that originally came up with this analogy in March of 2012.
>
> When we ask Bill: Is your answer to this question "no" ?
> Bill cannot possibly provide a correct answer because both answers of
> "yes" and "no" form a contradiction.
Since we are not part of the program, there is no contradiction in our
> On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>>> trying to overturn Turing's proof that that a general algorithm to solve
>>>> the halting problem for all possible program-input pairs cannot exist.
>>>>
>>>
>>> Yes. The key brand new insight that I had about this proof is that the
>>> actual execution trace never reaches the undecidable portion, thus
>>
>> The program has no "undecidable portion". We know perfectly well
>> whether it terminates or not, because it is trivial.
>>
>
> Daryl McCullough
> https://groups.google.com/g/comp.theory/c/wgJjJR78FaU/m/_eWPqsSS8bEJ
> I can finally give credit where credit is due. Daryl McCullough was the
> one that originally came up with this analogy in March of 2012.
>
> When we ask Bill: Is your answer to this question "no" ?
> Bill cannot possibly provide a correct answer because both answers of
> "yes" and "no" form a contradiction.
answer when we decide whether the example terminates or not.
If the example terminates and gives a result, that result may have
the interpretation that it is wrong; i.e. a contradiction.
If the program's is taken to mean "I do not halt", than that is wrong;
That has no bearing on the fact that the program has halted, and
that our own answer "it has halted" is right.
The decider is only shown wrong on that one example, not that it's
on all inputs. The decider is not absolutely contradicted.
> The brand new insight that I documented that I came up with in 2016 was
> that a halt decider that examines the simulation of its input as the
> basis for its halting decision would never reach the point where it
> returns any value to H_Hat().
implementing some actual decision algorithm, simply executes the input,
then if that input does not terminate, that "decision" will also not
terminate, and that it is victim to infinite regress.
The first time I learned about the halting problem, it was in a textbook
which noted this obvious fact.
You should be more humble in your claims that you have some brand new
result.
olcott
Mar 2, 2021, 2:50:11 PM3/2/21
to
On 3/2/2021 1:00 PM, olcott wrote:
> On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>>> trying to overturn Turing's proof that that a general algorithm to
>>>> solve
>>>> the halting problem for all possible program-input pairs cannot exist.
>>>>
>>>
>>> Yes. The key brand new insight that I had about this proof is that the
>>> actual execution trace never reaches the undecidable portion, thus
>>
>> The program has no "undecidable portion". We know perfectly well
>> whether it terminates or not, because it is trivial.
>>
There is a much earlier attribution to the same person:
> On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>>> trying to overturn Turing's proof that that a general algorithm to
>>>> solve
>>>> the halting problem for all possible program-input pairs cannot exist.
>>>>
>>>
>>> Yes. The key brand new insight that I had about this proof is that the
>>> actual execution trace never reaches the undecidable portion, thus
>>
>> The program has no "undecidable portion". We know perfectly well
>> whether it terminates or not, because it is trivial.
>>
sci.logic Daryl McCullough June 25, 2004
On Friday, June 25, 2004 at 6:30:39 PM UTC-5, Daryl McCullough wrote:
> You ask someone (we'll call him "Jack") to give a truthful
> yes/no answer to the following question:
> Will Jack's answer to this question be no?
> Jack can't possibly give a correct yes/no answer to the question.
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
Jack cannot possibly provide a correct answer because both answers of
Kaz Kylheku
Mar 2, 2021, 2:57:36 PM3/2/21
to
On 2021-03-02, olcott <No...@NoWhere.com> wrote:
> On 3/2/2021 1:00 PM, olcott wrote:
>> On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
>>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>>>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>>>> trying to overturn Turing's proof that that a general algorithm to
>>>>> solve
>>>>> the halting problem for all possible program-input pairs cannot exist.
>>>>>
>>>>
>>>> Yes. The key brand new insight that I had about this proof is that the
>>>> actual execution trace never reaches the undecidable portion, thus
>>>
>>> The program has no "undecidable portion". We know perfectly well
>>> whether it terminates or not, because it is trivial.
>>>
>
> There is a much earlier attribution to the same person:
>
> sci.logic Daryl McCullough June 25, 2004
> On Friday, June 25, 2004 at 6:30:39 PM UTC-5, Daryl McCullough wrote:
> > You ask someone (we'll call him "Jack") to give a truthful
> > yes/no answer to the following question:
> > Will Jack's answer to this question be no?
> > Jack can't possibly give a correct yes/no answer to the question.
>
> https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
>
> Jack cannot possibly provide a correct answer because both answers of
> "yes" and "no" form a contradiction.
What you're perpetually missing is that a mathematical or
> On 3/2/2021 1:00 PM, olcott wrote:
>> On 3/2/2021 11:46 AM, Kaz Kylheku wrote:
>>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>>>> On 3/2/2021 10:36 AM, Otto J. Makela wrote:
>>>>> I'm a bit late to the discussion, but this sounds a lot like you're
>>>>> trying to overturn Turing's proof that that a general algorithm to
>>>>> solve
>>>>> the halting problem for all possible program-input pairs cannot exist.
>>>>>
>>>>
>>>> Yes. The key brand new insight that I had about this proof is that the
>>>> actual execution trace never reaches the undecidable portion, thus
>>>
>>> The program has no "undecidable portion". We know perfectly well
>>> whether it terminates or not, because it is trivial.
>>>
>
> There is a much earlier attribution to the same person:
>
> sci.logic Daryl McCullough June 25, 2004
> On Friday, June 25, 2004 at 6:30:39 PM UTC-5, Daryl McCullough wrote:
> > You ask someone (we'll call him "Jack") to give a truthful
> > yes/no answer to the following question:
> > Will Jack's answer to this question be no?
> > Jack can't possibly give a correct yes/no answer to the question.
>
> https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
>
> Jack cannot possibly provide a correct answer because both answers of
> "yes" and "no" form a contradiction.
computatational function isn't Jack. If it gives a "yes" answer for some
input, it can give no other answer. Functions don't have the choice of
re-evaluating their answer and changing it.
Much of your rhetoric in this direction is laced with
anthropomorphic fallacy.
If we edit a function to give a different answer for the same input,
we are creating a different function. Since the input is the function
itself, the input has changed too!
You continue to be confused by this point; your work history consists
of producing different versions of code under the same names, taking
different inputs under the same name, and speaking about it in terms as
if they are all one thing.
olcott
Mar 2, 2021, 3:20:27 PM3/2/21
to
// P has the machine address of H_Hat()
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
void H_Hat(u32 P)
{
if (Input_Halts)
HERE: goto HERE;
return;
}
Although you may endlessly dodge this point it remains perfectly true
HERE: goto HERE;
return;
}
that both possible Boolean return values from Halts() to H_Hat() would
be made incorrect on the basis that they are contradicted.
It is also a verified fact that these return values are contradicted in
the exact same pathological self-reference(Olcott 2004) way that makes
it impossible for Jack to provide a correct answer to this question:
Is the answer to this question no?
Keith Thompson
Mar 2, 2021, 3:57:29 PM3/2/21
to
[more of the same]
Kaz, olcott's article to which you replied was posted to
comp.theory, comp.lang.c, comp.lang.c++, and comp.software-eng,
with followups directed to comp.lang.c. Your followup ignored the
"Followup-To: comp.theory" header line and cross-posted to all
four newsgroups.
Is your newsreader buggy, or are you deliberately making
inappropriate cross-posts, or is something else going on?
I've cross-posted this article and set followups to comp.theory only.
--
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 */
Kaz, olcott's article to which you replied was posted to
comp.theory, comp.lang.c, comp.lang.c++, and comp.software-eng,
with followups directed to comp.lang.c. Your followup ignored the
"Followup-To: comp.theory" header line and cross-posted to all
four newsgroups.
Is your newsreader buggy, or are you deliberately making
inappropriate cross-posts, or is something else going on?
I've cross-posted this article and set followups to comp.theory only.
--
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
Mar 2, 2021, 7:45:47 PM3/2/21
to
On 3/2/2021 6:20 PM, Richard Damon wrote:
> On 3/2/21 5:59 PM, olcott wrote:
>> On 3/2/2021 4:50 PM, Richard Damon wrote:
>>> On 3/2/21 5:24 PM, olcott wrote:
>>>> On 3/2/2021 3:07 PM, Richard Damon wrote:
>>>>> On 3/2/21 3:41 PM, olcott wrote:
>>>>>> On 3/2/2021 2:01 PM, Malcolm McLean wrote:
>>>>>>> On Tuesday, 2 March 2021 at 19:52:39 UTC, olcott wrote:
>>>>>>>> On 3/2/2021 1:45 PM, Siri Cruise wrote:
>>>>>>>>> In article <uLSdnZF1Hv7L6aP9...@giganews.com>,
>>>>>>>>> procedures that either never halt if the conjecture is true or do
>>>>>>>>> halt (on a counterexample) if the conjecture is false. If you
>>>>>>>>> really can solve the halting problem, then solve these and be
>>>>>>>>> famous for solving all number theory conjectures and
>>>>>>>>> simultaneously proving number theory is w-inconsistent.
>>>>>>>>>
>>>>>>>> My background is computer science not mathematics, I will leave the
>>>>>>>> math
>>>>>>>> aspects of this as an exercise for the reader on the basis of the
>>>>>>>> computer science solution that I have provided.
>>>>>>>>
>>>>>>> All you really need to know is that, if you could write a halt
>>>>>>> decider, then
>>>>>>> many problems considered by mathematicians to be insoluble would
>>>>>>> suddenly become soluble. That tells you that it's likely that there
>>>>>>> are issues
>>>>>>> in writing a halt decider which are at least as hard to resolve as
>>>>>>> finding
>>>>>>> solutions to all these previously insoluble maths problems. Otherwise
>>>>>>> mathematicians really aren't such a smart bunch.
>>>>>>>
>>>>>>> That's an informal argument, not a proof.
>>>>>>>
>>>>>>
>>>>>> I have been working on this for thousands and thousands of hours since
>>>>>> 2004. This is best documented in my thousands and thousands of
>>>>>> posts to
>>>>>> comp.theory.
>>>>>>
>>>>>> My solution is so simple that it is very obviously totally correct.
>>>>>> It is obvious that the standard halting problem proof counter-example
>>>>>> would infinitely invoke the halt decider.
>>>>>>
>>>>>> When the halt decider has been augmented to be able to see this
>>>>>> then it
>>>>>> can correctly decide halting on the conventional HP proof
>>>>>> counter-examples.
>>>>>>
>>>>>>
>>>>>> int Halts(u32 P, u32 I)
>>>>>> {
>>>>>> ((void(*)(int))P)(I);
>>>>>> return 1;
>>>>>> }
>>>>>>
>>>> an exception to the rule that when there is a sequence of two function
>>>> calls to the same function from the same machine address and no
>>>> conditional branch instructions inbetween that it might possibly not be
>>>> infinite recursion? This exception made me have to start looking at
>>>> inputs to function call.
>>>>
>>>>
>>>
>>> Ultimately the issue is that if you allow the use of any data base
>>> program flow control, even if not what you were calling a 'conditional
>>> jump' you can get the effect of a conditional jump.
>>>
>>> Since your simulation routine is in effect, such a program flow
>>> instruction (even if you don't want to call it that, especially inside
>>> you 'OS Code') I was able to defeat your incorrect rule (incorrect as it
>>> doesn't restrict the conditions enough) by entering one program with
>>> different data so it could use that data to create differing program
>>> flow after the call that you were detecting as recursive without
>>> conditional (because there WAS a conditional execution in the loop).
>>>
>>> Your modified rule is basicly roughly the detection of a loop by seeing
>>> the program return to a previous state with ALL the state being the same
>>> (which holds even with conditionals in the path). At the simulate call,
>>> assuming that you do block access to global variable, the state that
>>> crosses is limited, so is easier to check.
>>>
>>> Note that since it appears that Halts does have some access to global
>>> data, that condition isn't fully satisfied, but it may be you are
>>> preventing that information from leaking out enough for your purposes.
>>>
>>
>> That is not the specific concrete example that you previously provided.
>> Since I remember that this caused me to build the infrastructure to make
>> sure that I examined inputs to a function your concrete example had
>> different inputs. Maybe it was something like the second input was a
>> value used by a switch statement.
>>
>
> That is an exact decsription of what I did (A switch would have been a
> conditional).
>
> It worked by passing different values of the data parameter that the
> function use as the program parameter, thus getting the Halt Decider
> function to perform the conditional execution instruction cloaked behind
> your false wall of separation.
>
OK, great. That was an important critique. It caused me to focus on
examining to input to functions as a key element of halt deciding.
Assuming that what Malcolm said also applies to indirect recursion:
On 2/26/2021 2:41 PM, Malcolm McLean wrote:
> If A calls itself with exactly the same data as it was
> originally invoked with, then it must be infinitely recursive,
> even if there are conditional branches. It always takes the
> same branches.
Then detecting infinite recursion is made even simpler.
Noticing that the H_Hat() invocation of Halts() is infinitely recursive
for every halt decider that bases it halt deciding decision on examining
its own simulation of its input overcame the "impossible" aspect of
refuting the halting problem proofs. (Copyright Pete Olcott 2016, 2017).
The feedback that you and Malcolm provided was important to implementing
this halt decider. You corrected a key short-coming with the initial
halt decider design and Malcolm eliminated an unnecessary step.
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
> On 3/2/21 5:59 PM, olcott wrote:
>> On 3/2/2021 4:50 PM, Richard Damon wrote:
>>> On 3/2/21 5:24 PM, olcott wrote:
>>>> On 3/2/2021 3:07 PM, Richard Damon wrote:
>>>>> On 3/2/21 3:41 PM, olcott wrote:
>>>>>> On 3/2/2021 2:01 PM, Malcolm McLean wrote:
>>>>>>> On Tuesday, 2 March 2021 at 19:52:39 UTC, olcott wrote:
>>>>>>>> On 3/2/2021 1:45 PM, Siri Cruise wrote:
>>>>>>>>> In article <uLSdnZF1Hv7L6aP9...@giganews.com>,
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> Yes. The key brand new insight that I had about this proof is
>>>>>>>>>> that the
>>>>>>>>>
>>>>>>>>> It's easy to express some number theory conjectures as recursive
>>>>>>>>>
>>>>>>>>>> Yes. The key brand new insight that I had about this proof is
>>>>>>>>>> that the
>>>>>>>>>
>>>>>>>>> procedures that either never halt if the conjecture is true or do
>>>>>>>>> halt (on a counterexample) if the conjecture is false. If you
>>>>>>>>> really can solve the halting problem, then solve these and be
>>>>>>>>> famous for solving all number theory conjectures and
>>>>>>>>> simultaneously proving number theory is w-inconsistent.
>>>>>>>>>
>>>>>>>> My background is computer science not mathematics, I will leave the
>>>>>>>> math
>>>>>>>> aspects of this as an exercise for the reader on the basis of the
>>>>>>>> computer science solution that I have provided.
>>>>>>>>
>>>>>>> All you really need to know is that, if you could write a halt
>>>>>>> decider, then
>>>>>>> many problems considered by mathematicians to be insoluble would
>>>>>>> suddenly become soluble. That tells you that it's likely that there
>>>>>>> are issues
>>>>>>> in writing a halt decider which are at least as hard to resolve as
>>>>>>> finding
>>>>>>> solutions to all these previously insoluble maths problems. Otherwise
>>>>>>> mathematicians really aren't such a smart bunch.
>>>>>>>
>>>>>>> That's an informal argument, not a proof.
>>>>>>>
>>>>>>
>>>>>> I have been working on this for thousands and thousands of hours since
>>>>>> 2004. This is best documented in my thousands and thousands of
>>>>>> posts to
>>>>>> comp.theory.
>>>>>>
>>>>>> My solution is so simple that it is very obviously totally correct.
>>>>>> It is obvious that the standard halting problem proof counter-example
>>>>>> would infinitely invoke the halt decider.
>>>>>>
>>>>>> When the halt decider has been augmented to be able to see this
>>>>>> then it
>>>>>> can correctly decide halting on the conventional HP proof
>>>>>> counter-examples.
>>>>>>
>>>>>>
>>>>>> int Halts(u32 P, u32 I)
>>>>>> {
>>>>>> ((void(*)(int))P)(I);
>>>>>> return 1;
>>>>>> }
>>>>>>
>>>>>> void H_Hat(u32 P)
>>>>>> {
>>>>>> u32 Input_Halts = Halts(P, P);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> {
>>>>>> u32 Input_Halts = Halts(P, P);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>>>>>> Output("Input_Would_Halt = ", Input_Would_Halt);
>>>>>> }
>>>>>>
>>>>>>
>>>>
>>>> What was that counter-example that you presented that showed there was
>>>>>> {
>>>>>> u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>>>>>> Output("Input_Would_Halt = ", Input_Would_Halt);
>>>>>> }
>>>>>>
>>>>>>
>>>>
>>>> an exception to the rule that when there is a sequence of two function
>>>> calls to the same function from the same machine address and no
>>>> conditional branch instructions inbetween that it might possibly not be
>>>> infinite recursion? This exception made me have to start looking at
>>>> inputs to function call.
>>>>
>>>>
>>>
>>> Ultimately the issue is that if you allow the use of any data base
>>> program flow control, even if not what you were calling a 'conditional
>>> jump' you can get the effect of a conditional jump.
>>>
>>> Since your simulation routine is in effect, such a program flow
>>> instruction (even if you don't want to call it that, especially inside
>>> you 'OS Code') I was able to defeat your incorrect rule (incorrect as it
>>> doesn't restrict the conditions enough) by entering one program with
>>> different data so it could use that data to create differing program
>>> flow after the call that you were detecting as recursive without
>>> conditional (because there WAS a conditional execution in the loop).
>>>
>>> Your modified rule is basicly roughly the detection of a loop by seeing
>>> the program return to a previous state with ALL the state being the same
>>> (which holds even with conditionals in the path). At the simulate call,
>>> assuming that you do block access to global variable, the state that
>>> crosses is limited, so is easier to check.
>>>
>>> Note that since it appears that Halts does have some access to global
>>> data, that condition isn't fully satisfied, but it may be you are
>>> preventing that information from leaking out enough for your purposes.
>>>
>>
>> That is not the specific concrete example that you previously provided.
>> Since I remember that this caused me to build the infrastructure to make
>> sure that I examined inputs to a function your concrete example had
>> different inputs. Maybe it was something like the second input was a
>> value used by a switch statement.
>>
>
> That is an exact decsription of what I did (A switch would have been a
> conditional).
>
> It worked by passing different values of the data parameter that the
> function use as the program parameter, thus getting the Halt Decider
> function to perform the conditional execution instruction cloaked behind
> your false wall of separation.
>
OK, great. That was an important critique. It caused me to focus on
examining to input to functions as a key element of halt deciding.
Assuming that what Malcolm said also applies to indirect recursion:
On 2/26/2021 2:41 PM, Malcolm McLean wrote:
> If A calls itself with exactly the same data as it was
> originally invoked with, then it must be infinitely recursive,
> even if there are conditional branches. It always takes the
> same branches.
Then detecting infinite recursion is made even simpler.
Noticing that the H_Hat() invocation of Halts() is infinitely recursive
for every halt decider that bases it halt deciding decision on examining
its own simulation of its input overcame the "impossible" aspect of
refuting the halting problem proofs. (Copyright Pete Olcott 2016, 2017).
The feedback that you and Malcolm provided was important to implementing
this halt decider. You corrected a key short-coming with the initial
halt decider design and Malcolm eliminated an unnecessary step.
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
Kenny McCormack
Mar 2, 2021, 9:18:06 PM3/2/21
to
In article <874khtj...@nosuchdomain.example.com>,
--
People who want to share their religious views with you
almost never want you to share yours with them. -- Dave Barry
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Kaz Kylheku <563-36...@kylheku.com> writes:
>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>[more of the same]
>
>Kaz, olcott's article to which you replied was posted to
>comp.theory, comp.lang.c, comp.lang.c++, and comp.software-eng,
>with followups directed to comp.lang.c. Your followup ignored the
>"Followup-To: comp.theory" header line and cross-posted to all
>four newsgroups.
>
>Is your newsreader buggy, or are you deliberately making
>inappropriate cross-posts, or is something else going on?
>
>I've cross-posted this article and set followups to comp.theory only.
Wow. I'm so impressed.
>Kaz Kylheku <563-36...@kylheku.com> writes:
>> On 2021-03-02, olcott <No...@NoWhere.com> wrote:
>[more of the same]
>
>Kaz, olcott's article to which you replied was posted to
>comp.theory, comp.lang.c, comp.lang.c++, and comp.software-eng,
>with followups directed to comp.lang.c. Your followup ignored the
>"Followup-To: comp.theory" header line and cross-posted to all
>four newsgroups.
>
>Is your newsreader buggy, or are you deliberately making
>inappropriate cross-posts, or is something else going on?
>
>I've cross-posted this article and set followups to comp.theory only.
--
People who want to share their religious views with you
almost never want you to share yours with them. -- Dave Barry
Juha Nieminen
Mar 3, 2021, 2:24:04 AM3/3/21
to
In comp.lang.c++ Otto J. Makela <o...@iki.fi> wrote:
> I'm a bit late to the discussion, but this sounds a lot like you're
> trying to overturn Turing's proof that that a general algorithm to solve
> the halting problem for all possible program-input pairs cannot exist.
If the halting problem could be solved, it would be great news for
> I'm a bit late to the discussion, but this sounds a lot like you're
> trying to overturn Turing's proof that that a general algorithm to solve
> the halting problem for all possible program-input pairs cannot exist.
mathematics. Pretty much all unsolved problems in mathematics, at least
those that can be computed with an algorithm, would be solved in one
fell swoop.
The Riemann hypothesis? Simply create a program that checks every
single non-trivial zero of the zeta function and stops when it finds
one that's not on the critical line. Then simply use the marvelous
halting problem solution above to see if it ever terminates, and
you'll have proven the Riemann hypothesis as true or false.
Do odd perfect numbers exist? Simply create a program that goes
through every odd number and checks if it's perfect, and terminates
when it finds one. Use the halting problem proof to check if it will
ever terminate and you'll have solved the problem.
Collatz conjecture? Same thing. And so on and so forth.
David Brown
Mar 3, 2021, 2:59:00 AM3/3/21
to
that means he is not constrained by such simple mathematical logic, and
can solve the impossible in an way that mathematicians cannot.
You know, in the same way that non-physicists are not constrained by
physical laws that they don't understand, and can thus make moon rockets
in their garage powered by gravity-repulsive paint.
Juha Nieminen
Mar 3, 2021, 3:50:34 AM3/3/21
to
David Brown <david...@hesbynett.no> wrote:
> I think Pete Olcott already said that he was not a mathematician. So
> that means he is not constrained by such simple mathematical logic, and
> can solve the impossible in an way that mathematicians cannot.
>
> You know, in the same way that non-physicists are not constrained by
> physical laws that they don't understand, and can thus make moon rockets
> in their garage powered by gravity-repulsive paint.
I haven't followed what he has written and said about his approach, but
> I think Pete Olcott already said that he was not a mathematician. So
> that means he is not constrained by such simple mathematical logic, and
> can solve the impossible in an way that mathematicians cannot.
>
> You know, in the same way that non-physicists are not constrained by
> physical laws that they don't understand, and can thus make moon rockets
> in their garage powered by gravity-repulsive paint.
if I were to guess, he's probably doing the same thing as so many other
pseudomathematicians do with such things, when trying to contradict
well-established corroborated mathematical proofs: Simply *redefine*
the original problem so that it (possibly) fits his "proof".
A bit like trying to redefine the value of pi so that a proof of
squaring the circle becomes correct. (This is an actual real-life
example.)
mick...@potatofield.co.uk
Mar 3, 2021, 4:11:26 AM3/3/21
to
a definable value in the first place :)
David Brown
Mar 3, 2021, 4:23:18 AM3/3/21
to
On 03/03/2021 09:50, Juha Nieminen wrote:
> David Brown <david...@hesbynett.no> wrote:
>> I think Pete Olcott already said that he was not a mathematician. So
>> that means he is not constrained by such simple mathematical logic, and
>> can solve the impossible in an way that mathematicians cannot.
>>
>> You know, in the same way that non-physicists are not constrained by
>> physical laws that they don't understand, and can thus make moon rockets
>> in their garage powered by gravity-repulsive paint.
>
> I haven't followed what he has written and said about his approach, but
> if I were to guess, he's probably doing the same thing as so many other
> pseudomathematicians do with such things, when trying to contradict
> well-established corroborated mathematical proofs: Simply *redefine*
> the original problem so that it (possibly) fits his "proof".
I don't think anyone, including Olcott himself, really understands what
> David Brown <david...@hesbynett.no> wrote:
>> I think Pete Olcott already said that he was not a mathematician. So
>> that means he is not constrained by such simple mathematical logic, and
>> can solve the impossible in an way that mathematicians cannot.
>>
>> You know, in the same way that non-physicists are not constrained by
>> physical laws that they don't understand, and can thus make moon rockets
>> in their garage powered by gravity-repulsive paint.
>
> I haven't followed what he has written and said about his approach, but
> if I were to guess, he's probably doing the same thing as so many other
> pseudomathematicians do with such things, when trying to contradict
> well-established corroborated mathematical proofs: Simply *redefine*
> the original problem so that it (possibly) fits his "proof".
he is trying to do - though I haven't bothered following the details
either. He seems to propose some kind of simulator (for x86 assembly,
bizarrely, rather than the usual Turing machine or similar) with all
programs reduced to a "u32" type. Programs are split into a "decidable"
bit and an "undecidable" bit, and he avoids the usual never-ending
execution of the halting decider by only simulating the "decidable" bit.
>
> A bit like trying to redefine the value of pi so that a proof of
> squaring the circle becomes correct. (This is an actual real-life
> example.)
>
quite a bit about what works and doesn't work, by trying to solve that
kind of problem. And for those that really think they have got the
answer, they can learn about peer review and academic criticism. (There
are some people, of course, who never listen and never learn - Olcott
seems to be one of them.)
Perhaps Olcott could try a political solution, as Edward Goodwin did -
when the laws of mathematics stopped him from squaring the circle, he
tried to get the "Indiana Pi Bill" passed to trump the mathematical laws.
Juha Nieminen
Mar 3, 2021, 4:39:15 AM3/3/21
to
mick...@potatofield.co.uk wrote:
>>A bit like trying to redefine the value of pi so that a proof of
>>squaring the circle becomes correct. (This is an actual real-life
>>example.)
>
> Strictly speaking pi is an irrational number so doesn't actually have
> a definable value in the first place :)
Of course it does. Pi is a computable number, so it can perfectly well
>>A bit like trying to redefine the value of pi so that a proof of
>>squaring the circle becomes correct. (This is an actual real-life
>>example.)
>
> Strictly speaking pi is an irrational number so doesn't actually have
> a definable value in the first place :)
be defined, and computed to an arbitrary accuracy, using a finite
description.
Irrationality in itself has nothing to do with the squaring the
circle problem. The square root of 2 is irrational, but if the square
root could be used to define the area of a circle then it could be
"squared" as per the original problem description.
(The reason why the circle cannot be squared (using the tools in
the original problem) is because pi is not an algebraic number.)
Paavo Helde
Mar 3, 2021, 4:54:11 AM3/3/21
to
03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>
> Strictly speaking pi is an irrational number so doesn't actually have
> a definable value in the first place :)
You are confusing "definable" with "exactly representable in my favorite
>
> Strictly speaking pi is an irrational number so doesn't actually have
> a definable value in the first place :)
notation".
The value of pi can be defined with no problems, and it can be also
represented exactly. The most common exact representation makes use of a
Greek letter.
mick...@potatofield.co.uk
Mar 3, 2021, 4:56:26 AM3/3/21
to
On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>>>A bit like trying to redefine the value of pi so that a proof of
>>>squaring the circle becomes correct. (This is an actual real-life
>>>example.)
>>
>> Strictly speaking pi is an irrational number so doesn't actually have
>> a definable value in the first place :)
>
>Of course it does. Pi is a computable number, so it can perfectly well
>be defined, and computed to an arbitrary accuracy, using a finite
>description.
You really are an aspie arn't you. You can't even spot a light heated remark
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>>>A bit like trying to redefine the value of pi so that a proof of
>>>squaring the circle becomes correct. (This is an actual real-life
>>>example.)
>>
>> Strictly speaking pi is an irrational number so doesn't actually have
>> a definable value in the first place :)
>
>Of course it does. Pi is a computable number, so it can perfectly well
>be defined, and computed to an arbitrary accuracy, using a finite
>description.
when its signposted with a smiley.
But if you want to be pedantic irrational numbers cannot be represented by
the ratio of 2 integers therefor their true value is unknown and always will
be.
mick...@potatofield.co.uk
Mar 3, 2021, 5:12:54 AM3/3/21
to
On Wed, 3 Mar 2021 11:53:57 +0200
Paavo Helde <myfir...@osa.pri.ee> wrote:
>03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>>
>> Strictly speaking pi is an irrational number so doesn't actually have
>> a definable value in the first place :)
>
>You are confusing "definable" with "exactly representable in my favorite
>notation".
It would appear you are confusing definable with representable. Infinity
Paavo Helde <myfir...@osa.pri.ee> wrote:
>03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>>
>> Strictly speaking pi is an irrational number so doesn't actually have
>> a definable value in the first place :)
>
>You are confusing "definable" with "exactly representable in my favorite
>notation".
can be represented, that doesn't mean it can be defined especially given
there are numerous different types.
>The value of pi can be defined with no problems, and it can be also
>represented exactly. The most common exact representation makes use of a
>Greek letter.
Chris M. Thomasson
Mar 3, 2021, 5:24:55 AM3/3/21
to
precision. Say, I need at least 301 digits of pi to accurately work with
a certain fractal formula in a very deep zoom that uses an arbitrary
floating number package. Anything less than 301 digits of precision will
tend to start to creating "artifacts" that with ruin the rendering.
David Brown
Mar 3, 2021, 5:48:23 AM3/3/21
to
On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> mick...@potatofield.co.uk wrote:
>>>> A bit like trying to redefine the value of pi so that a proof of
>>>> squaring the circle becomes correct. (This is an actual real-life
>>>> example.)
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>> Of course it does. Pi is a computable number, so it can perfectly well
>> be defined, and computed to an arbitrary accuracy, using a finite
>> description.
>
> You really are an aspie arn't you. You can't even spot a light heated remark
> when its signposted with a smiley.
A smiley works to indicate a joke like this when it is clear that the
> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> mick...@potatofield.co.uk wrote:
>>>> A bit like trying to redefine the value of pi so that a proof of
>>>> squaring the circle becomes correct. (This is an actual real-life
>>>> example.)
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>> Of course it does. Pi is a computable number, so it can perfectly well
>> be defined, and computed to an arbitrary accuracy, using a finite
>> description.
>
> You really are an aspie arn't you. You can't even spot a light heated remark
> when its signposted with a smiley.
poster knows that what they are writing is obviously and completely wrong.
>
> But if you want to be pedantic irrational numbers cannot be represented by
> the ratio of 2 integers therefor their true value is unknown and always will
> be.
>
with the mathematics at this level. (Nothing wrong with that, of course
- few people know or care what in means to be "computable".) The true
value of π is known - it is π. It can't be written as a finite decimal
expansion, but that has nothing to do with its "true value" - it's just
a representation. (As an interesting aside, if you write π using a
hexadecimal expansion, you can calculate any given digit without having
to calculate the preceding digits. Weird and fascinating, IMHO.)
And "pedantic" is a compliment to a mathematician!
David Brown
Mar 3, 2021, 6:07:42 AM3/3/21
to
On 03/03/2021 11:12, mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 11:53:57 +0200
> Paavo Helde <myfir...@osa.pri.ee> wrote:
>> 03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>> You are confusing "definable" with "exactly representable in my favorite
>> notation".
>
> It would appear you are confusing definable with representable.
No, he is not.
> On Wed, 3 Mar 2021 11:53:57 +0200
> Paavo Helde <myfir...@osa.pri.ee> wrote:
>> 03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>> You are confusing "definable" with "exactly representable in my favorite
>> notation".
>
> It would appear you are confusing definable with representable.
> Infinity
> can be represented, that doesn't mean it can be defined especially given
> there are numerous different types.
interest. Infinities are not computable numbers, but they are well-defined.
>
>> The value of pi can be defined with no problems, and it can be also
>> represented exactly. The most common exact representation makes use of a
>> Greek letter.
>
> I don't think you understand the meaning of an irrational number.
>
that the others in this branch of the thread know exactly what the term
means.
The irrationality of pi is not relevant as to why its square root is not
constructable with ruler-and-compass geometry. √2 is irrational,
constructable, algebraic, and computable. π is irrational,
non-constructable, non-algebraic (transcendental) and computable - as is √π.
Juha Nieminen
Mar 3, 2021, 6:17:00 AM3/3/21
to
mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>mick...@potatofield.co.uk wrote:
>>>>A bit like trying to redefine the value of pi so that a proof of
>>>>squaring the circle becomes correct. (This is an actual real-life
>>>>example.)
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>>Of course it does. Pi is a computable number, so it can perfectly well
>>be defined, and computed to an arbitrary accuracy, using a finite
>>description.
>
> You really are an aspie arn't you. You can't even spot a light heated remark
> when its signposted with a smiley.
There is no joke in your statement. It's an assertion with no punchline
> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>mick...@potatofield.co.uk wrote:
>>>>A bit like trying to redefine the value of pi so that a proof of
>>>>squaring the circle becomes correct. (This is an actual real-life
>>>>example.)
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>>Of course it does. Pi is a computable number, so it can perfectly well
>>be defined, and computed to an arbitrary accuracy, using a finite
>>description.
>
> You really are an aspie arn't you. You can't even spot a light heated remark
> when its signposted with a smiley.
or anything. And it's an incorrect assertion.
> But if you want to be pedantic irrational numbers cannot be represented by
> the ratio of 2 integers therefor their true value is unknown and always will
> be.
non-recurring decimal expansion".
Pi is a computable number, and therefore it's perfectly well definable.
mick...@potatofield.co.uk
Mar 3, 2021, 6:27:20 AM3/3/21
to
On Wed, 3 Mar 2021 11:48:12 +0100
David Brown <david...@hesbynett.no> wrote:
>On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> mick...@potatofield.co.uk wrote:
>>>>> A bit like trying to redefine the value of pi so that a proof of
>>>>> squaring the circle becomes correct. (This is an actual real-life
>>>>> example.)
>>>>
>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>> a definable value in the first place :)
>>>
>>> Of course it does. Pi is a computable number, so it can perfectly well
>>> be defined, and computed to an arbitrary accuracy, using a finite
>>> description.
>>
>> You really are an aspie arn't you. You can't even spot a light heated remark
>> when its signposted with a smiley.
>
>A smiley works to indicate a joke like this when it is clear that the
>poster knows that what they are writing is obviously and completely wrong.
Ok, define the value of Pi then. And I don't mean just C/D.
David Brown <david...@hesbynett.no> wrote:
>On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> mick...@potatofield.co.uk wrote:
>>>>> A bit like trying to redefine the value of pi so that a proof of
>>>>> squaring the circle becomes correct. (This is an actual real-life
>>>>> example.)
>>>>
>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>> a definable value in the first place :)
>>>
>>> Of course it does. Pi is a computable number, so it can perfectly well
>>> be defined, and computed to an arbitrary accuracy, using a finite
>>> description.
>>
>> You really are an aspie arn't you. You can't even spot a light heated remark
>> when its signposted with a smiley.
>
>A smiley works to indicate a joke like this when it is clear that the
>poster knows that what they are writing is obviously and completely wrong.
>> But if you want to be pedantic irrational numbers cannot be represented by
>> the ratio of 2 integers therefor their true value is unknown and always will
>> be.
>>
>
>However, when you write this is is clear that you are not very familiar
>with the mathematics at this level. (Nothing wrong with that, of course
>- few people know or care what in means to be "computable".) The true
>value of π is known - it is π. It can't be written as a finite decimal
is not a value - its a symbol.
mick...@potatofield.co.uk
Mar 3, 2021, 6:29:22 AM3/3/21
to
On Wed, 3 Mar 2021 11:16:47 +0000 (UTC)
don't know what "light hearted" means. But then English is a 2nd or 3rd
language for you so fair enough.
>Pi is a computable number, and therefore it's perfectly well definable.
Define it then.
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>mick...@potatofield.co.uk wrote:
>>>>>A bit like trying to redefine the value of pi so that a proof of
>>>>>squaring the circle becomes correct. (This is an actual real-life
>>>>>example.)
>>>>
>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>> a definable value in the first place :)
>>>
>>>Of course it does. Pi is a computable number, so it can perfectly well
>>>be defined, and computed to an arbitrary accuracy, using a finite
>>>description.
>>
>> You really are an aspie arn't you. You can't even spot a light heated remark
>> when its signposted with a smiley.
>
>There is no joke in your statement. It's an assertion with no punchline
>or anything. And it's an incorrect assertion.
Thank you for proving my point so emphatically and also proving that you
>mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>mick...@potatofield.co.uk wrote:
>>>>>A bit like trying to redefine the value of pi so that a proof of
>>>>>squaring the circle becomes correct. (This is an actual real-life
>>>>>example.)
>>>>
>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>> a definable value in the first place :)
>>>
>>>Of course it does. Pi is a computable number, so it can perfectly well
>>>be defined, and computed to an arbitrary accuracy, using a finite
>>>description.
>>
>> You really are an aspie arn't you. You can't even spot a light heated remark
>> when its signposted with a smiley.
>
>There is no joke in your statement. It's an assertion with no punchline
>or anything. And it's an incorrect assertion.
don't know what "light hearted" means. But then English is a 2nd or 3rd
language for you so fair enough.
>Pi is a computable number, and therefore it's perfectly well definable.
Chris M. Thomasson
Mar 3, 2021, 6:50:32 AM3/3/21
to
On 3/3/2021 3:27 AM, mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 11:48:12 +0100
> David Brown <david...@hesbynett.no> wrote:
>> On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
>>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>> mick...@potatofield.co.uk wrote:
>>>>>> A bit like trying to redefine the value of pi so that a proof of
>>>>>> squaring the circle becomes correct. (This is an actual real-life
>>>>>> example.)
>>>>>
>>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>>> a definable value in the first place :)
>>>>
>>>> Of course it does. Pi is a computable number, so it can perfectly well
>>>> be defined, and computed to an arbitrary accuracy, using a finite
>>>> description.
>>>
>>> You really are an aspie arn't you. You can't even spot a light heated remark
>>> when its signposted with a smiley.
>>
>> A smiley works to indicate a joke like this when it is clear that the
>> poster knows that what they are writing is obviously and completely wrong.
>
> Ok, define the value of Pi then. And I don't mean just C/D.
[...]
> On Wed, 3 Mar 2021 11:48:12 +0100
> David Brown <david...@hesbynett.no> wrote:
>> On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
>>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>> mick...@potatofield.co.uk wrote:
>>>>>> A bit like trying to redefine the value of pi so that a proof of
>>>>>> squaring the circle becomes correct. (This is an actual real-life
>>>>>> example.)
>>>>>
>>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>>> a definable value in the first place :)
>>>>
>>>> Of course it does. Pi is a computable number, so it can perfectly well
>>>> be defined, and computed to an arbitrary accuracy, using a finite
>>>> description.
>>>
>>> You really are an aspie arn't you. You can't even spot a light heated remark
>>> when its signposted with a smiley.
>>
>> A smiley works to indicate a joke like this when it is clear that the
>> poster knows that what they are writing is obviously and completely wrong.
>
> Ok, define the value of Pi then. And I don't mean just C/D.
atan(1) * 4 ? pi is pi.
Infinite precision... ;^)
David Brown
Mar 3, 2021, 7:32:51 AM3/3/21
to
On 03/03/2021 12:27, mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 11:48:12 +0100
> David Brown <david...@hesbynett.no> wrote:
>> On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
>>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>> mick...@potatofield.co.uk wrote:
>>>>>> A bit like trying to redefine the value of pi so that a proof of
>>>>>> squaring the circle becomes correct. (This is an actual real-life
>>>>>> example.)
>>>>>
>>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>>> a definable value in the first place :)
>>>>
>>>> Of course it does. Pi is a computable number, so it can perfectly well
>>>> be defined, and computed to an arbitrary accuracy, using a finite
>>>> description.
>>>
>>> You really are an aspie arn't you. You can't even spot a light heated remark
>>> when its signposted with a smiley.
>>
>> A smiley works to indicate a joke like this when it is clear that the
>> poster knows that what they are writing is obviously and completely wrong.
>
> Ok, define the value of Pi then. And I don't mean just C/D.
Defining pi as the ratio of circumference to diameter of any circle is a
> On Wed, 3 Mar 2021 11:48:12 +0100
> David Brown <david...@hesbynett.no> wrote:
>> On 03/03/2021 10:56, mick...@potatofield.co.uk wrote:
>>> On Wed, 3 Mar 2021 09:39:03 +0000 (UTC)
>>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>> mick...@potatofield.co.uk wrote:
>>>>>> A bit like trying to redefine the value of pi so that a proof of
>>>>>> squaring the circle becomes correct. (This is an actual real-life
>>>>>> example.)
>>>>>
>>>>> Strictly speaking pi is an irrational number so doesn't actually have
>>>>> a definable value in the first place :)
>>>>
>>>> Of course it does. Pi is a computable number, so it can perfectly well
>>>> be defined, and computed to an arbitrary accuracy, using a finite
>>>> description.
>>>
>>> You really are an aspie arn't you. You can't even spot a light heated remark
>>> when its signposted with a smiley.
>>
>> A smiley works to indicate a joke like this when it is clear that the
>> poster knows that what they are writing is obviously and completely wrong.
>
> Ok, define the value of Pi then. And I don't mean just C/D.
perfectly good definition. But you can have lots of other definitions,
all of which are equivalent, including Chris' suggestion :
π = 4.tan⁻¹(1)
or, if you prefer, the limit of
π = 4 - 4/3 + 4/5 - 4/7 + 4/9 - ...
You can define it as the first positive solution "x" to
e ^ ix = -1
All of these uniquely specify a single number - that makes them definitions.
>
>>> But if you want to be pedantic irrational numbers cannot be represented by
>>> the ratio of 2 integers therefor their true value is unknown and always will
>>> be.
>>>
>>
>> However, when you write this is is clear that you are not very familiar
>> with the mathematics at this level. (Nothing wrong with that, of course
>
> So you are, good, then see above. Off you go...
So, what do /you/ mean when you say "true value", or that the "true
value" of a number is known? Do you just mean that when written down in
decimal, the representation is either finite or ends in an infinite
repetition of a finite sequence? That's a useful classification - so
useful, that we give it a name: "the rational numbers". (It is an
equivalent way to define them.) But mathematics does not pretend that
only such numbers have a "true value".
>
>> - few people know or care what in means to be "computable".) The true
>> value of π is known - it is π. It can't be written as a finite decimal
>
> It can't be written as a finite expansion in any number base and a symbol
> is not a value - its a symbol.
>
with - using a positive integer greater than 1 as the base. It is
perfectly valid, though somewhat obscure, to use other types of number
base. For example, π can be represented as 10 in base π.
You are mixing up representations and values here. A representation is
just how you write a value, and mathematicians use many different
representations for different purposes. Sometimes a given value can be
written finitely in a particular representation, sometimes not.
A good example would be the right angle. This is a well-defined
concept, with a well-defined value. Represented in degrees, it is 90°,
which in turn has a finite decimal representation. Represented in
radians, it is π/2, which does not have a finite decimal representation.
But the radian representation in different symbols is clear and finite.
Equally, 1 radian is easily and finitely represented in decimal, while
the degrees representation of the same angle is 180/π, which does not
have a finite representation in decimal.
In a desperate and feeble attempt to get on-topic for the group, the
value of a C++ object is not dependent on how you choose to display it
using an ostream.
Juha Nieminen
Mar 3, 2021, 7:37:58 AM3/3/21
to
mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 11:53:57 +0200
> Paavo Helde <myfir...@osa.pri.ee> wrote:
>>03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>>You are confusing "definable" with "exactly representable in my favorite
>>notation".
>
> It would appear you are confusing definable with representable. Infinity
> can be represented, that doesn't mean it can be defined especially given
> there are numerous different types.
Maybe you should specify what you mean by "definable".
> On Wed, 3 Mar 2021 11:53:57 +0200
> Paavo Helde <myfir...@osa.pri.ee> wrote:
>>03.03.2021 11:11 mick...@potatofield.co.uk kirjutas:
>>>
>>> Strictly speaking pi is an irrational number so doesn't actually have
>>> a definable value in the first place :)
>>
>>You are confusing "definable" with "exactly representable in my favorite
>>notation".
>
> It would appear you are confusing definable with representable. Infinity
> can be represented, that doesn't mean it can be defined especially given
> there are numerous different types.
The number pi can certainly be defined in a completely unambiguous way
with a finite expression. Just because it may have an infinite non-recurring
decimal expansion doesn't mean it can't be defined.
https://en.wikipedia.org/wiki/Definable_real_number
There exist real numbers that cannot be defined (with a finite expression),
and in fact almost all real numbers are like that, but pi is not one
of them.
Juha Nieminen
Mar 3, 2021, 7:41:46 AM3/3/21
to
mick...@potatofield.co.uk wrote:
> Thank you for proving my point so emphatically and also proving that you
> don't know what "light hearted" means. But then English is a 2nd or 3rd
> language for you so fair enough.
And assholery seems to be your first language.
> Thank you for proving my point so emphatically and also proving that you
> don't know what "light hearted" means. But then English is a 2nd or 3rd
> language for you so fair enough.
>>Pi is a computable number, and therefore it's perfectly well definable.
>
> Define it then.
Maybe you don't understand what a "definable number" is.
https://en.wikipedia.org/wiki/Definable_real_number
Paavo Helde
Mar 3, 2021, 7:46:27 AM3/3/21
to
[math]
\pi = \int_{-\infty}^\infty {dx \over 1+x^2}
[/math]
https://en.wikipedia.org/wiki/Pi#cite_note-16
(Remmert, Reinhold (2012). "Ch. 5 What is π?". In Heinz-Dieter
Ebbinghaus; Hans Hermes; Friedrich Hirzebruch; Max Koecher; Klaus
Mainzer; Jürgen Neukirch; Alexander Prestel; Reinhold Remmert (eds.).
Numbers. Springer. ISBN 978-1-4612-1005-4.)
mick...@potatofield.co.uk
Mar 3, 2021, 9:43:52 AM3/3/21
to
On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>> Thank you for proving my point so emphatically and also proving that you
>> don't know what "light hearted" means. But then English is a 2nd or 3rd
>> language for you so fair enough.
>
>And assholery seems to be your first language.
Its spelt arsehole in England - the clue is in the name of the language. If I
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>> Thank you for proving my point so emphatically and also proving that you
>> don't know what "light hearted" means. But then English is a 2nd or 3rd
>> language for you so fair enough.
>
>And assholery seems to be your first language.
wanted to learn proper Finnish I wouldn't go to Sweden.
>>>Pi is a computable number, and therefore it's perfectly well definable.
>>
>> Define it then.
>
>It's the ratio between the circumference and the diameter of a circle.
>
>Maybe you don't understand what a "definable number" is.
>
>https://en.wikipedia.org/wiki/Definable_real_number
Juha Nieminen
Mar 3, 2021, 12:06:12 PM3/3/21
to
mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>mick...@potatofield.co.uk wrote:
>>> Thank you for proving my point so emphatically and also proving that you
>>> don't know what "light hearted" means. But then English is a 2nd or 3rd
>>> language for you so fair enough.
>>
>>And assholery seems to be your first language.
>
> Its spelt arsehole in England - the clue is in the name of the language. If I
> wanted to learn proper Finnish I wouldn't go to Sweden.
And then you call me an "aspie".
> On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>mick...@potatofield.co.uk wrote:
>>> Thank you for proving my point so emphatically and also proving that you
>>> don't know what "light hearted" means. But then English is a 2nd or 3rd
>>> language for you so fair enough.
>>
>>And assholery seems to be your first language.
>
> Its spelt arsehole in England - the clue is in the name of the language. If I
> wanted to learn proper Finnish I wouldn't go to Sweden.
>>>>Pi is a computable number, and therefore it's perfectly well definable.
>>>
>>> Define it then.
>>
>>It's the ratio between the circumference and the diameter of a circle.
>>
>>Maybe you don't understand what a "definable number" is.
>>
>>https://en.wikipedia.org/wiki/Definable_real_number
>
> I guess its a case of defining define.
to be a definable number?
mick...@potatofield.co.uk
Mar 3, 2021, 12:11:47 PM3/3/21
to
On Wed, 3 Mar 2021 17:05:55 +0000 (UTC)
>> I guess its a case of defining define.
>
>Let me ask it this way: Why do you consider a fraction, like 1/3,
>to be a definable number?
It has a quantifiable value.
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>mick...@potatofield.co.uk wrote:
>>>> Thank you for proving my point so emphatically and also proving that you
>>>> don't know what "light hearted" means. But then English is a 2nd or 3rd
>>>> language for you so fair enough.
>>>
>>>And assholery seems to be your first language.
>>
>> Its spelt arsehole in England - the clue is in the name of the language. If I
>
>> wanted to learn proper Finnish I wouldn't go to Sweden.
>
>And then you call me an "aspie".
Just being helpful :)
>mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 12:41:33 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>mick...@potatofield.co.uk wrote:
>>>> Thank you for proving my point so emphatically and also proving that you
>>>> don't know what "light hearted" means. But then English is a 2nd or 3rd
>>>> language for you so fair enough.
>>>
>>>And assholery seems to be your first language.
>>
>> Its spelt arsehole in England - the clue is in the name of the language. If I
>
>> wanted to learn proper Finnish I wouldn't go to Sweden.
>
>And then you call me an "aspie".
>> I guess its a case of defining define.
>
>Let me ask it this way: Why do you consider a fraction, like 1/3,
>to be a definable number?
olcott
Mar 3, 2021, 1:52:55 PM3/3/21
to
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
All of the halting problem proofs are based on the fact that it is
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
impossible for Halts() to return a correct halting decision to H_Hat()
because H_Hat() contradicts whatever value that Halts() returns.
All of these same proofs ignore the fact that every halt decider that
bases its halt decision on examining the execution trace of its own
simulation of its input never reaches the point in the execution trace
where it would return a value to H_Hat().
>> On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
>>> A computation that would not halt if its simulation were not
>>> halted is indeed a non-halting computation.
That I have shown how a halt decider could examine such an execution
trace to determine that its input would not halt unless the simulation
of this input was terminated proves that these computations are halt
decidable.
olcott
Mar 3, 2021, 1:55:42 PM3/3/21
to
Juha Nieminen
Mar 3, 2021, 4:01:03 PM3/3/21
to
mick...@potatofield.co.uk wrote:
>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>to be a definable number?
>
> It has a quantifiable value.
What does that even mean?
>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>to be a definable number?
>
> It has a quantifiable value.
I think you are making stuff up as you go.
Keith Thompson
Mar 3, 2021, 5:18:57 PM3/3/21
to
original topic of this thread. I suggest not replying.
--
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
Mar 3, 2021, 6:06:06 PM3/3/21
to
On 3/3/2021 4:18 PM, Keith Thompson wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> mick...@potatofield.co.uk wrote:
>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>> to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>> What does that even mean?
>>
>> I think you are making stuff up as you go.
>
> I think he's making stuff up that has even less to do with C++ than the
> original topic of this thread. I suggest not replying.
>
Here is the original topic of this thread completely rewritten.
> Juha Nieminen <nos...@thanks.invalid> writes:
>> mick...@potatofield.co.uk wrote:
>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>> to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>> What does that even mean?
>>
>> I think you are making stuff up as you go.
>
> I think he's making stuff up that has even less to do with C++ than the
> original topic of this thread. I suggest not replying.
>
Criteria for deciding that H_Hat() calls Simulate() in infinite
recursion. I need to have this criteria validated.
(1) The execution trace of H_Hat() shows that it calls Simulate() from
the same machine address two times in sequence with the same data.
(2) It is assumed that Simulate() either directly invokes its input (as
shown below) or Simulate() emulates the execution of the x86 machine
language of its input (functionally equivalent to the direct execution
shown below).
Does everyone agree that the above criteria is sufficient to definitely
decide that H_Hat() is infinitely recursive?
#include <stdint.h>
#define u32 uint32_t
int Simulate(u32 P, u32 I)
{
((void(*)(u32))P)(I);
}
void H_Hat(u32 P)
{
Simulate(P, P);
}
int main()
{
Simulate((u32)H_Hat, (u32)H_Hat);
}
_Simulate()
[00000478](01) 55 push ebp
[00000479](02) 8bec mov ebp,esp
[0000047b](03) 8b450c mov eax,[ebp+0c]
[0000047e](01) 50 push eax
[0000047f](03) ff5508 call dword [ebp+08]
[00000482](03) 83c404 add esp,+04
[00000485](01) 5d pop ebp
[00000486](01) c3 ret
_H_Hat()
[00000868](01) 55 push ebp
[00000869](02) 8bec mov ebp,esp
[0000086b](03) 8b4508 mov eax,[ebp+08]
[0000086e](01) 50 push eax
[0000086f](03) 8b4d08 mov ecx,[ebp+08]
[00000872](01) 51 push ecx
[00000873](05) e800fcffff call 00000478
[00000878](03) 83c408 add esp,+08
[0000087b](01) 5d pop ebp
[0000087c](01) c3 ret
_main()
[00000888](01) 55 push ebp
[00000889](02) 8bec mov ebp,esp
[0000088b](05) 6868080000 push 00000868
[00000890](05) 6868080000 push 00000868
[00000895](05) e8defbffff call 00000478
[0000089a](03) 83c408 add esp,+08
[0000089d](02) 33c0 xor eax,eax
[0000089f](01) 5d pop ebp
[000008a0](01) c3 ret
Columns
(1) Sequence number
(2) Machine address of instruction
(3) Machine address of top of stack
(4) Value of top of stack after instruction executed
(5) Number of bytes of machine code
(6) Machine language bytes
(7) Assembly language text
(01)[00000888][00011194][00000000](01) 55 push ebp
(02)[00000889][00011194][00000000](02) 8bec mov ebp,esp
(03)[0000088b][00011190][00000868](05) 6868080000 push 00000868
(04)[00000890][0001118c][00000868](05) 6868080000 push 00000868
(05)[00000895][00011188][0000089a](05) e8defbffff call 00000478
(06)[00000868][00011178][00011184](01) 55 push ebp
(07)[00000869][00011178][00011184](02) 8bec mov ebp,esp
(08)[0000086b][00011178][00011184](03) 8b4508 mov eax,[ebp+08]
(09)[0000086e][00011174][00000868](01) 50 push eax
(10)[0000086f][00011174][00000868](03) 8b4d08 mov ecx,[ebp+08]
(11)[00000872][00011170][00000868](01) 51 push ecx
(12)[00000873][0001116c][00000878](05) e800fcffff call 00000478
Line (09) pushes second parameter to Simulate() machine address 0x878
Line (11) pushes first parameter to Simulate() machine address 0x878
Line (12) Calls Simulate(0x878, 0x878);
(13)[00000868][0001115c][00011168](01) 55 push ebp
(14)[00000869][0001115c][00011168](02) 8bec mov ebp,esp
(15)[0000086b][0001115c][00011168](03) 8b4508 mov eax,[ebp+08]
(16)[0000086e][00011158][00000868](01) 50 push eax
(17)[0000086f][00011158][00000868](03) 8b4d08 mov ecx,[ebp+08]
(18)[00000872][00011154][00000868](01) 51 push ecx
(19)[00000873][00011150][00000878](05) e800fcffff call 00000478
Line (16) pushes second parameter to Simulate() machine address 0x878
Line (18) pushes first parameter to Simulate() machine address 0x878
Line (19) Calls Simulate(0x878, 0x878);
(20)[00000868][00011140][0001114c](01) 55 push ebp
(21)[00000869][00011140][0001114c](02) 8bec mov ebp,esp
(22)[0000086b][00011140][0001114c](03) 8b4508 mov eax,[ebp+08]
(23)[0000086e][0001113c][00000868](01) 50 push eax
(24)[0000086f][0001113c][00000868](03) 8b4d08 mov ecx,[ebp+08]
(25)[00000872][00011138][00000868](01) 51 push ecx
(26)[00000873][00011134][00000878](05) e800fcffff call 00000478
Line (23) pushes second parameter to Simulate() machine address 0x878
Line (25) pushes first parameter to Simulate() machine address 0x878
Line (26) Calls Simulate(0x878, 0x878);
Now we have seen that Simulate() is invoked two times from the same
machine address of H_Hat() with the same data. We also know that
Simulate() either executes or emulates the machine language of its input
and nothing more. This seems to provide a sufficient basis for deciding
that H_Hat() is infinitely recursive, thus non-halting.
mick...@potatofield.co.uk
Mar 4, 2021, 4:23:47 AM3/4/21
to
On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>to be a definable number?
>>
>> It has a quantifiable value.
>
>What does that even mean?
It means it has a value that can be written down using actual numbers.
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>to be a definable number?
>>
>> It has a quantifiable value.
>
>What does that even mean?
>I think you are making stuff up as you go.
for not following everything.
mick...@potatofield.co.uk
Mar 4, 2021, 4:24:12 AM3/4/21
to
On Wed, 03 Mar 2021 14:18:44 -0800
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Juha Nieminen <nos...@thanks.invalid> writes:
>> mick...@potatofield.co.uk wrote:
>>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>> What does that even mean?
>>
>> I think you are making stuff up as you go.
>
>I think he's making stuff up that has even less to do with C++ than the
>original topic of this thread. I suggest not replying.
You do realise this is usenet? Topics drift.
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Juha Nieminen <nos...@thanks.invalid> writes:
>> mick...@potatofield.co.uk wrote:
>>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>> What does that even mean?
>>
>> I think you are making stuff up as you go.
>
>I think he's making stuff up that has even less to do with C++ than the
>original topic of this thread. I suggest not replying.
David Brown
Mar 4, 2021, 5:42:27 AM3/4/21
to
On 04/03/2021 10:23, mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> mick...@potatofield.co.uk wrote:
>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>> to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>> What does that even mean?
>
> It means it has a value that can be written down using actual numbers.
That is not what it would mean to a mathematician. It's good enough,
> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> mick...@potatofield.co.uk wrote:
>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>> to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>> What does that even mean?
>
> It means it has a value that can be written down using actual numbers.
perhaps, for a lot school maths. At a higher level, the term "number"
can be dependent on the context. /You/ probably just mean "decimal
digit", judging by your comment here. But to anyone interested in
mathematics beyond school level, "number" will usually mean "real
number" unless context dictates something else (integer, complex number,
transfinite number, length of a line, etc.).
You can't have a sensible conversation about mathematics (or indeed any
topic) if you insist on using your own limited definitions that are
different from other people's. You just make yourself look silly,
arguing about "defined values" when all you are trying to say is basic
facts about rational numbers that are well known to everyone else in the
thread.
Here's a clue for you - when everyone else in the discussion agrees with
each other, and disagrees with you, then either you have got your terms
wrong, or you are out of your depth. Many of us are happy to give you
pointers on what you are getting wrong here, but you have to cooperate
and understand that you /are/ wrong, rather than responding with insults
and totally misplaced patronisation.
>
>> I think you are making stuff up as you go.
>
> As I've said before, English is not your first language so I won't blame you
> for not following everything.
>
point out a dozen (minor) errors in the spelling and grammar of your
posts in this thread - I'm not sure I could find any in Juha's posts.
It would certainly be petty of me to do so, but hopefully you can see
the inappropriateness of railing on Juha's language skills.
mick...@potatofield.co.uk
Mar 4, 2021, 5:56:55 AM3/4/21
to
On Thu, 4 Mar 2021 11:42:12 +0100
David Brown <david...@hesbynett.no> wrote:
>On 04/03/2021 10:23, mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> mick...@potatofield.co.uk wrote:
>>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>> to be a definable number?
>>>>
>>>> It has a quantifiable value.
>>>
>>> What does that even mean?
>>
>> It means it has a value that can be written down using actual numbers.
>
>That is not what it would mean to a mathematician. It's good enough,
>perhaps, for a lot school maths. At a higher level, the term "number"
>can be dependent on the context. /You/ probably just mean "decimal
>digit", judging by your comment here. But to anyone interested in
>mathematics beyond school level, "number" will usually mean "real
>number" unless context dictates something else (integer, complex number,
>transfinite number, length of a line, etc.).
Oh ok, thanks for the heads up there Euclid.
David Brown <david...@hesbynett.no> wrote:
>On 04/03/2021 10:23, mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> mick...@potatofield.co.uk wrote:
>>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>> to be a definable number?
>>>>
>>>> It has a quantifiable value.
>>>
>>> What does that even mean?
>>
>> It means it has a value that can be written down using actual numbers.
>
>That is not what it would mean to a mathematician. It's good enough,
>perhaps, for a lot school maths. At a higher level, the term "number"
>can be dependent on the context. /You/ probably just mean "decimal
>digit", judging by your comment here. But to anyone interested in
>mathematics beyond school level, "number" will usually mean "real
>number" unless context dictates something else (integer, complex number,
>transfinite number, length of a line, etc.).
>> As I've said before, English is not your first language so I won't blame you
>> for not following everything.
>>
>
>Juha's written English is more accurate than yours. I believe I could
>point out a dozen (minor) errors in the spelling and grammar of your
>posts in this thread - I'm not sure I could find any in Juha's posts.
>It would certainly be petty of me to do so, but hopefully you can see
>the inappropriateness of railing on Juha's language skills.
I can speak passable French but I write it like a Martian. Far more useful
than the other way around.
No kindly shove your patronising attitude up your arse and fuck off.
David Brown
Mar 4, 2021, 6:21:47 AM3/4/21
to
On 04/03/2021 11:56, mick...@potatofield.co.uk wrote:
<snip the irrelevant bits>
If you value comprehension of what people write, then try re-reading the
thread and comprehending what others have said. Once you have
understood where you went wrong, you'll perhaps have learned something.
In the meantime, perhaps we could get back to C++.
<snip the irrelevant bits>
If you value comprehension of what people write, then try re-reading the
thread and comprehending what others have said. Once you have
understood where you went wrong, you'll perhaps have learned something.
In the meantime, perhaps we could get back to C++.
Bonita Montero
Mar 4, 2021, 7:10:05 AM3/4/21
to
Can you pleas stop posting things not related to C/C++-language
issues to comp.lang.c++/c ?
issues to comp.lang.c++/c ?
Juha Nieminen
Mar 4, 2021, 8:56:51 AM3/4/21
to
mick...@potatofield.co.uk wrote:
> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>mick...@potatofield.co.uk wrote:
>>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>>What does that even mean?
>
> It means it has a value that can be written down using actual numbers.
You can't write the entire decimal expansion of 1/3.
> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>mick...@potatofield.co.uk wrote:
>>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>to be a definable number?
>>>
>>> It has a quantifiable value.
>>
>>What does that even mean?
>
> It means it has a value that can be written down using actual numbers.
Consider *why* you think that you can, and then consider how is that
different from, for example, sqrt(2) or pi.
(Hint: What you can do is give a description, a definition, an algorithm
to write arbitrarily many of the digits of the decimal expansion of
that number. The same is true for all three examples above.)
sqrt(2) and pi are not any less "well-defined" as 1/3 is. The exact
algorithm to print out arbitrarily many digits of their decimal expansion
may be a bit more complicated, but that means nothing in this context.
>>I think you are making stuff up as you go.
>
> As I've said before, English is not your first language so I won't blame you
> for not following everything.
Ironically, I think I know English better than you. At least I know what a
"definable number" is.
MrM...@edgeoftheuniverse.com
Mar 4, 2021, 10:35:06 AM3/4/21
to
On Thu, 4 Mar 2021 13:56:37 +0000 (UTC)
written in a number of bases since its rational number. An irrational number
cannot be written down in ANY real base.
Juha Nieminen <nos...@thanks.invalid> wrote:
>mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>mick...@potatofield.co.uk wrote:
>>>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>>to be a definable number?
>>>>
>>>> It has a quantifiable value.
>>>
>>>What does that even mean?
>>
>> It means it has a value that can be written down using actual numbers.
>
>You can't write the entire decimal expansion of 1/3.
At the risk of getting drawn into this - the expansion of 1/3 can easily be
>mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>mick...@potatofield.co.uk wrote:
>>>>>Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>>to be a definable number?
>>>>
>>>> It has a quantifiable value.
>>>
>>>What does that even mean?
>>
>> It means it has a value that can be written down using actual numbers.
>
>You can't write the entire decimal expansion of 1/3.
written in a number of bases since its rational number. An irrational number
cannot be written down in ANY real base.
olcott
Mar 4, 2021, 10:46:14 AM3/4/21
to
David Brown
Mar 4, 2021, 11:19:34 AM3/4/21
to
number - there is nothing (except perhaps a concern for your own sanity)
stopping you using base π positional number systems. (Indeed, you don't
have to restrict yourself to real numbers.) Representations are all
just invented for convenience - you can invent any new own you like in
order to write down what you want. Simple integer base positional
numeral systems are merely the ones with which we are most familiar.
<https://en.wikipedia.org/wiki/Non-integer_base_of_numeration#Base_%CF%80>
You could define an "irrational number" as being a real number which
cannot be written using a finite sequence of digits in any integer base
representation. That would be a perfectly good definition - equivalent
to more common definitions.
But it bears no relationship to whether a number is "defined" or has a
"value". Mick's argument that π does not have a "defined value" because
you can't write it in a finite decimal expansion bears no more validity
than saying "a tenth" does not have a "defined value" because you can't
write it in Roman numerals.
Chris M. Thomasson
Mar 4, 2021, 1:00:55 PM3/4/21
to
On 3/4/2021 5:56 AM, Juha Nieminen wrote:
> mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> mick...@potatofield.co.uk wrote:
>>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>> to be a definable number?
>>>>
>>>> It has a quantifiable value.
>>>
>>> What does that even mean?
>>
>> It means it has a value that can be written down using actual numbers.
>
> You can't write the entire decimal expansion of 1/3.
0.333...
> mick...@potatofield.co.uk wrote:
>> On Wed, 3 Mar 2021 21:00:41 +0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> mick...@potatofield.co.uk wrote:
>>>>> Let me ask it this way: Why do you consider a fraction, like 1/3,
>>>>> to be a definable number?
>>>>
>>>> It has a quantifiable value.
>>>
>>> What does that even mean?
>>
>> It means it has a value that can be written down using actual numbers.
>
> You can't write the entire decimal expansion of 1/3.
;^)
Keith Thompson
Mar 4, 2021, 3:20:35 PM3/4/21
to
mick...@potatofield.co.uk writes:
[...]
Welcome to my killfile. I encourage others to do likewise.
[...]
> No kindly shove your patronising attitude up your arse and fuck off.
[...]
Welcome to my killfile. I encourage others to do likewise.
mickc...@vegetables.com
Mar 5, 2021, 5:11:15 AM3/5/21
to
On Thu, 04 Mar 2021 12:20:19 -0800
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>mick...@potatofield.co.uk writes:
>[...]
>> No kindly shove your patronising attitude up your arse and fuck off.
>[...]
>
>Welcome to my killfile. I encourage others to do likewise.
I hate to break the news to you, but killfiles stopped being any use sometime
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>mick...@potatofield.co.uk writes:
>[...]
>> No kindly shove your patronising attitude up your arse and fuck off.
>[...]
>
>Welcome to my killfile. I encourage others to do likewise.
around the early 90s.
Bonita Montero
Mar 7, 2021, 10:38:24 AM3/7/21
to
Detecting and handling infinite recursion is easy:
__try
{
...
}
__except( GetExceptionCode() == EXCEPTION_STACK_OVERFLOW ?
EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH )
{
...
}
Hrhr.
__try
{
...
}
__except( GetExceptionCode() == EXCEPTION_STACK_OVERFLOW ?
EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH )
{
...
}
Hrhr.
olcott
Mar 7, 2021, 10:55:10 AM3/7/21
to
halting problem counter examples on the basis of examining the x86
machine language execution trace of the H_Hat() invocations of Halts().
The halt decider decides that they are infinitely recursive, aborts its
simulation of H_Hat() and decides not halting.
Halts() has as its foundation a complete fully functional x86 emulator
that has "been on the market" for 25 years.
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
http://www.liarparadox.org/Eliminating_pathological_self_reference_error_from_the_halting_problem.pdf
olcott
Mar 9, 2021, 8:42:53 PM3/9/21
to
Eliminating pathological self-reference error from the halting problem
The pathological self reference error occurs whenever a question or
decision problem cannot be correctly answered because both of the yes/no
or true/false answers are contradicted.
If we ask Jack[1] this question: Will your answer to this question be no?
Neither answer of yes or no is correct because they are both contradicted.
When an input program is defined to do opposite of whatever the halt
decider decides about its halt status then we have the same pathological
self-reference error as Jack's question.
If the halt decider Halts() returns a value of true to H_Hat() then
H_Hat() would go into an infinite loop and never halt. If the halt
decider Halts() returns a value of false to H_Hat() then H_Hat would
immediately stop running.
The simplest way to define a halt decider is to make a program that
simply runs its input to see what it does. In technical terms this would
be a universal Turing machine (UTM) that has been adapted to become a
halt decider. This UTM would simply simulate the execution of its input
until its input halts on its own or the halt decider determines that its
input would never halt on its own and stops simulating it. In order for
the UTM to see what its input does it must keep track of an execution
trace of its input.
Every (at least partial) halt decider that decides the halting status of
its input on the basis of its examination of the execution trace of its
own simulation of this input would correctly decide the conventional
halting problem counter-examples as not halting.
The x86utm operating system was created so that halt deciders written in
the C programming language would be computationally equivalent to the
execution of actual Turing machines. These (at least partial) halt
deciders base their halting decision on examining the execution trace of
the x86 machine language of their input. The input is the COFF object
file output of a C compiler and is directly executed by the x86 emulator.
The halt decider Halts() determines that H_Hat() called it in infinite
recursion, on the basis of the x86 machine language execution trace
shown below, stop simulating its input, and decide not halting on the
basis that its input would not halt.
void H_Hat(u32 P)
{
u32 Input_Would_Halt = Halts(P, P);
if (Input_Would_Halt)
[0000088f](01) 55 push ebp
[00000890](02) 8bec mov ebp,esp
[00000892](01) 51 push ecx
[00000893](03) 8b4508 mov eax,[ebp+08]
[00000896](01) 50 push eax
[00000897](03) 8b4d08 mov ecx,[ebp+08]
[0000089a](01) 51 push ecx
[0000089b](05) e87ffeffff call 0000071f
[000008a0](03) 83c408 add esp,+08
[000008a3](03) 8945fc mov [ebp-04],eax
[000008a6](04) 837dfc00 cmp dword [ebp-04],+00
[000008aa](02) 7402 jz 000008ae
[000008ac](02) ebfe jmp 000008ac
[000008ae](02) 8be5 mov esp,ebp
[000008b0](01) 5d pop ebp
[000008b1](01) c3 ret
_main()
[000008bf](01) 55 push ebp
[000008c0](02) 8bec mov ebp,esp
[000008c2](01) 51 push ecx
[000008c3](05) 688f080000 push 0000088f
[000008c8](05) 688f080000 push 0000088f
[000008cd](05) e84dfeffff call 0000071f
[000008d2](03) 83c408 add esp,+08
[000008d5](03) 8945fc mov [ebp-04],eax
[000008d8](03) 8b45fc mov eax,[ebp-04]
[000008db](01) 50 push eax
[000008dc](05) 680b030000 push 0000030b
[000008e1](05) e869faffff call 0000034f
[000008e6](03) 83c408 add esp,+08
[000008e9](02) 33c0 xor eax,eax
[000008eb](02) 8be5 mov esp,ebp
[000008ed](01) 5d pop ebp
[000008ee](01) c3 ret
Columns
(1) Execution trace sequence number
(02)[000008c0][00011208][00000000](02) 8bec mov ebp,esp
(03)[000008c2][00011204][00000000](01) 51 push ecx
(04)[000008c3][00011200][0000088f](05) 688f080000 push 0000088f
(05)[000008c8][000111fc][0000088f](05) 688f080000 push 0000088f
(06)[000008cd][000111f8][000008d2](05) e84dfeffff call 0000071f
(07)[0000088f][00031288][0003128c](01) 55 push ebp
(08)[00000890][00031288][0003128c](02) 8bec mov ebp,esp
(09)[00000892][00031284][00021258](01) 51 push ecx
(10)[00000893][00031284][00021258](03) 8b4508 mov eax,[ebp+08]
(11)[00000896][00031280][0000088f](01) 50 push eax
(12)[00000897][00031280][0000088f](03) 8b4d08 mov ecx,[ebp+08]
(13)[0000089a][0003127c][0000088f](01) 51 push ecx
(14)[0000089b][00031278][000008a0](05) e87ffeffff call 0000071f
Line(11) Push second parameter value: 0000088f to Halts()
Line(13) Push first parameter value: 0000088f to Halts()
Line(14) H_Halt() calls Halts(0000088f, 0000088f)
(15)[0000088f][00042430][00042434](01) 55 push ebp
(16)[00000890][00042430][00042434](02) 8bec mov ebp,esp
(17)[00000892][0004242c][00032400](01) 51 push ecx
(18)[00000893][0004242c][00032400](03) 8b4508 mov eax,[ebp+08]
(19)[00000896][00042428][0000088f](01) 50 push eax
(20)[00000897][00042428][0000088f](03) 8b4d08 mov ecx,[ebp+08]
(21)[0000089a][00042424][0000088f](01) 51 push ecx
(22)[0000089b][00042420][000008a0](05) e87ffeffff call 0000071f
Line(19) Push second parameter value: 0000088f to Halts()
Line(21) Push first parameter value: 0000088f to Halts()
Line(22) H_Halt() calls Halts(0000088f, 0000088f)
Infinite Recursion Detected Simulation Stopped on the basis that H_Hat()
calls Halts() with the same data a second time in sequence from the same
machine address.
(23)[000008d2][00011204][00000000](03) 83c408 add esp,+08
(24)[000008d5][00011204][00000000](03) 8945fc mov [ebp-04],eax
(25)[000008d8][00011204][00000000](03) 8b45fc mov eax,[ebp-04]
(26)[000008db][00011200][00000000](01) 50 push eax
(27)[000008dc][000111fc][0000030b](05) 680b030000 push 0000030b
(28)[000008e1][000111f8][000008e6](05) e869faffff call 0000034f
Input_Would_Halt = 0
(29)[000008e6][00011204][00000000](03) 83c408 add esp,+08
(30)[000008e9][00011204][00000000](02) 33c0 xor eax,eax
(31)[000008eb][00011208][00000000](02) 8be5 mov esp,ebp
(32)[000008ed][0001120c][00010000](01) 5d pop ebp
(33)[000008ee][00011210][00000080](01) c3 ret
Number_of_User_Instructions(33)
Copyright 2021 PL Olcott
[1] sci.logic --- Daryl McCullough --- Jun 25, 2004, 6:30:39 PM
[The Psychology of Self-Reference]
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
The pathological self reference error occurs whenever a question or
decision problem cannot be correctly answered because both of the yes/no
or true/false answers are contradicted.
If we ask Jack[1] this question: Will your answer to this question be no?
Neither answer of yes or no is correct because they are both contradicted.
When an input program is defined to do opposite of whatever the halt
decider decides about its halt status then we have the same pathological
self-reference error as Jack's question.
If the halt decider Halts() returns a value of true to H_Hat() then
H_Hat() would go into an infinite loop and never halt. If the halt
decider Halts() returns a value of false to H_Hat() then H_Hat would
immediately stop running.
The simplest way to define a halt decider is to make a program that
simply runs its input to see what it does. In technical terms this would
be a universal Turing machine (UTM) that has been adapted to become a
halt decider. This UTM would simply simulate the execution of its input
until its input halts on its own or the halt decider determines that its
input would never halt on its own and stops simulating it. In order for
the UTM to see what its input does it must keep track of an execution
trace of its input.
Every (at least partial) halt decider that decides the halting status of
its input on the basis of its examination of the execution trace of its
own simulation of this input would correctly decide the conventional
halting problem counter-examples as not halting.
The x86utm operating system was created so that halt deciders written in
the C programming language would be computationally equivalent to the
execution of actual Turing machines. These (at least partial) halt
deciders base their halting decision on examining the execution trace of
the x86 machine language of their input. The input is the COFF object
file output of a C compiler and is directly executed by the x86 emulator.
The halt decider Halts() determines that H_Hat() called it in infinite
recursion, on the basis of the x86 machine language execution trace
shown below, stop simulating its input, and decide not halting on the
basis that its input would not halt.
void H_Hat(u32 P)
{
u32 Input_Would_Halt = Halts(P, P);
if (Input_Would_Halt)
HERE: goto HERE;
}
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
_H_Hat()
}
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
[0000088f](01) 55 push ebp
[00000890](02) 8bec mov ebp,esp
[00000892](01) 51 push ecx
[00000893](03) 8b4508 mov eax,[ebp+08]
[00000896](01) 50 push eax
[00000897](03) 8b4d08 mov ecx,[ebp+08]
[0000089a](01) 51 push ecx
[0000089b](05) e87ffeffff call 0000071f
[000008a0](03) 83c408 add esp,+08
[000008a3](03) 8945fc mov [ebp-04],eax
[000008a6](04) 837dfc00 cmp dword [ebp-04],+00
[000008aa](02) 7402 jz 000008ae
[000008ac](02) ebfe jmp 000008ac
[000008ae](02) 8be5 mov esp,ebp
[000008b0](01) 5d pop ebp
[000008b1](01) c3 ret
_main()
[000008bf](01) 55 push ebp
[000008c0](02) 8bec mov ebp,esp
[000008c2](01) 51 push ecx
[000008c3](05) 688f080000 push 0000088f
[000008c8](05) 688f080000 push 0000088f
[000008cd](05) e84dfeffff call 0000071f
[000008d2](03) 83c408 add esp,+08
[000008d5](03) 8945fc mov [ebp-04],eax
[000008d8](03) 8b45fc mov eax,[ebp-04]
[000008db](01) 50 push eax
[000008dc](05) 680b030000 push 0000030b
[000008e1](05) e869faffff call 0000034f
[000008e6](03) 83c408 add esp,+08
[000008e9](02) 33c0 xor eax,eax
[000008eb](02) 8be5 mov esp,ebp
[000008ed](01) 5d pop ebp
[000008ee](01) c3 ret
Columns
(1) Execution trace sequence number
(2) Machine address of instruction
(3) Machine address of top of stack
(4) Value of top of stack after instruction executed
(5) Number of bytes of machine code
(6) Machine language bytes
(7) Assembly language text
(01)[000008bf][00011208][00000000](01) 55 push ebp
(3) Machine address of top of stack
(4) Value of top of stack after instruction executed
(5) Number of bytes of machine code
(6) Machine language bytes
(7) Assembly language text
(02)[000008c0][00011208][00000000](02) 8bec mov ebp,esp
(03)[000008c2][00011204][00000000](01) 51 push ecx
(04)[000008c3][00011200][0000088f](05) 688f080000 push 0000088f
(05)[000008c8][000111fc][0000088f](05) 688f080000 push 0000088f
(06)[000008cd][000111f8][000008d2](05) e84dfeffff call 0000071f
(07)[0000088f][00031288][0003128c](01) 55 push ebp
(08)[00000890][00031288][0003128c](02) 8bec mov ebp,esp
(09)[00000892][00031284][00021258](01) 51 push ecx
(10)[00000893][00031284][00021258](03) 8b4508 mov eax,[ebp+08]
(11)[00000896][00031280][0000088f](01) 50 push eax
(12)[00000897][00031280][0000088f](03) 8b4d08 mov ecx,[ebp+08]
(13)[0000089a][0003127c][0000088f](01) 51 push ecx
(14)[0000089b][00031278][000008a0](05) e87ffeffff call 0000071f
Line(11) Push second parameter value: 0000088f to Halts()
Line(13) Push first parameter value: 0000088f to Halts()
Line(14) H_Halt() calls Halts(0000088f, 0000088f)
(15)[0000088f][00042430][00042434](01) 55 push ebp
(16)[00000890][00042430][00042434](02) 8bec mov ebp,esp
(17)[00000892][0004242c][00032400](01) 51 push ecx
(18)[00000893][0004242c][00032400](03) 8b4508 mov eax,[ebp+08]
(19)[00000896][00042428][0000088f](01) 50 push eax
(20)[00000897][00042428][0000088f](03) 8b4d08 mov ecx,[ebp+08]
(21)[0000089a][00042424][0000088f](01) 51 push ecx
(22)[0000089b][00042420][000008a0](05) e87ffeffff call 0000071f
Line(19) Push second parameter value: 0000088f to Halts()
Line(21) Push first parameter value: 0000088f to Halts()
Line(22) H_Halt() calls Halts(0000088f, 0000088f)
Infinite Recursion Detected Simulation Stopped on the basis that H_Hat()
calls Halts() with the same data a second time in sequence from the same
machine address.
(23)[000008d2][00011204][00000000](03) 83c408 add esp,+08
(24)[000008d5][00011204][00000000](03) 8945fc mov [ebp-04],eax
(25)[000008d8][00011204][00000000](03) 8b45fc mov eax,[ebp-04]
(26)[000008db][00011200][00000000](01) 50 push eax
(27)[000008dc][000111fc][0000030b](05) 680b030000 push 0000030b
(28)[000008e1][000111f8][000008e6](05) e869faffff call 0000034f
Input_Would_Halt = 0
(29)[000008e6][00011204][00000000](03) 83c408 add esp,+08
(30)[000008e9][00011204][00000000](02) 33c0 xor eax,eax
(31)[000008eb][00011208][00000000](02) 8be5 mov esp,ebp
(32)[000008ed][0001120c][00010000](01) 5d pop ebp
(33)[000008ee][00011210][00000080](01) c3 ret
Number_of_User_Instructions(33)
Copyright 2021 PL Olcott
[1] sci.logic --- Daryl McCullough --- Jun 25, 2004, 6:30:39 PM
[The Psychology of Self-Reference]
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
0 new messages