On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can determine that the input, A PROGRAM, never halts.
/Flibble
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>> must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation. >>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it
can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other number) is the wrong asnwer to the quesstion "does DDD specify a halting computation?".
HHH says "no" and HHH1 says "yes" so one of them gives the wrong answer.
*I can't imagine how Mike does not get this*
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
That the HHH and HHH1 give different reusults for the same input
means that their codes are not functionally equvalent and this
meas that they are not identical.
The subject line does not make sense as the message does not mean what "correct" means in this context. What is correct and what is not depends
on what requirements are specified, and that message specifies none.
For example, to drive a car on the right side of a road is incorrect in
some situations and correct in others, depending on laws applicable to
the road and and on the facts the laws specify as relevant.
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>> must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation. >>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it
can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
And at that point, you have different inputs for different HHHs, and possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Sorry, but you sre just showing your own stupidity, and ignorance of
what you are talking about.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>> different than the direct execution, even though he can't show the >>>>>> instruction actually correctly simulated where they differ, and thus >>>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call >>>>>> HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the
simulation.
Sorry, not being able to do something doesn't mean you get to
redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if
it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have.
Note, your "description" of HHH is just incorrect, as it is also
incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to simulate something.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 163:53:59 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
9,181 files (2,736M bytes) |
| Messages: | 2,411,516 |