On 10/19/24 11:20 PM, olcott wrote:

On 10/19/2024 9:27 PM, Richard Damon wrote:

On 10/19/24 8:13 PM, olcott wrote:

On 10/19/2024 4:53 PM, Richard Damon wrote:

On 10/19/24 7:26 AM, olcott wrote:

On 10/19/2024 6:21 AM, Richard Damon wrote:

On 10/18/24 11:19 PM, olcott wrote:

On 10/18/2024 9:49 PM, Richard Damon wrote:

On 10/18/24 8:52 PM, olcott wrote:

On 10/18/2024 6:06 PM, Richard Damon wrote:

On 10/18/24 10:10 AM, olcott wrote:

On 10/18/2024 6:17 AM, Richard Damon wrote:

On 10/17/24 11:47 PM, olcott wrote:

On 10/17/2024 10:27 PM, Richard Damon wrote:

On 10/17/24 9:47 PM, olcott wrote:

On 10/17/2024 8:13 PM, Richard Damon wrote:

On 10/17/24 7:31 PM, olcott wrote:

_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]

When DDD is correctly emulated by HHH according >>>>>>>>>>>>>>>>> to the semantics of the x86 language DDD cannot >>>>>>>>>>>>>>>>> possibly reach its own machine address [00002183] >>>>>>>>>>>>>>>>> no matter what HHH does.

[00002172]-->[00002173]-->[00002175]-->[0000217a]--+ >>>>>>>>>>>>>>>>> +------------------------------------------------------+ >>>>>>>>>>>>>>>>>

That may not line up that same way when view >>>>>>>>>>>>>>>>>



https://en.wikipedia.org/wiki/State_diagram

Except that 0000217a doesn't go to 00002172, but to >>>>>>>>>>>>>>>> 000015d2

IS THIS OVER YOUR HEAD?
What is the first machine address of DDD that HHH >>>>>>>>>>>>>>> emulating itself emulating DDD would reach?

Yes, HHH EMULATES the code at that address,

Which HHH emulates what code at which address?

Everyone, just once, which you should know, but ignore. >>>>>>>>>>>>
The Emulating HHH sees those addresses at its begining and >>>>>>>>>>>> then never again.

Then the HHH that it is emulating will see those addresses, >>>>>>>>>>>> but not the outer one that is doing that emulation of HHH. >>>>>>>>>>>>
Then the HHH that the second HHH is emulating will, but >>>>>>>>>>>> neither of the outer 2 HHH.

And so on.

Which HHH do you think EVER gets back to 00002172?

What instruction do you think that it emulates that would >>>>>>>>>>>> tell it to do so?

It isn't the call instruction at 0000217a, as that tells it >>>>>>>>>>>> to go into HHH.

At best the trace is:

00002172
00002173
00002175
0000217a
conditional emulation of 00002172
conditional emulation of 00002173
conditional emulation of 00002175
conditional emulation of 0000217a
CE of CE of 00002172
...

OK great this is finally good progress.

The "state" never repeats, it is alway a new state,

Every emulated DDD has an identical process state at every point >>>>>>>>>>> in its emulation trace when adjusting for different top of >>>>>>>>>>> stack values.

Nope, remember, each of those levels are CONDITIONAL,

*There are THREE different questions here*
(1) Can DDD emulated by HHH according to the semantics
     of the x86 language possibly reach its machine address >>>>>>>>>      [00002183] no matter what HHH does?

Ambiguouse question, as pointed out previously.

A) Do you mean the behavior of the PROGRAM DDD, that HHH has
emulated a copy of.

In that case, the answer is, if HHH aborts its emulation and
return, YES, if HHH never aborts its emulation, and thus doesn't >>>>>>>> ever return an answer to anyone NO.

B) If you mean, does the emulation done by HHH ever reach that >>>>>>>> place, no.

We are not asking if the code of HHH reaches inside
the code of DDD. Of course it doesn't this is stupid.

We are asking does any DDD of any DDD/HHH pair of the
infinite set of pairs such that DDD is emulated by HHH
according to the semantics of the x86 language reach its
own return instruction?

(2) Does HHH correctly detect and report the above?

No, because that isn't what you claim HHH is doing, so it can't >>>>>>>> be correct about that.

In other words you fail to comprehend that DDD failing
to reach its "return" instruction is isomorphic to:

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

... PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>>  > that P(P) *would* never stop running *unless* aborted.

We need to look at the two possible interpreations to question 1. >>>>>>>>
If you means A, then since HHH says no but the correct answer is >>>>>>>> yes, it is wrong.

If you mean B, and you mean your question is can HHH predict
that it can't reach the final state, but only needs to be right >>>>>>>> for this one input, then the problem is the question has become >>>>>>>> trivial, if it doesn't need to actually know anything about the >>>>>>>> input, it can just be programmed to say no.

I mean that the execution trace of DDD proves that HHH is correct >>>>>>> to reject DDD as impossibly reaching its own "return" instruction >>>>>>> even if it just guesses.

Also, we can make a trivial HHH, that just does the absolute
minimum, then aborts and returns no unconditionally to be
correct, showing your problem isn't interesting.

Or, your "problem" has left the domain of Program Theory,
becuause you don't consider DDD to be an actual program, at
which point it also becomes much less interesting.

(3) Does HHH do (2) it as a Turing computable function?

No, because the method your HHH uses isn't possible to be
expressed as a Turing Machine with a seperate input tape with
the full representatation of the program DDD.

Yet again you are not answering the question that
was asked. This must be your ADD.

The summation is the DDD does not halt and HHH
does correctly report this even if HHH as it is
currently implemented is not a Turing computable
function.

But the Program DDD DOES halt,

*Try and tell that to ChatGPT and it will make a fool of you*
https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e


Copyright 2024 Olcott "Talent hits a target no one else can hit;
Genius
hits a target no one else can see." Arthur Schopenhauer

Ignore any false information about the definiton of a termination
analyzer, and recall that the correct answer to a question given to
a termination analyzer is that it must report about the actual
behavior of the program that it has been given,

You are directly contradicting the verified fact that DDD
emulated by HHH according to the semantics of the x86 language
cannot possibly reach its own "return" instruction and halt.

But that isn't what the question being asked

Sure it is. You are just in psychological denial as proven by
the fact that all attempted rebuttals (yours and anyone else's)
to the following words have been baseless.

Does the input DDD to HHH specify a halting computation?

Which it isn't, but is a subtle change of the actual question.

The actual question (somewhat informally stated, but from the source you
like to use) says:

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run forever.

So, DDD is the COMPUTER PROGRAM to be decided on, and is converted to a DESCRIPTION of that program to be the input to the decider, and THAT is
the input.

So, the question has ALWAYS been about the behavior of the program (an OBJECTIVE standard, meaning the same to every decider the question is
posed to).

(where a halting computation is defined as)

DDD emulated by HHH according to the semantics of the x86
language reaches its own "return" instruction final state.

Except that isn't the definition of halting, as you have been told many
times, but apparently you can't undetstand.

Halting is a property of the PROGRAM. It is the property, as described
in the question, of will the program reach a final state if it is run,
or will it never reach such a final state.

DDD emulated by HHH is a standing for that only if HHH never aborts its emulation. But, since your HHH that answer must abort its emulation,
your criteria is just a bunch of meaningless gobbledygook.

It seems that a major part of the problem is you CHOSE to be ignorant of
the rules of the system, but learned it by what you call "First
Principles" (but you don't understand the term) by apparently trying to
derive the core principles of the system on your own. This is really a
ZERO Principle analysis, and doesn't get you the information you
actually need to use.

A "First Principles" approach that you refer to STARTS with an study and understanding of the actual basic principles of the system. That would
be things like the basic definitions of things like "Program", "Halting" "Deciding", "Turing Machine", and then from those concepts, sees what
can be done, without trying to rely on the ideas that others have used,
but see if they went down a wrong track, and the was a different path in
the same system.

It seems you never even learned the First Principles of Logic Systems,
bcause you don't understand that Formal Systems are built from their definitions, and those definitions can not be changed and let you stay
in the same system.

Since you like to break THAT rule, you put yourself outside of the
domain of Formal Logic completely, and thus LIE when you claim to be
working on a problem that is only actually defined in a specific system.

is, it is (or you claim it to be) about Termination, which is about
the behavior of the PROGRAM / FUNCITON (with all its used code) not
about a partial emulation of it.

Your statement is just an equivocation trying to confuse the idea of
comnplete correct emulations showing actual behavior, while a partial,
but correct, only shows partial behavior, not final behavior.

The VERIFIED FACT, is that what is defined as the BEHAVIOR of DDD,
which is what a termination analyser (or Halt Decider) has been
determined to be halting for the actual HHH you have provided.

Your claim tries to refer to the behavior of an only partial emuation
and claim that it shows non-termination, which it doesn't.

You are just proving that you are nothing but a stupid liar.

Your "Verified Fact" is just your LIE based on equivocation, as you
have been told, but don't seem to be able to understand it.

Sorry, you claimed no one could persuade the AI that you were wrong,
and I did it with ONE try.

How many attempts did it take you to get the answer you wanted out of
Chat GPT?

I only ever tried twice, once several months ago and
it got confused and this time. You can see all of the
details of this time.

SO, you don't even understand what I mean by "once".

I thought a bit, then typed ONE STATEMET into your ChatGPT and got that
answer. I didn't need to try other options.

I explained everything just once at the beginning.
Then I challenged it with your rebuttal several
times in several ways. Every time that I did this
it explained your mistake in great detail.

But it sure sounds like you tried several times in one "session" at the keyboard.

https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e
This is the most powerful free version it is full 4.0.
You don't need to login.

So?

AI is not the source of the defintions. The definitions established in
the original logic system is.

You are just showing you don't undertstand the basic nature of how to
use logic.

Sorry, you are just proving yourself to be a stupid idiodic pathological
liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/20/24 11:32 AM, olcott wrote:

On 10/20/2024 6:46 AM, Richard Damon wrote:

On 10/19/24 11:20 PM, olcott wrote:

On 10/19/2024 9:27 PM, Richard Damon wrote:

On 10/19/24 8:13 PM, olcott wrote:

You are directly contradicting the verified fact that DDD
emulated by HHH according to the semantics of the x86 language
cannot possibly reach its own "return" instruction and halt.

But that isn't what the question being asked

Sure it is. You are just in psychological denial as proven by
the fact that all attempted rebuttals (yours and anyone else's)
to the following words have been baseless.

Does the input DDD to HHH specify a halting computation?

Which it isn't, but is a subtle change of the actual question.

The actual question (somewhat informally stated, but from the source
you like to use) says:

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and
an input, whether the program will finish running, or continue to run
forever.

That is the problem. Because it is too informally stated
it can be misunderstood. No one ever intended for any
termination analyzer to ever report on anything besides
the behavior that its input actually specifies.

What is "informal" about the actual problem.

The informality is that it comes from a non-academic source, so doesn't
use the formal terminology, which you just wouldn't understand.

What is to be misunderstood?

Given that you start with a program, which is defined as the fully
detailed set of deterministic steps that are to be performed, and that
such a program, will do exactly one behavior for any given input given
to it, says that there is, BY DEFINITIOH a unique and specific answer
that the analysize must give to be correct.

The requirement says that the user needs to, by the rules defined by the analyszer, describe that program, and if the analyzer is going to be
able to qualify, must define at least one way (but could be multiple) of creating the proper description of that input program, and that an given
input that meets that requirement will exactly represent only a singe equivalence set of programs (an equivalence set of programs is a set of programs that all members always produce the same output results for
every possible input). Thus, there must exist a unique mapping from each
input to such an equivalence set to a correct answer.

Thus, it is THAT BEHAVIOR, the behavior of the full program that *IS*
the behavior that its input actually specifies.

WHAT IS WRONG WITH THAT?


Now, this does point out that you claim of what could be the
"finite-string input" for you HHH, can't possible be such a correct input,

So, DDD is the COMPUTER PROGRAM to be decided on,

No not at all. When DDD is directly executed it specifies a
different sequence of configurations than when DDD is emulated
by HHH according to the semantics of the x86 language.

And what step actually correctly emulated created the first difference
in sequence?

You have been asked this many times, and just fail to answer, because
your claim has just been proven to be a *LIE*, so of course you can't
find a proof for it,

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

... PO really /has/ an H (it's trivial to do for this one case)
that correctly determines that P(P) *would* never stop running
*unless* aborted.

But that is just admitting that your HHH isn't answering the HALTING
PROBLEM, but the POOP problem, which has a different domain

That everyone has always believed that a termination analyzer
must report on behavior that it does not see is the same sort
of mistake as believing that a set can be a member of itself.
Eliminate the false assumption and the issue is resolved.

There was NEVER a requirement that the termination analyser be able to
"see" the answer. That is part of the question. If it COULD always see
the behavior in question, then the question would be computable.

The fact that it is impossible to build a decider, like H that can
actually see the correct answer for D, is what shows that Halting is non-computable.

Flibble has shown a method that you could use to build an HHH that is
given the DDD that calls it, and correctly determines the answer, by
dividing the problem into two cases and see if either of them work out.

Thus DDD is not a "pathological input" for a smart enough termination
analyzer, working in the non-turing complete space defined by your
environment structure, but that case is "computable".

It is only when we go to the original D/P that does the opposite of what
H returns, that we find that we can not answer, and at least that
machine was able to figure that case out as being unsolvable.

and is converted to a DESCRIPTION of that program to be the input to
the decider, and THAT is the input.

So, the question has ALWAYS been about the behavior of the program (an
OBJECTIVE standard, meaning the same to every decider the question is
posed to).

Then it is the same error as a set defined as a member of itself.
The ZFC resolution to Russell's Paradox sets the precedent that
discarding false assumptions can be a path to a solution.

Nope. While a turing machine can not contain a "copy" of itself within
it (as that would lead to an infinite machine from the nesting), there
is no problem with giving a machine as an input a description of a
machine that contains a copy of itself.

This is part of what leads to uncomputable questions, but that isn't the
same type of error as the illogical contradictions from the rules
allowing sets to contain themselves.

There is no "false assumption" to be discarded, and you have done
NOTHING to attempt to try to show one.

(where a halting computation is defined as)

DDD emulated by HHH according to the semantics of the x86
language reaches its own "return" instruction final state.

Except that isn't the definition of halting, as you have been told
many times, but apparently you can't undetstand.

Sure and if everyone stuck with the "we have always done it that way therefore you can't change it" ZFC would have been rejected out-of-hand
and Russell's Paradox would remain unresolved.

Which means you just don't understand how Formal Systems work.

The Halting Problem is PROVEN to be uncomputable in the Computation
Theory of Turing Complete computations.

If you want to try to define your own different system, you have been
invited to do so, but that also comes with the requirement that you need
to first FULLY define what you system is going to use as its initial
truths and rules (and while you can add new truths or rules, you can't
change an existing one) and then show what you can do with that set.

I appears that the biggest problem with this is that you just don't
understand logic well enough to actually do that step, so you need to
work in systems already built, which means you need to follow those
systems rules, which means you need to learn them.

You don't seem to understand, that you can't just imagine a different
rule, without looking to see what that affects, and you want to change fundamentals, which have the possibility of totally changing the field,
but you have no idea how to figure out what will happen.

Halting is a property of the PROGRAM. It is the property, as described
in the question, of will the program reach a final state if it is run,
or will it never reach such a final state.

Much more generically at the philosophical foundations of logic
level all logic systems merely apply finite string transformation
rules to finite strings. Formal mathematical systems apply truth
preserving operations to finite strings having the Boolean value
of true.

So?

The key is that formal system define that there *IS* a pre-defined set
of initial known truths and rules, and everyone working in that system
needs to use that exact same set of rules.

If you want a different set of known truths and rules, you create a
DIFFERENT Formal System and work in that, and you can't claim that
something shown is system B applies to system A, because they are different.

DDD emulated by HHH is a standing for that only if HHH never aborts
its emulation. But, since your HHH that answer must abort its
emulation, your criteria is just a bunch of meaningless gobbledygook.

It seems that a major part of the problem is you CHOSE to be ignorant
of the rules of the system, but learned it by what you call "First
Principles" (but you don't understand the term) by apparently trying
to derive the core principles of the system on your own. This is
really a ZERO Principle analysis, and doesn't get you the information
you actually need to use.

ZFC did the same thing and successfully rejected the false assumption
that a set can be a member of itself.

No, they defined a *NEW* set theory that used a different set of
fundamental truths and rules and then showed what they could do with
those truths and rules (something that you could attempt for your ideas
if you were smart enough) and that fixed the problems seen, so the
"default" system was changed by the comunity to that.

A "First Principles" approach that you refer to STARTS with an study
and understanding of the actual basic principles of the system. That
would be things like the basic definitions of things like "Program",
"Halting" "Deciding", "Turing Machine", and then from those concepts,
sees what can be done, without trying to rely on the ideas that others
have used, but see if they went down a wrong track, and the was a
different path in the same system.

The actual barest essence for formal systems and computations
is finite string transformation rules applied to finite strings.

So, show what you can do with that.

Note, WHAT the rules can be is very important, and seems to be beyond
you ability to reason about.

After all, all a Turing Machine is is a way of defining a finite stting transformation computation.

The next minimal increment of further elaboration is that some
finite strings has an assigned or derived property of Boolean
true. At this point of elaboration Boolean true has no more
semantic meaning than FooBar.

And since you can't do the first step, you don't understand what that
actually means.

Some finite strings are assigned the FooBar property and other
finite string derive the FooBar property by applying FooBar
preserving operations to the first set.

But, since we have an infinite number of finite strings to be assigned
values, we can't just enumerate that set.

Once finite strings have the FooBar property we can define
computations that apply Foobar preserving operations to
determine if other finite strings also have this FooBar property.

It seems you never even learned the First Principles of Logic Systems,
bcause you don't understand that Formal Systems are built from their
definitions, and those definitions can not be changed and let you stay
in the same system.

The actual First Principles are as I say they are: Finite string transformation rules applied to finite strings. What you are
referring to are subsequent principles that have added more on
top of the actual first principles.

But it seems you never actually came up with actual "first Principles'
about what could be done at your first step, and thus you have no idea
what can be done at each of the later steps.

Also, you then want to talk about fields that HAVE defined what those
mean, but you don't understand that, so your claims about what they can
do are just baseless.

All you have done is proved that you don't really understand what you
are talking about, but try to throw around jargon that you don't
actually understand either, which makes so many of your statements just
false or meaningless.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/19/24 11:20 PM, olcott wrote:

On 10/19/2024 9:27 PM, Richard Damon wrote:

On 10/19/24 8:13 PM, olcott wrote:

On 10/19/2024 4:53 PM, Richard Damon wrote:

On 10/19/24 7:26 AM, olcott wrote:

On 10/19/2024 6:21 AM, Richard Damon wrote:

On 10/18/24 11:19 PM, olcott wrote:

On 10/18/2024 9:49 PM, Richard Damon wrote:

On 10/18/24 8:52 PM, olcott wrote:

On 10/18/2024 6:06 PM, Richard Damon wrote:

On 10/18/24 10:10 AM, olcott wrote:

On 10/18/2024 6:17 AM, Richard Damon wrote:

On 10/17/24 11:47 PM, olcott wrote:

On 10/17/2024 10:27 PM, Richard Damon wrote:

On 10/17/24 9:47 PM, olcott wrote:

On 10/17/2024 8:13 PM, Richard Damon wrote:

On 10/17/24 7:31 PM, olcott wrote:

_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]

When DDD is correctly emulated by HHH according >>>>>>>>>>>>>>>>> to the semantics of the x86 language DDD cannot >>>>>>>>>>>>>>>>> possibly reach its own machine address [00002183] >>>>>>>>>>>>>>>>> no matter what HHH does.

[00002172]-->[00002173]-->[00002175]-->[0000217a]--+ >>>>>>>>>>>>>>>>> +------------------------------------------------------+ >>>>>>>>>>>>>>>>>

That may not line up that same way when view >>>>>>>>>>>>>>>>>



https://en.wikipedia.org/wiki/State_diagram

Except that 0000217a doesn't go to 00002172, but to >>>>>>>>>>>>>>>> 000015d2

IS THIS OVER YOUR HEAD?
What is the first machine address of DDD that HHH >>>>>>>>>>>>>>> emulating itself emulating DDD would reach?

Yes, HHH EMULATES the code at that address,

Which HHH emulates what code at which address?

Everyone, just once, which you should know, but ignore. >>>>>>>>>>>>
The Emulating HHH sees those addresses at its begining and >>>>>>>>>>>> then never again.

Then the HHH that it is emulating will see those addresses, >>>>>>>>>>>> but not the outer one that is doing that emulation of HHH. >>>>>>>>>>>>
Then the HHH that the second HHH is emulating will, but >>>>>>>>>>>> neither of the outer 2 HHH.

And so on.

Which HHH do you think EVER gets back to 00002172?

What instruction do you think that it emulates that would >>>>>>>>>>>> tell it to do so?

It isn't the call instruction at 0000217a, as that tells it >>>>>>>>>>>> to go into HHH.

At best the trace is:

00002172
00002173
00002175
0000217a
conditional emulation of 00002172
conditional emulation of 00002173
conditional emulation of 00002175
conditional emulation of 0000217a
CE of CE of 00002172
...

OK great this is finally good progress.

The "state" never repeats, it is alway a new state,

Every emulated DDD has an identical process state at every point >>>>>>>>>>> in its emulation trace when adjusting for different top of >>>>>>>>>>> stack values.

Nope, remember, each of those levels are CONDITIONAL,

*There are THREE different questions here*
(1) Can DDD emulated by HHH according to the semantics
     of the x86 language possibly reach its machine address >>>>>>>>>      [00002183] no matter what HHH does?

Ambiguouse question, as pointed out previously.

A) Do you mean the behavior of the PROGRAM DDD, that HHH has
emulated a copy of.

In that case, the answer is, if HHH aborts its emulation and
return, YES, if HHH never aborts its emulation, and thus doesn't >>>>>>>> ever return an answer to anyone NO.

B) If you mean, does the emulation done by HHH ever reach that >>>>>>>> place, no.

We are not asking if the code of HHH reaches inside
the code of DDD. Of course it doesn't this is stupid.

We are asking does any DDD of any DDD/HHH pair of the
infinite set of pairs such that DDD is emulated by HHH
according to the semantics of the x86 language reach its
own return instruction?

(2) Does HHH correctly detect and report the above?

No, because that isn't what you claim HHH is doing, so it can't >>>>>>>> be correct about that.

In other words you fail to comprehend that DDD failing
to reach its "return" instruction is isomorphic to:

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

... PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>>  > that P(P) *would* never stop running *unless* aborted.

We need to look at the two possible interpreations to question 1. >>>>>>>>
If you means A, then since HHH says no but the correct answer is >>>>>>>> yes, it is wrong.

If you mean B, and you mean your question is can HHH predict
that it can't reach the final state, but only needs to be right >>>>>>>> for this one input, then the problem is the question has become >>>>>>>> trivial, if it doesn't need to actually know anything about the >>>>>>>> input, it can just be programmed to say no.

I mean that the execution trace of DDD proves that HHH is correct >>>>>>> to reject DDD as impossibly reaching its own "return" instruction >>>>>>> even if it just guesses.

Also, we can make a trivial HHH, that just does the absolute
minimum, then aborts and returns no unconditionally to be
correct, showing your problem isn't interesting.

Or, your "problem" has left the domain of Program Theory,
becuause you don't consider DDD to be an actual program, at
which point it also becomes much less interesting.

(3) Does HHH do (2) it as a Turing computable function?

No, because the method your HHH uses isn't possible to be
expressed as a Turing Machine with a seperate input tape with
the full representatation of the program DDD.

Yet again you are not answering the question that
was asked. This must be your ADD.

The summation is the DDD does not halt and HHH
does correctly report this even if HHH as it is
currently implemented is not a Turing computable
function.

But the Program DDD DOES halt,

*Try and tell that to ChatGPT and it will make a fool of you*
https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e


Copyright 2024 Olcott "Talent hits a target no one else can hit;
Genius
hits a target no one else can see." Arthur Schopenhauer

Ignore any false information about the definiton of a termination
analyzer, and recall that the correct answer to a question given to
a termination analyzer is that it must report about the actual
behavior of the program that it has been given,

You are directly contradicting the verified fact that DDD
emulated by HHH according to the semantics of the x86 language
cannot possibly reach its own "return" instruction and halt.

But that isn't what the question being asked

Sure it is. You are just in psychological denial as proven by
the fact that all attempted rebuttals (yours and anyone else's)
to the following words have been baseless.

Does the input DDD to HHH specify a halting computation?

Which it isn't, but is a subtle change of the actual question.

The actual question (somewhat informally stated, but from the source you
like to use) says:

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run forever.

So, DDD is the COMPUTER PROGRAM to be decided on, and is converted to a DESCRIPTION of that program to be the input to the decider, and THAT is
the input.

So, the question has ALWAYS been about the behavior of the program (an OBJECTIVE standard, meaning the same to every decider the question is
posed to).

(where a halting computation is defined as)

DDD emulated by HHH according to the semantics of the x86
language reaches its own "return" instruction final state.

Except that isn't the definition of halting, as you have been told many
times, but apparently you can't undetstand.

Halting is a property of the PROGRAM. It is the property, as described
in the question, of will the program reach a final state if it is run,
or will it never reach such a final state.

DDD emulated by HHH is a standing for that only if HHH never aborts its emulation. But, since your HHH that answer must abort its emulation,
your criteria is just a bunch of meaningless gobbledygook.

It seems that a major part of the problem is you CHOSE to be ignorant of
the rules of the system, but learned it by what you call "First
Principles" (but you don't understand the term) by apparently trying to
derive the core principles of the system on your own. This is really a
ZERO Principle analysis, and doesn't get you the information you
actually need to use.

A "First Principles" approach that you refer to STARTS with an study and understanding of the actual basic principles of the system. That would
be things like the basic definitions of things like "Program", "Halting" "Deciding", "Turing Machine", and then from those concepts, sees what
can be done, without trying to rely on the ideas that others have used,
but see if they went down a wrong track, and the was a different path in
the same system.

It seems you never even learned the First Principles of Logic Systems,
bcause you don't understand that Formal Systems are built from their definitions, and those definitions can not be changed and let you stay
in the same system.

Since you like to break THAT rule, you put y

is, it is (or you claim it to be) about Termination, which is about
the behavior of the PROGRAM / FUNCITON (with all its used code) not
about a partial emulation of it.

Your statement is just an equivocation trying to confuse the idea of
comnplete correct emulations showing actual behavior, while a partial,
but correct, only shows partial behavior, not final behavior.

The VERIFIED FACT, is that what is defined as the BEHAVIOR of DDD,
which is what a termination analyser (or Halt Decider) has been
determined to be halting for the actual HHH you have provided.

Your claim tries to refer to the behavior of an only partial emuation
and claim that it shows non-termination, which it doesn't.

You are just proving that you are nothing but a stupid liar.

Your "Verified Fact" is just your LIE based on equivocation, as you
have been told, but don't seem to be able to understand it.

Sorry, you claimed no one could persuade the AI that you were wrong,
and I did it with ONE try.

How many attempts did it take you to get the answer you wanted out of
Chat GPT?

I only ever tried twice, once several months ago and
it got confused and this time. You can see all of the
details of this time.

SO, you don't even understand what I mean by "once".

I thought a bit, then typed ONE STATEMET into your ChatGPT and got that
answer. I didn't need to try other options.

I explained everything just once at the beginning.
Then I challenged it with your rebuttal several
times in several ways. Every time that I did this
it explained your mistake in great detail.

But it sure sounds like you tried several times in one "session" at the keyboard.

https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e
This is the most powerful free version it is full 4.0.
You don't need to login.

So?

AI is not the source of the defintions. The definitions established in
the original logic system is.

You are just showing you don't undertstand the basic nature of how to
use logic.

Sorry, you are just proving yourself to be a stupid idiodic pathological
liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-20 15:32:45 +0000, olcott said:

The actual barest essence for formal systems and computations
is finite string transformation rules applied to finite strings.

Before you can start from that you need a formal theory that
can be interpreted as a theory of finite strings.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-21 13:52:28 +0000, olcott said:

On 10/21/2024 3:41 AM, Mikko wrote:

On 2024-10-20 15:32:45 +0000, olcott said:

The actual barest essence for formal systems and computations
is finite string transformation rules applied to finite strings.

Before you can start from that you need a formal theory that
can be interpreted as a theory of finite strings.

Not at all. The only theory needed are the operations
that can be performed on finite strings:
concatenation, substring, relational operator ...

You may try with an informal foundation but you need to make sure
that it is sufficicently well defined and that is easier with a
formal theory.

The minimal complete theory that I can think of computes
the sum of pairs of ASCII digit strings.

That is easily extended to Peano arithmetic.

As a bottom layer you need some sort of logic. There must be unambifuous
rules about syntax and inference.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-22 14:02:01 +0000, olcott said:

On 10/22/2024 2:13 AM, Mikko wrote:

On 2024-10-21 13:52:28 +0000, olcott said:

On 10/21/2024 3:41 AM, Mikko wrote:

On 2024-10-20 15:32:45 +0000, olcott said:

The actual barest essence for formal systems and computations
is finite string transformation rules applied to finite strings.

Before you can start from that you need a formal theory that
can be interpreted as a theory of finite strings.

Not at all. The only theory needed are the operations
that can be performed on finite strings:
concatenation, substring, relational operator ...

You may try with an informal foundation but you need to make sure
that it is sufficicently well defined and that is easier with a
formal theory.

The minimal complete theory that I can think of computes
the sum of pairs of ASCII digit strings.

That is easily extended to Peano arithmetic.

As a bottom layer you need some sort of logic. There must be unambifuous
rules about syntax and inference.

I already wrote this in C a long time ago.
It simply computes the sum the same way
that a first grader would compute the sum.

I have no idea how the first grade arithmetic
algorithm could be extended to PA.

Basically you define that the successor of X is X + 1. The only
primitive function of Peano arithmetic is the successor. Addition
and multiplication are recursively defined from the successor
function. Equality is often included in the underlying logic but
can be defined recursively from the successor function and the
order relation is defined similarly.

Anyway, the details are not important, only that it can be done.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)