On 3/16/2025 11:05 AM, olcott wrote:
On 3/16/2025 7:31 AM, joes wrote:
Am Sat, 15 Mar 2025 16:27:00 -0500 schrieb olcott:
On 3/15/2025 5:12 AM, Mikko wrote:
On 2025-03-14 14:39:30 +0000, olcott said:
On 3/14/2025 4:03 AM, Mikko wrote:
On 2025-03-13 20:56:22 +0000, olcott said:
On 3/13/2025 4:22 AM, Mikko wrote:
On 2025-03-13 00:36:04 +0000, olcott said:
>
>
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
>
When HHH correctly emulates N steps of the above functions none of
them can possibly reach their own "return" instruction and
terminate normally.
>
Nevertheless, assuming HHH is a decider, Infinite_Loop and
Infinite_Recursion specify a non-terminating behaviour, DDD
specifies a terminating behaviour
>
What is the sequence of machine language instructions of DDD
emulated by HHH such that DDD reaches its machine address 00002183?
>
Irrelevant off-topic distraction.
>
Proving that you don't have a clue that Rice's Theorem is anchored in
the behavior that its finite string input specifies.
>
Another irrelevant off-topic distraction, this time involving a false
claim.
One can be a competent C programmer without knowing anyting about
Rice's Theorem.
YES.
>
Rice's Theorem is about semantic properties in general, not just
behaviours.
The unsolvability of the halting problem is just a special case.
>
Does THE INPUT TO simulating termination analyzer HHH encode a C
function that reaches its "return"
instruction [WHEN SIMULATED BY HHH] (The definition of simulating
termination analyzer) ???
That can't be right. Otherwise my simulator could just not simulate
at all and say that no input halts.
>
Originally a "decider" was any TM that always stops
running for any reason.
In computability theory, a decider is a Turing
machine that halts for every input.[1]
https://en.wikipedia.org/wiki/Decider_(Turing_machine)
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
key word "correctly"
>
*I anchored what correct emulation means now*
<Accurate Paraphrase>
If emulating termination analyzer H emulates its input
finite string D of x86 machine language instructions
according to the semantics of the x86 programming language
until H correctly determines that this emulated D cannot
possibly reach its own "ret" instruction in any finite
number of correctly emulated steps then
H can abort its emulation of input D and correctly report
that D specifies a non-halting sequence of configurations.
</Accurate Paraphrase>
Nope:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
> Fritz Feldhase <
franz.fri...@gmail.com> writes:
>
> > On Monday, March 6, 2023 at 3:56:52 AM UTC+1, olcott wrote:
> >> On 3/5/2023 8:33 PM, Fritz Feldhase wrote:
> >> > On Monday, March 6, 2023 at 3:30:38 AM UTC+1, olcott wrote:
> >> > >
> >> > > I needed Sipser for people [bla]
> >> > >
> >> > Does Sipser support your view/claim that you have refuted the halting theorem?
> >> >
> >> > Does he write/teach that the halting theorem is invalid?
> >> >
> >> > Tell us, oh genius!
> >> >
> >> Professor Sipser only agreed that [...]
> >
> > So the answer is no. Noted.
> >
> >> Because he has >250 students he did not have time to examine anything
> >> else. [...]
> >
> > Oh, a CS professor does not have the time to check a refutation of the
> > halting theorem. *lol*
> I exchanged emails with him about this. He does not agree with anything
> substantive that PO has written. I won't quote him, as I don't have
> permission, but he was, let's say... forthright, in his reply to me.
>
On 8/23/2024 5:07 PM, Ben Bacarisse wrote:
> joes <
noreply@example.org> writes:
>
>> Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:
>
>>> Professor Sipser clearly agreed that an H that does a finite simulation
>>> of D is to predict the behavior of an unlimited simulation of D.
>>
>> If the simulator *itself* would not abort. The H called by D is,
>> by construction, the same and *does* abort.
>
> We don't really know what context Sipser was given. I got in touch at
> the time so do I know he had enough context to know that PO's ideas were
> "wacky" and that had agreed to what he considered a "minor remark".
>
> Since PO considers his words finely crafted and key to his so-called
> work I think it's clear that Sipser did not take the "minor remark" he
> agreed to to mean what PO takes it to mean! My own take if that he
> (Sipser) read it as a general remark about how to determine some cases,
> i.e. that D names an input that H can partially simulate to determine
> it's halting or otherwise. We all know or could construct some such
> cases.
>
> I suspect he was tricked because PO used H and D as the names without
> making it clear that D was constructed from H in the usual way (Sipser
> uses H and D in at least one of his proofs). Of course, he is clued in
> enough know that, if D is indeed constructed from H like that, the
> "minor remark" becomes true by being a hypothetical: if the moon is made
> of cheese, the Martians can look forward to a fine fondue. But,
> personally, I think the professor is more straight talking than that,
> and he simply took as a method that can work for some inputs. That's
> the only way is could be seen as a "minor remark" with being accused of
> being disingenuous.
On 8/23/2024 9:10 PM, Mike Terry wrote:
> So that PO will have no cause to quote me as supporting his case: what
> Sipser understood he was agreeing to was NOT what PO interprets it as
> meaning. Sipser would not agree that the conclusion applies in PO's
> HHH(DDD) scenario, where DDD halts.
Every sufficiently competent C programmer knows
Re: Every sufficiently competent C programmer knows