Re: Every sufficiently competent C programmer knows --- Semantic Property of Finite String

On Fri, 2025-03-14 at 09:35 -0500, olcott wrote:

On 3/14/2025 7:30 AM, dbush wrote:

On 3/13/2025 9:48 PM, olcott wrote:

On 3/13/2025 4:21 PM, Richard Heathfield wrote:

On 13/03/2025 20:48, dbush wrote:

On 3/13/2025 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

 
NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

 
The direct execution of DDD

 
is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

 
Which is weird, considering that a simulator should produce the same
behaviour.
 
 

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF
THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.
 

 
Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) cannot possibly
reach its own final state no matter what HHH
does.
 
Replacing the code of HHH1 with an unconditional simulator and
subsequently running HHH1(DD) does reach its
own final state.
 
If someone was not a liar they would say that
these are different computations.
 

 
Only because one changes the code that DD runs and one doesn't

 
It hardly matters. Either his emulation faithfully and correctly
establishes and reports (for EVERY program anyone cares to feed it)
the actual halting behaviour exhibited by the program it's emulating,
or it doesn't.
 

 
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 
That everyone expects the behavior of the directly
executed DDD to be the same as DDD correctly emulated
by HHH1 is verified as a factually correct expectation.

 
Right, because changing the code of HHH1 doesn't change the input.
 

 
That everyone expects the behavior of the directly
executed DDD to be the same as DDD correctly emulated
by HHH is verified as a factually incorrect expectation.
 

 
You only think that because you don't understand that changing the code
of HHH changes DDD.  Changing the input is not allowed.
 
 

It is very common for people to be so well indoctrinated
that they reject verified facts out-of-hand without review.
 

If it doesn't, it doesn't, and it's a lot of fuss over nothing.
 
But if it /does/, then we're right back at Turing's proof, because a
working emulator is just another way of running the code, and is
therefore superfluous to requirements. It adds nothing to the debate,
because we can just run the code and get the same answer the emulator
would provide.
 

 
For the first time in the history of mankind it proves
that a simulation of a virtual machine according to
the semantics of this machine language
DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT
EXECUTION OF THIS SAME MACHINE

 
You don't have the same machine.  You just can't see that.
 
And what you forget is that we're not asking what HHH is able to
simulate.  We're asking what DDD does when it's executed directly.  That
HHH attempts to use simulation doesn't change that.
 

 
PATHOLOGICAL SELF REFERENCE DOES CHANGE SEMANTICS
PATHOLOGICAL SELF REFERENCE DOES CHANGE SEMANTICS
PATHOLOGICAL SELF REFERENCE DOES CHANGE SEMANTICS
PATHOLOGICAL SELF REFERENCE DOES CHANGE SEMANTICS
 
"This sentence is not true"
is neither true nor false because of PSR
 
This sentence is not true: "This sentence is not true"
The exact same word-for-word sentence
IS TRUE IN THIS DIFFERING CONTEXT THAT DOES NOT HAVE PSR.
 

In other words, the emulator is a canard, a distraction, a cul-de-
sac, and a complete waste of time. If it happens to work, great! Well
done that man. But it doesn't affect the HP logic one microscopically
minuscule millijot.
 

 
The emulator proves the actual behavior specified by the
INPUT INPUT INPUT INPUT INPUT

 
And the behavior of the input is specified by the specification:
 
 
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
 
A solution to the halting problem is an algorithm H that computes the
following mapping:
 
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
 
 

 
That people disagree with the semantics of the x86 language
proves how deeply indoctrinated they are.
 

 
The semantics of the x86 language says that when the input to HHH(DDD)
is actually run on an actual x86 processor that it will halt.
 

 
 
void DDD()
{
   HHH(DDD);
   return;
}
 
DDD correctly simulated by HHH cannot possibly reach
its own "return" instruction in any finite number of
correctly simulated steps.
 
That you are clueless about the semantics of something
as simple as a tiny C function proves that you are not
competent to review my work.
 

https://en.wikipedia.org/wiki/Halting_problem
In computability theory, the halting problem is the problem of determining, from a description of an
arbitrary computer program and an input, whether the program will finish running, or continue to run
forever.

That means: H(D)=1 if D() halts and H(D)=0 if D() does not halt.

But, it seems you don't understand English, as least as my level, ....