On 10/28/2025 7:25 PM, Kaz Kylheku wrote:The strings are the same whatever you do with them.
On 2025-10-29, olcott <[email protected]> wrote:
On 10/28/2025 6:52 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <[email protected]> wrote:
On 10/28/2025 5:14 PM, Kaz Kylheku wrote:
If some H_other decider is tested on H_other(D), then the "Olcott*So we need to clarify*
reality distortion wave function" (ORDF) collapses, and D.input
becomes the same as D.noninput.
D.input_to_H versus D.non_input_to_H which can be:
D.input_to_H1 D.executed_from_main
I take Rice's semantic properties of programs and clarify that this
has always meant the semantic properties of finite string machine
descriptions.
Then I further divide this into (a) semantic properties of INPUT
finite strings (b) semantic properties of NON_INPUT finite strings
That much is obvious, but only because H1 continues past the secondThe problem is that "input" is just a role of some datum in aUnless you bother to pay attention to the fact that the sequence of
context, like a function
The input versus non-input distinction cannot be found in any binary
digit of the bit string comprising the datum itself.
steps of D simulated by H is a different sequence of steps than D
simulated by H1.
How do we know what is correct?Because all deciders only report on what their input specifies H(D)==0
and H1(D)==1 are both correct.
Suppose I'm given an input D, and two deciders X and Y.As far as a DOS (denial of service) attack goes H(D)==0 correctly
I know nothing about these. (But they are simulating deciders,
producing different executions.)
X accepts, Y rejects.
Do I regard both of them as right? Or one of them wrong?
If so, which one? Or both wrong?
Suppose I happen to be sure that D halts. So I know X is correct.
rejects its input.
So even if ostensibly you resolved the halting problem on one level by
simply /excusing/ some programs from calculating the traditional
halting value when they are given non-inputs, you've not actually
solved the real halting problem: that of the end-user simply wanting to
know whether a given program will terminate or not. The end user has no
way of knowing whether a program was excused on a non-input, or whether
it is just fumbling an input.
Am Tue, 28 Oct 2025 19:33:20 -0500 schrieb olcott:
On 10/28/2025 7:25 PM, Kaz Kylheku wrote:
On 2025-10-29, olcott <[email protected]> wrote:
On 10/28/2025 6:52 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <[email protected]> wrote:
On 10/28/2025 5:14 PM, Kaz Kylheku wrote:
If some H_other decider is tested on H_other(D), then the "Olcott >>>>>>> reality distortion wave function" (ORDF) collapses, and D.input*So we need to clarify*
becomes the same as D.noninput.
D.input_to_H versus D.non_input_to_H which can be:
D.input_to_H1 D.executed_from_main
I take Rice's semantic properties of programs and clarify that this >>>>>> has always meant the semantic properties of finite string machine
descriptions.
Then I further divide this into (a) semantic properties of INPUT
finite strings (b) semantic properties of NON_INPUT finite strings
The strings are the same whatever you do with them.
The problem is that "input" is just a role of some datum in aUnless you bother to pay attention to the fact that the sequence of
context, like a function
The input versus non-input distinction cannot be found in any binary >>>>> digit of the bit string comprising the datum itself.
steps of D simulated by H is a different sequence of steps than D
simulated by H1.
That much is obvious, but only because H1 continues past the second recursively simulated call to H.
How do we know what is correct?Because all deciders only report on what their input specifies H(D)==0
and H1(D)==1 are both correct.
Suppose I'm given an input D, and two deciders X and Y.As far as a DOS (denial of service) attack goes H(D)==0 correctly
I know nothing about these. (But they are simulating deciders,
producing different executions.)
X accepts, Y rejects.
Do I regard both of them as right? Or one of them wrong?
If so, which one? Or both wrong?
Suppose I happen to be sure that D halts. So I know X is correct.
rejects its input.
It’s a false positive. One can run D just fine.
So even if ostensibly you resolved the halting problem on one level by
simply /excusing/ some programs from calculating the traditional
halting value when they are given non-inputs, you've not actually
solved the real halting problem: that of the end-user simply wanting to
know whether a given program will terminate or not. The end user has no
way of knowing whether a program was excused on a non-input, or whether
it is just fumbling an input.
That’s his solution to the HP: it is wrong to even think about it.
On 11/3/2025 8:12 AM, joes wrote:
Am Tue, 28 Oct 2025 19:33:20 -0500 schrieb olcott:
On 10/28/2025 7:25 PM, Kaz Kylheku wrote:
On 2025-10-29, olcott <[email protected]> wrote:
On 10/28/2025 6:52 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <[email protected]> wrote:
*So we need to clarify*
D.input_to_H versus D.non_input_to_H which can be:
D.input_to_H1 D.executed_from_main
I take Rice's semantic properties of programs and clarify that
this has always meant the semantic properties of finite string
machine descriptions.
Then I further divide this into (a) semantic properties of INPUT >>>>>>> finite strings (b) semantic properties of NON_INPUT finite strings
The strings are the same whatever you do with them.Not exactly because D simulated by H requires H to simulate (an instance
of) itself simulating (an instance of)
D and D simulated by H1 does not require this.
That much is obvious, but only because H1 continues past the secondUnless you bother to pay attention to the fact that the sequence of
steps of D simulated by H is a different sequence of steps than D
simulated by H1.
recursively simulated call to H.
As far as a DOS (denial of service) attack goes H(D)==0 correctlyIt’s a false positive. One can run D just fine.
rejects its input.
That’s his solution to the HP: it is wrong to even think about it.
Am Mon, 03 Nov 2025 10:20:04 -0600 schrieb olcott:
On 11/3/2025 8:12 AM, joes wrote:
Am Tue, 28 Oct 2025 19:33:20 -0500 schrieb olcott:
On 10/28/2025 7:25 PM, Kaz Kylheku wrote:
On 2025-10-29, olcott <[email protected]> wrote:
On 10/28/2025 6:52 PM, Kaz Kylheku wrote:
On 2025-10-28, olcott <[email protected]> wrote:
Not exactly because D simulated by H requires H to simulate (an instance*So we need to clarify*
D.input_to_H versus D.non_input_to_H which can be:
D.input_to_H1 D.executed_from_main
I take Rice's semantic properties of programs and clarify that >>>>>>>> this has always meant the semantic properties of finite string >>>>>>>> machine descriptions.
Then I further divide this into (a) semantic properties of INPUT >>>>>>>> finite strings (b) semantic properties of NON_INPUT finite strings
The strings are the same whatever you do with them.
of) itself simulating (an instance of)
D and D simulated by H1 does not require this.
That much is obvious, but only because H1 continues past the secondUnless you bother to pay attention to the fact that the sequence of >>>>>> steps of D simulated by H is a different sequence of steps than D
simulated by H1.
recursively simulated call to H.
As far as a DOS (denial of service) attack goes H(D)==0 correctlyIt’s a false positive. One can run D just fine.
rejects its input.
That’s his solution to the HP: it is wrong to even think about it.
H and H1 are passed the same string.
On 11/3/2025 11:06 AM, joes wrote:
Am Mon, 03 Nov 2025 10:20:04 -0600 schrieb olcott:
On 11/3/2025 8:12 AM, joes wrote:
The strings are the same whatever you do with them.Not exactly because D simulated by H requires H to simulate (an
instance of) itself simulating (an instance of)
D and D simulated by H1 does not require this.
As far as a DOS (denial of service) attack goes H(D)==0 correctlyIt’s a false positive. One can run D just fine.
rejects its input.
H and H1 are passed the same string.Yet H must simulate itself simulating D and H1 must not simulate itself simulating D.
Am Mon, 03 Nov 2025 11:22:05 -0600 schrieb olcott:
On 11/3/2025 11:06 AM, joes wrote:
Am Mon, 03 Nov 2025 10:20:04 -0600 schrieb olcott:
On 11/3/2025 8:12 AM, joes wrote:
The strings are the same whatever you do with them.Not exactly because D simulated by H requires H to simulate (an
instance of) itself simulating (an instance of)
D and D simulated by H1 does not require this.
As far as a DOS (denial of service) attack goes H(D)==0 correctlyIt’s a false positive. One can run D just fine.
rejects its input.
H and H1 are passed the same string.Yet H must simulate itself simulating D and H1 must not simulate itself
simulating D.
Of course. The string D is different from itself because it can’t call
two different functions at once?
On 11/3/2025 11:26 AM, joes wrote:
Am Mon, 03 Nov 2025 11:22:05 -0600 schrieb olcott:int main()
On 11/3/2025 11:06 AM, joes wrote:
Am Mon, 03 Nov 2025 10:20:04 -0600 schrieb olcott:
On 11/3/2025 8:12 AM, joes wrote:
The strings are the same whatever you do with them.Not exactly because D simulated by H requires H to simulate (an
instance of) itself simulating (an instance of)
D and D simulated by H1 does not require this.
As far as a DOS (denial of service) attack goes H(D)==0 correctly >>>>>>> rejects its input.It’s a false positive. One can run D just fine.
H and H1 are passed the same string.Yet H must simulate itself simulating D and H1 must not simulate
itself simulating D.
Of course. The string D is different from itself because it can’t call
two different functions at once?
{
H(D); // correctly returns 0
H1(D) // correctly returns 1
}
Yet H must simulate itself simulating D
and H1 must not simulate itself simulating D.
I never even had to tell the LLMs about this
they all figured this out on their own.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 76:03:04 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
4,753 files (1,565M bytes) |
| Messages: | 2,443,114 |