Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #107629
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Newsgroups | comp.theory, sci.logic |
| Subject | Re: Why do people here insist on denying these verified facts? |
| Date | 2024-06-22 13:08 -0400 |
| Organization | i2pn2 (i2pn.org) |
| Message-ID | <v570e5$onl4$10@i2pn2.org> (permalink) |
| References | <v56n8h$3pr25$1@dont-email.me> <v56ntj$onl3$7@i2pn2.org> <v56ps2$3q4ea$1@dont-email.me> <v56ql2$onl3$9@i2pn2.org> <v56t5a$3ql1v$1@dont-email.me> |
Cross-posted to 2 groups.
On 6/22/24 12:12 PM, olcott wrote:
> On 6/22/2024 10:29 AM, Richard Damon wrote:
>> On 6/22/24 11:16 AM, olcott wrote:
>>> On 6/22/2024 9:42 AM, Richard Damon wrote:
>>>> On 6/22/24 10:31 AM, olcott wrote:
>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>
>>>>> To understand this analysis requires a sufficient knowledge of
>>>>> the C programming language and what an x86 emulator does. HHH0
>>>>> and HHH1 have this criteria as their algorithm:
>>>>
>>>> Which you just showed you don't have, since on comp.lang.c++ you
>>>> thought that
>>>>
>>>> x *= ++f * ++f;
>>>>
>>>> had defined behavior for primative types for f.
>>>>
>>>>>
>>>>> <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 words 10/13/2022>
>>>>
>>>> Which used the definition of "Correct Simulation" to mean a
>>>> simulation that produces the EXACT results of the direct execution
>>>> of the machine being simulated, which requires a simulation that
>>>> will not "abort" its simulation, EVER (except by reaching a final
>>>> state).
>>>>
>>>
>>> I have had enough of your deception trying to get away
>>> with denying the semantics of the x86 programming language.
>>> I really hope that you don't get condemned to Hell over this.
>>
>> And what in the actual detail of the x86 programming language says
>> something diffferent than what I say?
>>
>> I think YOU are the one in danger, as you LIE about what the x86
>> assembly code says,
>>
>>>
>>>> You Deciders do not do this, nor do they do this about an actual
>>>> Correct Simulation per that definition of the input, so they can not
>>>> use the second clause.
>>>>
>>>>>
>>>>> 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.
>>>>> >
>>>>>
>>>>> Ben only agrees that the criteria is met for the input. He
>>>>> does not agree that the criteria has been meet for non-inputs.
>>>>
>>>> Ben only agrees that H correctly decides the exact criteria that you
>>>> state, that no H can "correctly simuate" (per YOUR definition) the
>>>> input to a final state.
>>>
>>> And you happily deny the verified facts at the possible cost
>>> of damnation in Hell.
>>>
>>>> Thus, he is agreeing that you H is a POOP decider, for this input,
>>>> but not that it is a HALTING decider for this input, since its
>>>> criteria is not the Halting Criteria.
>>>>
>>>>>
>>>>> Computable functions are the formalized analogue of the intuitive
>>>>> notion of algorithms, in the sense that a function is computable if
>>>>> there exists an algorithm that can do the job of the function, i.e.
>>>>> *given an input of the function domain*
>>>>> *it can return the corresponding output*
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>
>>>>> *That seems to say that non-inputs do not count*
>>>>
>>>> But we aren't talking about "Non-Inputs",
>>>
>>> The D(D) that calls H(D,D) such that this call returns has
>>> provably different behavior than D correctly simulated by H
>>> is measured by the actual semantics of the x86 programming
>>> language.
>>>
>>> How the Hell does anyone feel that they can get away with
>>> flatly contradicting the semantics of the x86 programming
>>> language?
>>>
>>> We are a herd and our first duty it to follow the herd
>>> even if the herd leaps off a cliff.
>>>
>>>> and in fact, YOUR arguement needs to look at the non-inputs, as it
>>>> allows the input to change when you argue about other deciders.
>>>>
>>> int sum(int x, int y){ return x + y; }
>>> In other words sum(3,4) must consider the sum of 5 + 6?
>>>
>>>> The input is the finite string.
>>>>
>>>> The MEANING of that finite string is defined by the PROBLEM.
>>>
>>> LIAR. You know that the meaning of the finite string
>>> is defined by the semantics of the x86 language.
>>
>> Right, by what the DIRECT EXECUTION of that set of instruction will do.
>>
>> Which means, for your input, in needs the instuctions of the decider
>> it calls.
>>
>>>
>>> I might start wishing that you get a tiny taste of Hell
>>> to set you on the correct path.
>>>
>>> As Christ said as ye judge ye shall be judged so I do
>>> wish the same thing upon myself. If I am on the wrong
>>> path then I sincerely wish for the minimum adversity
>>> required to definitely set me on the right path.
>>>
>>>> The decider gets to define the encoding, but not the
>>>> meaning/behavior of the encoded items.
>>>>
>>>
>>> When the x86 language is specified then the decider
>>> has zero leeway in this.
>>
>> So, what in the x86 language shows what you claim?
>>
>>>
>>>> Halting DEFINES the meaning/behavior to be that of the directly run
>>>> program represented by the input.
>>>
>>> That makes it contradict one of its own axioms, thus
>>> conclusively proving that it is incorrect:
>>>
>>> Computable functions are the formalized analogue of the
>>> intuitive notion of algorithms, in the sense that a
>>> function is computable if there exists an algorithm
>>> that can do the job of the function, i.e.
>>> *given an input of the function domain it*
>>> *can return the corresponding output*
>>> https://en.wikipedia.org/wiki/Computable_function
>>
>> Who says Halting is a Computable Function?
>>
>
> That is the wrong question.
No, it is exactly the right question.
You can't claim the Definition of Halting is in contradiction to the
definition of a Computable Function unless you say that Halting needs to
be Computable.
Since it isn't defined to be that, it doesn't need to be compatable with it.
> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.
HALTING, as properly defined is NOT comptable.
You are stuck in a circular argument where you are trying to define it
to be computable by redefining what it is, which means you aren't
actually talking about Halting.
>
>> THAT is part of your problem.
>>
>> The question actually is, "IS Halting Computable?"
>>
>>>
>>>>>
>>>>> *Here is the verified facts that everyone denies*
>>>>> *Here is the verified facts that everyone denies*
>>>>> *Here is the verified facts that everyone denies*
>>>>> *Here is the verified facts that everyone denies*
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH0(DDD);
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", HHH0(DDD));
>>>>> Output("Input_Halts = ", HHH1(DDD));
>>>>> }
>>>>>
>>>>> It is a verified fact that the behavior that finite string DDD
>>>>> presents to HH0 is that when DDD correctly emulated by HH0
>>>>> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
>>>>>
>>>>> It is a verified fact that the behavior that finite string DDD
>>>>> presents to HH1 is that when DDD correctly emulated by HH1
>>>>> calls HH0(DDD) that *THIS CALL DOES RETURN*
>>>>>
>>>>>
>>>>
>>>>
>>>> The problem is that the "behavior" that the finite string DDD
>>>> presents to HH0, is DEFINED by the problem.
>>>
>>> LIAR. It is defined by the semantics of the x86 language.
>>
>> Right, as the results of the direfdt execution of the input, which
>> means the input needs to contain ALL the instructions that will be
>> executed.
>>
>
> *WRONG*
> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.
Halting is NOT computable. PERIOD.
Your "Computable Function" is not Halting. PERIOD.
You are just being caught in your own lies.
>
>>>
>>>> And if that problem is the Halting Problem, that behavior is the
>>>> behavior of the machine the input represents. If HH0 treats the
>>>> input as having a different behavior, then HH0 just isn't a Halting
>>>> Decider, but something else.
>>>>
>>>> If HH0 is supposed to be a Halting decider, but uses a method that
>>>> makes it see something other than that behavior, then it is just an
>>>> incorrect Halting Decider, and its algorithm just creates an
>>>> incorrect recreation of the property of the input it is supposed to
>>>> be working on.
>>>>
>>>>
>>>> A bit of a side note, the actual "Input" to HH0, is a pointer to
>>>> memory, and as such it passes a reference to ALL of memory
>>>> considering the starting point to be that address, so your "Input"
>>>> isn't actually the few bytes of DDD, but ALL of memory and a
>>>> starting point. If you actually mean that the input is just those
>>>> few bytes pointed to by the address, then the input is improperly
>>>> formed and is NOT a proper representation of the input machine,
>>>> becuase it is incomplete.
>>>>
>>>> The fact you don't understand this, seems to imply you are lacking
>>>> the basic knowledge to be talking about this sort of thing.
>>>>
>>>
>>> The input to HHH0(DDD) includes itself.
>>> The input to HHH1(DDD) DOES NOT include itself.
>>
>> So?
>>
>
> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.
Halting is NOT computable. PERIOD.
Your "Computable Function" is not Halting. PERIOD.
You are just being caught in your own lies.
>
>>>
>>> It is stipulated that correct emulation is defined by the
>>> semantics of the x86 programming language and nothing else.
>>
>> Right, so HHH0 needs to determine what the ACTUAL BEHAVIOR of its
>> input is to be a Halt Decider, and that means it needs to figure out
>> what it will itself do.
>>
>>>
>>> DDD correctly emulated by HHH0 correctly determines that
>>> the call from the emulated DDD to HHH0 DOES NOT RETURN.
>>
>> Nope, It just determins that it doesn't know if the call will return.
>>
>
> *WHY LIE ABOUT THIS* ???
> *We can see the repeating state and HHH0 sees this too*
> Begin Local Halt Decider Simulation Execution Trace Stored at:15e2fa
> [00002172][0015e2ea][0015e2ee] 55 push ebp ; begin DDD
> [00002173][0015e2ea][0015e2ee] 8bec mov ebp,esp
> [00002175][0015e2e6][00002172] 6872210000 push 00002172 ; push DDD
> [0000217a][0015e2e2][0000217f] e853f4ffff call 000015d2 ; call HHH0
AND RIGHT HERE YOU VIOLATED YOUR DEFINITION OF "CORRECT SIMUATION"
Please show the reference in a x86 reference manual that says that this
is what the call 0000015d2 does at the CPU LEVEL.
This is one of your CORE LIES.
> New slave_stack at:198d1a
> [00002172][001a8d12][001a8d16] 55 push ebp ; begin DDD
> [00002173][001a8d12][001a8d16] 8bec mov ebp,esp
> [00002175][001a8d0e][00002172] 6872210000 push 00002172 ; push DDD
> [0000217a][001a8d0a][0000217f] e853f4ffff call 000015d2 ; call HHH0
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> The above does not have a separate recursive simulation detection
> it simply uses its infinite recursion criteria:
And isn't based on the CORRECT x86 SIMULATION of the input, so doesn't
meet your criteria.
Showing you are just a pathetic liar.
Proves based on LIES are just LIES.
>
> if (current->Simplified_Opcode == CALL)
> if (current->Simplified_Opcode ==
> traced->Simplified_Opcode) // CALL
> if (current->Address == traced->Address) // from same address
> if (current->Decode_Target ==
> traced->Decode_Target) // to Same Function
> if (Count_Conditional_Branch_Instructions == 0) // no escape
> {
> OutputString((char*)"Local Halt Decider: "
> "Infinite Recursion Detected Simulation Stopped\n\n");
> return 1;
> }
>
> void Infinite_Recursion()
> {
> Infinite_Recursion();
> }
>
> int main()
> {
> Output("Input_Halts = ", HHH0(Infinite_Recursion));
> }
>
> _Infinite_Recursion()
> [00002152] 55 push ebp
> [00002153] 8bec mov ebp,esp
> [00002155] e8f8ffffff call 00002152
> [0000215a] 5d pop ebp
> [0000215b] c3 ret
> Size in bytes:(0010) [0000215b]
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:1138d2
> [00002152][001138c2][001138c6] 55 push ebp
> [00002153][001138c2][001138c6] 8bec mov ebp,esp
> [00002155][001138be][0000215a] e8f8ffffff call 00002152
> [00002152][001138ba][001138c2] 55 push ebp
> [00002153][001138ba][001138c2] 8bec mov ebp,esp
> [00002155][001138b6][0000215a] e8f8ffffff call 00002152
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>>>
>>> DDD correctly emulated by HHH1 correctly determines that
>>> the call from the emulated DDD to HHH0 DOES RETURN.
>>>
>>>
>>>
>>>
>>
>
Back to comp.theory | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 09:31 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 10:42 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 10:16 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 11:29 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 11:12 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 13:08 -0400
Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-22 16:03 +0000
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 11:18 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 13:13 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 12:29 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 14:43 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 13:49 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 14:55 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 14:03 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 15:19 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 14:35 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 15:43 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 14:49 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 16:08 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 18:59 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 20:19 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 22:37 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 07:28 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:36 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 14:22 -0400
Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-22 20:01 +0000
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 18:57 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 20:07 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 19:09 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 20:26 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 22:46 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 07:28 -0400
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:37 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 14:22 -0400
Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-25 09:20 +0000
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-23 12:50 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:25 -0500
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:31 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-24 08:52 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-24 19:20 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:42 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-25 08:29 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-26 10:41 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-26 07:25 -0500
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:02 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-27 12:18 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-28 11:55 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-28 09:54 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-28 23:49 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-29 10:44 +0300
Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-25 20:41 +0000
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-25 16:24 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-26 10:46 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-26 07:45 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-26 19:41 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:06 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-27 14:19 -0500
Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-26 08:19 +0000
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-23 12:42 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:23 -0500
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:32 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-24 08:50 -0500
Re: Why do people here insist on denying these verified facts? immibis <news@immibis.com> - 2024-06-24 16:03 +0200
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:48 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-25 08:19 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-26 10:54 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-26 07:53 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-26 19:41 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:18 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-27 14:42 -0500
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-28 12:06 +0300
Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-28 10:07 -0500
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-29 10:47 +0300
Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-24 19:21 -0400
Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:47 +0300
Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-25 08:54 +0000
csiph-web