Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down

On 6/1/24 4:23 PM, olcott wrote:

On 6/1/2024 2:03 PM, Richard Damon wrote:

On 6/1/24 2:46 PM, olcott wrote:

On 6/1/2024 1:43 PM, Richard Damon wrote:

On 6/1/24 2:31 PM, olcott wrote:

On 6/1/2024 1:21 PM, Richard Damon wrote:

On 6/1/24 2:07 PM, olcott wrote:

On 6/1/2024 12:56 PM, Richard Damon wrote:

On 6/1/24 1:44 PM, olcott wrote:

On 6/1/2024 12:33 PM, Richard Damon wrote:

On 6/1/24 1:27 PM, olcott wrote:

On 6/1/2024 12:22 PM, Richard Damon wrote:

On 6/1/24 12:38 PM, olcott wrote:

On 6/1/2024 11:27 AM, Richard Damon wrote:

On 6/1/24 12:13 PM, olcott wrote:

On 6/1/2024 10:56 AM, Richard Damon wrote:

On 6/1/24 11:30 AM, olcott wrote:

>
*I will not discuss any other points with you until after you either*
(a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
     simulated by embedded_H remain stuck in recursive simulation for
     1 to ∞ of correct simulation or
>
(b) Correctly prove otherwise.

>
And until you answer the question of what that actually means, I will reply WHO CARES.
>

>
typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         HH(DD,DD);
12         return 0;
13       }
>
Every DD correctly simulated by any HH of the infinite set of HH/DD
pairs that match the above template never reaches past its own simulated
line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>
In this case HH is either a pure simulator that never halts or
HH is a pure function that stops simulating after some finite number
of simulated lines. The line count is stored in a local variable.
The pure function HH always returns the meaningless value of 56
after it stops simulating.
>

>
So, still no answer, to teh question.

>
You can pretend that you don't understand something that you do indeed
understand into perpetuity.
>
The key measure of dishonestly would be that you continue to say
that you don't understand yet never ever point out exactly what you
don't understand and why you don't understand it.
>

I giuess that Mean YOU don't even know what you are asking, though it seems that now you are admitting that your HH doesn't actually ANSWER the question, so it isn't ACTUALL a decider for any function except the "56" mapping.
>
I will repeat the question and until you answer the question of what that actually means, I will reply WHO CARES.
>
DO you mean the simulation of the TEMPLATE DD,

>
*Of course I don't mean that nonsense. I mean exactly what I specified*
>

which means that we CAN'T simulate the call HH as we have no code past point to simulate, and thus your claim is just a LIE.
>
Or, do you mean a given instance of HH simulating a given instance of DD, at which point we never have the 1 to infinte number of simulatons of THAT INPUT, so your claim is just a LIE.
>

>
Every element of the infinite set of every H/D pairs...
Every element of the infinite set of every H/D pairs...
Every element of the infinite set of every H/D pairs...
>
*Its not that hard when one refrains from dishonesty*
We can't even say that you forgot these details from one reply
to the next because the details are still in this same post.
>

>
And every one gives a meaningless answer,

>
*THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
DD correctly emulated by HH with an x86 emulator cannot possibly
reach past its own machine instruction [00001c2e] in any finite
number of steps of correct emulation.
>

>
Why? I don't care about it.
>
As I have said, the implication of your definition of "Correct SImulation" means that this says NOTHING about the halting behavior of DD. (only not halted yet)
>

>
*THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
DD correctly emulated by HH with an x86 emulator cannot possibly
reach past its own machine instruction [00001c2e] in any finite
*or infinite* number of steps of correct emulation.
>
When I say it that way you claim to be confused and what I do
not say it that way you claim what I say is incomplete proof.

>
WHy do I care? I won't spend the effort to even try to refute something that is clearly meaningless.
>
You seem to have a conflict of definitions, as a given DD will only ever be simulated by ONE given HH that only simuates for one number of steps.
>

>
typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         HH(DD,DD);
12         return 0;
13       }
>
You continue to either fail to understand or seemingly more likely
simply lie about the fact that every DD correctly simulated by any
HH that can possibly exist cannot possibly reach past its own line 03.
>
*THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
*THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
*THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>

>
Except that even YOU agreed that it did.
>

>
*I never agreed that THE INPUT TO HH(DD,DD) HALTS*

>
Really, Ben points this out from time to time.
>
Do you think that DD(DD) doesn't halt?
>

>
I will not respond to any of your replies while you continue to play
head games.
>
*Changing the subject away from this is construed as a head game*
DD correctly simulated by pure function HH cannot possibly reach
past its own line 03 in any finite number of steps of correct
simulation.
>
In case you didn't know pure functions must halt because they must
return a value.
>

>
Nope, The programming definition of a "Pure Function" does NOT actually require that they actually return a value, never returning a value is a "return value" for such a function.
>
The requirments is that its return value is the SAME for all calls with the same parameters, Not returning is the same value as Not Returning.
>

 In computer programming, a pure function is a function that has the following properties:
 (1) the function return values are identical for identical arguments
(no variation with local static variables, non-local variables, mutable
reference arguments or input streams), and

And never returning is "returning" and identical value as all other never returning.

 (2) the function has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or input/output streams).
https://en.wikipedia.org/wiki/Pure_function
 *I don't believe that a pure function is not required to halt*
*A pure function that returns no value can't reasonably construed*
*as any function at all*

Where does it say what you claim it to say?
Being a "Pure Function" is supposed to be something that is easily proven of a function. If it requires Halting, it can be impossible to prove.

 When terms-of-the-art are involved a {dead cat} can be called
"a little puppy running around the living room".

But I am not doing that, so you are just showing your belief in Red Herring, and that you don't actually have logic to back yourself up.

 

So, your refusing to answers is just an indication that you hae gotten stuck again.
>
Now, some fields consider programs that don't stop to return usless and define them out of bounds, but the general definition doesn't care.
>
Sort of like Computations, Some require them to give an answer, or they aren't one, but then it make the Halting Problem harder to talk about in the field of Computations, as if it has to Halt to be one, asking if it halts doesn't make sense, so you need a term for the more general case where you don't have the requirement to always give an answer.

 I am trying to make my words accessible to software engineers giving these words a much broader audience that will utterly reject that
DD correctly simulated by DD can possibly involve HH emulating
the machine code instructions of DD either incorrectly or in the
incorrect order.
 

So, just define them correctly. Even in "Software Engineering" it is quite obvious that a simulation that has been aborted, does not by itself show that the thing being simulated will never halt.
The only way to actually test that by simulation, is to keep on simulating until you have the data to actually prove the statement.
Also, it is well known that the program does what the program does, and a program that does something different isn't the same program.
Thus if a DD is built on a given HH, changing that HH to do something else gives you a different DD.