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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 19:42 -0600 |
| Message-ID | <10g8a9c$vrtg$1@dont-email.me> |
| In reply to | #641260 |
On 11/26/2025 7:24 PM, Python wrote:
> 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 !
Kaz is saying that he can "resume" a simulation
that has just proved that it will never stop
running to a different machine state to "prove"
that this simulation does stop running.
I am estimating that you are agreeing with
Kaz not even knowing that what he is claiming.
--
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 | Python <python@cccp.invalid> |
|---|---|
| Date | 2025-11-27 02:00 +0000 |
| Message-ID | <4p9d_Jnf16LRCUCi3z7O-Aq2C68@jntp> |
| In reply to | #641263 |
Le 27/11/2025 à 02:42, olcott a écrit :
> On 11/26/2025 7:24 PM, Python wrote:
>> 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 !
>
> Kaz is saying that he can "resume" a simulation
> that has just proved that it will never stop
> running to a different machine state to "prove"
> that this simulation does stop running.
He is right.
> I am estimating that you are agreeing with
> Kaz not even knowing that what he is claiming.
You are "estimating" wrong. This is called hubris and lies. Both are SINS.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 20:37 -0600 |
| Message-ID | <10g8dgv$10ub6$1@dont-email.me> |
| In reply to | #641266 |
On 11/26/2025 8:00 PM, Python wrote:
> Le 27/11/2025 à 02:42, olcott a écrit :
>> On 11/26/2025 7:24 PM, Python wrote:
>>> 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 !
>>
>> Kaz is saying that he can "resume" a simulation
>> that has just proved that it will never stop
>> running to a different machine state to "prove"
>> that this simulation does stop running.
>
> He is right.
>
He is resuming a simulation that he already admitted
that he conclusively proved is non-halting to contradict
himself and prove that it is halting by "resuming" this
simulation at a different machine state.
>> I am estimating that you are agreeing with
>> Kaz not even knowing that what he is claiming.
>
> You are "estimating" wrong. This is called hubris and lies. Both are SINS.
I have never said a single thing in this forum since
2020 that I did not wholeheartedly believe is true.
To the best of my knowledge I have not even exaggerated
at all or made any substantive error since 2020 in
the substance of any of my claims since 2020.
To the best of my knowledge the biggest mistake
that I have made since 2020 is my syllogism example
that I made today and Kaz caught.
--
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 04:15 +0000 |
| Message-ID | <20251126201212.411@kylheku.com> |
| In reply to | #641269 |
On 2025-11-27, olcott <polcott333@gmail.com> wrote: > On 11/26/2025 8:00 PM, Python wrote: >>> Kaz is saying that he can "resume" a simulation >>> that has just proved that it will never stop >>> running to a different machine state to "prove" >>> that this simulation does stop running. >> >> He is right. >> > > He is resuming a simulation that he already admitted > that he conclusively proved is non-halting to contradict What? I did not. You must be brandishing your second grade level reading comprehension again. > himself and prove that it is halting by "resuming" this > simulation at a different machine state. The simulation is resumed at exactly the simulation's current state as it was left behind when the decider stopped stepping it. But don't take my word for it. You could check it in the actual ... code! You are just not good at following the semantics of the C language and the x86 instruction set. >> You are "estimating" wrong. This is called hubris and lies. Both are SINS. > > I have never said a single thing in this forum since > 2020 that I did not wholeheartedly believe is true. You would look smarter if you admitted it's all been gaslighting and trolling. -- 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 22:31 -0600 |
| Message-ID | <10g8k6o$131v3$1@dont-email.me> |
| In reply to | #641275 |
On 11/26/2025 10:15 PM, Kaz Kylheku wrote:
> On 2025-11-27, olcott <polcott333@gmail.com> wrote:
>> On 11/26/2025 8:00 PM, Python wrote:
>>>> Kaz is saying that he can "resume" a simulation
>>>> that has just proved that it will never stop
>>>> running to a different machine state to "prove"
>>>> that this simulation does stop running.
>>>
>>> He is right.
>>>
>>
>> He is resuming a simulation that he already admitted
>> that he conclusively proved is non-halting to contradict
>
> What? I did not. You must be brandishing your second
> grade level reading comprehension again.
>
>> himself and prove that it is halting by "resuming" this
>> simulation at a different machine state.
>
> The simulation is resumed at exactly the simulation's
> current state as it was left behind when the decider
> stopped stepping it.
>
Unless it is the total machine state it is cheating.
> But don't take my word for it. You could check it in
> the actual ... code!
>
> You are just not good at following the semantics of
> the C language and the x86 instruction set.
>
Here is the dumbed down version
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
How is this DDD going to reach its "return" statement???
>>> You are "estimating" wrong. This is called hubris and lies. Both are SINS.
>>
>> I have never said a single thing in this forum since
>> 2020 that I did not wholeheartedly believe is true.
>
> You would look smarter if you admitted it's all been
> gaslighting and trolling.
>
--
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 06:51 +0000 |
| Message-ID | <20251126222456.207@kylheku.com> |
| In reply to | #641277 |
On 2025-11-27, olcott <polcott333@gmail.com> wrote:
> On 11/26/2025 10:15 PM, Kaz Kylheku wrote:
>> On 2025-11-27, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 8:00 PM, Python wrote:
>>>>> Kaz is saying that he can "resume" a simulation
>>>>> that has just proved that it will never stop
>>>>> running to a different machine state to "prove"
>>>>> that this simulation does stop running.
>>>>
>>>> He is right.
>>>>
>>>
>>> He is resuming a simulation that he already admitted
>>> that he conclusively proved is non-halting to contradict
>>
>> What? I did not. You must be brandishing your second
>> grade level reading comprehension again.
>>
>>> himself and prove that it is halting by "resuming" this
>>> simulation at a different machine state.
>>
>> The simulation is resumed at exactly the simulation's
>> current state as it was left behind when the decider
>> stopped stepping it.
>
> Unless it is the total machine state it is cheating.
You idiot, what you are proposing is to turn back time over
the entire apparatus. That will would create an instant loop, like in
time-travel science fiction.
The techniqjue I implemented, which is apparently beyond
your understanding, doesn't involve rewinding anything.
There is no manpulation of state other than /identifyng/
a simulation that has been abandoned and then stepping it
forward by making more DebugStep calls that the decider
refused to make.
There is no rewinding or replay going on.
>> But don't take my word for it. You could check it in
>> the actual ... code!
>>
>> You are just not good at following the semantics of
>> the C language and the x86 instruction set.
>>
>
> Here is the dumbed down version
All you are capable of.
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> HHH simulates DDD that calls HHH(DDD)
> that simulates DDD that calls HHH(DDD)...
>
> How is this DDD going to reach its "return" statement???
It has been explained umpteen times.
It reaches that statement in exactly the same way the top-level DDD()
called from main() does.
I can answer questions about it, but at some point you
have to do your own experimenting.
I've given you the tool to see where abandoned simulations
are heading; you can /use/ that as a debugging/verification
tool to make sure that the simulations do what you think
(and publicly say) they do.
You have static variable cheats in your code which enable
you to get that behavior.
Here is the kicker:
* It's only because your cheats are not completely working that I obtained
* the expected results!!! Mike Terry identified this first.
Here is hat happens: HHH simulates DDD, performing the abort tests.
DDD starts a level [2] simulation. That simulation also calls HHH
and when it hits that address, the abort criteria kick in: the outer
HHH bails and returns 0.
Now we get to the kicker: before returning, HHH overwrites the
static execution trace buffer pointer wth 0x90909090.
Now, we resume the abandoned level [1] simulation. What happens is that
the level [2] simulation now continues executing into HHH. This level
[2] HHH notices, "hey, I don't have an execution trace buffer: the
pointer is 0x90909090". It therefore allocates one and thinks that it
is the Root decider (Root == 1). Therefore, the level [2] HHH performs
the abort test, and eventually returns 0 to the level [2] DDD. That DDD
then terminates whch is detected by the level [1] HHH, which returns 0.
The level [1] DD then terminates, and so ends the level[1] simulation
that we resumed.
So by dumb luck, we observe the "correct" behavior; your stupid
cheat fucked itself by resetting the trace buffer pointer.
Most of my remarks refer to a correctly implemented, de-fuckerized
version of your test case without the static data, in which HHH,
DD and all those are pure functions.
Mike Terry implemented something like that, "MTJ_HHH" and "MJT_DD".
He saw the infinite tower of termnating simuations start up,
and proceed into several levels.
--
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-27 08:59 -0600 |
| Message-ID | <10g9p0v$1gggu$1@dont-email.me> |
| In reply to | #641292 |
On 11/27/2025 12:51 AM, Kaz Kylheku wrote: > On 2025-11-27, olcott <polcott333@gmail.com> wrote: >> On 11/26/2025 10:15 PM, Kaz Kylheku wrote: >>> On 2025-11-27, olcott <polcott333@gmail.com> wrote: >>>> On 11/26/2025 8:00 PM, Python wrote: >>>>>> Kaz is saying that he can "resume" a simulation >>>>>> that has just proved that it will never stop >>>>>> running to a different machine state to "prove" >>>>>> that this simulation does stop running. >>>>> >>>>> He is right. >>>>> >>>> >>>> He is resuming a simulation that he already admitted >>>> that he conclusively proved is non-halting to contradict >>> >>> What? I did not. You must be brandishing your second >>> grade level reading comprehension again. >>> >>>> himself and prove that it is halting by "resuming" this >>>> simulation at a different machine state. >>> >>> The simulation is resumed at exactly the simulation's >>> current state as it was left behind when the decider >>> stopped stepping it. >> >> Unless it is the total machine state it is cheating. > > You idiot, what you are proposing is to turn back time over > the entire apparatus. That will would create an instant loop, like in > time-travel science fiction. > What I am proposing is that proceeding beyond this point is nuts On 11/4/2025 8:43 PM, Kaz Kylheku wrote: > On 2025-11-05, olcott <polcott333@gmail.com> wrote: >> >> ...D simulated by H cannot possibly reach its own >> simulated "return" statement... > > Yes; this doesn't happen while H is 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-27 10:16 -0500 |
| Message-ID | <wXZVQ.37583$fE57.10207@fx15.iad> |
| In reply to | #641309 |
On 11/27/25 9:59 AM, olcott wrote: > On 11/27/2025 12:51 AM, Kaz Kylheku wrote: >> On 2025-11-27, olcott <polcott333@gmail.com> wrote: >>> On 11/26/2025 10:15 PM, Kaz Kylheku wrote: >>>> On 2025-11-27, olcott <polcott333@gmail.com> wrote: >>>>> On 11/26/2025 8:00 PM, Python wrote: >>>>>>> Kaz is saying that he can "resume" a simulation >>>>>>> that has just proved that it will never stop >>>>>>> running to a different machine state to "prove" >>>>>>> that this simulation does stop running. >>>>>> >>>>>> He is right. >>>>>> >>>>> >>>>> He is resuming a simulation that he already admitted >>>>> that he conclusively proved is non-halting to contradict >>>> >>>> What? I did not. You must be brandishing your second >>>> grade level reading comprehension again. >>>> >>>>> himself and prove that it is halting by "resuming" this >>>>> simulation at a different machine state. >>>> >>>> The simulation is resumed at exactly the simulation's >>>> current state as it was left behind when the decider >>>> stopped stepping it. >>> >>> Unless it is the total machine state it is cheating. >> >> You idiot, what you are proposing is to turn back time over >> the entire apparatus. That will would create an instant loop, like in >> time-travel science fiction. >> > > What I am proposing is that proceeding beyond this point is nuts Which shows that YOU are nuts and think LIES are valid logic. > > On 11/4/2025 8:43 PM, Kaz Kylheku wrote: > > On 2025-11-05, olcott <polcott333@gmail.com> wrote: > >> > >> ...D simulated by H cannot possibly reach its own > >> simulated "return" statement... > > > > Yes; this doesn't happen while H is running. > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-27 18:17 +0000 |
| Message-ID | <20251127101123.995@kylheku.com> |
| In reply to | #641309 |
On 2025-11-27, olcott <polcott333@gmail.com> wrote: > On 11/27/2025 12:51 AM, Kaz Kylheku wrote: >> On 2025-11-27, olcott <polcott333@gmail.com> wrote: >>> On 11/26/2025 10:15 PM, Kaz Kylheku wrote: >>>> On 2025-11-27, olcott <polcott333@gmail.com> wrote: >>>>> On 11/26/2025 8:00 PM, Python wrote: >>>>>>> Kaz is saying that he can "resume" a simulation >>>>>>> that has just proved that it will never stop >>>>>>> running to a different machine state to "prove" >>>>>>> that this simulation does stop running. >>>>>> >>>>>> He is right. >>>>>> >>>>> >>>>> He is resuming a simulation that he already admitted >>>>> that he conclusively proved is non-halting to contradict >>>> >>>> What? I did not. You must be brandishing your second >>>> grade level reading comprehension again. >>>> >>>>> himself and prove that it is halting by "resuming" this >>>>> simulation at a different machine state. >>>> >>>> The simulation is resumed at exactly the simulation's >>>> current state as it was left behind when the decider >>>> stopped stepping it. >>> >>> Unless it is the total machine state it is cheating. >> >> You idiot, what you are proposing is to turn back time over >> the entire apparatus. That will would create an instant loop, like in >> time-travel science fiction. >> > > What I am proposing is that proceeding beyond this point is nuts That's not a technical argument though; that's just your own insecurity speaking. Quite the contrary. What is nuts is the development of the x86utm and Halt7. Code for resuming abandoned simulations is an injection of a small amount of sanity into the project. It exposes (in one more way) that your claims are nuts. You obviously don't have any understanding of software, if you don't realize that if we have the slave_state pointer of a simulation, we can make it take another step wth DebugStep. -- 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-27 07:41 -0500 |
| Message-ID | <qGXVQ.34691$d6ed.23825@fx12.iad> |
| In reply to | #641277 |
On 11/26/25 11:31 PM, olcott wrote:
> On 11/26/2025 10:15 PM, Kaz Kylheku wrote:
>> On 2025-11-27, olcott <polcott333@gmail.com> wrote:
>>> On 11/26/2025 8:00 PM, Python wrote:
>>>>> Kaz is saying that he can "resume" a simulation
>>>>> that has just proved that it will never stop
>>>>> running to a different machine state to "prove"
>>>>> that this simulation does stop running.
>>>>
>>>> He is right.
>>>>
>>>
>>> He is resuming a simulation that he already admitted
>>> that he conclusively proved is non-halting to contradict
>>
>> What? I did not. You must be brandishing your second
>> grade level reading comprehension again.
>>
>>> himself and prove that it is halting by "resuming" this
>>> simulation at a different machine state.
>>
>> The simulation is resumed at exactly the simulation's
>> current state as it was left behind when the decider
>> stopped stepping it.
>>
>
> Unless it is the total machine state it is cheating.
>
>> But don't take my word for it. You could check it in
>> the actual ... code!
>>
>> You are just not good at following the semantics of
>> the C language and the x86 instruction set.
>>
>
> Here is the dumbed down version
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> HHH simulates DDD that calls HHH(DDD)
> that simulates DDD that calls HHH(DDD)...
But that isn't what HHH does, so your logic is just a lie.
Sorry, all you are doing is proving you think lies are valid logic.
>
> How is this DDD going to reach its "return" statement???
>
>>>> You are "estimating" wrong. This is called hubris and lies. Both are
>>>> SINS.
>>>
>>> I have never said a single thing in this forum since
>>> 2020 that I did not wholeheartedly believe is true.
>>
>> You would look smarter if you admitted it's all been
>> gaslighting and trolling.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-27 07:40 -0500 |
| Message-ID | <mFXVQ.34690$d6ed.11541@fx12.iad> |
| In reply to | #641269 |
On 11/26/25 9:37 PM, olcott wrote:
> On 11/26/2025 8:00 PM, Python wrote:
>> Le 27/11/2025 à 02:42, olcott a écrit :
>>> On 11/26/2025 7:24 PM, Python wrote:
>>>> 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 !
>>>
>>> Kaz is saying that he can "resume" a simulation
>>> that has just proved that it will never stop
>>> running to a different machine state to "prove"
>>> that this simulation does stop running.
>>
>> He is right.
>>
>
> He is resuming a simulation that he already admitted
> that he conclusively proved is non-halting to contradict
> himself and prove that it is halting by "resuming" this
> simulation at a different machine state.
>
But if the simulation was conclusively proved to be non-halting, why did
it halt?
Answer: Because it was NOT proved to be non-halting, a DIFFERENT input,
one that called a DIFFERENT decider was shown to be non-halting.
The problem is you logic is built on the concept that changing constants
in the middle of a problem is valid.
In other words, that it is ok to LIE.
>>> I am estimating that you are agreeing with
>>> Kaz not even knowing that what he is claiming.
>>
>> You are "estimating" wrong. This is called hubris and lies. Both are
>> SINS.
>
> I have never said a single thing in this forum since
> 2020 that I did not wholeheartedly believe is true.
But, since a reasonable person (which you are not) would understand it
them not be true, make you just a pathological liar.
Lies include statements that are obviously false, even if the person
unreasonably beleives them, that just shows they are mentally incapable
of understanding the truth.
>
> To the best of my knowledge I have not even exaggerated
> at all or made any substantive error since 2020 in
> the substance of any of my claims since 2020.
>
> To the best of my knowledge the biggest mistake
> that I have made since 2020 is my syllogism example
> that I made today and Kaz caught.
>
And the problem that "to the best of your knowledge" is MEANINGLESS as
you are just proving yourself to be delusional.
Knowledge and truth are different, but you think you miniscule idea of
what you know defines truth, showing your utter stupidity,
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-26 23:00 -0800 |
| Message-ID | <10g8sti$14eiv$12@dont-email.me> |
| In reply to | #641257 |
On 11/26/2025 4: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.
>
> 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.
I can picture his try into that realm. Dr. Race and/or crash a lot? He
most likely does not even know what a race-condition is.
>
>> 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.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Python <python@cccp.invalid> |
|---|---|
| Date | 2025-11-27 01:39 +0000 |
| Message-ID | <BPfyvRvQ-B_vRGgpZ4qdE1iUFW4@jntp> |
| In reply to | #641256 |
Le 27/11/2025 à 01:20, olcott a écrit :
> 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.
https://hammadulhaq.medium.com/the-dunning-kruger-effect-and-llms-confidence-vs-competence-in-ai-e882866366de
> I will fix this by actually adapting a C interpreter
> to prove that you are a liar to anyone that knows C.
You didn't react to my post about 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.
Not too difficult. Your sophistries, incompetence and lies are obvious.
> 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.
Don't pretend to talk about what other people would say. SINNER!
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 19:47 -0600 |
| Message-ID | <10g8aj5$vuuk$1@dont-email.me> |
| In reply to | #641261 |
On 11/26/2025 7:39 PM, Python wrote:
> Le 27/11/2025 à 01:20, olcott a écrit :
>> 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.
>
> https://hammadulhaq.medium.com/the-dunning-kruger-effect-and-llms-
> confidence-vs-competence-in-ai-e882866366de
>
>> I will fix this by actually adapting a C interpreter
>> to prove that you are a liar to anyone that knows C.
>
> You didn't react to my post about C :-)
>
I don't every recall you ever mentioning anything
about 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.
>
> Not too difficult. Your sophistries, incompetence and lies are obvious.
>
The chief editor of one of the most prestigious
computer science journals exchanged about 15
emails with me. The bottom line was that he
could not understand the x86 language well enough.
>> 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.
>
> Don't pretend to talk about what other people would say. SINNER!
>
>
I have spoken with Ben continuously for 15 years.
He knows this aspect of computer science quite well.
Perhaps better than anyone else here.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* 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 | Python <python@cccp.invalid> |
|---|---|
| Date | 2025-11-27 01:59 +0000 |
| Message-ID | <6ItZXR06JTRavw0RD1vkwwla-XA@jntp> |
| In reply to | #641264 |
Le 27/11/2025 à 02:47, olcott a écrit :
> On 11/26/2025 7:39 PM, Python wrote:
>> Le 27/11/2025 à 01:20, olcott a écrit :
>>> 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.
>>
>> https://hammadulhaq.medium.com/the-dunning-kruger-effect-and-llms-
>> confidence-vs-competence-in-ai-e882866366de
>>
>>> I will fix this by actually adapting a C interpreter
>>> to prove that you are a liar to anyone that knows C.
>>
>> You didn't react to my post about C :-)
>>
>
> I don't every recall you ever mentioning anything
> about c.
on sci.math
Subject: C Question for P. Olcott
Date: 26/11/2025 ; 04:02 (CET)
>>> 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.
>>
>> Not too difficult. Your sophistries, incompetence and lies are obvious.
>>
>
> The chief editor of one of the most prestigious
> computer science journals exchanged about 15
> emails with me. The bottom line was that he
> could not understand the x86 language well enough.
This is a very common evasive action to avoid abusive cranks.
>>> 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.
>>
>> Don't pretend to talk about what other people would say. SINNER!
>>
>>
>
> I have spoken with Ben continuously for 15 years.
> He knows this aspect of computer science quite well.
> Perhaps better than anyone else here.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its input D
> until H correctly determines that its simulated D would never
> stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
And you misrepresent what they mean.
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
Same.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-26 20:26 -0600 |
| Message-ID | <10g8ctc$10odk$1@dont-email.me> |
| In reply to | #641265 |
On 11/26/2025 7:59 PM, Python wrote:
> Le 27/11/2025 à 02:47, olcott a écrit :
>> On 11/26/2025 7:39 PM, Python wrote:
>>> Le 27/11/2025 à 01:20, olcott a écrit :
>>>> 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.
>>>
>>> https://hammadulhaq.medium.com/the-dunning-kruger-effect-and-llms-
>>> confidence-vs-competence-in-ai-e882866366de
>>>
>>>> I will fix this by actually adapting a C interpreter
>>>> to prove that you are a liar to anyone that knows C.
>>>
>>> You didn't react to my post about C :-)
>>>
>>
>> I don't every recall you ever mentioning anything
>> about c.
>
> on sci.math
>
> Subject: C Question for P. Olcott
> Date: 26/11/2025 ; 04:02 (CET)
>
(1) That has nothing to do with the topic at hand.
(2) I only look at comp.theory.
>
>>>> 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.
>>>
>>> Not too difficult. Your sophistries, incompetence and lies are obvious.
>>>
>>
>> The chief editor of one of the most prestigious
>> computer science journals exchanged about 15
>> emails with me. The bottom line was that he
>> could not understand the x86 language well enough.
>
> This is a very common evasive action to avoid abusive cranks.
After 15 emails? The problem is that the x86 language is
a dead language. I will reformulate using a C interpreter.
>
>>>> 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.
>>>
>>> Don't pretend to talk about what other people would say. SINNER!
>>>
>>>
>>
>> I have spoken with Ben continuously for 15 years.
>> He knows this aspect of computer science quite well.
>> Perhaps better than anyone else here.
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>> If simulating halt decider H correctly simulates its input D
>> until H correctly determines that its simulated D would never
>> stop running unless aborted then
>>
>> H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
>
> And you misrepresent what they mean.
>
It was my own words that I spent two years carefully
crafting that he agreed with.
The first paragraph (that Ben and no one else agreed with)
has only a single correct interpretation.
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>> > I don't think that is the shell game. PO really /has/ an H
>> > (it's trivial to do for this one case) that correctly determines
>> > that P(P) *would* never stop running *unless* aborted.
>
> Same.
So you are the second person out of dozens and dozens
that agree with Ben? That is a good sign.
--
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 04:19 +0000 |
| Message-ID | <20251126201555.690@kylheku.com> |
| In reply to | #641264 |
On 2025-11-27, olcott <polcott333@gmail.com> wrote: > The chief editor of one of the most prestigious > computer science journals exchanged about 15 > emails with me. The bottom line was that he > could not understand the x86 language well enough. LOL; the obvious interpretation of that is "I will say anything for you to stop e-mailing me, you sick crank". -- 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 22:39 -0600 |
| Message-ID | <10g8kmq$136eb$1@dont-email.me> |
| In reply to | #641276 |
On 11/26/2025 10:19 PM, Kaz Kylheku wrote: > On 2025-11-27, olcott <polcott333@gmail.com> wrote: >> The chief editor of one of the most prestigious >> computer science journals exchanged about 15 >> emails with me. The bottom line was that he >> could not understand the x86 language well enough. > > LOL; the obvious interpretation of that is "I will say anything > for you to stop e-mailing me, you sick crank". > That would not take 25 emails. I just counted them. If I was incorrect then someone would be able to point to some actual mistake and thus not need to rely on ad hominem and insults. To the best of my knowledge You were the only one that ever found any actual mistake in my work that was not a mere typo since 2020. On 11/26/2025 3:42 PM, Kaz Kylheku wrote: > On 2025-11-26, olcott <polcott333@gmail.com> wrote: >> "animals" <are> "living things" is stipulated. > > So a dead rabbit isn't an animal? > > Pure genius! > -- 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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-11-27 09:49 +0200 |
| Message-ID | <10g8vr5$16p4g$1@dont-email.me> |
| In reply to | #641213 |
olcott kirjoitti 26.11.2025 klo 17.17:
> 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.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it executes
according to the x86 semantics. When DD is executed according to the x86
semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-26 23:58 -0800 |
| Message-ID | <10g90aq$154ar$4@dont-email.me> |
| In reply to | #641297 |
On 11/26/2025 11:49 PM, Mikko wrote:
> olcott kirjoitti 26.11.2025 klo 17.17:
>> 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.
>
> You are the one who disagrees with the x86 processors about the x86
> language semantics. When an x86 processor executes a program it executes
> according to the x86 semantics. When DD is executed according to the x86
> semantics it halts. Anybody who says that DD specifies a non-halting
> behaviour disagrees with the x86 semantics.
>
But, DD can halt or not halt, right?
Olcott cherry picks a hyper simple program and says see, I can tell if
it halts or not! I am an genius. Ect... He can detect a non-terminating
condition! God be praised indeed.
If HHH(DD) returns non-zero it goes into an infinite GOTO loop. We can
say this is non-halting. If HHH(DD) returns zero, DD halts.
int DD()
{
10: int Halt_Status = HHH(DD);
20: if (Halt_Status)
30: HERE: goto HERE;
40: return Halt_Status;
}
?
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | sci.math
csiph-web