Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.math > #640762 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-11-14 09:00 -0600 |
| Last post | 2025-11-28 11:01 -0500 |
| Articles | 20 on this page of 81 — 7 participants |
Back to article view | Back to sci.math
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-14 09:00 -0600
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-17 07:31 -0600
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-17 07:31 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-26 12:01 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 09:17 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-26 10:29 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 18:35 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 13:55 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 14:58 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 21:47 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 15:53 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 22:19 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 16:48 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 18:00 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 23:55 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 18:20 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 00:39 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 18:51 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 20:02 -0500
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:24 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 19:42 -0600
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 02:00 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 20:37 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 04:15 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:31 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 06:51 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-27 08:59 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:16 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:17 +0000
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 07:41 -0500
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 07:40 -0500
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:00 -0800
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:39 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 19:47 -0600
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:59 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 20:26 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 04:19 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:39 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-27 09:49 +0200
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:58 -0800
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:14 +0200
The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-11-28 08:46 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-11-28 10:59 -0500
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-11-29 11:27 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-11-29 10:38 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-11-29 14:58 -0500
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-01 12:45 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 06:47 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 14:29 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 08:38 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 14:45 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 08:57 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:06 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:19 -0600
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:26 -0600
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:29 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:31 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:39 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:48 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:55 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 16:00 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 10:27 -0600
Re: The halting problem is incorrect two different ways --- updated "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-01 16:41 -0800
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-03 18:24 -0600
Olcott is provably correct --- no one can correctly refute this olcott <polcott333@gmail.com> - 2025-12-03 19:54 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-02 11:07 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-02 08:14 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-03 13:34 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-03 10:27 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-04 11:17 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-04 08:15 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-06 11:23 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-06 06:47 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-12-06 17:26 -0500
Re: The halting problem is incorrect two different ways --- faking ignorance olcott <polcott333@gmail.com> - 2025-11-27 09:21 -0600
Re: The halting problem is incorrect two different ways --- faking ignorance Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:40 -0500
Re: The halting problem is incorrect two different ways --- faking ignorance Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:37 +0000
Re: The halting problem is incorrect two different ways --- faking ignorance Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:24 +0000
Re: The halting problem is incorrect two different ways --- faking ignorance Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:18 +0200
Re: The halting problem is incorrect two different ways --- faking ignorance olcott <polcott333@gmail.com> - 2025-11-28 08:52 -0600
Re: The halting problem is incorrect two different ways --- faking ignorance Richard Damon <Richard@Damon-Family.org> - 2025-11-28 11:01 -0500
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-14 09:00 -0600 |
| Subject | The halting problem is incorrect two different ways |
| Message-ID | <10f7g5q$2tkbn$1@dont-email.me> |
On 11/14/2025 3:21 AM, Mikko wrote:
> On 2025-11-13 15:50:37 +0000, olcott said:
>
>> On 11/13/2025 2:48 AM, Mikko wrote:
>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>
>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>
>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to the
>>>>>>>>>>>>>>> semantic and other
>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>
>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>
>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>
>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>
>>>>>>>>>>> A question about me is off topic in comp.theory. But yes, I
>>>>>>>>>>> did yesterday.
>>>>>>>>>>
>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>
>>>>>>>>>> int H(char* P);
>>>>>>>>>>
>>>>>>>>>> int D()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The above is in test.c
>>>>>>>>>>
>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>
>>>>>>>>>> simulate test.c
>>>>>>>>>>
>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>> from the command prompt.
>>>>>>>>>
>>>>>>>>> Any program that does not correctly tell whether test.c halts
>>>>>>>>> is not
>>>>>>>>> a halt decider. A program that gives an incorrect answer is not
>>>>>>>>> even
>>>>>>>>> a partial halt decider.
>>>>>>>>>
>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>
>>>>>>>>> According to C semanttics it should simulate H(D), either
>>>>>>>>> simultating
>>>>>>>>> instructions of H or simulating the return from H(D) with the same
>>>>>>>>> returned value as H(D) would return if executed, or do whatever
>>>>>>>>> H would
>>>>>>>>> do if H would not not return.
>>>>>>>>
>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>
>>>>>>> It is the behavour C semantics specifies. According to C semantics
>>>>>>> any other behavour that produces the same result is equally valid.
>>>>>>>
>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>> again and again.
>>>>>>>
>>>>>>> If that happens then H does not return and therefore is not a
>>>>>>> decider.
>>>>>>
>>>>>> Maybe my work is over your head.
>>>>>
>>>>> Maybe the definition of "decider" is over your head.
>>>>
>>>> typedef int (*ptr)();
>>>> int HHH(ptr P);
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> HHH(DD);
>>>> }
>>>>
>>>> People here have consistently lied about
>>>> DD simulated by HHH reaching its own "return"
>>>> statement final halt state for three years.
>>>>
>>>> You yourself have not told the truth about
>>>> this even once.
>>>
>>> That seems to confirm that the definition of "decider" is over your
>>> head.
>>
>> I am just talking at the level of the execution
>> trace of C functions. D does specify non-halting
>> behavior to its termination analyzer.
>
> The termination problem is not about specifying "to its termination
> analyzer". Instead the termination problem is to determine whether
> a program terminates every time when used as it was designed to be
> used.
>
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
My solution is to have my H report on the behavior
that its actual input actually specifies.
Another solution is that because the halting problem
proof requires a halt decider H to report on the halt
status of an input D that does the opposite of
whatever H reports that this H/D halting problem
instance is merely the liar paradox in disguise.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-17 07:31 -0600 |
| Message-ID | <10ff841$s7dk$3@dont-email.me> |
| In reply to | #640762 |
On 11/17/2025 2:43 AM, Mikko wrote:
> On 2025-11-17 00:12:14 +0000, olcott said:
>
>> On 11/16/2025 3:18 AM, Mikko wrote:
>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>
>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>
>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to the
>>>>>>>>>>>>>>>>>>>>> semantic and other
>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory. But
>>>>>>>>>>>>>>>>> yes, I did yesterday.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any program that does not correctly tell whether test.c
>>>>>>>>>>>>>>> halts is not
>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect answer
>>>>>>>>>>>>>>> is not even
>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D), either
>>>>>>>>>>>>>>> simultating
>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D) with
>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or do
>>>>>>>>>>>>>>> whatever H would
>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the behavour C semantics specifies. According to C
>>>>>>>>>>>>> semantics
>>>>>>>>>>>>> any other behavour that produces the same result is equally
>>>>>>>>>>>>> valid.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If that happens then H does not return and therefore is not
>>>>>>>>>>>>> a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>
>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>
>>>>>>>>>> int DD()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> HHH(DD);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> People here have consistently lied about
>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>
>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>> this even once.
>>>>>>>>>
>>>>>>>>> That seems to confirm that the definition of "decider" is over
>>>>>>>>> your head.
>>>>>>>>
>>>>>>>> I am just talking at the level of the execution
>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>> behavior to its termination analyzer.
>>>>>>>
>>>>>>> The termination problem is not about specifying "to its termination
>>>>>>> analyzer". Instead the termination problem is to determine whether
>>>>>>> a program terminates every time when used as it was designed to be
>>>>>>> used.
>>>>>>
>>>>>> The halting problem requires that a halt decider
>>>>>> correctly report on the behavior of its caller
>>>>>> and no halt decider can even see its actual caller.
>>>>>
>>>>> Every halt decider is required to report on the behaviour asked about.
>>>>
>>>> And this is incorrect when it has not access to
>>>> the behavior that it is asked about.
>>>
>>> No, it is not. The solution to the halting problem must include the
>>> necessary access. Conversely, a proof that the necessary access is
>>> impossible is sufficient to prove that halting problem is unsolvable.
>>
>> Reporing on the behavior of DD() executed from
>> main requires HHH to report on information
>> that is not contained in its input thus it is
>> incorrect to require HHH to report on that.
>
> That HHH fails to meet the requirements does not mean that the
> requirements are wrong. It merely meas that HHH is not a halt
> decider.
>
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a mapping from
their [finite string] inputs to an accept or reject
state on the basis that this [finite string] input
specifies or fails to specify a semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-17 07:31 -0600 |
| Message-ID | <10ff84e$s7dk$4@dont-email.me> |
| In reply to | #640762 |
On 11/17/2025 2:43 AM, Mikko wrote:
> On 2025-11-17 00:12:14 +0000, olcott said:
>
>> On 11/16/2025 3:18 AM, Mikko wrote:
>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>
>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>
>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to the
>>>>>>>>>>>>>>>>>>>>> semantic and other
>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory. But
>>>>>>>>>>>>>>>>> yes, I did yesterday.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any program that does not correctly tell whether test.c
>>>>>>>>>>>>>>> halts is not
>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect answer
>>>>>>>>>>>>>>> is not even
>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D), either
>>>>>>>>>>>>>>> simultating
>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D) with
>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or do
>>>>>>>>>>>>>>> whatever H would
>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the behavour C semantics specifies. According to C
>>>>>>>>>>>>> semantics
>>>>>>>>>>>>> any other behavour that produces the same result is equally
>>>>>>>>>>>>> valid.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If that happens then H does not return and therefore is not
>>>>>>>>>>>>> a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>
>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>
>>>>>>>>>> int DD()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> HHH(DD);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> People here have consistently lied about
>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>
>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>> this even once.
>>>>>>>>>
>>>>>>>>> That seems to confirm that the definition of "decider" is over
>>>>>>>>> your head.
>>>>>>>>
>>>>>>>> I am just talking at the level of the execution
>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>> behavior to its termination analyzer.
>>>>>>>
>>>>>>> The termination problem is not about specifying "to its termination
>>>>>>> analyzer". Instead the termination problem is to determine whether
>>>>>>> a program terminates every time when used as it was designed to be
>>>>>>> used.
>>>>>>
>>>>>> The halting problem requires that a halt decider
>>>>>> correctly report on the behavior of its caller
>>>>>> and no halt decider can even see its actual caller.
>>>>>
>>>>> Every halt decider is required to report on the behaviour asked about.
>>>>
>>>> And this is incorrect when it has not access to
>>>> the behavior that it is asked about.
>>>
>>> No, it is not. The solution to the halting problem must include the
>>> necessary access. Conversely, a proof that the necessary access is
>>> impossible is sufficient to prove that halting problem is unsolvable.
>>
>> Reporing on the behavior of DD() executed from
>> main requires HHH to report on information
>> that is not contained in its input thus it is
>> incorrect to require HHH to report on that.
>
> That HHH fails to meet the requirements does not mean that the
> requirements are wrong. It merely meas that HHH is not a halt
> decider.
>
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a mapping from
their [finite string] inputs to an accept or reject
state on the basis that this [finite string] input
specifies or fails to specify a semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-11-26 12:01 +0200 |
| Message-ID | <10g6j5r$9aql$1@dont-email.me> |
| In reply to | #640831 |
olcott kirjoitti 17.11.2025 klo 15.31:
> On 11/17/2025 2:43 AM, Mikko wrote:
>> On 2025-11-17 00:12:14 +0000, olcott said:
>>
>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>
>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>
>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to
>>>>>>>>>>>>>>>>>>>>>> the semantic and other
>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory. But
>>>>>>>>>>>>>>>>>> yes, I did yesterday.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any program that does not correctly tell whether test.c
>>>>>>>>>>>>>>>> halts is not
>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect answer
>>>>>>>>>>>>>>>> is not even
>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D)
>>>>>>>>>>>>>>>> with the same
>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or do
>>>>>>>>>>>>>>>> whatever H would
>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the behavour C semantics specifies. According to C
>>>>>>>>>>>>>> semantics
>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If that happens then H does not return and therefore is
>>>>>>>>>>>>>> not a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>
>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>
>>>>>>>>>>> int DD()
>>>>>>>>>>> {
>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> HHH(DD);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>
>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>> this even once.
>>>>>>>>>>
>>>>>>>>>> That seems to confirm that the definition of "decider" is over
>>>>>>>>>> your head.
>>>>>>>>>
>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>
>>>>>>>> The termination problem is not about specifying "to its termination
>>>>>>>> analyzer". Instead the termination problem is to determine whether
>>>>>>>> a program terminates every time when used as it was designed to be
>>>>>>>> used.
>>>>>>>
>>>>>>> The halting problem requires that a halt decider
>>>>>>> correctly report on the behavior of its caller
>>>>>>> and no halt decider can even see its actual caller.
>>>>>>
>>>>>> Every halt decider is required to report on the behaviour asked
>>>>>> about.
>>>>>
>>>>> And this is incorrect when it has not access to
>>>>> the behavior that it is asked about.
>>>>
>>>> No, it is not. The solution to the halting problem must include the
>>>> necessary access. Conversely, a proof that the necessary access is
>>>> impossible is sufficient to prove that halting problem is unsolvable.
>>>
>>> Reporing on the behavior of DD() executed from
>>> main requires HHH to report on information
>>> that is not contained in its input thus it is
>>> incorrect to require HHH to report on that.
>>
>> That HHH fails to meet the requirements does not mean that the
>> requirements are wrong. It merely meas that HHH is not a halt
>> decider.
>>
>
> That HHH fails to meet the requirements by itself does
> not mean that the requirements are wrong.
>
> Turing machine deciders only compute a mapping from
> their [finite string] inputs to an accept or reject
> state on the basis that this [finite string] input
> specifies or fails to specify a semantic or syntactic
> property.
>
> That the information that HHH is required to report
> on simply is not contained in its input is what makes
> the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify the
encoding rules so that the input contains the full specification of the
behaviour.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 09:17 -0600 |
| Message-ID | <10g75m9$gf3b$3@dont-email.me> |
| In reply to | #641198 |
On 11/26/2025 4:01 AM, Mikko wrote:
> olcott kirjoitti 17.11.2025 klo 15.31:
>> On 11/17/2025 2:43 AM, Mikko wrote:
>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>
>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>
>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to
>>>>>>>>>>>>>>>>>>>>>>> the semantic and other
>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory. But
>>>>>>>>>>>>>>>>>>> yes, I did yesterday.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any program that does not correctly tell whether test.c
>>>>>>>>>>>>>>>>> halts is not
>>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect
>>>>>>>>>>>>>>>>> answer is not even
>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D)
>>>>>>>>>>>>>>>>> with the same
>>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or do
>>>>>>>>>>>>>>>>> whatever H would
>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is the behavour C semantics specifies. According to C
>>>>>>>>>>>>>>> semantics
>>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If that happens then H does not return and therefore is
>>>>>>>>>>>>>>> not a decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>
>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>
>>>>>>>>>>>> int DD()
>>>>>>>>>>>> {
>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>
>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>> this even once.
>>>>>>>>>>>
>>>>>>>>>>> That seems to confirm that the definition of "decider" is
>>>>>>>>>>> over your head.
>>>>>>>>>>
>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>
>>>>>>>>> The termination problem is not about specifying "to its
>>>>>>>>> termination
>>>>>>>>> analyzer". Instead the termination problem is to determine whether
>>>>>>>>> a program terminates every time when used as it was designed to be
>>>>>>>>> used.
>>>>>>>>
>>>>>>>> The halting problem requires that a halt decider
>>>>>>>> correctly report on the behavior of its caller
>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>
>>>>>>> Every halt decider is required to report on the behaviour asked
>>>>>>> about.
>>>>>>
>>>>>> And this is incorrect when it has not access to
>>>>>> the behavior that it is asked about.
>>>>>
>>>>> No, it is not. The solution to the halting problem must include the
>>>>> necessary access. Conversely, a proof that the necessary access is
>>>>> impossible is sufficient to prove that halting problem is unsolvable.
>>>>
>>>> Reporing on the behavior of DD() executed from
>>>> main requires HHH to report on information
>>>> that is not contained in its input thus it is
>>>> incorrect to require HHH to report on that.
>>>
>>> That HHH fails to meet the requirements does not mean that the
>>> requirements are wrong. It merely meas that HHH is not a halt
>>> decider.
>>>
>>
>> That HHH fails to meet the requirements by itself does
>> not mean that the requirements are wrong.
>>
>> Turing machine deciders only compute a mapping from
>> their [finite string] inputs to an accept or reject
>> state on the basis that this [finite string] input
>> specifies or fails to specify a semantic or syntactic
>> property.
>>
>> That the information that HHH is required to report
>> on simply is not contained in its input is what makes
>> the requirements wrong.
>
> No, it merely means that the designer ot HHH has failed to specify the
> encoding rules so that the input contains the full specification of the
> behaviour.
>
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-26 10:29 -0500 |
| Message-ID | <B1FVQ.45131$5c64.1874@fx10.iad> |
| In reply to | #641213 |
On 11/26/25 10:17 AM, olcott wrote:
> On 11/26/2025 4:01 AM, Mikko wrote:
>> olcott kirjoitti 17.11.2025 klo 15.31:
>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>
>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>
>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to
>>>>>>>>>>>>>>>>>>>>>>>> the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory. But
>>>>>>>>>>>>>>>>>>>> yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any program that does not correctly tell whether
>>>>>>>>>>>>>>>>>> test.c halts is not
>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect
>>>>>>>>>>>>>>>>>> answer is not even
>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D)
>>>>>>>>>>>>>>>>>> with the same
>>>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or do
>>>>>>>>>>>>>>>>>> whatever H would
>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is the behavour C semantics specifies. According to C
>>>>>>>>>>>>>>>> semantics
>>>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If that happens then H does not return and therefore is
>>>>>>>>>>>>>>>> not a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>
>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>
>>>>>>>>>>>> That seems to confirm that the definition of "decider" is
>>>>>>>>>>>> over your head.
>>>>>>>>>>>
>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>
>>>>>>>>>> The termination problem is not about specifying "to its
>>>>>>>>>> termination
>>>>>>>>>> analyzer". Instead the termination problem is to determine
>>>>>>>>>> whether
>>>>>>>>>> a program terminates every time when used as it was designed
>>>>>>>>>> to be
>>>>>>>>>> used.
>>>>>>>>>
>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>
>>>>>>>> Every halt decider is required to report on the behaviour asked
>>>>>>>> about.
>>>>>>>
>>>>>>> And this is incorrect when it has not access to
>>>>>>> the behavior that it is asked about.
>>>>>>
>>>>>> No, it is not. The solution to the halting problem must include the
>>>>>> necessary access. Conversely, a proof that the necessary access is
>>>>>> impossible is sufficient to prove that halting problem is unsolvable.
>>>>>
>>>>> Reporing on the behavior of DD() executed from
>>>>> main requires HHH to report on information
>>>>> that is not contained in its input thus it is
>>>>> incorrect to require HHH to report on that.
>>>>
>>>> That HHH fails to meet the requirements does not mean that the
>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>> decider.
>>>>
>>>
>>> That HHH fails to meet the requirements by itself does
>>> not mean that the requirements are wrong.
>>>
>>> Turing machine deciders only compute a mapping from
>>> their [finite string] inputs to an accept or reject
>>> state on the basis that this [finite string] input
>>> specifies or fails to specify a semantic or syntactic
>>> property.
>>>
>>> That the information that HHH is required to report
>>> on simply is not contained in its input is what makes
>>> the requirements wrong.
>>
>> No, it merely means that the designer ot HHH has failed to specify the
>> encoding rules so that the input contains the full specification of the
>> behaviour.
>>
>
> In other words you are trying to get away with
> disagreeing with the semantics of the x86 language
> or the semantics of the C programing language.
>
No, you are, as you think a call instruction doesn't go into the
function called, and that a correct simulation of it might differ from
the behavior that the actual x86 does.
Sorry, You "proof" need to lie, under the excuse that the details are
too complicated, as you can't show what you want without lying.
THe fact that D, when run, halts says your simulation is just incorrect.
Your logic is based on being able to have two programs being the "same"
code, even though they do different things.
H can't both abort and not abort at the same time.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-26 18:35 +0000 |
| Message-ID | <20251126103451.940@kylheku.com> |
| In reply to | #641213 |
On 2025-11-26, olcott <polcott333@gmail.com> wrote: > In other words you are trying to get away with > disagreeing with the semantics of the x86 language > or the semantics of the C programing language. Says the pitiful twit who has no meaningful response to results shown with code. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 13:55 -0600 |
| Message-ID | <10g7lv2$njp7$1@dont-email.me> |
| In reply to | #641224 |
On 11/26/2025 12:35 PM, Kaz Kylheku wrote: > On 2025-11-26, olcott <polcott333@gmail.com> wrote: >> In other words you are trying to get away with >> disagreeing with the semantics of the x86 language >> or the semantics of the C programing language. > > Says the pitiful twit who has no meaningful response to results shown > with code. > I am not the one that came up with the jackass idea of restarting a simulation after it has already conclusively proved that it cannot possibly halt. news://news.eternal-september.org/20251104183329.967@kylheku.com On 11/4/2025 8:43 PM, Kaz Kylheku wrote: > On 2025-11-05, olcott <polcott333@gmail.com> wrote: >> >> The whole point is that D simulated by H >> cannot possbly reach its own simulated >> "return" statement no matter what H does. > > Yes; this doesn't happen while H is running. > > So while H does /something/, no matter what H does, > that D simulation won't reach the return statement. > -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable. This required establishing a new foundation for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-26 14:58 -0500 |
| Message-ID | <10g7m5s$mhag$2@dont-email.me> |
| In reply to | #641240 |
On 11/26/2025 2:55 PM, olcott wrote: > On 11/26/2025 12:35 PM, Kaz Kylheku wrote: >> On 2025-11-26, olcott <polcott333@gmail.com> wrote: >>> In other words you are trying to get away with >>> disagreeing with the semantics of the x86 language >>> or the semantics of the C programing language. >> >> Says the pitiful twit who has no meaningful response to results shown >> with code. >> > > I am not the one that came up with the jackass idea > of restarting a simulation after it has already > conclusively proved that it cannot possibly halt. That the continuation of the simulation reaches a final halting state conclusively proves otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-26 21:47 +0000 |
| Message-ID | <20251126134708.468@kylheku.com> |
| In reply to | #641241 |
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote: > On 11/26/2025 2:55 PM, olcott wrote: >> On 11/26/2025 12:35 PM, Kaz Kylheku wrote: >>> On 2025-11-26, olcott <polcott333@gmail.com> wrote: >>>> In other words you are trying to get away with >>>> disagreeing with the semantics of the x86 language >>>> or the semantics of the C programing language. >>> >>> Says the pitiful twit who has no meaningful response to results shown >>> with code. >>> >> >> I am not the one that came up with the jackass idea >> of restarting a simulation after it has already >> conclusively proved that it cannot possibly halt. > > That the continuation of the simulation reaches a final halting state > conclusively proves otherwise. And Olcott has no idea how to fix it and is no longer able to engage with tasks involving code. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 15:53 -0600 |
| Message-ID | <10g7ss1$qbil$2@dont-email.me> |
| In reply to | #641245 |
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>> On 11/26/2025 2:55 PM, olcott wrote:
>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>> In other words you are trying to get away with
>>>>> disagreeing with the semantics of the x86 language
>>>>> or the semantics of the C programing language.
>>>>
>>>> Says the pitiful twit who has no meaningful response to results shown
>>>> with code.
>>>>
>>>
>>> I am not the one that came up with the jackass idea
>>> of restarting a simulation after it has already
>>> conclusively proved that it cannot possibly halt.
>>
>> That the continuation of the simulation reaches a final halting state
>> conclusively proves otherwise.
>
> And Olcott has no idea how to fix it and is no longer
> able to engage with tasks involving code.
>
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-26 22:19 +0000 |
| Message-ID | <20251126141918.86@kylheku.com> |
| In reply to | #641248 |
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>> In other words you are trying to get away with
>>>>>> disagreeing with the semantics of the x86 language
>>>>>> or the semantics of the C programing language.
>>>>>
>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>> with code.
>>>>>
>>>>
>>>> I am not the one that came up with the jackass idea
>>>> of restarting a simulation after it has already
>>>> conclusively proved that it cannot possibly halt.
>>>
>>> That the continuation of the simulation reaches a final halting state
>>> conclusively proves otherwise.
>>
>> And Olcott has no idea how to fix it and is no longer
>> able to engage with tasks involving code.
>>
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> return;
> }
>
> And the continuation of the simulation
> at the "return" statement "proves"
> by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 16:48 -0600 |
| Message-ID | <10g804j$rqms$1@dont-email.me> |
| In reply to | #641251 |
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>> In other words you are trying to get away with
>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>> or the semantics of the C programing language.
>>>>>>
>>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>>> with code.
>>>>>>
>>>>>
>>>>> I am not the one that came up with the jackass idea
>>>>> of restarting a simulation after it has already
>>>>> conclusively proved that it cannot possibly halt.
>>>>
>>>> That the continuation of the simulation reaches a final halting state
>>>> conclusively proves otherwise.
>>>
>>> And Olcott has no idea how to fix it and is no longer
>>> able to engage with tasks involving code.
>>>
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> return;
>> }
>>
>> And the continuation of the simulation
>> at the "return" statement "proves"
>> by deception that infinite loops halt.
>
> I have no idea what you are blabbing about, and neither do you.
>
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
This simulation is "resumed" at the "return"
instruction. This "proves" that Infinite_Loop()
can reach its "return" instruction thus never
really needed to be aborted.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-26 18:00 -0500 |
| Message-ID | <10g80pj$ovei$1@dont-email.me> |
| In reply to | #641252 |
On 11/26/2025 5:48 PM, olcott wrote:
> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>> In other words you are trying to get away with
>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>> or the semantics of the C programing language.
>>>>>>>
>>>>>>> Says the pitiful twit who has no meaningful response to results
>>>>>>> shown
>>>>>>> with code.
>>>>>>>
>>>>>>
>>>>>> I am not the one that came up with the jackass idea
>>>>>> of restarting a simulation after it has already
>>>>>> conclusively proved that it cannot possibly halt.
>>>>>
>>>>> That the continuation of the simulation reaches a final halting state
>>>>> conclusively proves otherwise.
>>>>
>>>> And Olcott has no idea how to fix it and is no longer
>>>> able to engage with tasks involving code.
>>>>
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> And the continuation of the simulation
>>> at the "return" statement "proves"
>>> by deception that infinite loops halt.
>>
>> I have no idea what you are blabbing about, and neither do you.
>>
>
> We could simulate Infinite_Loop() until it
> proves that it cannot possibly stop running
> unless aborted, then abort it. Now to use
> your method we can "resume" the simulation
> at a different machine state.
False. We would resume the simulation of Infinite_Loop at the same
machine state (which doesn't include the simulator) and the resumption
would not halt.
In contract, we can resume the simulation of DD at the same machine
state (which again doesn't include the the simulator) and the resumption
has been shown to halt.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-26 23:55 +0000 |
| Message-ID | <20251126155440.395@kylheku.com> |
| In reply to | #641252 |
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>> In other words you are trying to get away with
>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>> or the semantics of the C programing language.
>>>>>>>
>>>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>>>> with code.
>>>>>>>
>>>>>>
>>>>>> I am not the one that came up with the jackass idea
>>>>>> of restarting a simulation after it has already
>>>>>> conclusively proved that it cannot possibly halt.
>>>>>
>>>>> That the continuation of the simulation reaches a final halting state
>>>>> conclusively proves otherwise.
>>>>
>>>> And Olcott has no idea how to fix it and is no longer
>>>> able to engage with tasks involving code.
>>>>
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> And the continuation of the simulation
>>> at the "return" statement "proves"
>>> by deception that infinite loops halt.
>>
>> I have no idea what you are blabbing about, and neither do you.
>>
>
> We could simulate Infinite_Loop() until it
> proves that it cannot possibly stop running
> unless aborted, then abort it. Now to use
> your method we can "resume" the simulation
> at a different machine state.
No, you fucking idiot.
> This simulation is "resumed" at the "return"
> instruction.
No, you fucking idiot.
"In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language."
See above.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 18:20 -0600 |
| Message-ID | <10g85fk$u57s$1@dont-email.me> |
| In reply to | #641255 |
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> In other words you are trying to get away with
>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>
>>>>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>>>>> with code.
>>>>>>>>
>>>>>>>
>>>>>>> I am not the one that came up with the jackass idea
>>>>>>> of restarting a simulation after it has already
>>>>>>> conclusively proved that it cannot possibly halt.
>>>>>>
>>>>>> That the continuation of the simulation reaches a final halting state
>>>>>> conclusively proves otherwise.
>>>>>
>>>>> And Olcott has no idea how to fix it and is no longer
>>>>> able to engage with tasks involving code.
>>>>>
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> And the continuation of the simulation
>>>> at the "return" statement "proves"
>>>> by deception that infinite loops halt.
>>>
>>> I have no idea what you are blabbing about, and neither do you.
>>>
>>
>> We could simulate Infinite_Loop() until it
>> proves that it cannot possibly stop running
>> unless aborted, then abort it. Now to use
>> your method we can "resume" the simulation
>> at a different machine state.
>
> No, you fucking idiot.
>
>> This simulation is "resumed" at the "return"
>> instruction.
>
> No, you fucking idiot.
>
> "In other words you are trying to get away with
> disagreeing with the semantics of the x86 language
> or the semantics of the C programing language."
>
> See above.
>
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
Ben Bacarisse would confirm that this one also
would never stop running.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-27 00:39 +0000 |
| Message-ID | <20251126163259.71@kylheku.com> |
| In reply to | #641256 |
On 2025-11-27, olcott <polcott333@gmail.com> wrote:
> On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>
>>>>>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>>>>>> with code.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am not the one that came up with the jackass idea
>>>>>>>> of restarting a simulation after it has already
>>>>>>>> conclusively proved that it cannot possibly halt.
>>>>>>>
>>>>>>> That the continuation of the simulation reaches a final halting state
>>>>>>> conclusively proves otherwise.
>>>>>>
>>>>>> And Olcott has no idea how to fix it and is no longer
>>>>>> able to engage with tasks involving code.
>>>>>>
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> And the continuation of the simulation
>>>>> at the "return" statement "proves"
>>>>> by deception that infinite loops halt.
>>>>
>>>> I have no idea what you are blabbing about, and neither do you.
>>>>
>>>
>>> We could simulate Infinite_Loop() until it
>>> proves that it cannot possibly stop running
>>> unless aborted, then abort it. Now to use
>>> your method we can "resume" the simulation
>>> at a different machine state.
>>
>> No, you fucking idiot.
>>
>>> This simulation is "resumed" at the "return"
>>> instruction.
>>
>> No, you fucking idiot.
>>
>> "In other words you are trying to get away with
>> disagreeing with the semantics of the x86 language
>> or the semantics of the C programing language."
>>
>> See above.
>>
>
> I discussed you (not by name) with Claude AI.
> It is convinced that you must be a liar.
Right; anything but atually get to grips with some code.
> I will fix this by actually adapting a C interpreter
> to prove that you are a liar to anyone that knows C.
>
> I tried to do this with x86 yet this proved far
> too difficult for even the chief editor of one
> of the most prestigious computer science journals.
It is child's play to show that your claims based on
that x86 contraption are incorrect.
> When you resume any simulation that cannot possibly
> stop running to the exact same total machine state
No, only the state of the simulation is resumed, not
the total machine state.
Maybe you are not familar with operating systems.
When a descheduled or blocked thread is resumed, the entire machine
state doesn't rewind back to the time that thread stopped. Only that
thread's state is restored.
It is obvious you have gaps in your understanding of
concurrent programming.
> Ben Bacarisse would confirm that this one also
> would never stop running.
That is correct.
But the simulation of a D, which calls a H(D) that returns 0, is
terminating. So for that resumed simulation, we would find that inside
the simulation, the simulated H(D) returns 0 to the simulated D, which
executes its simulated return.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 18:51 -0600 |
| Message-ID | <10g87a7$upad$1@dont-email.me> |
| In reply to | #641257 |
On 11/26/2025 6:39 PM, Kaz Kylheku wrote:
> On 2025-11-27, olcott <polcott333@gmail.com> wrote:
>> On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>>
>>>>>>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>>>>>>> with code.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am not the one that came up with the jackass idea
>>>>>>>>> of restarting a simulation after it has already
>>>>>>>>> conclusively proved that it cannot possibly halt.
>>>>>>>>
>>>>>>>> That the continuation of the simulation reaches a final halting state
>>>>>>>> conclusively proves otherwise.
>>>>>>>
>>>>>>> And Olcott has no idea how to fix it and is no longer
>>>>>>> able to engage with tasks involving code.
>>>>>>>
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> And the continuation of the simulation
>>>>>> at the "return" statement "proves"
>>>>>> by deception that infinite loops halt.
>>>>>
>>>>> I have no idea what you are blabbing about, and neither do you.
>>>>>
>>>>
>>>> We could simulate Infinite_Loop() until it
>>>> proves that it cannot possibly stop running
>>>> unless aborted, then abort it. Now to use
>>>> your method we can "resume" the simulation
>>>> at a different machine state.
>>>
>>> No, you fucking idiot.
>>>
>>>> This simulation is "resumed" at the "return"
>>>> instruction.
>>>
>>> No, you fucking idiot.
>>>
>>> "In other words you are trying to get away with
>>> disagreeing with the semantics of the x86 language
>>> or the semantics of the C programing language."
>>>
>>> See above.
>>>
>>
>> I discussed you (not by name) with Claude AI.
>> It is convinced that you must be a liar.
>
> Right; anything but atually get to grips with some code.
>
>> I will fix this by actually adapting a C interpreter
>> to prove that you are a liar to anyone that knows C.
>>
>> I tried to do this with x86 yet this proved far
>> too difficult for even the chief editor of one
>> of the most prestigious computer science journals.
>
> It is child's play to show that your claims based on
> that x86 contraption are incorrect.
>
>> When you resume any simulation that cannot possibly
>> stop running to the exact same total machine state
>
> No, only the state of the simulation is resumed, not
> the total machine state.
>
Great you finally admit that you are cheating.
Anyone knowing comp.theory will understand this
is cheating.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-26 20:02 -0500 |
| Message-ID | <10g87v9$v1jp$1@dont-email.me> |
| In reply to | #641258 |
On 11/26/2025 7:51 PM, olcott wrote:
> On 11/26/2025 6:39 PM, Kaz Kylheku wrote:
>> On 2025-11-27, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>>>
>>>>>>>>>>> Says the pitiful twit who has no meaningful response to
>>>>>>>>>>> results shown
>>>>>>>>>>> with code.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am not the one that came up with the jackass idea
>>>>>>>>>> of restarting a simulation after it has already
>>>>>>>>>> conclusively proved that it cannot possibly halt.
>>>>>>>>>
>>>>>>>>> That the continuation of the simulation reaches a final halting
>>>>>>>>> state
>>>>>>>>> conclusively proves otherwise.
>>>>>>>>
>>>>>>>> And Olcott has no idea how to fix it and is no longer
>>>>>>>> able to engage with tasks involving code.
>>>>>>>>
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> And the continuation of the simulation
>>>>>>> at the "return" statement "proves"
>>>>>>> by deception that infinite loops halt.
>>>>>>
>>>>>> I have no idea what you are blabbing about, and neither do you.
>>>>>>
>>>>>
>>>>> We could simulate Infinite_Loop() until it
>>>>> proves that it cannot possibly stop running
>>>>> unless aborted, then abort it. Now to use
>>>>> your method we can "resume" the simulation
>>>>> at a different machine state.
>>>>
>>>> No, you fucking idiot.
>>>>
>>>>> This simulation is "resumed" at the "return"
>>>>> instruction.
>>>>
>>>> No, you fucking idiot.
>>>>
>>>> "In other words you are trying to get away with
>>>> disagreeing with the semantics of the x86 language
>>>> or the semantics of the C programing language."
>>>>
>>>> See above.
>>>>
>>>
>>> I discussed you (not by name) with Claude AI.
>>> It is convinced that you must be a liar.
>>
>> Right; anything but atually get to grips with some code.
>>
>>> I will fix this by actually adapting a C interpreter
>>> to prove that you are a liar to anyone that knows C.
>>>
>>> I tried to do this with x86 yet this proved far
>>> too difficult for even the chief editor of one
>>> of the most prestigious computer science journals.
>>
>> It is child's play to show that your claims based on
>> that x86 contraption are incorrect.
>>
>>> When you resume any simulation that cannot possibly
>>> stop running to the exact same total machine state
>>
>> No, only the state of the simulation is resumed, not
>> the total machine state.
>>
>
> Great you finally admit that you are cheating.
No, you just admitted that you don't know how simulation works.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@cccp.invalid> |
|---|---|
| Date | 2025-11-27 01:24 +0000 |
| Message-ID | <-k3t_AWjQHLMjeopJvJ2h2VN98Y@jntp> |
| In reply to | #641258 |
Le 27/11/2025 à 01:51, olcott a écrit :
> On 11/26/2025 6:39 PM, Kaz Kylheku wrote:
>> On 2025-11-27, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
>>>>>>>>> On 11/26/2025 2:55 PM, olcott wrote:
>>>>>>>>>> On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-11-26, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>>>
>>>>>>>>>>> Says the pitiful twit who has no meaningful response to results shown
>>>>>>>>>>> with code.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am not the one that came up with the jackass idea
>>>>>>>>>> of restarting a simulation after it has already
>>>>>>>>>> conclusively proved that it cannot possibly halt.
>>>>>>>>>
>>>>>>>>> That the continuation of the simulation reaches a final halting state
>>>>>>>>> conclusively proves otherwise.
>>>>>>>>
>>>>>>>> And Olcott has no idea how to fix it and is no longer
>>>>>>>> able to engage with tasks involving code.
>>>>>>>>
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> And the continuation of the simulation
>>>>>>> at the "return" statement "proves"
>>>>>>> by deception that infinite loops halt.
>>>>>>
>>>>>> I have no idea what you are blabbing about, and neither do you.
>>>>>>
>>>>>
>>>>> We could simulate Infinite_Loop() until it
>>>>> proves that it cannot possibly stop running
>>>>> unless aborted, then abort it. Now to use
>>>>> your method we can "resume" the simulation
>>>>> at a different machine state.
>>>>
>>>> No, you fucking idiot.
>>>>
>>>>> This simulation is "resumed" at the "return"
>>>>> instruction.
>>>>
>>>> No, you fucking idiot.
>>>>
>>>> "In other words you are trying to get away with
>>>> disagreeing with the semantics of the x86 language
>>>> or the semantics of the C programing language."
>>>>
>>>> See above.
>>>>
>>>
>>> I discussed you (not by name) with Claude AI.
>>> It is convinced that you must be a liar.
>>
>> Right; anything but atually get to grips with some code.
>>
>>> I will fix this by actually adapting a C interpreter
>>> to prove that you are a liar to anyone that knows C.
>>>
>>> I tried to do this with x86 yet this proved far
>>> too difficult for even the chief editor of one
>>> of the most prestigious computer science journals.
>>
>> It is child's play to show that your claims based on
>> that x86 contraption are incorrect.
>>
>>> When you resume any simulation that cannot possibly
>>> stop running to the exact same total machine state
>>
>> No, only the state of the simulation is resumed, not
>> the total machine state.
>>
>
> Great you finally admit that you are cheating.
> Anyone knowing comp.theory will understand this
> is cheating.
Quite the opposite.
Don't pretend to talk in the name of other people. SINNER !
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | sci.math
csiph-web