On 11/5/24 8:22 PM, olcott wrote:
On 11/5/2024 6:04 PM, Richard Damon wrote:
On 11/5/24 12:08 PM, olcott wrote:
On 11/5/2024 6:03 AM, Richard Damon wrote:
On 11/4/24 10:15 PM, olcott wrote:
On 11/4/2024 8:42 PM, Richard Damon wrote:
On 11/4/24 8:32 PM, olcott wrote:
On 11/4/2024 6:21 PM, Richard Damon wrote:
On 11/4/24 7:48 AM, olcott wrote:
On 11/4/2024 6:07 AM, Richard Damon wrote:
On 11/3/24 11:03 PM, olcott wrote:
On 11/3/2024 9:57 PM, Richard Damon wrote:
On 11/3/24 10:19 PM, olcott wrote:
On 11/3/2024 7:46 PM, Richard Damon wrote:
On 11/3/24 8:38 PM, olcott wrote:
On 11/3/2024 7:26 PM, Richard Damon wrote:
On 11/3/24 8:21 PM, olcott wrote:
>
What would an unbounded emulation do?
>
>
Keep on emulating for an unbounded number of steps.
>
Something you don't seem to understand as part of the requirements.
>
Non-Halting isn't just did reach a final state in some finite number of steps, but that it will NEVER reach a final state even if you process an unbounded number of steps.
>
Would an unbounded emulation of DDD by HHH halt?
>
Not a valid question, as your HHH does not do an unbounded emulation, but aborts after a defined time.
>
>
*Now you are contradicting yourself*
YOU JUST SAID THAT HHH NEED NOT DO AN UNBOUNDED
EMULATION TO PREDICT WHAT AN UNBOUNDED EMULATION WOULD DO.
>
Right. it doesn't NEED to do the operation, just report what an unbounded emulation would do.
>
You asked about an "unbounded emulation of DDD by HHH" but that isn't possible, as HHH doesn't do that.
>
>
On 11/3/2024 12:20 PM, Richard Damon wrote:
> On 11/3/24 9:39 AM, olcott wrote:
>>
>> The finite string input to HHH specifies that HHH
>> MUST EMULATE ITSELF emulating DDD.
>
> Right, and it must CORRECTLY determine what an unbounded
> emulation of that input would do, even if its own programming
> only lets it emulate a part of that.
>
>
*You JUST said that HHH does not need to do an unbounded emulation*
*You JUST said that HHH does not need to do an unbounded emulation*
*You JUST said that HHH does not need to do an unbounded emulation*
*You JUST said that HHH does not need to do an unbounded emulation*
>
>
Right, it doesn't need to DO the unbounded emulatiohn just figure out what it would do.
>
Just like we can compute:
>
1 + 1/2 + 1/4 + 1/8 + ... + 1/2^n + ...
>
Ether by adding the infinite number of terms, or we can notice something about it to say it will sum, in the infinite limit, to 2.
>
>
In the same way, if HHH can see something in its simulation that tells it THIS this program can NEVER halt, it can report it.
>
>
Anyone with sufficient technical competence can see that
the unbounded emulation of DDD emulated by HHH can never halt.
>
No, because the HHH that is given doesn't do that, and that is the only one that matters.
>
>
On 11/3/2024 12:20 PM, Richard Damon wrote:
> On 11/3/24 9:39 AM, olcott wrote:
>>
>> The finite string input to HHH specifies that HHH
>> MUST EMULATE ITSELF emulating DDD.
>
> Right, and it must CORRECTLY determine what an unbounded
> emulation of that input would do, even if its own programming
> only lets it emulate a part of that.
>
>
If you are going to keep contradicting yourself
I am going to stop looking at anything you say.
>
And where is the contradiction?
>
HHH doesn't need to do the unlimited emulation, just say what the unlimited emulation by the unlimited emulator (which WILL be a different program) will do.
>
>
That is what I have been saying all along.
>
So, you agree that HHH1's emulation to the completion shows that the complete emulation of the input to HHH does halt, and thus the correct answer for HHH to give for *THIS* input, which has implicitly included *THIS* HHH as part of it, is that it halts.
>
>
Nothing like this.
You continue to fail to understand that halting
requires reaching the "return" instruction final
halt state. DDD emulated by HHH never does this.
>
But the emulation by HHH isn't the correct measure of DDD reaching its return statement.
>
Well we did get somewhere on this so that is more progress.
Only reaching the final state is halting.
And only something that continues to the end shows that, an emulation that aborts doesn't show that the input is non-halting unless it can prove that the unaborted emulation of that EXACT PROGRAM would never halt.
By the correct meaning of the statement, it is just false.
>
ChatGPT explains why and how it <is> the correct measure
in its own words and from a point of view that I not tell
it or even see for myself.
https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2
Base on your LIES, so doesn't mean anything,
By your attempted meaning, it is just nonsense, and thus a lie to claim it to be true.
>
*It is actually your words that are nonsense*
(a) Finite string of x86 machine code DDD +
Which include the code of the HHH that DDD calls, which you have said is the HHH that aborts and returns the answer.
(b) The semantics of the x86 language +
Which is the defintion of doing *EVERY* instruction, just as presented, and not stopping until you reach a conclusion, something HHH doesn't do, so HHH's emulation doesn't follow this.
(c) DDD is calling its own termination analyzer
Which is irrelevent as it has nothing to do with "x86 langugage semantics", and when taken into account mean that HHH *MUST* return to DDD, and thus DDD MUST halt.
Thus proving that HHH is wrong, and you are just a liar.
∴ HHH is correct to reject its input as non-halting
Nope, just proves that you fail to understand how to do logic, but believe that lying is an acceptable form of logic.
*THIS IS THE PART THAT YOU PRETEND TO NOT SEE*
We can only get to the behavior of the directly executed
DDD() by ignoring (b).
How is that? You seem unable to explain, only make false claims.
The sementics of the x86 language say that the input does what it does when executed. PERIOD.
So, your saying that the x86 semantics only show something when you ignore the x86 semantics is just an admission that you are lying.
You are just trapped in your equivocation, unable to resolve it without admitting your error, but because of it, you are just showing your stupidity.
>
>
And thus, HHH is just wrong.
>
>
No contradiciton in that, unlike your claim that HHH can do a partial emulation to predict what it itself would do when it does a complete emulation of the exact same input using the exact same code.
>
>
I have never said that.
*ChatGPT explains that HHH does meet your model*
>
Nope, it admitted that it doesn't.
>
>
*Simplified Analogy*
Think of HHH as a "watchdog" that steps in during real
execution to stop DDD() from running forever. But when
HHH simulates DDD(), it's analyzing an "idealized" version
of DDD() where nothing stops the recursion. In the simulation,
DDD() is seen as endlessly recursive, so HHH concludes that
it would not halt without external intervention.
>
https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2
>
>
>
>
Except that your input is a LIE.
>
>
It is very stupid to say that a byte string of x86 code is a lie.
>
>
But it doesn't represent the program DDD.
>
THAT is the lie.
>
It is ridiculously stupid to call the ACTUAL x86
machine language of DDD that calls the x86 machine
language of HHH a lie.
It is when you OMIT some of it. Only the WHOLE TRUTH is the truth, a partial truth is just a lie.
You clearly don't understand what a PROGRAM is, and that the PROGRAM DDD must include the code for the HHH that it calls.
It isn't analyzing an "idealized" version of its input, it is analyzing the input it is actually given, where DDD calls the existing HHH, not the idealized version of it.
>
You should know this, and thus all you have done is show that your logic is just based on LIES.
>
>
The paragraph that you said that I keep quoting
is a breakthrough. that you keep contradicting
your own words seems quite dumb to me.
>
How am I contradicting myself?
>
HHH doesn't need to actualy emulate DDD completely, just determine, like HHH1 does, that it will reach the return instruction.
>
That is not what the machine code of DDD that calls
the machine code of HHH says. You are living in a fantasy land.
Right, so that is part of the input, or it can't be emulated.
The Machine code of HHH says that it will abort its emulation and return, so that is the only correct result per the x86 language.
>
Now, if you want to try to define some alternate model of computation
>
No need to do this the x86 model of computation says it all.
(a) Finite string of x86 machine code DDD +
>
Of the FULL program.
>
(b) The semantics of the x86 language +
>
As show by the FULL emulation of the input/
>
(c) DDD is calling its own termination analyzer
>
Which is irrelevent to (b), and if we know that HHH is a termination analyser, we KNOW it will return an answer and thus DDD will halt
>
∴ HHH is correct to reject its input as non-halting
>
Nope, and making the claim just shows that you are an ignorant liar.
>
That you called machine code a liar decimates your
credibility on this.
That you call omitting code (because you aren't going to do what it says) telling the truth just shows that you are a pathological liar.
Note, I didn't call the code a "liar", as it can't be, as it is inanimate.
I called YOU a liar, as you told a falsehood, one that you SHOULD know.
>
As far as the non-halting of the input to the conventional
HP proofs goes these two models are exactly the same.
>
But the input halts, in both models, so your HHH is wrong both ways.
>
A DDD does HALT this DDD IS NOT THE INPUT !!!
A DDD does HALT this DDD IS NOT THE INPUT !!!
A DDD does HALT this DDD IS NOT THE INPUT !!!
What other DDD exists for this HHH?
Your problem is you are caught in your web of lies.
Part of your problem is you lied when you set up the problem, as you lied when you just gave HHH the code for DDD when you claimed your were giving "DDD" as the input, but the input for that type of program needs to be a description of a program, the FULL program, which needs to include what it calls, like HHH.
If you want to create a new theory of computation with a different definition of a program, go ahead and try, but until you do, and fully document it and make clear you are using it, you are stuck with the classical "received" definitions, even if you don't believe in them or understand them.
You are just proving you ignorance.
>
where you can do this, go ahead and try. I suspect you will find it impossible to make such a system objectively consistant with inputs not matching themselves, or programs being able to include stuff that changes on them. And, until you DO actually define such a system, you can't use it as part of your arguement. Your don't even seem to have a real concept of such a system, but just think that is what is.
>
Sorry, you are just proving that you don't understand what you are talking about.
>
>
>
>
The philosophy of computation reformulates existing ideas on a new basis ---
Re: The philosophy of computation reformulates existing ideas on a new basis ---