On 8/28/2022 9:41 PM, olcott wrote:
> On 8/28/2022 10:18 PM, Jeff Barnett wrote:
>> On 8/28/2022 6:01 PM, olcott wrote:
>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>
>>>> <SNIP> idiotic posted.
>>>>
>>>> Since you couldn't even write a TM that decides if a number, base
>>>> one, was even or odd, how do you justify a thread with this title?
>>>>
>>>
>>> I told you I was very sick from chemo therapy.
>>> Would it help my credibility if I finished this?
>>>
>>> I have been in the middle of fully translating
>>> my system to Linux. I have most of this done now.
>> If you have that much time to fully translate to Linux, you certainly
>> had ten minutes to write the fucking TM. Of course you couldn't
>
> It looks like it might be a 12 hour day to find out why my TM simulator
> is not working and another 12 hour day to load all of the details in my
> head. Some of the guys here that have written these things many times
> could probably figure it out in ten minutes.
>
> All but the actual halt decider itself has already been fully ported to
> Linux so that it works under both Linux and Windows. I have to complete
> my ELF_Object parser.

Who gives a POOP? Really, who?? You are only working on this approach to
cover up the fact that many small children have abilities far exceeding
your own. Ben could give you the exact date that you delivered one of
your spectacular lies; You know, the one about have a TM just like the
one described in Linz. You literally can't do a TM that takes less than
10 minutes. You must be horribly embarrassed by that fact. I know I
would be.

Decades of POOP variations, your ideas are. And that means you have a
lot of useless POOP for brains. There are also the facts that you can
write a decent TM+input execution engine in Lisp in about 10 minutes and
a decent one in C, FORTRAN, COBOL, or Java in about 20 minutes. You've
spent your last days on earth writing POOP in and for assembler. Absurd.

You've learned nothing, you proved nothing, and are doing everything in
your limited power to avoid the feeling of inadequacy that's plagued you
your whole life. It's about your last chance to do something sane. Try
it at least once before it's too late. You might get a thrill if you
take a REASONABLE problem and make a little progress on it. The trick is
to give up the idea that the Universe has picked you to do something
special. It hasn't.

>> concentrate for ten minutes, now or in the past. Grade school kids can
>> do it with a little coaching. You can't. You have no credibility, just
>> a mouth that constantly spouts gibberish. Sorry about your cancer but
>> it's time you properly finish at least one simple task correctly. If
>> it gets you soon, you'll be known as the man/child who never
>> accomplished anything and showed a genetic-based discipline to resist
>> learning anything too. What a total waste.--
Jeff Barnett

On Monday, 29 August 2022 at 05:12:01 UTC+2, olcott wrote:
> > Mike.
> I can't possibly publish *UNTIL AFTER I AM UNDERSTOOD*
The problem with "being understood" is your fault. Not anybody else's fault.

You haven't figured out yet that nobody on this forum understands topos theory.
Nobody understands that in general topology models of computation metaphorically "keep falling off the trees".

But you are stuck in a room full of idiots who only know about one model of computation - Turing Machines.
It's absolutely your fault for being in the wrong room.

That said, when you (eventually) end up in a room full of topologists you are going to get the same damn treatment as you are getting here!
Because topologists have their own language/theory/jargon - and their jargon is also entirely unrelatead to C, x86 and the likes.

And I am going to bet money that you aren't going to learn the language of topology either.

On Monday, 29 August 2022 at 08:30:54 UTC+2, Jeff Barnett wrote:
>You know, the one about have a TM just like the
> one described in Linz. You literally can't do a TM that takes less than
> 10 minutes. You must be horribly embarrassed by that fact. I know I
> would be.
All this time demonstrating how smart you are and how stupid olcott is, you haven't actually figured out that his model of computation is more powerful than a TM?

But you are encouraging him to "do a TM". You aren't even trying to help him, you are just trying to indoctrinate him.

On Monday, 29 August 2022 at 05:18:30 UTC+2, richar...@gmail.com wrote:
> But it is in the complete simulation of the input to H(Px,Px), and that
> is what matters for the answer that H is supposed to give.
>
> You still don't understand that H isn't doing a complete simulation
> since it DOES abort its simulation.
Fucking shit-for-brains idiot.

In Mathematics ALL functions are black boxes (https://en.wikipedia.org/wiki/Black_box ).
From the perspective of any caller you have absolutely zero-knowledge of H's internal workings.

You have absolutely no way of knowing whether it "aborted" the simulation; or whether it "completed" the simulation, or whether it asked an oracle. You take the output at face value!
The fact that you don't understand the difference between the extensional and intensional perspectives is absolutely mind-boggling!

Probably because you haven't even figured out that intensional equality is undecidable! Go ahead and show me a program (in your favourite programming language) which implements the function equal(x,y) which returns True for x=1, y=1. Go ahead and implement the equality operator on a Turing Machine and apply it to the pair <1,1>.

I bet you can't!

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

> And besides I don't see anything Ben is going to try to teach you as
> likely to cause you to withdraw any of your claims.

I offered in the genuine hope of correcting one specific claim, now long
washed away by the fire hose of nonsense coming from PO.

He tried, for a while, to argue that the very definition of the problem
was wrong because the /behaviour/ of the input was not "the input". He
knew that a decider decides something about the input, but he could only
imagine syntactic properties. Along with a party checker, I'd asked for
the /specification/ of a "prime decider" because I wanted PO to see
clearly that the condition for accepting is usually property of what the
input /represents/, not "of the input" in some literal sense.

The reason to have an actual TM (the parity checker) was to move on to
specifying (and, if possible, writing) a couple of TMs that decide
things about encoded TMs and encoded TM computations. At every stage I
intended getting PO to write the specification, as that was, at the
time, the main problem area. The idea that a TM, H, should accept all
(and only) strings of the form <[M],I> where M halts on input I, would,
I naively hoped, be seen as an obviously valid specification.

Writing a parity checker I be something one might ask a student to do in
a tutorial, in real time on the board, right after the first lecture on
TMs. I thought it would be a matter of a minute or two at most. After
all, he'd been posting about TM for years. I really had no idea how
little PO understood about TMs.

Then (because I'd deliberately left the encoding open so it could be as
simple as he wanted it to be) he decided to do it for decimal
representations! (And of course he never actually did it for any
representation.)

--
Ben.

"dklei...@gmail.com" <dkleinecke@gmail.com> writes:

> On Sunday, August 28, 2022 at 8:50:51 PM UTC-7, Mike Terry wrote:

>> Anyhow, I'm confident PO will never actually get around to submitting
>> his paper. He'd have to get it (coherently) written, for starters,
>> and I don't think he's got a clue where to start on that. He just
>> doesn't understand what's required for a research paper, or even what
>> definitions and proofs look like, let alone what actually needs to be
>> proved etc.. Maybe he could hire someone to write it for him, but
>> such a helper can't magically turn wrong claims into valid proofs, so
>> he's stuck.
>>
> Surely somewhere there is a vanity mathematical journal that will publish
> his paper for a price. But I discover I don't know about one. Are
> there any?

There must be, surely. When I was an academic I often got spam from
publishers of vanity journals asking for submissions (at a price). That
was CS, of course, and it was many, many years ago, so maybe they have
all vanished. Perhaps the self-publishing sites have spoilt the
business model?

> An interesting busines opportunity ?

--
Ben.

Skep Dick <skepdick22@gmail.com> writes:

> you haven't actually figured out that his model of computation is
> more powerful than a TM?

(a) If it's more powerful, why does the decider get the answer wrong?
(b) He's written it in C and you think it's more powerful than a TM?

--
Ben.

On Monday, 29 August 2022 at 12:38:04 UTC+2, Ben Bacarisse wrote:
> Skep Dick <skepd...@gmail.com> writes:
>
> > you haven't actually figured out that his model of computation is
> > more powerful than a TM?
> (a) If it's more powerful, why does the decider get the answer wrong?
In which model of computation are you asserting the "wrongness" of H's output?
Which function is asserting the "wrongness" of H's output?
What is H's output compared to in order to assert its "wrongness"?

> (b) He's written it in C and you think it's more powerful than a TM?
Absolutely! C has an oracle - the fucking programer!

In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
> Since Turing machines are mathematical objects that only exist in the
> mind people can have contradictory thus incoherent ideas about these
> abstract mathematical objects and never realize that their ideas are
> incoherent.
>
> When we study the theory of computation using physically existing
> machines such as the x86 architecture then the incoherent abstract ideas
> are shown to be incoherent in that they cannot be physically implemented.

You can't limit yourself to a particular computer architecture because if
you do, then your results are useless.

If, for example, we limit ourselves to the x86 computer architecture, then
in principle every single algorithm is technically either O(1) or can't be
computed. Which is a completely useless result.

On 8/29/22 12:08 AM, olcott wrote:
> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>
>> On 8/28/22 9:15 PM, olcott wrote:
>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> Since Turing machines are mathematical objects that only exist
>>>>>>>>> in the
>>>>>>>>> mind people can have contradictory thus incoherent ideas about
>>>>>>>>> these
>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>> ideas are
>>>>>>>>> incoherent.
>>>>>>>>>
>>>>>>>>> When we study the theory of computation using physically existing
>>>>>>>>> machines such as the x86 architecture then the incoherent abstract
>>>>>>>>> ideas are shown to be incoherent in that they cannot be physically
>>>>>>>>> implemented.
>>>>>>>>>
>>>>>>>>> void Px(ptr x)
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If a decider must always return a value whenever it is called this
>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>> infinite recursion.
>>>>>>>>>
>>>>>>>>> This even requires that the function call from Px to H(Px,Px) must
>>>>>>>>> return a value to Px even if this function call to H is not even
>>>>>>>>> executed. In the physical model of computation it is an axiom the
>>>>>>>>> programs that are not executed never return values because it is
>>>>>>>>> physically impossible.
>>>>>>>>>
>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>> H(Px,Px)
>>>>>>>>> in infinite recursion H aborts its simulation of Px before this
>>>>>>>>> call
>>>>>>>>> is executed.
>>>>>>>>>
>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>> Computer science says that H must still return a value to Px even
>>>>>>>>> though the call to H is not even executed because all deciders
>>>>>>>>> must
>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>
>>>>>>>> Computer science is correct on this point, what is incorrect is
>>>>>>>> your
>>>>>>>> implementation of H.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>> So you are saying the a computer program that is never even executed
>>>>>>> must still return a result?
>>>>>>
>>>>>> The "result" of a program that never returns is None!
>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>
>>>>>> No problem - is just a definition.
>>>>>
>>>>> H(Px,Px) returns 0 to main. Some people have said that the when Px
>>>>> calls H(Px,Px) that H must return a value to Px even though this
>>>>> function call from Px to H is never executed.
>>>>
>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS executed.
>>>>
>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior that H
>>>> determines.
>>>>
>>>
>>> You said that H must always return a result to its caller even if
>>> this call is never actually executed.
>>>
>>
>> You don't HAVE a caller unless you execute the call instruction.
>
> DON'T CHANGE THE SUBJECT
> DON'T CHANGE THE SUBJECT
> DON'T CHANGE THE SUBJECT

I am NOT changing the subject, you are just showing your stupidity.

>
> A decider must always return to its caller:
> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*

Right, and the call to H is Px IS Executed in the methods that are
defined to determine the behavior of the input, that being either the
direct execution of it or the UTM simulation of it.

>
> H simulates Px until Px reaches its machine address [0000110d] and then
> H aborts its simulation of Px so the call from H(Px,Px) is never
> executed thus H is still a decider.

But H's simulation doesn't define the behavior of the input, since it
isn't a COMPLETE simulation, so not a UTM simulation.

Yes, H doesn't need to simulate to the return, but the behavior is based
on the call and return happening.

>
> _Px()
> [00001102](01)  55             push ebp
> [00001103](02)  8bec           mov ebp,esp
> [00001105](03)  8b4508         mov eax,[ebp+08]
> [00001108](01)  50             push eax      // Push Px
> [00001109](03)  8b4d08         mov ecx,[ebp+08]
> [0000110c](01)  51             push ecx      // Push Px
> [0000110d](05)  e880fdffff     call 00000e92 // call H
> [00001112](03)  83c408         add esp,+08
> [00001115](01)  5d             pop ebp
> [00001116](01)  c3             ret
> Size in bytes:(0021) [00001116]
>
>
>

Do you even really know what a UTM is, or what a correct and complete
simulation is?

Your errors seem to indicate that you don't

The ACTUAL BEHAVIOR of Px WILL INCLUDE a call of H and a return from H.

Of course, if H doesn't simulate that, it will have a hard time guessing
at the behavior of the program, and guess it needs to do, as it doesn't
have the information needed to make a good determination.

On 8/29/22 1:38 AM, dklei...@gmail.com wrote:
> On Sunday, August 28, 2022 at 8:50:51 PM UTC-7, Mike Terry wrote:
>> On 29/08/2022 04:08, Richard Damon wrote:
>>> On 8/28/22 10:57 PM, Mike Terry wrote:
>>>> On 29/08/2022 01:01, olcott wrote:
>>>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>>>
>>>>>> <SNIP> idiotic posted.
>>>>>>
>>>>>> Since you couldn't even write a TM that decides if a number, base one, was even or odd, how do
>>>>>> you justify a thread with this title?
>>>>>>
>>>>>
>>>>> I told you I was very sick from chemo therapy.
>>>>> Would it help my credibility if I finished this?
>>>>
>>>> I rather doubt that, but there's a chance that you might /learn/ something about TMs and how they
>>>> are used if you completed Ben's program. Simply learning about TMs won't specifically help your
>>>> credibility though, unless it leads you to recognise the problems with your current claims and
>>>> withdraw them. That /would/ improve your credibility somewhat, but only in a "negative negative"
>>>> sort of way. (I'm guessing you'd still be claiming to have refuted all sorts of other things,
>>>> which would still mark you as a crank for most readers. And besides I don't see anything Ben is
>>>> going to try to teach you as likely to cause you to withdraw any of your claims.)
>>>>
>>>> Just writing the one TM to decide even numbers in itself won't help your credibility much, because
>>>> I imagine most people are already prepared to believe you could do that with appropriate effort.
>>>>
>>>> I've just had the thought that perhaps you believe people reject your claims because you lack
>>>> credibility as an expert : if only you "had more credibility" then the things you say would
>>>> transform magically from nonsense into correctly proven claims? That doesn't make ANY sense, but
>>>> perhaps its how you view the world... Are you thinking if you demonstrate a simple programming
>>>> task, your already spoken words will start being interpreted differently? That's not going to
>>>> happen.
>>>>
>>>>>
>>>>> I have been in the middle of fully translating
>>>>> my system to Linux. I have most of this done now.
>>>>
>>>> None of that will further your goals of publishing in a reputable peer-reviewd journal ONE IOTA!
>>>> Neither will wasting the rest of your life arguing with people here in comp.theory! You will
>>>> simply die one day, then the world will just forget you (as it forgets 99.9999% of us...) and
>>>> carry on.
>>>>
>>>> Seriously - if your true aim is for your work to be remembered, you need to actually present it to
>>>> a publisher. Forget about porting stuff to Linux, or building exercise TMs or even arguing
>>>> interminably on comp.theory - unless really you're just looking to use up remaining time and bow
>>>> out comfortably... [the latter is actually not an unreasonable path for you]
>>>>
>>>>
>>>> Mike.
>>>
>>> My guess is that something in him KNOWS that if he just submits the paper with what he currently
>>> has, it will just get rejected (it they even bother to tell him it is rejected).
>>>
>>> He seems desperate to try to find the right words that might let his lies sneek past the reviews and
>>> get him published.
>>>
>>> In a sense, his discussion here in comp.theory are just like him porting his system to linux, a good
>>> excuse to delay getting to where he want to be, because he knows subconsciously that if he actully
>>> get there he will just fail.
>> Yes, I think this is likely. Going a bit further, I think we are all capabable of deceiving
>> ourselves to some extent when we're trapped in an unpalatable situation, in order to get through the
>> situation with our psyches unharmed. And PO is especially adept at self deception! But mostly at
>> some deep level we also know we are deceiving ourselves, even while we subconciously avoid
>> situations which might lead us to confront those deceptions... we have to deceive ourselves "just
>> enough" to get through...
>>
>> Anyhow, I'm confident PO will never actually get around to submitting his paper. He'd have to get
>> it (coherently) written, for starters, and I don't think he's got a clue where to start on that. He
>> just doesn't understand what's required for a research paper, or even what definitions and proofs
>> look like, let alone what actually needs to be proved etc.. Maybe he could hire someone to write it
>> for him, but such a helper can't magically turn wrong claims into valid proofs, so he's stuck.
>>
> Surely somewhere there is a vanity mathematical journal that will publish
> his paper for a price. But I discover I don't know about one. Are there any?
>
> An interesting busines opportunity ?

As Ben says, they exist, and PO is even using something like that now
(researchgate) but even he is smart enough to know that publishing on
those doesn't mean anything.

He thinks he just needs to polish his words well enough to get people to
accept his twisted illogical rants. But I think part of him inside knows
that isn't going to happen.

On 8/29/22 12:11 AM, olcott wrote:
> On 8/28/2022 10:27 PM, Richard Damon wrote:
>>
>> On 8/28/22 11:11 PM, olcott wrote:
>>> On 8/28/2022 9:57 PM, Mike Terry wrote:
>>>> On 29/08/2022 01:01, olcott wrote:
>>>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>>>
>>>>>> <SNIP> idiotic posted.
>>>>>>
>>>>>> Since you couldn't even write a TM that decides if a number, base
>>>>>> one, was even or odd, how do you justify a thread with this title?
>>>>>>
>>>>>
>>>>> I told you I was very sick from chemo therapy.
>>>>> Would it help my credibility if I finished this?
>>>>
>>>> I rather doubt that, but there's a chance that you might /learn/
>>>> something about TMs and how they are used if you completed Ben's
>>>> program.  Simply learning about TMs won't specifically help your
>>>> credibility though, unless it leads you to recognise the problems
>>>> with your current claims and withdraw them.  That /would/ improve
>>>> your credibility somewhat, but only in a "negative negative" sort of
>>>> way. (I'm guessing you'd still be claiming to have refuted all sorts
>>>> of other things, which would still mark you as a crank for most
>>>> readers. And besides I don't see anything Ben is going to try to
>>>> teach you as likely to cause you to withdraw any of your claims.)
>>>>
>>>> Just writing the one TM to decide even numbers in itself won't help
>>>> your credibility much, because I imagine most people are already
>>>> prepared to believe you could do that with appropriate effort.
>>>>
>>>> I've just had the thought that perhaps you believe people reject
>>>> your claims because you lack credibility as an expert : if only you
>>>> "had more credibility" then the things you say would transform
>>>> magically from nonsense into correctly proven claims?  That doesn't
>>>> make ANY sense, but perhaps its how you view the world...  Are you
>>>> thinking if you demonstrate a simple programming task, your already
>>>> spoken words will start being interpreted differently?  That's not
>>>> going to happen.
>>>>
>>>>>
>>>>> I have been in the middle of fully translating
>>>>> my system to Linux. I have most of this done now.
>>>>
>>>> None of that will further your goals of publishing in a reputable
>>>> peer-reviewd journal ONE IOTA! Neither will wasting the rest of your
>>>> life arguing with people here in comp.theory!  You will simply die
>>>> one day, then the world will just forget you (as it forgets 99.9999%
>>>> of us...) and carry on.
>>>>
>>>> Seriously - if your true aim is for your work to be remembered, you
>>>> need to actually present it to a publisher.  Forget about porting
>>>> stuff to Linux, or building exercise TMs or even arguing
>>>> interminably on comp.theory - unless really you're just looking to
>>>> use up remaining time and bow out comfortably... [the latter is
>>>> actually not an unreasonable path for you]
>>>>
>>>>
>>>> Mike.
>>>
>>> I can't possibly publish *UNTIL AFTER I AM UNDERSTOOD*
>>>
>>> If people fully understood what I am saying then they would
>>> understand that that the dogma of computer science textbooks that say
>>> that H(P,P) must base its halt status decision on the behavior of
>>> P(P) is incorrect. >
>>> They have to very carefully to go through every single detail of my
>>> explanation of exactly how and why it is incorrect and
>>>
>>> *utterly stop short-circuiting to the dogma*
>>> *utterly stop short-circuiting to the dogma*
>>> *utterly stop short-circuiting to the dogma*
>>>
>>> One of the ways that they short circuit is to say that it is a
>>> definition thus cannot be incorrect. A definition can be incorrect
>>> *only* when it directly contradicts other correct definitions.
>>>
>>>
>>
>> And what is that contradiction?
>>
>
> I am not going to talk about it with you your mind wanders too much.

Translation: I can't express it without revealing my stupidity.

>
>> Quote SOURCES for the definitions you are using. (Not just "The
>> Meaning of the words", what source is providing the meaning of the
>> words).
>>
>> I think you will find that you aren't actully using correct definitions.
>>
>> You have been relying on your own understanding of what things must be
>> like, but you also have refused to learn the definitions of those
>> things, so you are working in a total absence of actual facts.
>>
>>
>> You have made it clear from your rants where you disagree with things,
>> but you provide NO source for what you are basing your idea on.
>>
>> Note, Starting from First Principles means you actually need to START
>> with the First Principle definitions.
>>
>> And, if from those first principles you come up with an idea that is
>> sort of like by not identical to an idea from the original system, you
>> can't just call your thing the same as the original thing.
>>
>> That method may work for emperical systems, where you have a clear
>> goal of what you want to acheive in the physical universe, and are
>> looking for a better way to get there.
>>
>> It doesn't work so well in a Theoretical Realm, where different
>> defintions mean things are different. You can perhaps discover new
>> concepts, but not 'correct' and existing one by redefining it.
>
>

On Sunday, August 28, 2022 at 8:47:18 PM UTC+1, olcott wrote:
> Since Turing machines are mathematical objects that only exist in the
> mind people can have contradictory thus incoherent ideas about these
> abstract mathematical objects and never realize that their ideas are
> incoherent.

I think it might help to look at things a different way.

In most of your posts, you are looking at the problem from the point of view of the simulator. For many programs, a human can look at the program and see whether it halts or not. So it is tempting to think that a program ought to be able to look at another program, run it carefully and decide whether or not it halts. You, of course, think that you have already perfected such a program, but even if you didn't it is quite understandable that you would think you were at least nearly there and that only a little bit more tinkering was required.

Let's look instead that the function P we are considering. This is copied from one of your earlier posts, it's not quite the same as the one in the post I'm replying to, but it sets it all out very neatly:

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

// P does the opposite of whatever H decides
void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status) // if H(P,P) reports that its input halts
HERE: goto HERE; // P loops and never halts
return; // else P halts
}

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

P is a nice simple function. It calls H and branches on the result. You have told us that H(P, P) is zero, so Halt_Status is set to zero, the "if" fails, we get to the "return" and the function ends. All nice and simple. The problem is that H(P, P) being zero is supposed to say that P does not halt.

So does H get it wrong? Well, we can imagine what would happen if H(P, P) were non-zero - Halt_Status is set to non-zero, the "if" succeeds, we go into the loop and the function never ends. This time the problem is that H(P, P) being non-zero is supposed to say that P does halt.

When we look at it this way, it seems clearer that there is no way H can work properly. You have tried two different techniques to explain things away.. Sometimes you say that P is not the program that H(P, P) is considering - even going so far sometimes to say that it is a "non-input", but this is clearly nonsense, if P is the first argument then P is the program being considered. The other approach is to say that, although P halts, in some sense it doesn't really halt. Sometime you "prove" this by asserting both that your simulator is correct and that it says P does not halt, instead of recognising this as a contradiction. Other times you talk about simulations - your simulator aborts when if (supposedly) works out that P is not going to halt, and so the results you get are somehow not what really happens.

I think considering the function that P actually is gives a much better understanding of what is going on than simply talking about simulations and posting traces.

On Monday, 29 August 2022 at 13:37:20 UTC+2, richar...@gmail.com wrote:
> Translation: I can't express it without revealing my stupidity.
Translation to the translation: I reveal my own stupidity when I show utter ignorance of the problem with ALL static abstractions.

https://en.wikipedia.org/wiki/Expression_problem

Skep Dick <skepdick22@gmail.com> writes:

> On Monday, 29 August 2022 at 12:38:04 UTC+2, Ben Bacarisse wrote:
>> Skep Dick <skepd...@gmail.com> writes:
>>
>> > you haven't actually figured out that his model of computation is
>> > more powerful than a TM?
>> (a) If it's more powerful, why does the decider get the answer wrong?
> In which model of computation are you asserting the "wrongness" of H's
> output?

In PO's model, H reports false for a halting computation. Are you ok
with that?

> Which function is asserting the "wrongness" of H's output?

PO has not said. You seem to know what he means so maybe you can help
us all out and explain what function should be used to determine if H is
right or wrong.

> What is H's output compared to in order to assert its "wrongness"?

Since he used to pretend that H computed the halting function, I just
went with that, but maybe you can help explain why H rejecting <[M],I>
when M halts on input I is correct? PO has not been able to persuade
anyone but you.

>> (b) He's written it in C and you think it's more powerful than a TM?
> Absolutely! C has an oracle - the fucking programer!

Don't be silly.

--
Ben.
"What's the 0th integer greater than 4? It's 4!" (Skep Dick, Aug 2022)

On Monday, 29 August 2022 at 16:29:57 UTC+2, Ben Bacarisse wrote:
> In PO's model
That's impossible.

>H reports false
Yes, it does.

> for a halting computation.
There is no decider in PO's model which determines this. How have you arrived at this answer?

*HINT* you were NOT using the function H - because you disagreed with its answer.

> > Which function is asserting the "wrongness" of H's output?
> PO has not said.
It's ot on PO to say that. It's on YOU to say it.

YOU are claiming to be working in HIS model.
YOU are claiming to have a decider which produces "true" for the computation in question.

Where is this decider?

>You seem to know what he means so maybe you can help
> us all out and explain what function should be used to determine if H is
> right or wrong.
You really seem to be super confused about who is "you" and who is "me" in this interaction.

YOU are claiming that his halt decider is reporting "incorrect" results.
YOU are the one disagreeing with H.
YOU are claiming to be working in HIS model.

Whic function in PO's model disagrees with H about P?

> > What is H's output compared to in order to assert its "wrongness"?
> Since he used to pretend that H computed the halting function, I just
> went with that, but maybe you can help explain why H rejecting <[M],I>
> when M halts on input I is correct?
Maybe you can explain which function (in PO's model) you used to compute THAT M halts on I?

*HINT* it's not the H function. Because whatever function you seem to have in mind disagrees with H.

>PO has not been able to persuade anyone but you.
He hasn't persuaded me. I am just working in his model and paying out the consequences. Unlike you.

> >> (b) He's written it in C and you think it's more powerful than a TM?
> > Absolutely! C has an oracle - the fucking programer!
> Don't be silly.
Great advice! When are you going to start following it?

Which function in PO's model decides THAT M halts on I? Oh, that's right - there is no such function. YOU are playing oracle.

> Ben.
> "What's the 0th integer greater than 4? It's 4!" (Skep Dick, Aug 2022)
"I don't understand the difference between Nat -> Nat -> Bool and Nat -> Nat -> Nat!" (Ben Bacarisse, Aug 2022)

On 29/08/2022 06:38, dklei...@gmail.com wrote:
> On Sunday, August 28, 2022 at 8:50:51 PM UTC-7, Mike Terry wrote:
>> On 29/08/2022 04:08, Richard Damon wrote:
>>> On 8/28/22 10:57 PM, Mike Terry wrote:
>>>> On 29/08/2022 01:01, olcott wrote:
>>>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>>>
>>>>>> <SNIP> idiotic posted.
>>>>>>
>>>>>> Since you couldn't even write a TM that decides if a number, base one, was even or odd, how do
>>>>>> you justify a thread with this title?
>>>>>>
>>>>>
>>>>> I told you I was very sick from chemo therapy.
>>>>> Would it help my credibility if I finished this?
>>>>
>>>> I rather doubt that, but there's a chance that you might /learn/ something about TMs and how they
>>>> are used if you completed Ben's program. Simply learning about TMs won't specifically help your
>>>> credibility though, unless it leads you to recognise the problems with your current claims and
>>>> withdraw them. That /would/ improve your credibility somewhat, but only in a "negative negative"
>>>> sort of way. (I'm guessing you'd still be claiming to have refuted all sorts of other things,
>>>> which would still mark you as a crank for most readers. And besides I don't see anything Ben is
>>>> going to try to teach you as likely to cause you to withdraw any of your claims.)
>>>>
>>>> Just writing the one TM to decide even numbers in itself won't help your credibility much, because
>>>> I imagine most people are already prepared to believe you could do that with appropriate effort.
>>>>
>>>> I've just had the thought that perhaps you believe people reject your claims because you lack
>>>> credibility as an expert : if only you "had more credibility" then the things you say would
>>>> transform magically from nonsense into correctly proven claims? That doesn't make ANY sense, but
>>>> perhaps its how you view the world... Are you thinking if you demonstrate a simple programming
>>>> task, your already spoken words will start being interpreted differently? That's not going to
>>>> happen.
>>>>
>>>>>
>>>>> I have been in the middle of fully translating
>>>>> my system to Linux. I have most of this done now.
>>>>
>>>> None of that will further your goals of publishing in a reputable peer-reviewd journal ONE IOTA!
>>>> Neither will wasting the rest of your life arguing with people here in comp.theory! You will
>>>> simply die one day, then the world will just forget you (as it forgets 99.9999% of us...) and
>>>> carry on.
>>>>
>>>> Seriously - if your true aim is for your work to be remembered, you need to actually present it to
>>>> a publisher. Forget about porting stuff to Linux, or building exercise TMs or even arguing
>>>> interminably on comp.theory - unless really you're just looking to use up remaining time and bow
>>>> out comfortably... [the latter is actually not an unreasonable path for you]
>>>>
>>>>
>>>> Mike.
>>>
>>> My guess is that something in him KNOWS that if he just submits the paper with what he currently
>>> has, it will just get rejected (it they even bother to tell him it is rejected).
>>>
>>> He seems desperate to try to find the right words that might let his lies sneek past the reviews and
>>> get him published.
>>>
>>> In a sense, his discussion here in comp.theory are just like him porting his system to linux, a good
>>> excuse to delay getting to where he want to be, because he knows subconsciously that if he actully
>>> get there he will just fail.
>> Yes, I think this is likely. Going a bit further, I think we are all capabable of deceiving
>> ourselves to some extent when we're trapped in an unpalatable situation, in order to get through the
>> situation with our psyches unharmed. And PO is especially adept at self deception! But mostly at
>> some deep level we also know we are deceiving ourselves, even while we subconciously avoid
>> situations which might lead us to confront those deceptions... we have to deceive ourselves "just
>> enough" to get through...
>>
>> Anyhow, I'm confident PO will never actually get around to submitting his paper. He'd have to get
>> it (coherently) written, for starters, and I don't think he's got a clue where to start on that. He
>> just doesn't understand what's required for a research paper, or even what definitions and proofs
>> look like, let alone what actually needs to be proved etc.. Maybe he could hire someone to write it
>> for him, but such a helper can't magically turn wrong claims into valid proofs, so he's stuck.
>>
> Surely somewhere there is a vanity mathematical journal that will publish
> his paper for a price. But I discover I don't know about one. Are there any?
>
> An interesting busines opportunity ?
>

We could all get together and set one up, specially for PO! If he insists on a physical
distribution, I'm sure we could all join as journal subscribers and send ourselves (and PO) a
physical copy. Now, how much can we charge...?

Mike.

On 8/29/2022 1:30 AM, Jeff Barnett wrote:
> On 8/28/2022 9:41 PM, olcott wrote:
>> On 8/28/2022 10:18 PM, Jeff Barnett wrote:
>>> On 8/28/2022 6:01 PM, olcott wrote:
>>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>>
>>>>> <SNIP> idiotic posted.
>>>>>
>>>>> Since you couldn't even write a TM that decides if a number, base
>>>>> one, was even or odd, how do you justify a thread with this title?
>>>>>
>>>>
>>>> I told you I was very sick from chemo therapy.
>>>> Would it help my credibility if I finished this?
>>>>
>>>> I have been in the middle of fully translating
>>>> my system to Linux. I have most of this done now.
>>> If you have that much time to fully translate to Linux, you certainly
>>> had ten minutes to write the fucking TM. Of course you couldn't
>>
>> It looks like it might be a 12 hour day to find out why my TM
>> simulator is not working and another 12 hour day to load all of the
>> details in my head. Some of the guys here that have written these
>> things many times could probably figure it out in ten minutes.
>>
>> All but the actual halt decider itself has already been fully ported
>> to Linux so that it works under both Linux and Windows. I have to
>> complete my ELF_Object parser.
>
> Who gives a POOP? Really, who?? You are only working on this approach to
> cover up the fact that many small children have abilities far exceeding
> your own. Ben could give you the exact date that you delivered one of
> your spectacular lies; You know, the one about have a TM just like the
> one described in Linz. You literally can't do a TM that takes less than
> 10 minutes. You must be horribly embarrassed by that fact. I know I
> would be.
>
> Decades of POOP variations, your ideas are. And that means you have a
> lot of useless POOP for brains. There are also the facts that you can
> write a decent TM+input execution engine in Lisp in about 10 minutes and
> a decent one in C, FORTRAN, COBOL, or Java in about 20 minutes. You've
> spent your last days on earth writing POOP in and for assembler. Absurd.
>
> You've learned nothing, you proved nothing, and are doing everything in
> your limited power to avoid the feeling of inadequacy that's plagued you
> your whole life. It's about your last chance to do something sane. Try
> it at least once before it's too late. You might get a thrill if you
> take a REASONABLE problem and make a little progress on it. The trick is
> to give up the idea that the Universe has picked you to do something
> special. It hasn't.
>

You have never provided anything besides ad hominem I would estimate
that the reason for this is to mask your lack of technical competence in
this field.

>>> concentrate for ten minutes, now or in the past. Grade school kids
>>> can do it with a little coaching. You can't. You have no credibility,
>>> just a mouth that constantly spouts gibberish. Sorry about your
>>> cancer but it's time you properly finish at least one simple task
>>> correctly. If it gets you soon, you'll be known as the man/child who
>>> never accomplished anything and showed a genetic-based discipline to
>>> resist learning anything too. What a total waste.--
> Jeff Barnett

--
Copyright 2022 Pete Olcott

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

On 29/08/2022 04:11, olcott wrote:
> On 8/28/2022 9:57 PM, Mike Terry wrote:
>> On 29/08/2022 01:01, olcott wrote:
>>> On 8/28/2022 5:20 PM, Jeff Barnett wrote:
>>>> On 8/28/2022 1:47 PM, olcott wrote:
>>>>
>>>> <SNIP> idiotic posted.
>>>>
>>>> Since you couldn't even write a TM that decides if a number, base one, was even or odd, how do
>>>> you justify a thread with this title?
>>>>
>>>
>>> I told you I was very sick from chemo therapy.
>>> Would it help my credibility if I finished this?
>>
>> I rather doubt that, but there's a chance that you might /learn/ something about TMs and how they
>> are used if you completed Ben's program.  Simply learning about TMs won't specifically help your
>> credibility though, unless it leads you to recognise the problems with your current claims and
>> withdraw them.  That /would/ improve your credibility somewhat, but only in a "negative negative"
>> sort of way. (I'm guessing you'd still be claiming to have refuted all sorts of other things,
>> which would still mark you as a crank for most readers.  And besides I don't see anything Ben is
>> going to try to teach you as likely to cause you to withdraw any of your claims.)
>>
>> Just writing the one TM to decide even numbers in itself won't help your credibility much, because
>> I imagine most people are already prepared to believe you could do that with appropriate effort.
>>
>> I've just had the thought that perhaps you believe people reject your claims because you lack
>> credibility as an expert : if only you "had more credibility" then the things you say would
>> transform magically from nonsense into correctly proven claims?  That doesn't make ANY sense, but
>> perhaps its how you view the world...  Are you thinking if you demonstrate a simple programming
>> task, your already spoken words will start being interpreted differently?  That's not going to
>> happen.
>>
>>>
>>> I have been in the middle of fully translating
>>> my system to Linux. I have most of this done now.
>>
>> None of that will further your goals of publishing in a reputable peer-reviewd journal ONE IOTA!
>> Neither will wasting the rest of your life arguing with people here in comp.theory!  You will
>> simply die one day, then the world will just forget you (as it forgets 99.9999% of us...) and
>> carry on.
>>
>> Seriously - if your true aim is for your work to be remembered, you need to actually present it to
>> a publisher.  Forget about porting stuff to Linux, or building exercise TMs or even arguing
>> interminably on comp.theory - unless really you're just looking to use up remaining time and bow
>> out comfortably... [the latter is actually not an unreasonable path for you]
>>
>>
>> Mike.
>
> I can't possibly publish *UNTIL AFTER I AM UNDERSTOOD*

But you will never be understood here, because what you're saying is obviously wrong, and the people
here are not idiots, so they quickly understand you are Wrong.

If you actually believe people here are idiots, then why are you trying to convince them? You
should bypass them, and go to the real experts - the publishers with their peer reviewers are the
ones you need to convince.

If you restrict yourself to only trying to publish AFTER you convince people here, then YOU ARE
ENSURING THAT YOU WILL *NEVER* TRY TO PUBLISH. You will just die and be totally forgotten - no
"legacy" or such.

>
> If people fully understood what I am saying then they would understand that that the dogma of
> computer science textbooks that say that H(P,P) must base its halt status decision on the behavior
> of P(P) is incorrect.

You really can't help using duffer wording, can you? What do you mean by "...must base its halt
status decision on ..." ? The actual facts here are extremely simple:
1) a halt decider is fed two logical inputs:
- the first is a /representation/ of a TM P
- the second is a /representation/ of a finite tape input D
2) the HD is required to :
- ACCEPT the input if P(D) halts
- REJECT the input if P(D) never halts
[NOTE: no mention of emulation!]
3) DUH! : the HD is only "allowed" to "base its processing", and hence its final
decision on its two inputs above in (1)

Only a dumbo would actually want to repeatedly point out (3) which is why I prefixed it with DUH!.
(3) is just WHAT a TM DOES. OF COURSE a TM can only follow its programming, acting on the data on
its input tape - it's not psychic. IN THAT SENSE, it can only "BASE ITS DECISION" on its "actual
input".

That's doesn't alter the fact that for a HD, the response it is required to give is as in (2) above.
The whole point of the halting challenge is for the TM to meet condition (2), while "basing" its
processing just on the /representations/ of P and D which it has been given. Can a TM do that?

If people properly understand what you're saying, they'll conclude that you're an idiot, who doesn't
understand even the requirements of the halting problem you profess to be talking about! :)

>
> They have to very carefully to go through every single detail of my explanation of exactly how and
> why it is incorrect and
>
> *utterly stop short-circuiting to the dogma*
> *utterly stop short-circuiting to the dogma*
> *utterly stop short-circuiting to the dogma*
>

That's sure-fire CRANK language - make sure you explain about "short-circuiting the dogma" in the
abstract for your journal article, because we don't want the peer reviewers making judgements purely
based on dogma!

Mike.

On 8/29/2022 4:32 AM, Ben Bacarisse wrote:
> "dklei...@gmail.com" <dkleinecke@gmail.com> writes:
>
>> On Sunday, August 28, 2022 at 8:50:51 PM UTC-7, Mike Terry wrote:
>
>>> Anyhow, I'm confident PO will never actually get around to submitting
>>> his paper. He'd have to get it (coherently) written, for starters,
>>> and I don't think he's got a clue where to start on that. He just
>>> doesn't understand what's required for a research paper, or even what
>>> definitions and proofs look like, let alone what actually needs to be
>>> proved etc.. Maybe he could hire someone to write it for him, but
>>> such a helper can't magically turn wrong claims into valid proofs, so
>>> he's stuck.
>>>
>> Surely somewhere there is a vanity mathematical journal that will publish
>> his paper for a price. But I discover I don't know about one. Are
>> there any?
>
> There must be, surely. When I was an academic I often got spam from
> publishers of vanity journals asking for submissions (at a price). That
> was CS, of course, and it was many, many years ago, so maybe they have
> all vanished. Perhaps the self-publishing sites have spoilt the
> business model?
>
>> An interesting busines opportunity ?

I still get email "invitations" to publish or even be editor for special
issues. All at a price of course. Incoming rate is a few a month.
--
Jeff Barnett

On 8/28/2022 10:18 PM, Richard Damon wrote:
> On 8/28/22 11:15 PM, olcott wrote:
>> On 8/28/2022 10:01 PM, Richard Damon wrote:
>>> On 8/28/22 10:47 PM, olcott wrote:
>>>> On 8/28/2022 8:19 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/28/22 9:15 PM, olcott wrote:
>>>>>> On 8/28/2022 7:47 PM, Richard Damon wrote:
>>>>>>> On 8/28/22 8:07 PM, olcott wrote:
>>>>>>>> On 8/28/2022 3:44 PM, Skep Dick wrote:
>>>>>>>>> On Sunday, 28 August 2022 at 22:10:37 UTC+2, olcott wrote:
>>>>>>>>>> On 8/28/2022 3:02 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sun, 28 Aug 2022 14:47:08 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Since Turing machines are mathematical objects that only
>>>>>>>>>>>> exist in the
>>>>>>>>>>>> mind people can have contradictory thus incoherent ideas
>>>>>>>>>>>> about these
>>>>>>>>>>>> abstract mathematical objects and never realize that their
>>>>>>>>>>>> ideas are
>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>
>>>>>>>>>>>> When we study the theory of computation using physically
>>>>>>>>>>>> existing
>>>>>>>>>>>> machines such as the x86 architecture then the incoherent
>>>>>>>>>>>> abstract
>>>>>>>>>>>> ideas are shown to be incoherent in that they cannot be
>>>>>>>>>>>> physically
>>>>>>>>>>>> implemented.
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> Output("Input_Halts = ", H(Px, Px));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> If a decider must always return a value whenever it is
>>>>>>>>>>>> called this
>>>>>>>>>>>> requires H to return a value to Px even though H is called in
>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> This even requires that the function call from Px to
>>>>>>>>>>>> H(Px,Px) must
>>>>>>>>>>>> return a value to Px even if this function call to H is not
>>>>>>>>>>>> even
>>>>>>>>>>>> executed. In the physical model of computation it is an
>>>>>>>>>>>> axiom the
>>>>>>>>>>>> programs that are not executed never return values because
>>>>>>>>>>>> it is
>>>>>>>>>>>> physically impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> When simulating halt decider H sees that Px is about to call
>>>>>>>>>>>> H(Px,Px)
>>>>>>>>>>>> in infinite recursion H aborts its simulation of Px before
>>>>>>>>>>>> this call
>>>>>>>>>>>> is executed.
>>>>>>>>>>>>
>>>>>>>>>>>> *Clearly computer science is incorrect on this point*
>>>>>>>>>>>> Computer science says that H must still return a value to Px
>>>>>>>>>>>> even
>>>>>>>>>>>> though the call to H is not even executed because all
>>>>>>>>>>>> deciders must
>>>>>>>>>>>> ALWAYS return to their caller.
>>>>>>>>>>>
>>>>>>>>>>> Computer science is correct on this point, what is incorrect
>>>>>>>>>>> is your
>>>>>>>>>>> implementation of H.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>> So you are saying the a computer program that is never even
>>>>>>>>>> executed
>>>>>>>>>> must still return a result?
>>>>>>>>>
>>>>>>>>> The "result" of a program that never returns is None!
>>>>>>>>> This is equivalent of treating non-termination as an effect.
>>>>>>>>>
>>>>>>>>> No problem - is just a definition.
>>>>>>>>
>>>>>>>> H(Px,Px) returns 0 to main. Some people have said that the when
>>>>>>>> Px calls H(Px,Px) that H must return a value to Px even though
>>>>>>>> this function call from Px to H is never executed.
>>>>>>>
>>>>>>> Except that in the ACTUAL BEHAVIOR of the input, the call IS
>>>>>>> executed.
>>>>>>>
>>>>>>> You are just confusiong the ACTUAL BEHAVIOR with the behavior
>>>>>>> that H determines.
>>>>>>>
>>>>>>
>>>>>> You said that H must always return a result to its caller even if
>>>>>> this call is never actually executed.
>>>>>>
>>>>>
>>>>> You don't HAVE a caller unless you execute the call instruction.
>>>>
>>>> DON'T CHANGE THE SUBJECT
>>>> DON'T CHANGE THE SUBJECT
>>>> DON'T CHANGE THE SUBJECT
>>>
>>> I DIDN'T. I don't think you know what a subject is.
>>>
>>>>
>>>> A decider must always return to its caller:
>>>> *ONLY THOSE TIMES WHERE THE CALL TO THE DECIDER IS ACTUALLY EXECUTED*
>>>>
>>>
>>> So, you don't think that Px calls H?
>>
>> The call to H(Px,Px) from P is never executed, thus H need not return
>> to Px.
>>
>>
>
> But it is in the complete simulation of the input to H(Px,Px), and that
> is what matters for the answer that H is supposed to give.
>

*This thread had nothing to do with that*
The question is whether or not H must return a value to Px when the call
to H(Px,Px) from Px is never invoked.

--
Copyright 2022 Pete Olcott

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

On 8/29/2022 11:09 AM, olcott wrote:
> On 8/29/2022 1:30 AM, Jeff Barnett wrote:

<SNIP> the usual crap?

>>
>
> You have never provided anything besides ad hominem I would estimate
> that the reason for this is to mask your lack of technical competence in
> this field.

There! Did that fell good? In the time you composed and sent your usual
piece of POOP, you could have coded a TM that could tell if an input
number base one was odd or even. Think how much better that would make
you feel then this useless nonsense. Is the above ad hominem, a type of
argument only you are allowed to use?
--
Jeff Barnett

On 8/29/2022 6:24 AM, Juha Nieminen wrote:
> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:
>> Since Turing machines are mathematical objects that only exist in the
>> mind people can have contradictory thus incoherent ideas about these
>> abstract mathematical objects and never realize that their ideas are
>> incoherent.
>>
>> When we study the theory of computation using physically existing
>> machines such as the x86 architecture then the incoherent abstract ideas
>> are shown to be incoherent in that they cannot be physically implemented.
>
> You can't limit yourself to a particular computer architecture because if
> you do, then your results are useless.
>
> If, for example, we limit ourselves to the x86 computer architecture, then
> in principle every single algorithm is technically either O(1) or can't be
> computed. Which is a completely useless result.

By moving from an abstract model of computation where every detail is
merely imagined and never concretely demonstrated it is possible to
imaging that a decider must return a result to every caller even in the
case where the function call is not even executed.

When we move to a concrete model of computation we know that it is
utterly ridiculous that a program that is never executed produces any
output. From this we can know that decider are not supposed to return
any values when a function call to them is never actually executed.

void P(ptr x)
{ H(x, x);
return;
}

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

_Px()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](03) 8b4508 mov eax,[ebp+08]
[00001108](01) 50 push eax // push P
[00001109](03) 8b4d08 mov ecx,[ebp+08]
[0000110c](01) 51 push ecx // push P
[0000110d](05) e880fdffff call 00000e92 // call H
[00001112](03) 83c408 add esp,+08
[00001115](01) 5d pop ebp
[00001116](01) c3 ret
Size in bytes:(0021) [00001116]

H aborts its simulation of P as soon as H sees that P would call H at
machine address [0000110d] before this call is even executed.

According to what two people have said computer science requires
deciders to return values to their callers even if the call is never
executed.

--
Copyright 2022 Pete Olcott

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

Skep Dick <skepdick22@gmail.com> writes:

> On Monday, 29 August 2022 at 16:29:57 UTC+2, Ben Bacarisse wrote:
>> In PO's model
> That's impossible.

Eh?

>>H reports false
>
> Yes, it does.
>
>> for a halting computation.
>
> There is no decider in PO's model which determines this. How have you
> arrived at this answer?

From PO's words: H(P,P) == false is correct "even though P(P) halts".

>>PO has not been able to persuade anyone but you.
>
> He hasn't persuaded me.

Great. Is there some point of disagreement between us on PO's non-result?

> "I don't understand the difference between Nat -> Nat -> Bool and Nat
> -> Nat -> Nat!" (Ben Bacarisse, Aug 2022)

That's dishonest. I think you should aim higher.

--
Ben.
"What's the 0th integer greater than 4? It's 4!" (Skep Dick, Aug 2022)

On 8/29/2022 8:09 AM, Paul N wrote:
> On Sunday, August 28, 2022 at 8:47:18 PM UTC+1, olcott wrote:
>> Since Turing machines are mathematical objects that only exist in the
>> mind people can have contradictory thus incoherent ideas about these
>> abstract mathematical objects and never realize that their ideas are
>> incoherent.
>
> I think it might help to look at things a different way.
>
> In most of your posts, you are looking at the problem from the point of view of the simulator. For many programs, a human can look at the program and see whether it halts or not. So it is tempting to think that a program ought to be able to look at another program, run it carefully and decide whether or not it halts. You, of course, think that you have already perfected such a program, but even if you didn't it is quite understandable that you would think you were at least nearly there and that only a little bit more tinkering was required.
>
> Let's look instead that the function P we are considering. This is copied from one of your earlier posts, it's not quite the same as the one in the post I'm replying to, but it sets it all out very neatly:
>
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status) // if H(P,P) reports that its input halts
> HERE: goto HERE; // P loops and never halts
> return; // else P halts
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> P is a nice simple function. It calls H and branches on the result. You have told us that H(P, P) is zero, so Halt_Status is set to zero, the "if" fails, we get to the "return" and the function ends. All nice and simple. The problem is that H(P, P) being zero is supposed to say that P does not halt.
>
> So does H get it wrong? Well, we can imagine what would happen if H(P, P) were non-zero - Halt_Status is set to non-zero, the "if" succeeds, we go into the loop and the function never ends. This time the problem is that H(P, P) being non-zero is supposed to say that P does halt.
>
> When we look at it this way, it seems clearer that there is no way H can work properly. You have tried two different techniques to explain things away. Sometimes you say that P is not the program that H(P, P) is considering - even going so far sometimes to say that it is a "non-input", but this is clearly nonsense, if P is the first argument then P is the program being considered. The other approach is to say that, although P halts, in some sense it doesn't really halt. Sometime you "prove" this by asserting both that your simulator is correct and that it says P does not halt, instead of recognising this as a contradiction. Other times you talk about simulations - your simulator aborts when if (supposedly) works out that P is not going to halt, and so the results you get are somehow not what really happens.
>
> I think considering the function that P actually is gives a much better understanding of what is going on than simply talking about simulations and posting traces.

*THIS IS KNOWN TO BE TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
The UTM SIMULATION of a machine description always provides the actual
behavior specified by this machine description.

When-so-ever a simulating halt decider must abort the simulation of its
input to prevent the infinite execution of this input it has correctly
predicted the actual behavior of this input because a simulating halt
decider that never aborts its simulation is a UTM.

--
Copyright 2022 Pete Olcott

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