On 2025-11-15, olcott <polcott333@gmail.com> wrote:
On 11/15/2025 2:11 PM, Kaz Kylheku wrote:
On 2025-11-15, olcott <polcott333@gmail.com> wrote:
On 11/15/2025 12:11 PM, Kaz Kylheku wrote:
What I mean by that is that the simulation of D
doesn't reach that statement while conducted by H.
Thus conclusively proving the the input to H(D)
No, the mere incompleteness of a simulation does not prove
that the subject terminates or does not terminate.
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
You already admitted that D simulated by H
cannot possibly reach its own final halt state.
The full limit of my observation is this: the /simulation/ conducted by
H, of D, is not conducted far enough to reproduce the situation where D returns. That's the most exact wording, no more no less.
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
On 11/15/2025 3:33 PM, Kaz Kylheku wrote:
On 2025-11-15, olcott <polcott333@gmail.com> wrote:
You already admitted that D simulated by H
cannot possibly reach its own final halt state.
The full limit of my observation is this: the /simulation/ conducted by
H, of D, is not conducted far enough to reproduce the situation where D
returns. That's the most exact wording, no more no less.
That is a damned lie.
When I said damned I mean that
you might actually be condemned to actual Hell.
The whole purpose of my 28 year long primary research
was to show how "true on the basis of meaning" can be
made computable.
So while you may think that your lies are mere trollish
fun if the planet is killed off in part because of your
lies their may be actual Hell toupee.
On 2025-11-15, olcott <polcott333@gmail.com> wrote:
On 11/15/2025 3:33 PM, Kaz Kylheku wrote:
On 2025-11-15, olcott <polcott333@gmail.com> wrote:
You already admitted that D simulated by H
cannot possibly reach its own final halt state.
The full limit of my observation is this: the /simulation/ conducted by
H, of D, is not conducted far enough to reproduce the situation where D
returns. That's the most exact wording, no more no less.
That is a damned lie.
So you are sayiing that the simulation conduced by H, of D,
/is/ conducted far enough to reproduce the situation where D
returns?
When D is the diagonal D, we are not observing that, right?
*Headscratch*
When I said damned I mean that
you might actually be condemned to actual Hell.
The whole purpose of my 28 year long primary research
was to show how "true on the basis of meaning" can be
made computable.
True is not based on meaning. Primary truth are based on
a correspondence between propositions and the state of
the world that those propostions are about.
After that, it's all logical operators combining
them together, hopefully in ways that preserve truths.
So while you may think that your lies are mere trollish
fun if the planet is killed off in part because of your
lies their may be actual Hell toupee.
That's weapons-grade crazy. If you dohn't agree with a lunatic who
thinks the halting problem in math/CS is wrong, you are helping destroy
the planet.
Seriously, pause to listen to yourself for a moment.
On 2025-11-15, olcott <polcott333@gmail.com> wrote:
On 11/15/2025 3:33 PM, Kaz Kylheku wrote:
On 2025-11-15, olcott <polcott333@gmail.com> wrote:
You already admitted that D simulated by H
cannot possibly reach its own final halt state.
The full limit of my observation is this: the /simulation/ conducted by
H, of D, is not conducted far enough to reproduce the situation where D
returns. That's the most exact wording, no more no less.
That is a damned lie.
So you are sayiing that the simulation conduced by H, of D,
/is/ conducted far enough to reproduce the situation where D
returns?
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
...D simulated by H cannot possibly reach its own
simulated "return" statement...
Yes; this doesn't happen while H is running.
On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:
On 11/15/2025 6:56 PM, HAL 9000 wrote:
On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:It great to have someone new here, welcome.
On 5/8/2025 8:30 PM, Keith Thompson wrote:That is only the case if HHH is of an erroneous design: whatever HHH
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you know that DDD
correctly simulated by HHH cannot possibly each its own "return" >>>>>>>> instruction.
This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
is responding to below:
*Here is his response *I am a competent C programmer (and I don't believe you can make the >>>>>>> same claim). I don't know what HHH is. The name "HHH" tells me >>>>>>> nothing about what it's supposed to do. Without knowing what HHH >>>>>>> is,For the purpose of this discussion HHH is exactly what I said it is. >>>>>> It correctly simulates DDD.
I can't say much about your code (or is it pseudo-code?).
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed >>>>> to it? Must the passed function be one that takes no arguments and
does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
We need not know anything else about HHH to know that DDD correctly >>>>>> simulated by HHH cannot possibly REACH its own "return" instruction. >>>>>
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD(); return;
}
Then the return statement (which is unnecessary anyway) will never be >>>>> reached. In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the >>>>> unnecessary return statement will never be reached.
does with DDD should NOT leak out of HHH so your SHD is designed
incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
HHH is erroneous.
/HAL
https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
termination analyzer HHH and input DD have been a fully operational
software system for more than three years.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
When N statements of DD are simulated by HHH according to the semantics
of the C programming language the simulated DD cannot reach its own
simulated "return" statement final halt state for any value of N.
HHH report on the actual behavior that its actual input actually
specifies as measured by DD simulated by HHH.
HHH cannot possibly report on the behavior of its caller because HHH has
no way of knowing what function is calling it.
This means that when the halting problem requires HHH to report on the
behavior of its caller: DD() that its is requiring something outside the
scope of computation,
No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is erroneous.
/HAL
On 11/16/2025 6:42 AM, HAL 9000 wrote:
On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:That is the key objection to my work.
On 11/15/2025 6:56 PM, HAL 9000 wrote:
On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:It great to have someone new here, welcome.
On 5/8/2025 8:30 PM, Keith Thompson wrote:That is only the case if HHH is of an erroneous design: whatever HHH
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you know that DDD
correctly simulated by HHH cannot possibly each its own "return" >>>>>>>>> instruction.
This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
is responding to below:
*Here is his response *I am a competent C programmer (and I don't believe you can make >>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>>> HHH is,For the purpose of this discussion HHH is exactly what I said it >>>>>>> is.
I can't say much about your code (or is it pseudo-code?).
It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is
passed to it? Must the passed function be one that takes no
arguments and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between >>>>>> calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
We need not know anything else about HHH to know that DDD
correctly simulated by HHH cannot possibly REACH its own "return" >>>>>>> instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD(); return;
}
Then the return statement (which is unnecessary anyway) will never >>>>>> be reached. In practice, the program will likely crash due to a
stack overflow, unless the compiler implements tail-call
optimization, in which case the program might just run forever --
which also means the unnecessary return statement will never be
reached.
does with DDD should NOT leak out of HHH so your SHD is designed
incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
HHH is erroneous.
/HAL
https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
termination analyzer HHH and input DD have been a fully operational
software system for more than three years.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
When N statements of DD are simulated by HHH according to the
semantics of the C programming language the simulated DD cannot reach
its own simulated "return" statement final halt state for any value of
N.
HHH report on the actual behavior that its actual input actually
specifies as measured by DD simulated by HHH.
HHH cannot possibly report on the behavior of its caller because HHH
has no way of knowing what function is calling it.
This means that when the halting problem requires HHH to report on the
behavior of its caller: DD() that its is requiring something outside
the scope of computation,
No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
erroneous.
/HAL
The information that HHH is required to report on simply is not
contained in its input.
HHH cannot report on the behavior of its caller because it has no way of
even knowing which function called it. The same thing applies to the
Peter Linz Turing machine version.
HHH(DD) does correctly report on the behavior that its input specifies.
No decider can ever report on more than that.
int sum(int x, int y){ return x + y;}
sum(3,4) cannot report on the sum of 5+6 even if required to do so. That requirement is incorrect.
I have worked on this for 28 years because:
If the halting problem is correct then the notion of "true on the basis
of meaning" is broken.
On Sun, 16 Nov 2025 09:29:48 -0600, olcott wrote:
On 11/16/2025 6:42 AM, HAL 9000 wrote:
On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:That is the key objection to my work.
On 11/15/2025 6:56 PM, HAL 9000 wrote:
On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:It great to have someone new here, welcome.
On 5/8/2025 8:30 PM, Keith Thompson wrote:That is only the case if HHH is of an erroneous design: whatever HHH >>>>> does with DDD should NOT leak out of HHH so your SHD is designed
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you know that DDD >>>>>>>>>> correctly simulated by HHH cannot possibly each its own "return" >>>>>>>>>> instruction.
This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
is responding to below:
*Here is his response *I am a competent C programmer (and I don't believe you can make >>>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>>>> HHH is,For the purpose of this discussion HHH is exactly what I said it >>>>>>>> is.
I can't say much about your code (or is it pseudo-code?).
It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is
passed to it? Must the passed function be one that takes no
arguments and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between >>>>>>> calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate >>>>>>> DDD.
We need not know anything else about HHH to know that DDD
correctly simulated by HHH cannot possibly REACH its own "return" >>>>>>>> instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>> does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD(); return;
}
Then the return statement (which is unnecessary anyway) will never >>>>>>> be reached. In practice, the program will likely crash due to a >>>>>>> stack overflow, unless the compiler implements tail-call
optimization, in which case the program might just run forever -- >>>>>>> which also means the unnecessary return statement will never be
reached.
incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus >>>>> HHH is erroneous.
/HAL
https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
termination analyzer HHH and input DD have been a fully operational
software system for more than three years.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
When N statements of DD are simulated by HHH according to the
semantics of the C programming language the simulated DD cannot reach
its own simulated "return" statement final halt state for any value of >>>> N.
HHH report on the actual behavior that its actual input actually
specifies as measured by DD simulated by HHH.
HHH cannot possibly report on the behavior of its caller because HHH
has no way of knowing what function is calling it.
This means that when the halting problem requires HHH to report on the >>>> behavior of its caller: DD() that its is requiring something outside
the scope of computation,
No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
erroneous.
/HAL
The information that HHH is required to report on simply is not
contained in its input.
HHH cannot report on the behavior of its caller because it has no way of
even knowing which function called it. The same thing applies to the
Peter Linz Turing machine version.
HHH(DD) does correctly report on the behavior that its input specifies.
No decider can ever report on more than that.
int sum(int x, int y){ return x + y;}
sum(3,4) cannot report on the sum of 5+6 even if required to do so. That
requirement is incorrect.
I have worked on this for 28 years because:
If the halting problem is correct then the notion of "true on the basis
of meaning" is broken.
DD halts.
/HAL
On Sun, 16 Nov 2025 09:29:48 -0600, olcott wrote:
On 11/16/2025 6:42 AM, HAL 9000 wrote:
On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:That is the key objection to my work.
On 11/15/2025 6:56 PM, HAL 9000 wrote:
On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:It great to have someone new here, welcome.
On 5/8/2025 8:30 PM, Keith Thompson wrote:That is only the case if HHH is of an erroneous design: whatever HHH >>>>> does with DDD should NOT leak out of HHH so your SHD is designed
olcott <polcott333@gmail.com> writes:
On 5/8/2025 6:49 PM, Keith Thompson wrote:
olcott <polcott333@gmail.com> writes:
[...]
void DDD()"cannot possibly each"?
{
HHH(DDD);
return;
}
If you are a competent C programmer then you know that DDD >>>>>>>>>> correctly simulated by HHH cannot possibly each its own "return" >>>>>>>>>> instruction.
This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
is responding to below:
*Here is his response *I am a competent C programmer (and I don't believe you can make >>>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells >>>>>>>>> me nothing about what it's supposed to do. Without knowing what >>>>>>>>> HHH is,For the purpose of this discussion HHH is exactly what I said it >>>>>>>> is.
I can't say much about your code (or is it pseudo-code?).
It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is
passed to it? Must the passed function be one that takes no
arguments and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between >>>>>>> calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate >>>>>>> DDD.
We need not know anything else about HHH to know that DDD
correctly simulated by HHH cannot possibly REACH its own "return" >>>>>>>> instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>> does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD(); return;
}
Then the return statement (which is unnecessary anyway) will never >>>>>>> be reached. In practice, the program will likely crash due to a >>>>>>> stack overflow, unless the compiler implements tail-call
optimization, in which case the program might just run forever -- >>>>>>> which also means the unnecessary return statement will never be
reached.
incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus >>>>> HHH is erroneous.
/HAL
https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
termination analyzer HHH and input DD have been a fully operational
software system for more than three years.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
When N statements of DD are simulated by HHH according to the
semantics of the C programming language the simulated DD cannot reach
its own simulated "return" statement final halt state for any value of >>>> N.
HHH report on the actual behavior that its actual input actually
specifies as measured by DD simulated by HHH.
HHH cannot possibly report on the behavior of its caller because HHH
has no way of knowing what function is calling it.
This means that when the halting problem requires HHH to report on the >>>> behavior of its caller: DD() that its is requiring something outside
the scope of computation,
No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
erroneous.
/HAL
The information that HHH is required to report on simply is not
contained in its input.
HHH cannot report on the behavior of its caller because it has no way of
even knowing which function called it. The same thing applies to the
Peter Linz Turing machine version.
HHH(DD) does correctly report on the behavior that its input specifies.
No decider can ever report on more than that.
int sum(int x, int y){ return x + y;}
sum(3,4) cannot report on the sum of 5+6 even if required to do so. That
requirement is incorrect.
I have worked on this for 28 years because:
If the halting problem is correct then the notion of "true on the basis
of meaning" is broken.
DD halts.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,089 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 153:45:24 |
| Calls: | 13,921 |
| Calls today: | 2 |
| Files: | 187,021 |
| D/L today: |
3,744 files (941M bytes) |
| Messages: | 2,457,161 |