On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
Right and it doesn't.
I am saying that HHH does need to do the infinite emulation itself, but >>>
But doesn't give the required answer, which is based on something
doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation itself, >>>>> but
Right and it doesn't.
But doesn't give the required answer, which is based on something
doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH and DDD
are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of the
program DDD would do if it was based on some OTHER version of HHH,
Right, and it must CORRECTLY determine what an unbounded--
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation
itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on something
doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH and DDD
are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of the
program DDD would do if it was based on some OTHER version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation
itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on something
doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH and
DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of the
program DDD would do if it was based on some OTHER version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
Nope, never said it could immulate some OTHER input, or predict what
some OTHER program does.
must CORRECTLY determine what an unbounded--
emulation of that input would do,
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation
itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on something >>>>>> doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH and
DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of the
program DDD would do if it was based on some OTHER version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
Nope, never said it could immulate some OTHER input, or predict what
some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation >>>>>>>>> itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on something >>>>>>> doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH and
DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of the
program DDD would do if it was based on some OTHER version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
Nope, never said it could immulate some OTHER input, or predict what
some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different DDD that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that DDD
calls. so that doesn't change.
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:*Yes just like you agreed that it should*
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming >>>>>>> > only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation >>>>>>>>>> itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on
something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH and >>>>>> DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of the >>>>>> program DDD would do if it was based on some OTHER version of HHH, >>>>>
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>
Nope, never said it could immulate some OTHER input, or predict what
some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different DDD
that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that DDD
calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming >>>>>>>> > only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation >>>>>>>>>>> itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on
something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH
and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of
the program DDD would do if it was based on some OTHER version of >>>>>>> HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>>
Nope, never said it could immulate some OTHER input, or predict
what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different DDD
that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that DDD
calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything that you
say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something different than it is, that is just foolishness.
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>> > emulation of that input would do, even if its own programming >>>>>>>>> > only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation >>>>>>>>>>>> itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on
something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH >>>>>>>> and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of >>>>>>>> the program DDD would do if it was based on some OTHER version >>>>>>>> of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>>>
Nope, never said it could immulate some OTHER input, or predict
what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different DDD
that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that DDD
calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything that you
say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
Even HHH itself is bounded
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>> > emulation of that input would do, even if its own programming >>>>>>>>>> > only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite emulation >>>>>>>>>>>>> itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on >>>>>>>>>>> something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH >>>>>>>>> and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of >>>>>>>>> the program DDD would do if it was based on some OTHER version >>>>>>>>> of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>>>>
Nope, never said it could immulate some OTHER input, or predict >>>>>>> what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different DDD
that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that DDD
calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything that
you say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
HHH
must CORRECTLY determine what an unboundedEven HHH itself is bounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
Right, but that unlimited emulation isn't done by CHANGING the copy of
HHH that DDD calls, but by giving the input to a DIFFERENT program than
HHH that does the unlimited emulation,
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>> > emulation of that input would do, even if its own programming >>>>>>>>>>> > only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite >>>>>>>>>>>>>> emulation itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on >>>>>>>>>>>> something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, HHH >>>>>>>>>> and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version of >>>>>>>>>> the program DDD would do if it was based on some OTHER version >>>>>>>>>> of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>> > emulation of that input would do,
even if its own programming only lets it emulate a part of >>>>>>>>> that.
Nope, never said it could immulate some OTHER input, or predict >>>>>>>> what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different DDD >>>>>> that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that DDD >>>>>> calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything that
you say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
HHH
must CORRECTLY determine what an unboundedEven HHH itself is bounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
Right, but that unlimited emulation isn't done by CHANGING the copy of
HHH that DDD calls, but by giving the input to a DIFFERENT program
than HHH that does the unlimited emulation,
*That is NOT what you said*
On 11/3/2024 12:20 PM, Richard Damon wrote:
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
On 11/9/24 10:10 PM, olcott wrote:
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH >>>>>>>>>>>> >> MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>> > emulation of that input would do, even if its own >>>>>>>>>>>> programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite >>>>>>>>>>>>>>> emulation itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on >>>>>>>>>>>>> something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT.
*Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, >>>>>>>>>>> HHH and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted
its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error.
In other words, it tries to predict what some OTHER version >>>>>>>>>>> of the program DDD would do if it was based on some OTHER >>>>>>>>>>> version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>> > emulation of that input would do,
even if its own programming only lets it emulate a part of >>>>>>>>>> that.
Nope, never said it could immulate some OTHER input, or predict >>>>>>>>> what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different
DDD that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that
DDD calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything that
you say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
HHH
must CORRECTLY determine what an unboundedEven HHH itself is bounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
Right, but that unlimited emulation isn't done by CHANGING the copy
of HHH that DDD calls, but by giving the input to a DIFFERENT program
than HHH that does the unlimited emulation,
*That is NOT what you said*
On 11/3/2024 12:20 PM, Richard Damon wrote:
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
No, that *IS* what I said, you just don't hear right, because you
"filter" thing through your stupidity.
I said emulation of *that* input.
On 11/9/2024 9:30 PM, Richard Damon wrote:
On 11/9/24 10:10 PM, olcott wrote:
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH >>>>>>>>>>>>> >> MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>>> > emulation of that input would do, even if its own >>>>>>>>>>>>> programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite >>>>>>>>>>>>>>>> emulation itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on >>>>>>>>>>>>>> something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT. >>>>>>>>>>>>> *Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, >>>>>>>>>>>> HHH and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted >>>>>>>>>>>>> its emulation of DDD. This specific DDD never halts
even if it stops running due to out-of-memory error. >>>>>>>>>>>>>
In other words, it tries to predict what some OTHER version >>>>>>>>>>>> of the program DDD would do if it was based on some OTHER >>>>>>>>>>>> version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>> > emulation of that input would do,
even if its own programming only lets it emulate a part of >>>>>>>>>>> that.
Nope, never said it could immulate some OTHER input, or
predict what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different >>>>>>>> DDD that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that >>>>>>>> DDD calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything that >>>>>> you say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>> >
HHH
must CORRECTLY determine what an unboundedEven HHH itself is bounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>> >
Right, but that unlimited emulation isn't done by CHANGING the copy
of HHH that DDD calls, but by giving the input to a DIFFERENT
program than HHH that does the unlimited emulation,
*That is NOT what you said*
On 11/3/2024 12:20 PM, Richard Damon wrote:
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
No, that *IS* what I said, you just don't hear right, because you
"filter" thing through your stupidity.
I said emulation of *that* input.
HHH must determine what would happen if HHH never aborted DDD.
On 11/9/24 10:36 PM, olcott wrote:
On 11/9/2024 9:30 PM, Richard Damon wrote:
On 11/9/24 10:10 PM, olcott wrote:
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH >>>>>>>>>>>>>> >> MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>>>> > emulation of that input would do, even if its own >>>>>>>>>>>>>> programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite >>>>>>>>>>>>>>>>> emulation itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on >>>>>>>>>>>>>>> something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT. >>>>>>>>>>>>>> *Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about.
It seems, you don't understand that in a given evaluation, >>>>>>>>>>>>> HHH and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted >>>>>>>>>>>>>> its emulation of DDD. This specific DDD never halts >>>>>>>>>>>>>> even if it stops running due to out-of-memory error. >>>>>>>>>>>>>>
In other words, it tries to predict what some OTHER version >>>>>>>>>>>>> of the program DDD would do if it was based on some OTHER >>>>>>>>>>>>> version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>> > emulation of that input would do,
even if its own programming only lets it emulate a part >>>>>>>>>>>> of that.
Nope, never said it could immulate some OTHER input, or >>>>>>>>>>> predict what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different >>>>>>>>> DDD that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that >>>>>>>>> DDD calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything
that you say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>> >
HHH
must CORRECTLY determine what an unboundedEven HHH itself is bounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>> >
Right, but that unlimited emulation isn't done by CHANGING the copy >>>>> of HHH that DDD calls, but by giving the input to a DIFFERENT
program than HHH that does the unlimited emulation,
*That is NOT what you said*
On 11/3/2024 12:20 PM, Richard Damon wrote:
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that.
;
No, that *IS* what I said, you just don't hear right, because you
"filter" thing through your stupidity.
I said emulation of *that* input.
HHH must determine what would happen if HHH never aborted DDD.
That is nonsense, as HHH does what HHH does, and the other machibne you
call HHH that never aborts isn't HHH, so this DDD doesn't call it.
On 11/3/24 9:39 AM, olcott wrote:
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming
only lets it emulate a part of that.
On 11/9/2024 9:30 PM, Richard Damon wrote:What a clusterfuck.
On 11/9/24 10:10 PM, olcott wrote:
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
HHH must determine what would happen if HHH never aborted DDD.No, that *IS* what I said, you just don't hear right, because you*That is NOT what you said*Right, but that unlimited emulation isn't done by CHANGING the copyOn 11/3/2024 12:20 PM, Richard Damon wrote:No, the HHH that the input call can not change, or everything that >>>>>> you say afterwords is just a lie.What changes is that the HHH that does abort must report on what >>>>>>> the behavior of DDD would be if it never aborted.Right, the UNBOUNDED EMULATION, not the results of a different >>>>>>>> DDD that called an HHH that did an unbounded emulation.You said that the bounded HHHNope, never said it could immulate some OTHER input, or predict >>>>>>>>>> what some OTHER program does.HHH predicts what would happen if no HHH ever aborted its >>>>>>>>>>>>> emulation of DDD. This specific DDD never halts even if it >>>>>>>>>>>>> stops running due to out-of-memory error.In other words, it tries to predict what some OTHER version >>>>>>>>>>>> of the program DDD would do if it was based on some OTHER >>>>>>>>>>>> version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>> > emulation of that input would do,
even if its own programming only lets it emulate a part of >>>>>>>>>>> that.
must CORRECTLY determine what an unbounded emulation of that >>>>>>>>> > input would do,
The input doesn't change, and the input specifies the HHH that >>>>>>>> DDD calls. so that doesn't change.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
must CORRECTLY determine what an unbounded emulation of that
input would do,
even if its own programming only lets it emulate a part of that. >>>>> HHH
must CORRECTLY determine what an unbounded emulation of that
input would do,
even if its own programming only lets it emulate a part of that. >>>>> Even HHH itself is bounded
of HHH that DDD calls, but by giving the input to a DIFFERENT program
than HHH that does the unlimited emulation,
On 11/3/2024 12:20 PM, Richard Damon wrote:
[HHH itself] must CORRECTLY determine what an unbounded emulation
of that input would do,
even if its own programming only lets it emulate a part of that.
"filter" thing through your stupidity.
I said emulation of *that* input.
Am Sat, 09 Nov 2024 21:36:46 -0600 schrieb olcott:
On 11/9/2024 9:30 PM, Richard Damon wrote:
On 11/9/24 10:10 PM, olcott wrote:
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
What a clusterfuck.HHH must determine what would happen if HHH never aborted DDD.No, that *IS* what I said, you just don't hear right, because you*That is NOT what you said*Right, but that unlimited emulation isn't done by CHANGING the copyOn 11/3/2024 12:20 PM, Richard Damon wrote:No, the HHH that the input call can not change, or everything that >>>>>>> you say afterwords is just a lie.What changes is that the HHH that does abort must report on what >>>>>>>> the behavior of DDD would be if it never aborted.Right, the UNBOUNDED EMULATION, not the results of a different >>>>>>>>> DDD that called an HHH that did an unbounded emulation.You said that the bounded HHHNope, never said it could immulate some OTHER input, or predict >>>>>>>>>>> what some OTHER program does.HHH predicts what would happen if no HHH ever aborted its >>>>>>>>>>>>>> emulation of DDD. This specific DDD never halts even if it >>>>>>>>>>>>>> stops running due to out-of-memory error.In other words, it tries to predict what some OTHER version >>>>>>>>>>>>> of the program DDD would do if it was based on some OTHER >>>>>>>>>>>>> version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
; Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>> > emulation of that input would do,
; even if its own programming only lets it emulate a part of >>>>>>>>>>>> that.
; must CORRECTLY determine what an unbounded emulation of that >>>>>>>>>> > input would do,
The input doesn't change, and the input specifies the HHH that >>>>>>>>> DDD calls. so that doesn't change.
HHH doesn't report on the non-sense idea of it being something
different than it is, that is just foolishness.
; must CORRECTLY determine what an unbounded emulation of that
; input would do,
; even if its own programming only lets it emulate a part of that. >>>>>> HHH
; must CORRECTLY determine what an unbounded emulation of that
; input would do,
; even if its own programming only lets it emulate a part of that. >>>>>> Even HHH itself is bounded
of HHH that DDD calls, but by giving the input to a DIFFERENT program >>>>> than HHH that does the unlimited emulation,
On 11/3/2024 12:20 PM, Richard Damon wrote:
; [HHH itself] must CORRECTLY determine what an unbounded emulation >>>> > of that input would do,
; even if its own programming only lets it emulate a part of that.
"filter" thing through your stupidity.
I said emulation of *that* input.
On 11/10/2024 5:56 AM, Richard Damon wrote:
On 11/9/24 10:36 PM, olcott wrote:
On 11/9/2024 9:30 PM, Richard Damon wrote:
On 11/9/24 10:10 PM, olcott wrote:
On 11/9/2024 9:03 PM, Richard Damon wrote:
On 11/9/24 9:53 PM, olcott wrote:
On 11/9/2024 8:48 PM, Richard Damon wrote:
On 11/9/24 9:38 PM, olcott wrote:
On 11/9/2024 8:11 PM, Richard Damon wrote:
On 11/9/24 9:01 PM, olcott wrote:
On 11/9/2024 7:59 PM, Richard Damon wrote:
On 11/9/24 8:28 PM, olcott wrote:
On 11/9/2024 6:19 PM, Richard Damon wrote:
On 11/9/24 6:43 PM, olcott wrote:
On 11/9/2024 2:56 PM, Richard Damon wrote:
On 11/9/24 3:01 PM, olcott wrote:
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
;;
The finite string input to HHH specifies that HHH >>>>>>>>>>>>>>> >> MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>>>>> > emulation of that input would do, even if its own >>>>>>>>>>>>>>> programming
only lets it emulate a part of that.
;
I am saying that HHH does need to do the infinite >>>>>>>>>>>>>>>>>> emulation itself, but
Right and it doesn't.
But doesn't give the required answer, which is based on >>>>>>>>>>>>>>>> something doing it.
The unaborted emulation of DDD by HHH DOES NOT HALT. >>>>>>>>>>>>>>> *Maybe I have to dumb it down some more*
But that isn't the HHH that you are talking about. >>>>>>>>>>>>>>
It seems, you don't understand that in a given evaluation, >>>>>>>>>>>>>> HHH and DDD are FIXED PROGRAM.
HHH predicts what would happen if no HHH ever aborted >>>>>>>>>>>>>>> its emulation of DDD. This specific DDD never halts >>>>>>>>>>>>>>> even if it stops running due to out-of-memory error. >>>>>>>>>>>>>>>
In other words, it tries to predict what some OTHER >>>>>>>>>>>>>> version of the program DDD would do if it was based on >>>>>>>>>>>>>> some OTHER version of HHH,
*Yes just like you agreed that it should*
On 11/3/2024 12:20 PM, Richard Damon wrote:
Right, and it must CORRECTLY determine what an unbounded >>>>>>>>>>>>> > emulation of that input would do,
even if its own programming only lets it emulate a part >>>>>>>>>>>>> of that.
Nope, never said it could immulate some OTHER input, or >>>>>>>>>>>> predict what some OTHER program does.
You said that the bounded HHH
must CORRECTLY determine what an unbounded
emulation of that input would do,
Right, the UNBOUNDED EMULATION, not the results of a different >>>>>>>>>> DDD that called an HHH that did an unbounded emulation.
The input doesn't change, and the input specifies the HHH that >>>>>>>>>> DDD calls. so that doesn't change.
What changes is that the HHH that does abort must
report on what the behavior of DDD would be if it
never aborted.
No, the HHH that the input call can not change, or everything >>>>>>>> that you say afterwords is just a lie.
HHH doesn't report on the non-sense idea of it being something >>>>>>>> different than it is, that is just foolishness.
On 11/3/2024 12:20 PM, Richard Damon wrote:
must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>>> >
HHH
must CORRECTLY determine what an unboundedEven HHH itself is bounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>>>> >
Right, but that unlimited emulation isn't done by CHANGING the
copy of HHH that DDD calls, but by giving the input to a DIFFERENT >>>>>> program than HHH that does the unlimited emulation,
*That is NOT what you said*
On 11/3/2024 12:20 PM, Richard Damon wrote:
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming only lets it emulate a part of that. >>>>> >
No, that *IS* what I said, you just don't hear right, because you
"filter" thing through your stupidity.
I said emulation of *that* input.
HHH must determine what would happen if HHH never aborted DDD.
That is nonsense, as HHH does what HHH does, and the other machibne
you call HHH that never aborts isn't HHH, so this DDD doesn't call it.
That *is* the fundamental principle of emulating termination
analyzers that works correctly on infinite loops and infinite
recursion. ChatGPT fully comprehends the correctness of this
principle and cannot be convinced otherwise.
*ChatGPT*
Simplified Analogy:
Think of HHH as a "watchdog" that steps in during real execution
to stop DDD() from running forever. But when HHH simulates DDD(),
it's analyzing an "idealized" version of DDD() where nothing stops the recursion. In the simulation, DDD() is seen as endlessly recursive, so
HHH concludes that it would not halt without external intervention. https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2
The author of the best selling book on the Theory of Computation
also agrees with this principle
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
A correct simulation is defined as H emulating D according to the
semantics of the x86 language. This does include H emulating itself
emulating D.
Furthermore you yourself agree
On 11/3/2024 12:20 PM, Richard Damon wrote:
On 11/3/24 9:39 AM, olcott wrote:
The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.
Right, and it must CORRECTLY determine what an unbounded
emulation of that input would do, even if its own programming
only lets it emulate a part of that.
[HHH itself] must CORRECTLY determine what an unbounded
emulation of that input would do,
even if its own programming
only lets it emulate a part of that.
even though HHH itself is a bounded emulation.
Clearly one that disagrees with their own self is
one that is incorrect.
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:Exactly. The actual Halting Problem was called that by Davis
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD
to the actual behavior that DDD specifies and this
DOES INCLUDE HHH emulating itself emulating DDD.
Yes but not the particular mapping required by the halting problem.
Yes it is the particular mapping required by the halting problem. >>>>>>>>>>> The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider terminates. >>>>>>>>>> If HHH(DDD) terminates so does DDD. The halting problmen requires >>>>>>>>>> that if DDD terminates then HHH(DDD) accepts as halting.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a particular strictly
C function will ever reach its return instruction is equally hard. About
It has always been about whether or not a finite string input
specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but Turing's >>>>>
in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented and what >>>> words were used. Post had studied the halting problem of his tag system >>>> much earlier but didn't call it a machine. Many other problems were also >>>> studied and later found to be more or less related to the halting
problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that
particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually
regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear
about your choice. To argue about the meaning of words id a clear
indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
The halting problem has always been about whether a finite
string input specifies a computation that will reach its
final halt state.
If you disagree then you must provide a complete and coherent
counter-example conclusively proving otherwise not merely
some vague reference to some other things somewhere else.
From https://www.tutorialspoint.com/automata_theory/
turing_machine_halting_problem.htm
Turing Machine Halting Problem
Input − A Turing machine and an input string w.
Problem − Does the Turing machine finish computing of the string w in a >>> finite number of steps? The answer must be either yes or no.
The computation specified by the finite string DDD
emulated by HHH cannot possibly reach its "return"
instruction final halt state.
The computation specified by the finite string DDD
emulated by HHH1 IS NOT THE ACTUAL INPUT TO HHH.
HHH must compute the mapping FROM ITS INPUT TO THE
BEHAVIOR THAT THIS INPUT SPECIFIES.
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD
to the actual behavior that DDD specifies and this >>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD.
Yes but not the particular mapping required by the halting >>>>>>>>>>>>> problem.
Yes it is the particular mapping required by the halting >>>>>>>>>>>> problem.
The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider terminates. >>>>>>>>>>> If HHH(DDD) terminates so does DDD. The halting problmen >>>>>>>>>>> requires
that if DDD terminates then HHH(DDD) accepts as halting.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a
particular strictly
C function will ever reach its return instruction is equally >>>>>>>>> hard. About
It has always been about whether or not a finite string input
specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but
Turing's
Exactly. The actual Halting Problem was called that by Davis
in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented and >>>>> what
words were used. Post had studied the halting problem of his tag
system
much earlier but didn't call it a machine. Many other problems were >>>>> also
studied and later found to be more or less related to the halting
problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that
particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually
regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear
about your choice. To argue about the meaning of words id a clear
indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
The halting problem has always been about whether a finite
string input specifies a computation that will reach its
final halt state.
If you disagree then you must provide a complete and coherent
counter-example conclusively proving otherwise not merely
some vague reference to some other things somewhere else.
From https://www.tutorialspoint.com/automata_theory/
turing_machine_halting_problem.htm
Turing Machine Halting Problem
Input − A Turing machine and an input string w.
Problem − Does the Turing machine finish computing of the string w
in a finite number of steps? The answer must be either yes or no.
The computation specified by the finite string DDD
emulated by HHH cannot possibly reach its "return"
instruction final halt state.
It can and does if HHH is a decider and otherwise does not matter.
The computation specified by the finite string DDD
emulated by HHH1 IS NOT THE ACTUAL INPUT TO HHH.
HHH1 can take same inputs as HHH. These inputs specify some behaviour.
What they do with this input may differ.
HHH must compute the mapping FROM ITS INPUT TO THE
BEHAVIOR THAT THIS INPUT SPECIFIES.
Not to full behaviour but to one feature of that behaviour.
Doesn't HHH1 need to?
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD
to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD.
Yes but not the particular mapping required by the halting >>>>>>>>>>>>>> problem.
Yes it is the particular mapping required by the halting >>>>>>>>>>>>> problem.
The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider
terminates.
If HHH(DDD) terminates so does DDD. The halting problmen >>>>>>>>>>>> requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a
particular strictly
C function will ever reach its return instruction is equally >>>>>>>>>> hard. About
It has always been about whether or not a finite string input >>>>>>>>> specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but >>>>>>>> Turing's
Exactly. The actual Halting Problem was called that by Davis
in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented
and what
words were used. Post had studied the halting problem of his tag
system
much earlier but didn't call it a machine. Many other problems
were also
studied and later found to be more or less related to the halting
problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that >>>>>> particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually
regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear
about your choice. To argue about the meaning of words id a clear
indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The halting problem has always been about whether a finite
string input specifies a computation that will reach its
final halt state.
If you disagree then you must provide a complete and coherent
counter-example conclusively proving otherwise not merely
some vague reference to some other things somewhere else.
From https://www.tutorialspoint.com/automata_theory/
turing_machine_halting_problem.htm
Turing Machine Halting Problem
Input − A Turing machine and an input string w.
Problem − Does the Turing machine finish computing of the string w >>>>> in a finite number of steps? The answer must be either yes or no.
The computation specified by the finite string DDD
emulated by HHH cannot possibly reach its "return"
instruction final halt state.
It can and does if HHH is a decider and otherwise does not matter.
_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]
HHH is a correct termination analyzer that does correctly
determine that DDD emulated by HHH cannot possibly reach
its own [00002183] machine address.
The erroneous assumptions about halt deciders are anchored
in the lack of a complete concrete example where the behavior
specified by the finite string can be unequivocally determined.
That people continue to stupidly try to get away with disagreeing
with the x86 language proves that anything less than the 100%
complete specification that the x86 language provides cannot
possibly overcome the strong indoctrination into an incoherent view.
The computation specified by the finite string DDD
emulated by HHH1 IS NOT THE ACTUAL INPUT TO HHH.
HHH1 can take same inputs as HHH. These inputs specify some behaviour.
What they do with this input may differ.
*It is the behavior of their own input that they must report on*
It has always been ridiculously stupid for everyone here to
require HHH to ignore the actual behavior specified by its own
input and instead report on the behavior of the input to HHH1.
HHH must compute the mapping FROM ITS INPUT TO THE
BEHAVIOR THAT THIS INPUT SPECIFIES.
Not to full behaviour but to one feature of that behaviour.
Doesn't HHH1 need to?
Both HHH and HHH1 must report on whether or not their simulation
of their own input can possibly reach its own "return" instruction
final halt state. They get different answers ONLY BECAUSE THE BEHAVIOR
OF THEIR INPUT DDD IS DIFFERENT!
On 11/11/2024 5:06 AM, Mikko wrote:It is the same input.
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
It can and does if HHH is a decider and otherwise does not matter.The computation specified by the finite string DDD emulated by HHHTuring Machine Halting Problem Input − A Turing machine and an input >>>>> string w.
Problem − Does the Turing machine finish computing of the string w >>>>> in a finite number of steps? The answer must be either yes or no.
cannot possibly reach its "return"
instruction final halt state.
*It is the behavior of their own input that they must report on*The computation specified by the finite string DDD emulated by HHH1 ISHHH1 can take same inputs as HHH. These inputs specify some behaviour.
NOT THE ACTUAL INPUT TO HHH.
What they do with this input may differ.
It has always been ridiculously stupid for everyone here to require HHHThe input is the same: DDD which calls HHH.
to ignore the actual behavior specified by its own input and instead
report on the behavior of the input to HHH1.
That makes no sense. The simulators do different things to the sameBoth HHH and HHH1 must report on whether or not their simulation ofHHH must compute the mapping FROM ITS INPUT TO THE BEHAVIOR THAT THISNot to full behaviour but to one feature of that behaviour.
INPUT SPECIFIES.
Doesn't HHH1 need to?
their own input can possibly reach its own "return" instruction final
halt state. They get different answers ONLY BECAUSE THE BEHAVIOR OF
THEIR INPUT DDD IS DIFFERENT!
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD
to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD.
Yes but not the particular mapping required by the halting problem.
Yes it is the particular mapping required by the halting problem. >>>>>>>>>>>>> The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider terminates. >>>>>>>>>>>> If HHH(DDD) terminates so does DDD. The halting problmen requires >>>>>>>>>>>> that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a particular strictly
C function will ever reach its return instruction is equally hard. About
It has always been about whether or not a finite string input >>>>>>>>> specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but Turing's
Exactly. The actual Halting Problem was called that by Davis
in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented and what >>>>>> words were used. Post had studied the halting problem of his tag system >>>>>> much earlier but didn't call it a machine. Many other problems were also >>>>>> studied and later found to be more or less related to the halting
problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that >>>>>> particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually
regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear
about your choice. To argue about the meaning of words id a clear
indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD >>>>>>>>>>>>>>>> to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD. >>>>>>>>>>>>>>>Yes but not the particular mapping required by the >>>>>>>>>>>>>>> halting problem.
Yes it is the particular mapping required by the halting >>>>>>>>>>>>>> problem.
The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider >>>>>>>>>>>>> terminates.
If HHH(DDD) terminates so does DDD. The halting problmen >>>>>>>>>>>>> requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a
particular strictly
C function will ever reach its return instruction is equally >>>>>>>>>>> hard. About
It has always been about whether or not a finite string input >>>>>>>>>> specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but >>>>>>>>> Turing's
Exactly. The actual Halting Problem was called that by Davis
in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented >>>>>>> and what
words were used. Post had studied the halting problem of his tag >>>>>>> system
much earlier but didn't call it a machine. Many other problems
were also
studied and later found to be more or less related to the halting >>>>>>> problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that >>>>>>> particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually >>>>> regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear
about your choice. To argue about the meaning of words id a clear >>>>>>> indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The exact definition of "halt" varies depending on the model.
For a Turing machine halting means reaching a configuration
where where there is no rule for the state and current symbol.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
THere is similar ambiguity in
x86 semantics as there are operation codes that are defined on
some x86 processor models but undefined on others, and it is
also undefined what happens on a jump to a address in a
non-exstent or uninitialised memory.
On 11/12/2024 5:22 AM, Mikko wrote:
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD >>>>>>>>>>>>>>>>> to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD. >>>>>>>>>>>>>>>>Yes but not the particular mapping required by the >>>>>>>>>>>>>>>> halting problem.
Yes it is the particular mapping required by the halting >>>>>>>>>>>>>>> problem.
The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider >>>>>>>>>>>>>> terminates.
If HHH(DDD) terminates so does DDD. The halting problmen >>>>>>>>>>>>>> requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a >>>>>>>>>>>> particular strictly
C function will ever reach its return instruction is equally >>>>>>>>>>>> hard. About
It has always been about whether or not a finite string input >>>>>>>>>>> specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but >>>>>>>>>> Turing's
Exactly. The actual Halting Problem was called that by Davis >>>>>>>>> in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented >>>>>>>> and what
words were used. Post had studied the halting problem of his tag >>>>>>>> system
much earlier but didn't call it a machine. Many other problems >>>>>>>> were also
studied and later found to be more or less related to the halting >>>>>>>> problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that >>>>>>>> particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually >>>>>> regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear >>>>>>>> about your choice. To argue about the meaning of words id a clear >>>>>>>> indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The exact definition of "halt" varies depending on the model.
For a Turing machine halting means reaching a configuration
where where there is no rule for the state and current symbol.
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out. That is just not what is meant by halting. In software
engineering terms "halting" is only normal termination.
THere is similar ambiguity in
x86 semantics as there are operation codes that are defined on
some x86 processor models but undefined on others, and it is
also undefined what happens on a jump to a address in a
non-exstent or uninitialised memory.
_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]
Anyone with sufficient understanding of the x86 language
fully well knows that no DDD emulated by any HHH can
possibly reach past its own [0000217a] machine address.
On 11/12/2024 5:22 AM, Mikko wrote:Only if the called HHH doesn’t halt. Why doesn’t it?
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
THere is similar ambiguity in x86 semantics as there are operationAnyone with sufficient understanding of the x86 language fully well
codes that are defined on some x86 processor models but undefined on
others, and it is also undefined what happens on a jump to a address in
a non-exstent or uninitialised memory.
knows that no DDD emulated by any HHH can possibly reach past its own [0000217a] machine address.
On 11/12/2024 5:22 AM, Mikko wrote:
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD >>>>>>>>>>>>>>>>> to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD. >>>>>>>>>>>>>>>>Yes but not the particular mapping required by the halting problem.
Yes it is the particular mapping required by the halting problem.
The exact same process occurs in the Linz proof.
The halting probelm requires that every halt decider terminates. >>>>>>>>>>>>>> If HHH(DDD) terminates so does DDD. The halting problmen requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a particular strictly
C function will ever reach its return instruction is equally hard. About
It has always been about whether or not a finite string input >>>>>>>>>>> specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem but Turing's
Exactly. The actual Halting Problem was called that by Davis >>>>>>>>> in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented and what
words were used. Post had studied the halting problem of his tag system
much earlier but didn't call it a machine. Many other problems were also
studied and later found to be more or less related to the halting >>>>>>>> problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input
specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that >>>>>>>> particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually >>>>>> regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear >>>>>>>> about your choice. To argue about the meaning of words id a clear >>>>>>>> indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The exact definition of "halt" varies depending on the model.
For a Turing machine halting means reaching a configuration
where where there is no rule for the state and current symbol.
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is just not what is meant by halting. In software
engineering terms "halting" is only normal termination.
Am Tue, 12 Nov 2024 16:45:10 -0600 schrieb olcott:
On 11/12/2024 5:22 AM, Mikko wrote:
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
Only if the called HHH doesn’t halt. Why doesn’t it?THere is similar ambiguity in x86 semantics as there are operationAnyone with sufficient understanding of the x86 language fully well
codes that are defined on some x86 processor models but undefined on
others, and it is also undefined what happens on a jump to a address in
a non-exstent or uninitialised memory.
knows that no DDD emulated by any HHH can possibly reach past its own
[0000217a] machine address.
On 2024-11-12 22:45:10 +0000, olcott said:
On 11/12/2024 5:22 AM, Mikko wrote:
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:The halting probelm requires that every halt decider >>>>>>>>>>>>>>> terminates.
On 2024-11-02 12:24:29 +0000, olcott said:
HHH does compute the mapping from its input DDD >>>>>>>>>>>>>>>>>> to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD. >>>>>>>>>>>>>>>>>Yes but not the particular mapping required by the >>>>>>>>>>>>>>>>> halting problem.
Yes it is the particular mapping required by the halting >>>>>>>>>>>>>>>> problem.
The exact same process occurs in the Linz proof. >>>>>>>>>>>>>>>
If HHH(DDD) terminates so does DDD. The halting problmen >>>>>>>>>>>>>>> requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.
Not in the original problem but the question whether a >>>>>>>>>>>>> particular strictly
C function will ever reach its return instruction is >>>>>>>>>>>>> equally hard. About
It has always been about whether or not a finite string input >>>>>>>>>>>> specifies a computation that reaches its final state.
Not really. The original problem was not a halting problem >>>>>>>>>>> but Turing's
Exactly. The actual Halting Problem was called that by Davis >>>>>>>>>> in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented >>>>>>>>> and what
words were used. Post had studied the halting problem of his >>>>>>>>> tag system
much earlier but didn't call it a machine. Many other problems >>>>>>>>> were also
studied and later found to be more or less related to the halting >>>>>>>>> problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input >>>>>>>>>> specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes >>>>>>>>> that
particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually >>>>>>> regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear >>>>>>>>> about your choice. To argue about the meaning of words id a clear >>>>>>>>> indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes >>>>> of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The exact definition of "halt" varies depending on the model.
For a Turing machine halting means reaching a configuration
where where there is no rule for the state and current symbol.
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
You have also talked about x86, so it is better to include that.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
You may call it "only normal termitaion" but there are other terminations that need not be called "normal".
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is in the same category as the "aboting" your HHH may do with
certain inputs. The program does specify a next action but the
specified action is not performed.
That is just not what is meant by halting. In software
engineering terms "halting" is only normal termination.
No, it is not. I have worked with software enginees so much that I know
that they don't identify halting with normal termination. And also that
they are not always ssystematic and consistent with their words.
On 11/13/2024 4:54 AM, Mikko wrote:
On 2024-11-12 22:45:10 +0000, olcott said:
On 11/12/2024 5:22 AM, Mikko wrote:
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:Not really. The original problem was not a halting problem >>>>>>>>>>>> but Turing's
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:The halting probelm requires that every halt decider >>>>>>>>>>>>>>>> terminates.
On 2024-11-02 12:24:29 +0000, olcott said: >>>>>>>>>>>>>>>>>>
HHH does compute the mapping from its input DDD >>>>>>>>>>>>>>>>>>> to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD. >>>>>>>>>>>>>>>>>>Yes but not the particular mapping required by the >>>>>>>>>>>>>>>>>> halting problem.
Yes it is the particular mapping required by the >>>>>>>>>>>>>>>>> halting problem.
The exact same process occurs in the Linz proof. >>>>>>>>>>>>>>>>
If HHH(DDD) terminates so does DDD. The halting problmen >>>>>>>>>>>>>>>> requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly >>>>>>>>>>>>>>> reach its "return" instruction final state.
Not in the original problem but the question whether a >>>>>>>>>>>>>> particular strictly
C function will ever reach its return instruction is >>>>>>>>>>>>>> equally hard. About
It has always been about whether or not a finite string input >>>>>>>>>>>>> specifies a computation that reaches its final state. >>>>>>>>>>>>
Exactly. The actual Halting Problem was called that by Davis >>>>>>>>>>> in 1952. Not the same as Turing proof.
In early times there was variation in how things were
presented and what
words were used. Post had studied the halting problem of his >>>>>>>>>> tag system
much earlier but didn't call it a machine. Many other problems >>>>>>>>>> were also
studied and later found to be more or less related to the halting >>>>>>>>>> problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input >>>>>>>>>>> specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes >>>>>>>>>> that
particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is
usually
regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear >>>>>>>>>> about your choice. To argue about the meaning of words id a clear >>>>>>>>>> indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes >>>>>> of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other >>>>>> words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The exact definition of "halt" varies depending on the model.
For a Turing machine halting means reaching a configuration
where where there is no rule for the state and current symbol.
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
You have also talked about x86, so it is better to include that.
That is construed as the precise details of the behavior
of the C function.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
You may call it "only normal termitaion" but there are other terminations
that need not be called "normal".
When we preserve the mapping to Turing machines then
reaching the return instruction is the only correct
notion of a final halt state.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is in the same category as the "aboting" your HHH may do with
certain inputs. The program does specify a next action but the
specified action is not performed.
No it is not. A emulating termination analyzer is
defined to abort as soon as aborting is the only way
to prevent its own non-termination.
THIS IS CORRECT ON THE BASIS OF SEMANTIC TAUTOLOGY.
If I say that 2 + 3 = 5 it is not a rebuttal to say I
doan beeve in nummers theys aint nun sich thang as rithmetic.
That is just not what is meant by halting. In software
engineering terms "halting" is only normal termination.
No, it is not. I have worked with software enginees so much that I know
that they don't identify halting with normal termination. And also that
they are not always ssystematic and consistent with their words.
On 11/13/2024 2:37 AM, joes wrote:
Am Tue, 12 Nov 2024 16:45:10 -0600 schrieb olcott:
On 11/12/2024 5:22 AM, Mikko wrote:Only if the called HHH doesn’t halt. Why doesn’t it?
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
THere is similar ambiguity in x86 semantics as there are operationAnyone with sufficient understanding of the x86 language fully well
codes that are defined on some x86 processor models but undefined on
others, and it is also undefined what happens on a jump to a address in >>>> a non-exstent or uninitialised memory.
knows that no DDD emulated by any HHH can possibly reach past its own
[0000217a] machine address.
You can keep dishonestly removing the code that I
am referring to.
_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]
DDD emulated by HHH keeps cycling through the first
four instructions from [00002172] to [0000217a] and
thus cannot possibly reach past its own machine address
[0000217a] whether HHH halts or not.
On 11/13/2024 4:54 AM, Mikko wrote:
On 2024-11-12 22:45:10 +0000, olcott said:
On 11/12/2024 5:22 AM, Mikko wrote:
On 2024-11-11 15:15:09 +0000, olcott said:
On 11/11/2024 5:06 AM, Mikko wrote:
On 2024-11-09 14:56:14 +0000, olcott said:
On 11/9/2024 3:53 AM, Mikko wrote:
On 2024-11-08 14:39:20 +0000, olcott said:
On 11/8/2024 6:39 AM, Mikko wrote:
On 2024-11-07 16:39:57 +0000, olcott said:
On 11/7/2024 3:56 AM, Mikko wrote:
On 2024-11-06 15:26:06 +0000, olcott said:
On 11/6/2024 8:39 AM, Mikko wrote:Not really. The original problem was not a halting problem but Turing's
On 2024-11-05 13:18:43 +0000, olcott said:
On 11/5/2024 3:01 AM, Mikko wrote:
On 2024-11-03 15:13:56 +0000, olcott said:void Infinite_Loop()
On 11/3/2024 7:04 AM, Mikko wrote:The halting probelm requires that every halt decider terminates.
On 2024-11-02 12:24:29 +0000, olcott said: >>>>>>>>>>>>>>>>>>
HHH does compute the mapping from its input DDD >>>>>>>>>>>>>>>>>>> to the actual behavior that DDD specifies and this >>>>>>>>>>>>>>>>>>> DOES INCLUDE HHH emulating itself emulating DDD. >>>>>>>>>>>>>>>>>>Yes but not the particular mapping required by the halting problem.
Yes it is the particular mapping required by the halting problem.
The exact same process occurs in the Linz proof. >>>>>>>>>>>>>>>>
If HHH(DDD) terminates so does DDD. The halting problmen requires
that if DDD terminates then HHH(DDD) accepts as halting. >>>>>>>>>>>>>>>
{
HERE: goto HERE;
return;
}
No that is false.
The measure is whether a C function can possibly >>>>>>>>>>>>>>> reach its "return" instruction final state.
Not in the original problem but the question whether a particular strictly
C function will ever reach its return instruction is equally hard. About
It has always been about whether or not a finite string input >>>>>>>>>>>>> specifies a computation that reaches its final state. >>>>>>>>>>>>
Exactly. The actual Halting Problem was called that by Davis >>>>>>>>>>> in 1952. Not the same as Turing proof.
In early times there was variation in how things were presented and what
words were used. Post had studied the halting problem of his tag system
much earlier but didn't call it a machine. Many other problems were also
studied and later found to be more or less related to the halting >>>>>>>>>> problem and its variants.
*So we are back to The Halting Problem itself*
has always been about whether or not a finite string input >>>>>>>>>>> specifies a computation that reaches its final state.
No, it has been a collection of related problems that includes that >>>>>>>>>> particular one.
The halting problem has always been abuut halting
Nevertheless Turing's solution to his circularity problem is usually >>>>>>>> regarded as the first solution to the halting problem.
As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear >>>>>>>>>> about your choice. To argue about the meaning of words id a clear >>>>>>>>>> indcation of an intent to avoid an honest discussion.
It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.
Above you have argued about the meanings of the words and
keep doing so below.
It is the meaning of the bytes of x86 code and
bytes of code are not words.
No, nothing you have said tells anuything about meanings of the bytes >>>>>> of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other >>>>>> words.
Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.
The exact definition of "halt" varies depending on the model.
For a Turing machine halting means reaching a configuration
where where there is no rule for the state and current symbol.
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
You have also talked about x86, so it is better to include that.
That is construed as the precise details of the behavior
of the C function.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
You may call it "only normal termitaion" but there are other terminations
that need not be called "normal".
When we preserve the mapping to Turing machines then
reaching the return instruction is the only correct
notion of a final halt state.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is in the same category as the "aboting" your HHH may do with
certain inputs. The program does specify a next action but the
specified action is not performed.
No it is not. A emulating termination analyzer is
defined to abort as soon as aborting is the only way
to prevent its own non-termination.
On 2024-11-13 23:08:40 +0000, olcott said:
On 11/13/2024 4:54 AM, Mikko wrote:
On 2024-11-12 22:45:10 +0000, olcott said:
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
You have also talked about x86, so it is better to include that.
That is construed as the precise details of the behavior
of the C function.
Doing so deviates from the meaning of "C language".
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution
should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
You may call it "only normal termitaion" but there are other
terminations
that need not be called "normal".
When we preserve the mapping to Turing machines then
reaching the return instruction is the only correct
notion of a final halt state.
No, it is not. If you want to use the expression "final halt state"
about Turing machines you must define it in terms of Turing macnine
concepts, either as halting or as someting else.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is in the same category as the "aboting" your HHH may do with
certain inputs. The program does specify a next action but the
specified action is not performed.
No it is not. A emulating termination analyzer is
defined to abort as soon as aborting is the only way
to prevent its own non-termination.
If for a particular input aborting is the only way to prevent its own non-termination then "as soon as" can only mean before doing anything
and therefore before finding out that there is no other way.
On 11/14/2024 3:06 AM, Mikko wrote:
On 2024-11-13 23:08:40 +0000, olcott said:
On 11/13/2024 4:54 AM, Mikko wrote:
On 2024-11-12 22:45:10 +0000, olcott said:
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
You have also talked about x86, so it is better to include that.
That is construed as the precise details of the behavior
of the C function.
Doing so deviates from the meaning of "C language".
Not at all. x86 is the Tarski meta-language that
specifies the precise fully concrete semantics
of the C code.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution >>>>>> should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
You may call it "only normal termitaion" but there are other
terminations
that need not be called "normal".
When we preserve the mapping to Turing machines then
reaching the return instruction is the only correct
notion of a final halt state.
No, it is not. If you want to use the expression "final halt state"
about Turing machines you must define it in terms of Turing macnine
concepts, either as halting or as someting else.
We cannot refer to any feature in C++ that Turing Machines
lack and maintain the mapping to Turing Machines. There
is no such thing as abnormal termination in TMs.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is in the same category as the "aboting" your HHH may do with
certain inputs. The program does specify a next action but the
specified action is not performed.
No it is not. A emulating termination analyzer is
defined to abort as soon as aborting is the only way
to prevent its own non-termination.
If for a particular input aborting is the only way to prevent its own
non-termination then "as soon as" can only mean before doing anything
That is a ridiculously stupid way to look at it.
<As soon as> means the point in the execution
trace where the non-halt criteria it first met.
For the current algorithm this is immediately after
HHH emulates itself emulating DDD until its emulated
HHH is about to emulated itself emulating DDD.
and therefore before finding out that there is no other way.
On 11/14/2024 3:06 AM, Mikko wrote:
On 2024-11-13 23:08:40 +0000, olcott said:
On 11/13/2024 4:54 AM, Mikko wrote:
On 2024-11-12 22:45:10 +0000, olcott said:
Since we are only talking about Turing Machines and C functions
there is no need to get into other models.
You have also talked about x86, so it is better to include that.
That is construed as the precise details of the behavior
of the C function.
Doing so deviates from the meaning of "C language".
Not at all. x86 is the Tarski meta-language that
specifies the precise fully concrete semantics
of the C code.
For a C program it is more ambiguous as there are situations
where the language standard does not specify whether the execution >>>>>> should be terminated or continued.
Reaching the "return" instruction final halt state <is>
the only normal termination for a C function.
You may call it "only normal termitaion" but there are other terminations >>>> that need not be called "normal".
When we preserve the mapping to Turing machines then
reaching the return instruction is the only correct
notion of a final halt state.
No, it is not. If you want to use the expression "final halt state"
about Turing machines you must define it in terms of Turing macnine
concepts, either as halting or as someting else.
We cannot refer to any feature in C++ that Turing Machines
lack and maintain the mapping to Turing Machines. There
is no such thing as abnormal termination in TMs.
If you want to get silly you can say that a C function stuck
in an infinite loop "halts" when you yank the computer's power
cord out.
That is in the same category as the "aboting" your HHH may do with
certain inputs. The program does specify a next action but the
specified action is not performed.
No it is not. A emulating termination analyzer is
defined to abort as soon as aborting is the only way
to prevent its own non-termination.
If for a particular input aborting is the only way to prevent its own
non-termination then "as soon as" can only mean before doing anything
That is a ridiculously stupid way to look at it.
<As soon as> means the point in the execution
trace where the non-halt criteria it first met.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 997 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 227:03:42 |
| Calls: | 13,046 |
| Calls today: | 1 |
| Files: | 186,574 |
| Messages: | 3,292,814 |