XPost: sci.logic

On 10/27/24 10:17 AM, olcott wrote:

I am keeping this post in both sci.logic and comp.theory
because it focuses on a similar idea to the Curry/Howard
correspondence between formal systems and computation.

Computation and all of the mathematical and logical operations
of mathematical logic can be construed as finite string
transformation rules applied to finite strings.

The semantics associated with finite string tokens can
be directly accessible to expression in the formal language.
It is basically an enriched type hierarchy called a knowledge
ontology.

A computation can be construed as the tape input to a
Turing machine and its tape output. All of the cases
where the output was construed as a set of final machine
states can be written to the tape.

I am not sure but I think that this may broaden the scope
of a computable function, or not.

Except that nothing you described related to what a "computabe function"
is at all, as a "Computable Function" is just a Function (which is just
a specific, but arbitrary, mapping of an input space to an output space)
that can have a computation built that computes that mapping based on representations of items in the input space to representations of items
in the output space.

The operations of formal systems can thus be directly
performed by a TM. to make things more interesting the
tape alphabet is UTM-32 of a TM equivalent RASP machine.

On 10/27/2024 6:38 AM, Richard Damon wrote:

On 10/26/24 9:22 PM, olcott wrote:

On 10/26/2024 8:04 PM, Richard Damon wrote:

On 10/26/24 5:57 PM, olcott wrote:

On 10/26/2024 10:48 AM, Richard Damon wrote:

On 10/26/24 8:59 AM, olcott wrote:

On 10/26/2024 2:52 AM, Mikko wrote:

On 2024-10-25 14:37:19 +0000, olcott said:

On 10/25/2024 3:14 AM, Mikko wrote:

On 2024-10-24 16:07:03 +0000, olcott said:

On 10/24/2024 9:06 AM, Mikko wrote:

On 2024-10-22 15:04:37 +0000, olcott said:

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

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

On 10/16/2024 11:37 AM, Mikko wrote:

On 2024-10-16 14:27:09 +0000, olcott said:

The whole notion of undecidability is anchored in >>>>>>>>>>>>>>>>> ignoring the fact that
some expressions of language are simply not truth bearers. >>>>>>>>>>>>>>>>

A formal theory is undecidable if there is no Turing >>>>>>>>>>>>>>>> machine that
determines whether a formula of that theory is a theorem >>>>>>>>>>>>>>>> of that
theory or not. Whether an expression is a truth bearer >>>>>>>>>>>>>>>> is not
relevant. Either there is a valid proof of that formula >>>>>>>>>>>>>>>> or there
is not. No third possibility.

After being continually interrupted by emergencies >>>>>>>>>>>>>>> interrupting other emergencies...

If the answer to the question: Is X a formula of theory Y >>>>>>>>>>>>>>> cannot be determined to be yes or no then the question >>>>>>>>>>>>>>> itself is somehow incorrect.

There are several possibilities.

A theory may be intentionally incomplete. For example, >>>>>>>>>>>>>> group theory
leaves several important question unanswered. There are >>>>>>>>>>>>>> infinitely
may different groups and group axioms must be true in >>>>>>>>>>>>>> every group.

Another possibility is that a theory is poorly
constructed: the
author just failed to include an important postulate. >>>>>>>>>>>>>>
Then there is the possibility that the purpose of the >>>>>>>>>>>>>> theory is
incompatible with decidability, for example arithmetic. >>>>>>>>>>>>>>

An incorrect question is an expression of language that >>>>>>>>>>>>>>> is not a truth bearer translated into question form. >>>>>>>>>>>>>>>
When "X a formula of theory Y" is neither true nor false >>>>>>>>>>>>>>> then "X a formula of theory Y" is not a truth bearer. >>>>>>>>>>>>>>

Whether AB = BA is not answered by group theory but is alwasy >>>>>>>>>>>>>> true or false about specific A and B and universally true in >>>>>>>>>>>>>> some groups but not all.

See my most recent reply to Richard it sums up
my position most succinctly.

We already know that your position is uninteresting.

Don't want to bother to look at it (AKA uninteresting) is not at >>>>>>>>>>> all the same thing as the corrected foundation to computability >>>>>>>>>>> does not eliminate undecidability.

No, but we already know that you don't offer anything interesting >>>>>>>>>> about foundations to computability or undecidabilty.

In the same way that ZFC eliminated RP True_Olcott(L,x)
eliminates undecidability. Not bothering to pay attention
is less than no rebuttal what-so-ever.

No, not in the same way.

Pathological self reference causes an issue in both cases.
This issue is resolved by disallowing it in both cases.

Nope, because is set theory, the "self-reference"

does exist and is problematic in its several other instances.
Abolishing it in each case DOES ELIMINATE THE FREAKING PROBLEM.

Yes, IN SET THEORY, the "self-reference" can be banned, by the
nature of the contstruction.

That seems to be the best way.

It works for sets, but not for Computations, due to the way things are
defined.

In Computation Theory it can not, without making the system less
than Turing Complete, as the structure of the Computations
fundamentally allow for it,

Sure.

So, you ADMIT that your computation system you are trying to advocate
is less than Turing Complete?

I never said that.

Sure you do.

You have said that D isn't allowed to make its own copy of H.

YOu have said that some inputs are just not allowed to be given.

In a Turing Complete system, ANY program can have a copy of it made and
be encorporated within the code of another totally independent program.

And a Turing Complete decider can take *ANY* input and decide on it.

That means that the Halting Problem isn't a problem.

and in a way that is potentially undetectable.

I really don't think so it only seems that way.

Of course it is.

The method of assigning meaning to the symbols can be done is a meta-
system that the system doesn't know about, and thus its meaning is
unknowable to the logic system.

When the only way that you learn is to memorize things from books
you make huge mistakes. It is the typical convention to assign
meaning in a way that the systems is unaware of. This is not the
only possible way. It is a ridiculously stupid way that causes
all kinds of undetectable semantic errors.

And when it is clear that you NEVER LEARNED anything you talk about, but
only rotely quote things out of ignroance, you prove yourself to be just
an ignorant pathological liar.

The "system" knows the mathematics of the numbers, and that might be all.

The "meta-system" can know properties of the numbers, and properties
that partucular operations preserve.

There is no "semantic" error, as the numbers have always meant what they
meant.

Note, the fact that it *IS* possible to assign this meaning in a way
that the system is unaware of, is what keeps the system from having any
ability to have a rule to reject things based on that meaning.

If there is a semantic error in the operation, then you should be able
to show where said error came about by a semantic error in the meta-system.

Remember, you can not get a semantic error by starting with just
semantically correct axioms, and applying only sematnically correct
operations to them.

If you can, then your system just started out broken.

You don't seem to understand that fact, but the fundamental nature
of being able to encode your processing in the same sort of strings
you process makes this a possibility.

Not at all. Tarski made this mistake of saying this and
everyone believed him.

Nope, he PROVED that the statement was constructable with only the
assumption that True(L, x) existed as a predicate.

It does not make these things undetectable, it merely
allows failing to detect.

No, it makes things undetectable, unless you allow the system to just
reject ALL statements, even if they are not actually "self-
referential" to be considered "bad".

When we encode natural langugae as formal language
"This sentence is not true"
becomes:

?- LP = not(true(LP)).
LP = not(true(LP)).

?- unify_with_occurs_check(LP, not(true(LP))).
false.

A detected error.

And, you need to show how you got to that first encoding from a
semantically correct statement.

Yes, starting with an error, you can prove that there is an error.

Dues to the nature of its relationship to Mathematics and Logic, it
turns out that and logic with certain minimal requirements can get
into a similar situation.

I think that I can see deeper than the Curry/Howard Isomorphism.
Computations and formal systems are in their most basic foundational
essence finite string transformation rules.

You don't undertstand what you see.

Part of the problem is that while Compuation Theory and Formal Logic
System do have large parts that are just finite string transformation
rules, they have other parts that are not.

You won't be able to show this. Try to define any computation
that cannot be expressed as a tape input and a tape output.

Because I wasn't talking about a "Computation" but about the definition
of a FUNCTION, as defined in Computation Theory.

There is no requirement that Functions be expressable as a finite finite
string transformation.

It is just a mapping of a possible infinite set of input strings to
output strings by some rule, that is deterministic but may not
necessarily be finite.

For instance, Halt(M, d) maps to 1 if the Turing Machine M, when given
the input tape d, will halt is some finite number of steps (but no upper
bound to the number of steps it can take) while it maps to 0 if that
Machine given that data will keep on processing even when allowed to run
for an unbounded number of step (aka infinity). That definition is NOT a "computation" as it does not always give an answer in a finite number of
steps, but is a mapping.

A TM takes its tape as input and has a set of final states and
or a tape output. The final states could be written to the tape.
You memorize from textbooks and I see deeper than textbooks say.

But you seem to have missed what the theory was all about, and its focus
wasn't the behavior of the Turing Machine, that was just a tool to use
to define what IS computable, and to try to decide what is and what is
not computable.

Your only way to remove it from these fields is to remove that
source of "power" in the systems, and the cost of that is just too
high for most people, thus you plan just fails.

Detection then rejection.

But since detection is impossible, you can not get to rejection.

Detection is "impossible" only because of foundational misconceptions.

No, it is impossible because it is impossible in the actual field.

Since you got the field backwards, and think it is asking about behavior
of Turing Machines, you just don't undetstand what you are doing.

Once you allow the creation of the statement, you can't reject it
later and still have the claim of handling "All".

Sure you can. As long as the error is detected before final
output all is well.

And if that can't be done in a finite number of steps, it can't be done.

The problem is that *ALL* is a big number.

Of course, you understanding is too crude to see this issue, so it
just goes over your head, and your claims just reveal your ignorance
of the fields.

Sorry, that is just the facts, that you seem to be too stupid to
understand.

In other words you can correctly explain every single detail
conclusively proving how finite string transformation rules
are totally unrelated to either computation and formal systems.

That isn't what I said, and just proves your stupidity.

You mind is just too small to handle these discussions.

You can't even form sound rebuttals. The main rebuttal that
you have is essentially anchored in ad hominem. Your rebuttals
never have anything in the ballpark of sound reasoning.

And you don't understand even what an ad hominem is. Ad hominem means I
say you are wrong because of something that you are, but that isn't what
I do. I point out your errors, by quoting the established FACTS of the
system. THAT is what makes you wrong, that you don't follow the REQUIRED
rules of the system you claim to be working in.

You ignore them, proving you are too stupid to know what you are doing,
thus PROVING my observations about you.

You aren't wrong because you are stupid, you are stupid because you keep
on insisting on things that have been proven wrong. That just follows
the meaning of the words.

*The form of your best rebuttals*
I memorized X from a book and you are not doing it that way
therefore you are stupid and ignorant.

Nope, I can quote the RULE that defines the system, and which violating
puts you out of the system. You just admit you are out of the system
because you won't follow the rules, and then LIE that you are in the
system by trying to say the rules don't matter (when they are the
definition of what does matter).

The philosophy of computation begins with existing ideas and
sees what happens when these ideas are reformulated.

Maybe the "Philospophy" of Computation, but not the SCIENCE of
Computation Theory.

SCIENCE follows the rules, something you don't seem to understand,
because you are just ignorant of the basics.

Sorry, you are just proving your utter ignorance of what you talk about
and your stupidity in reasoning about things that you claim you know.

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

On 10/27/24 6:01 PM, olcott wrote:

On 10/27/2024 12:48 PM, Richard Damon wrote:

On 10/27/24 10:17 AM, olcott wrote:

I am keeping this post in both sci.logic and comp.theory
because it focuses on a similar idea to the Curry/Howard
correspondence between formal systems and computation.

Computation and all of the mathematical and logical operations
of mathematical logic can be construed as finite string
transformation rules applied to finite strings.

The semantics associated with finite string tokens can
be directly accessible to expression in the formal language.
It is basically an enriched type hierarchy called a knowledge
ontology.

A computation can be construed as the tape input to a
Turing machine and its tape output. All of the cases
where the output was construed as a set of final machine
states can be written to the tape.

I am not sure but I think that this may broaden the scope
of a computable function, or not.

Except that nothing you described related to what a "computabe function"

I intend to reply to other aspects of your reply later
on as long as your reply to this reply is not lame.

When a Turing machine transforms the contents of its
input tape into the contents of its output tape this
seems to necessarily always be a computable function
no matter what the TM does in-between.

Yes, a Turing Machine will always be computing the mapping from some
computable function.

It is NOT the "Computable Function" itself, as that is a thing of a
different ty[pe.

It just computed the mapping definied by that function.

Note, the mapping of the function might not be defined in terms of "finite-strings", but will be something that can be described by a
finite string if we want to talk about it being computable.

For instance, the Halting Function, that the Halting problem is about,
is defined with Turing Machines as its input (not finite strings).

The key point here is that different implementation of a attempted
Turing Machines to try to compute this might use different ways of
representing the machines, so the function can't just be thought of as
taking the string.

We can look at the equivalent mapping based on the encoding of the given decider, if the encoding has the required property that a given finite
string can only represent one Turing Machine by the rules of that decider.

Note, This is one spot your HHH/DDD pairing fails, as what you want to
claim as the input reprenting DDD does NOT have that property, as the
finite string does not represent a specific computation, as it depends
on what HHH it is being pair with.

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

On 10/27/24 10:55 PM, olcott wrote:

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

On 10/27/24 6:01 PM, olcott wrote:

On 10/27/2024 12:48 PM, Richard Damon wrote:

On 10/27/24 10:17 AM, olcott wrote:

I am keeping this post in both sci.logic and comp.theory
because it focuses on a similar idea to the Curry/Howard
correspondence between formal systems and computation.

Computation and all of the mathematical and logical operations
of mathematical logic can be construed as finite string
transformation rules applied to finite strings.

The semantics associated with finite string tokens can
be directly accessible to expression in the formal language.
It is basically an enriched type hierarchy called a knowledge
ontology.

A computation can be construed as the tape input to a
Turing machine and its tape output. All of the cases
where the output was construed as a set of final machine
states can be written to the tape.

I am not sure but I think that this may broaden the scope
of a computable function, or not.

Except that nothing you described related to what a "computabe
function"

I intend to reply to other aspects of your reply later
on as long as your reply to this reply is not lame.

When a Turing machine transforms the contents of its
input tape into the contents of its output tape this
seems to necessarily always be a computable function
no matter what the TM does in-between.

Yes, a Turing Machine will always be computing the mapping from some
computable function.

It is NOT the "Computable Function" itself, as that is a thing of a
different ty[pe.

It just computed the mapping definied by that function.

Note, the mapping of the function might not be defined in terms of
"finite-strings", but will be something that can be described by a
finite string if we want to talk about it being computable.

Yes. We are getting somewhere now.

For instance, the Halting Function, that the Halting problem is about,
is defined with Turing Machines as its input (not finite strings).

Not in the least little bit.
It seems totally crazy that you would say this.

It has always been finite string Turing Machine descriptions.

The machine being used to compute the Halting Function has taken a
finite string description, the Halting Function itself always took a
Turing Machine,

These finite strings do have a specific semantics associated
with them and that is the semantics of Turing Machines.

No, the method of representing the Turing Machine is defined by the decider.

The "Semantics of Turing Machines" does have a finite string representation.

It defines a Turing Machine as having a "Set of States" (and "States"
don't have a defined string representation

The key point here is that different implementation of a attempted
Turing Machines to try to compute this might use different ways of
representing the machines, so the function can't just be thought of as
taking the string.

A string that maps to the semantics of Turing Machines.
The bytes of x86 machine code have the precisely defined
semantics of the x86 language.

Right, so in the context of a decider defined to take an input encoded
as an x86 binary, that is how you defined the form of the representation.

That didn't come from the rules of Turing Machines,

We can look at the equivalent mapping based on the encoding of the
given decider, if the encoding has the required property that a given
finite string can only represent one Turing Machine by the rules of
that decider.

We simply hypothesize some arbitrary specific standard.
No need to actually do this WHEN WE UNDERSTAND THAT X86
EXAMPLE <IS> ISOMORPHIC TO LINZ.

But it isn't, and CAN'T be because you don't even have two seperate
programs, but one which intertines its own code with its data.

You just don't know what "Isomorphic" means.

In the Linz statement, H^ contained its own copy of H, and was built to
run as its own independent machine. In your system, you have claimed
that it can't be done. Therefore, you have limited your system to
something less than Turing Complete.

Note, This is one spot your HHH/DDD pairing fails, as what you want to
claim as the input reprenting DDD does NOT have that property, as the
finite string does not represent a specific computation, as it depends
on what HHH it is being pair with.

You really can't simply get away with simply ignoring
the self-reference by pretending that it does not exist
without looking foolish.

Ane you can't ignore the definition of the system, like what a PROGRAM
is. What you want to call "DDD" isn't a program, and thus isn't a proper
input for a program behavior analysizer like a Halt Decider or a
Termination Analyzer.

*MAYBE YOU NEED TO REREAD THIS 10,000 TIMES*
When HHH emulates itself emulating DDD this is different than HHH1
emulating itself emulating DDD because the first case really happens
and the second case cannot possibly happen.

Only in your NON-TURING EQUIVALENT system.

Sorry, you are just proving that you are a stupid idiot that doesn't
know what you are talking about.

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

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

On 10/27/24 10:55 PM, olcott wrote:

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

On 10/27/24 6:01 PM, olcott wrote:

On 10/27/2024 12:48 PM, Richard Damon wrote:

On 10/27/24 10:17 AM, olcott wrote:

I am keeping this post in both sci.logic and comp.theory
because it focuses on a similar idea to the Curry/Howard
correspondence between formal systems and computation.

Computation and all of the mathematical and logical operations
of mathematical logic can be construed as finite string
transformation rules applied to finite strings.

The semantics associated with finite string tokens can
be directly accessible to expression in the formal language.
It is basically an enriched type hierarchy called a knowledge
ontology.

A computation can be construed as the tape input to a
Turing machine and its tape output. All of the cases
where the output was construed as a set of final machine
states can be written to the tape.

I am not sure but I think that this may broaden the scope
of a computable function, or not.

Except that nothing you described related to what a "computabe
function"

I intend to reply to other aspects of your reply later
on as long as your reply to this reply is not lame.

When a Turing machine transforms the contents of its
input tape into the contents of its output tape this
seems to necessarily always be a computable function
no matter what the TM does in-between.

Yes, a Turing Machine will always be computing the mapping from some
computable function.

It is NOT the "Computable Function" itself, as that is a thing of a
different ty[pe.

It just computed the mapping definied by that function.

Note, the mapping of the function might not be defined in terms of
"finite-strings", but will be something that can be described by a
finite string if we want to talk about it being computable.

Yes. We are getting somewhere now.

For instance, the Halting Function, that the Halting problem is
about, is defined with Turing Machines as its input (not finite
strings).

Not in the least little bit.
It seems totally crazy that you would say this.

It has always been finite string Turing Machine descriptions.

The machine being used to compute the Halting Function has taken a
finite string description, the Halting Function itself always took a
Turing Machine,

That is incorrect. It has always been the finite string Turing Machine description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

Nope, read the problem you have quoted in the past.

The FUNCTION is the Halting Function, which is about Turing Machines,

The decider is what takes a finite string, and that string is described
as a representation of the Turing Machine the Halting Function mapped.

It CAN'T be about the string, as every decider might take a different
form of encoding.

So yes, the TURING MACH(INE DECIDER takes a string, but the HALTING
FUNCTION takes a Turing Machine and its input.

Your problem is you don't understand what Computation Theory calls a "Function", and have guessed wrong.

These finite strings do have a specific semantics associated
with them and that is the semantics of Turing Machines.

No, the method of representing the Turing Machine is defined by the
decider.

The "Semantics of Turing Machines" does have a finite string
representation.

It may seem that way because there is no currently universal standard
like there is for the x86 language. For these thing to be properly investigated we must begin with a standard language. The machine
merely conforms to that standard.

Nope, doesn't work that way, The is no rule that says the decider needs
to uuse any particular form of encoding, and thus the Function that
defines the mapping can't be based on one.

You are just proving your stupidity,

It defines a Turing Machine as having a "Set of States" (and "States"
don't have a defined string representation

 A turing machine program consists of a list of 'quintuples', each one
of which is a five-symbol turing machine instruction.  For example, the quintuple 'SCcsm' is executed by the machine if it is in state 'S' and
is reading the symbol 'C' on the tape.  In that case, the instruction
causes the machine to make a transition to state 's' and to overwrite
the symbol 'C' on the tape with the symbol 'c'.  The last operation it performs under this instruction is to move the tape reading head one
symbol to the left or right according to whether 'm' is 'l' or 'r'. http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

And none of those have a defined finite-string encoding. Since you can't
even know what the symbol set to encode into, that becomes a lot harder
to define.

And, if you did limit it

SCcsm
current state number,
current symbol,
overwrite current symbol
next state number,
move tape head left or right

And how do you encode that into an arbitrary symbol set.

And, does it HAVE to be organized that way, NO.

If you limited it to that, you would only prove that you can't solve the problem with that particular encoding, which isn't good enougy to answer
the question about computablility.

Which you are just showing you just don't undetstand.

The key point here is that different implementation of a attempted
Turing Machines to try to compute this might use different ways of
representing the machines, so the function can't just be thought of
as taking the string.

A string that maps to the semantics of Turing Machines.
The bytes of x86 machine code have the precisely defined
semantics of the x86 language.

Right, so in the context of a decider defined to take an input encoded
as an x86 binary, that is how you defined the form of the representation.

Yes.

So, why doesn't your input contain the x86 code for all of the program
being given, like the code for HHH.

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code
for HHH, so it needs to be part of the input.

That didn't come from the rules of Turing Machines,

Already specified above: SCcsm easy to implement in existing hardware.

So, all you are showing is that it CAN be encoded, not that it must be
encoded that way.

We can look at the equivalent mapping based on the encoding of the
given decider, if the encoding has the required property that a
given finite string can only represent one Turing Machine by the
rules of that decider.

We simply hypothesize some arbitrary specific standard.
No need to actually do this WHEN WE UNDERSTAND THAT X86
EXAMPLE <IS> ISOMORPHIC TO LINZ.

But it isn't, and CAN'T be because you don't even have two seperate
programs, but one which intertines its own code with its data.

You just don't know what "Isomorphic" means.

Isomorphic like analogous does not mean identical in every way.
In both cases the input is defined to do the opposite of whatever
value the termination analyzer returns. The key essence remains
the same.

Isomorphic means *SAME* form. You show some similarity, but not in the ESSENTIAL nature of the thing, since your input isn't even of the same
kind of thing or even closely related.

The Linz proof uses the description of a COMPLETE program, yours is a
fragment missing essential code.

Those are NOT even "similar"

In the Linz statement, H^ contained its own copy of H, and was built
to run as its own independent machine. In your system, you have
claimed that it can't be done.

Without many thousands of more development hours on my part.
AProVE: Non-Termination Witnesses for C Programs, may be able
to already do this.

So, you admit that your system doesn't meet the requriements, and thus
your proof is bogus.

Sorry, you can't say "I could have done better" unless you actually DO
that better.

Remember, YOU are the one claiming to have disproved a well established
theory. YOU need to have REAL proof, not a sketch of an idea with more
wholes in it than a wheel of Swiss Cheese.,

Therefore, you have limited your system to something less than Turing
Complete.

Note, This is one spot your HHH/DDD pairing fails, as what you want
to claim as the input reprenting DDD does NOT have that property, as
the finite string does not represent a specific computation, as it
depends on what HHH it is being pair with.

You really can't simply get away with simply ignoring
the self-reference by pretending that it does not exist
without looking foolish.

Ane you can't ignore the definition of the system, like what a PROGRAM
is. What you want to call "DDD" isn't a program, and thus isn't a
proper input for a program behavior analysizer like a Halt Decider or
a Termination Analyzer.

It <is> sufficiently isomorphic. The Linz H runs into the
exact same key element of the halting problem proofs where
an input is defined to do the opposite of whatever value
that it returns.

You may think so, but that just proves your logic is based on LIES.

All you are doing is to admit that you are just using a Strawman
arguement, something "close enough" to falsely claim to be equivalent,
when it isn't.

x86utm simply cannot evaluate the effects of arbitrary
conditional branch instructions. AProVE: Non-Termination
Witnesses for C Programs can already do this.

So, you admit that your proof is just a failure, and doesn't do what you
claim,

Something else MIGHT be able to do it, but even they don't claim to have
done what you claim.

Sorry, you are just proving how bad of a liar you are.

*MAYBE YOU NEED TO REREAD THIS 10,000 TIMES*
When HHH emulates itself emulating DDD this is different than HHH1
emulating itself emulating DDD because the first case really happens
and the second case cannot possibly happen.

Only in your NON-TURING EQUIVALENT system.

In the x86 language that is Turing equivalent in every way
except unlimited memory. To the best of my knowledge all of
my code can be encoded in a Rasp machine.

Nope, because the input isn't in an independent space, and can't have
its own copy of HHH.

You "decider" fails to meet the basic requirements, as you have shown
that a copy of it behaves differently,

Sorry, you are just proving that you are a stupid idiot that doesn't
know what you are talking about.

That totally over-the-top statement makes you look quite foolish
and greatly reduces your credibility as you have been warned by
several others.

Whjy, it is true.

I consistently prove that I do know what I am talking about and
you consistently fail to point out any specific errors.

No, you consistently CLAIM to things you are unable to prove.

I DO point out specific errors, that you have been unable to even try to refute, so I guess you are just admitting to those errors.

Philosophy of computation examines different ways of doing
things besides the ways carefully memorized from textbooks.

But we aren't talking about the "Philosophy" of computation, but the
SCIENCE of Computation Theory.

It seems you don't even understand the nature of your topic, you are so
dumb.

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

On 10/28/24 8:57 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a
finite string description, the Halting Function itself always took a
Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts? https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

So, he begins by asking if we can built that Turing Machine to compute
the Halting Function.

Note, the criteria:

Does M, when started in the initial configuration qow, perform a
computation that eventually halts?

That is the Halting Function. What is its "inputs" the Machine M and the
input tape.

NOT the description. That is just what was given to the decider.

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects simulation out of hand:

Because the PARTIAL emulation that you describe doesn't matter, and you
seem to forget the BY DEFINITION embedded_H does exactly the same thing
as H.

He doesn't "reject" simulation, he is just using the fact that the only "correct simuation" is a simulation that exactly reproduces the behavior
of that which it is simulating.

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

So?

Just because it is impossible to do doesn't meaan we can't be asked to
do it. Especially when the ultimate question is CAN we do it.

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not HHH ever aborts its emulation of DDD.

because the emulation of DDD by HHH can never be complete and correct
and have HHH give an answer.

IS FREAKING ISOMORPHIC TO

⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Nope. Since partial emulation is not "isomorphic" to complete behavior.

Now, perhaps you can use the ismorphism of both being impossible to do
to try to demonstart that the halting problem is uncomputable.

But, trying to claim that the partial emulation by some copy of H not
reaching the final state says that H^ <H^> is non-halting is just bad
logic, and a LIE.

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

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a
finite string description, the Halting Function itself always took a
Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts? https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time
by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg
Turing machines in his proof that no Turing machine is a halt decider.

--
Mikko

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

Am Mon, 28 Oct 2024 22:08:50 -0500 schrieb olcott:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the
code for HHH, so it needs to be part of the input.

At machine address 0000217a HHH emulates itself emulating DDD without
knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again?

When HHH (unknowingly) emulates itself emulating DDD this emulated HHH
is going to freaking emulate DDD.

Of course. For that it needs its own code. This doesn't need to be
marked specially as being itself (HHH is not conscious), it just
needs to be identical to the running code.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the
code for HHH, so it needs to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating
DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again?

When HHH (unknowingly) emulates itself emulating DDD this
emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might
figure out that it is emulating an emulating decider, at which point it
knows that the decider might choose to abort its conditional emulation
to return, so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that if I don't
abort, it never will, and thus I am stuck, so I need to abort.

The problem is that it also needs to be smarter than you have been, and
realize this means that that original call to HHHG *WILL* return, and
return with what ever answer it gives, and at the moment, it doesn't
know what that program will do with that answer, which it will need to
know to give the right answer.

So, your logic is wrong, and a LIE, as you said as your premise here
that HHH never know it was emulating itself, so, how then did it convert
the concept of the call HHH to being an emulator without recognizing itself?

Note, if it JUST decides that it is an "emulator", it made an error, as
it is a CONDITIONAL emulator, that may (and if this HHH aborts, WILL)
stop its emulation and return an answer.

To think of it as an unconditional emulator is to make an error and
presume the input given wasn't the actual input that was given.

So, your problem is that you logic just forgets about some of the
details it doesn't want to think about. Which shows that you idea of "interrupting conditions" like if you ever conclude P and not P for some
P, you need to abort that step and weren't allowed to use that otherwise "valid" inference rule, just doesn't work.

Sorry, you are just proving yourself wrong.

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

Am Tue, 29 Oct 2024 09:58:50 -0500 schrieb olcott:

On 10/29/2024 9:50 AM, Andy Walker wrote:

On 29/10/2024 13:56, olcott wrote:

To the best of my knowledge no one besides me ever came up with the
idea of making a simulating halt decider / emulating termination
analyzer.

    The /idea/ is ancient, and certainly dates back at least to
    the
1970s.  For a relatively informal discussion, see paragraph 3 of
  http://www.cuboid.me.uk/anw/G12FCO/lect18.html

The word "simulate" or "UTM" or "interpret" was not there.
Let me know what keyword to search for I have to prepare my house for my cancer treatment.

The key word is "see". Oh wait, that's "emulate", which you haven't
explained the relevant difference from simulation of. Please keep
us posted about your health.

intended for second-year undergraduates and present on the web from
1996 [though then as a Nottingham University web page].  I certainly
didn't invent the idea.  The same page includes some stuff about Busy
Beavers.
You, and perhaps others, may also find some of the surrounding pages
[linked from that one] interesting, eg the stuff about UTMs and about
minimal computers.  Again, I am not claiming credit for inventing any
of this.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Tue, 29 Oct 2024 09:54:10 -0500 schrieb olcott:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the
code for HHH, so it needs to be part of the input.

You are not that stupid You are not that ignorant and this is not
your ADD
At machine address 0000217a HHH emulates itself emulating DDD
without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again?

When HHH (unknowingly) emulates itself emulating DDD this emulated HHH
is going to freaking emulate DDD.
Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might
figure out that it is emulating an emulating decider, at which point it
knows that the decider might choose to abort its conditional emulation
to return, so it needs to emulate further.
Only by recognizing itself, does it have grounds to say that if I don't
abort, it never will, and thus I am stuck, so I need to abort.

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE.

Right, your algorithm doesn't use this solution.

DDD emulated by HHH according to the semantics of the x86 language
cannot possibly reach its own "return" instruction whether or not any
HHH ever aborts its emulation of DDD.

:

I read, reread again and again to make sure that my understanding is
correct. You seems to glance at a few words before spouting off a canned rebuttal that does not even apply to my words.

lololol

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Tue, 29 Oct 2024 08:56:19 -0500 schrieb olcott:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>> finite string description, the Halting Function itself always took >>>>>> a Turing Machine,

That is incorrect. It has always been the finite string Turing
Machine description of a Turing machine is the input to the halt
decider. There are always been a distinction between the abstraction >>>>> and the encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine M and an
input w, does M, when started in the initial configuration qow,
perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
simulated by embedded_H cannot possibly reach either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩
because like everyone else he rejects simulation out of hand:
We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because there is
no limit on the length of the computation.

That statement does not fully reject simulation but is correct in the
observation that non-halting cannot be determied in finite time by a
complete simulation so someting else is needed instead of or in
addition to a partial simulation. Linz does include simulationg Turing
machines in his proof that no Turing machine is a halt decider.

To the best of my knowledge no one besides me ever came up with the idea
of making a simulating halt decider / emulating termination analyzer.

That's very bad knowledge.

Every sufficiently competent and honest person agrees that I am correct.

You live in a very sad world.

Insufficiently competent or dishonest people can not show any actual
error in my work. They generally incorrectly paraphrase my work and then
form a rebuttal to the incorrect paraphrase. This is known as the
strawman deception.

This is a very easy excuse.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Tue, 29 Oct 2024 08:23:04 -0500 schrieb olcott:

On 10/29/2024 3:44 AM, joes wrote:

Am Mon, 28 Oct 2024 22:08:50 -0500 schrieb olcott:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the
code for HHH, so it needs to be part of the input.

At machine address 0000217a HHH emulates itself emulating DDD
without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again?

When HHH (unknowingly) emulates itself emulating DDD this emulated HHH
is going to freaking emulate DDD.

Of course. For that it needs its own code. This doesn't need to be
marked specially as being itself (HHH is not conscious), it just needs
to be identical to the running code.

I have provided that at the TOP of page 21 since September 8,10,11 https://www.liarparadox.org/HHH(DDD).pdf

Not the point. The code of DDD only without HHH is not a complete program
and cannot be meaningfully simulated, as there is nothing to call.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 10/29/24 11:39 AM, olcott wrote:

On 10/29/2024 10:18 AM, joes wrote:

Am Tue, 29 Oct 2024 09:58:50 -0500 schrieb olcott:

On 10/29/2024 9:50 AM, Andy Walker wrote:

On 29/10/2024 13:56, olcott wrote:

To the best of my knowledge no one besides me ever came up with the
idea of making a simulating halt decider / emulating termination
analyzer.

      The /idea/ is ancient, and certainly dates back at least to >>>>       the
1970s.  For a relatively informal discussion, see paragraph 3 of
    http://www.cuboid.me.uk/anw/G12FCO/lect18.html

The word "simulate" or "UTM" or "interpret" was not there.
Let me know what keyword to search for I have to prepare my house for my >>> cancer treatment.

The key word is "see". Oh wait, that's "emulate", which you haven't
explained the relevant difference from simulation of. Please keep
us posted about your health.

The good news about my health is that I will probably
not be dead very soon.

An x86 emulation has a 100% perfectly exact standard
such that anyone disagreeing is unequivocally wrong.
A simulation is much more vague.

Right, assuming it is a COMPLETE x86 emulation, which HHH doesn't do.

What do you consider the difference between "emulation" and "simulation"?

intended for second-year undergraduates and present on the web from
1996 [though then as a Nottingham University web page].  I certainly
didn't invent the idea.  The same page includes some stuff about Busy >>>> Beavers.
You, and perhaps others, may also find some of the surrounding pages
[linked from that one] interesting, eg the stuff about UTMs and about
minimal computers.  Again, I am not claiming credit for inventing any >>>> of this.

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

On 2024-10-29 13:56:19 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>> finite string description, the Halting Function itself always took a >>>>>> Turing Machine,

That is incorrect. It has always been the finite string Turing Machine >>>>> description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩
correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects
simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time
by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg
Turing machines in his proof that no Turing machine is a halt decider.

To the best of my knowledge no one besides me ever came up with the
idea of making a simulating halt decider / emulating termination
analyzer.

Textboods may mention the idea but there is not much to say about it,
only that it does not give a complete solution. Linz' proof covers
all Turing machines. A simulating halt decider that is not a Turing
machine is not interesting because there is no known way to make it.

--
Mikko

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

On 10/29/24 9:38 PM, olcott wrote:

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

On 10/29/24 11:39 AM, olcott wrote:

On 10/29/2024 10:18 AM, joes wrote:

Am Tue, 29 Oct 2024 09:58:50 -0500 schrieb olcott:

On 10/29/2024 9:50 AM, Andy Walker wrote:

On 29/10/2024 13:56, olcott wrote:

To the best of my knowledge no one besides me ever came up with the >>>>>>> idea of making a simulating halt decider / emulating termination >>>>>>> analyzer.

      The /idea/ is ancient, and certainly dates back at least to >>>>>>       the
1970s.  For a relatively informal discussion, see paragraph 3 of
    http://www.cuboid.me.uk/anw/G12FCO/lect18.html

The word "simulate" or "UTM" or "interpret" was not there.
Let me know what keyword to search for I have to prepare my house
for my
cancer treatment.

The key word is "see". Oh wait, that's "emulate", which you haven't
explained the relevant difference from simulation of. Please keep
us posted about your health.

The good news about my health is that I will probably
not be dead very soon.

An x86 emulation has a 100% perfectly exact standard
such that anyone disagreeing is unequivocally wrong.
A simulation is much more vague.

Right, assuming it is a COMPLETE x86 emulation, which HHH doesn't do.

Requiring the complete emulation of a non-terminating input is
a complete jackass thing to say because no one could be that stupid.

WHy? if that is what is NEEDED to get the right answer?

Only a complete jackass would think the WRONG answer was right.

You are starting with the FALSE PRESUMPTION that the function *IS*
computable, when that is what the ultimate question is.

THe fact that it might require "infinite work" to determine is part of
what makes Halting non-computable.

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

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without
the code for HHH, so it needs to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating
DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again? >>>>>>

When HHH (unknowingly) emulates itself emulating DDD this
emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It
might figure out that it is emulating an emulating decider, at which
point it knows that the decider might choose to abort its
conditional emulation to return, so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that if I
don't abort, it never will, and thus I am stuck, so I need to abort.

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE.
https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

I read, reread again and again to make sure that my understanding
is correct. You seems to glance at a few words before spouting off a
canned rebuttal that does not even apply to my words.

No, it knows its own code because it rule for "No conditional
branches" excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs,
could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are just a lie,

If you don't have time to do it right, you might as well not do it.

Your problem is you have brainwashed yourself with your equivocation, to
the point you no longer understand that DDD is not the emulation of the
code of DDD done by HHH, but the full behavior of the full code that DDD
uses, which is what we see with its actual behavior

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

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code for HHH, so it needs
to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating
DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again? >>>>>>>

When HHH (unknowingly) emulates itself emulating DDD this
emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might figure out that it is
emulating an emulating decider, at which point it knows that the decider might choose to abort
its conditional emulation to return, so it needs to emulate further. >>>>>
Only by recognizing itself, does it have grounds to say that if I don't abort, it never will,
and thus I am stuck, so I need to abort.

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE.
https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

I read, reread again and again to make sure that my understanding
is correct. You seems to glance at a few words before spouting off a canned rebuttal that does
not even apply to my words.

No, it knows its own code because it rule for "No conditional branches" excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs,
could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are just a lie,

PO definitely has a deep-rooted problem with his thinking here. Comments in his code suggest he
really does believe somehow that HHH counts as "OS code" which can be ignored! It's all over the
place in the code...

It reminds me as well of his "global" halt decider thinking which (as I understand it) was some
scheme he had early on, where the equivalent of HHH really would have been part of x86utm.exe
(arguably "the OS") rather than part of halt7.c. Thankfully that thinking was abandonned long ago,
but when PO abandons some line of argument that's not an indication that he has understood his error
- simply that he recognises that he's not getting anywhere [and has no prospect of getting anywhere]
with that line of argument.


Mike.

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

On 10/30/24 10:28 PM, olcott wrote:

On 10/30/2024 6:35 PM, Richard Damon wrote:

On 10/30/24 8:28 AM, olcott wrote:

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

On 10/29/24 9:41 PM, olcott wrote:

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

On 10/29/24 10:41 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics
without the code for HHH, so it needs to be part of the input. >>>>>>>>>>>>

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating >>>>>>>>>>> DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD >>>>>>>>>> again?

When HHH (unknowingly) emulates itself emulating DDD this
emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. >>>>>>>> It might figure out that it is emulating an emulating decider, >>>>>>>> at which point it knows that the decider might choose to abort >>>>>>>> its conditional emulation to return, so it needs to emulate
further.

Only by recognizing itself, does it have grounds to say that if >>>>>>>> I don't abort, it never will, and thus I am stuck, so I need to >>>>>>>> abort.

Counter-factual. This algorithm has no ability to its own code.
https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801 >>>>>>>
*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

No, it knows its own code because it rule for "No conditional
branches" excludes that code.

Are you really so stupid that you think this will help
DDD reach its own return instruction?

DDD doesn't need any help to reach its own return instruction, as
the HHH that it calls DOES abort and return to it.

Are you really so stupid that you think you can keep getting
away with the strawman deception by changing the subject away
from DDD emulated by HHH?

What strawman?

I am just going to the defintions of the problem you claim to be solving.

Do I have to repeat this a few hundred times in every post
so that you can remember from one post to the next?

*AT THIS POINT HHH IS NOT A HALT DECIDER OR A TERMINATION ANALYZER*
*AT THIS POINT HHH IS NOT A HALT DECIDER OR A TERMINATION ANALYZER*
*AT THIS POINT HHH IS NOT A HALT DECIDER OR A TERMINATION ANALYZER*

But, you haven't removed yourself from the topic, so the definitions
still apply.

HHH is each element of the set of x86 emulators that emulates zero
to infinity steps of DDD including zero to infinity emulations of
itself emulating DDD.

No, it isn't, because your published HHH is not a "set of programs".

It is *A* progrtam.

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Which means HHH can't abort its emulaiton, or it fails to meet its
requrements.

And thus the ONLY HHH that meets yor requrements is a different one than presented, and that one returns to NOBODY.

You can't try to redefine the terms until you clearly and public
announce that you are leaving Computation Theory behind, and nothing you
talk about can be broght back in.

Then you need to sit down and actually DEFINE what you mean by things,
and that means clarify the equivocation.

Sorry, but thpse ARE the rules.

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

On 2024-10-29 14:35:34 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>> finite string description, the Halting Function itself always took a >>>>>> Turing Machine,

That is incorrect. It has always been the finite string Turing Machine >>>>> description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩
correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects
simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time
by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg
Turing machines in his proof that no Turing machine is a halt decider.

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

- irrelevant
- couterfactual

--
Mikko

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

On 2024-10-30 12:24:13 +0000, olcott said:

On 10/30/2024 5:07 AM, Mikko wrote:

On 2024-10-29 13:56:19 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>> finite string description, the Halting Function itself always took a >>>>>>>> Turing Machine,

That is incorrect. It has always been the finite string Turing Machine >>>>>>> description of a Turing machine is the input to the halt decider. >>>>>>> There are always been a distinction between the abstraction and the >>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects >>>>> simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time
by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg
Turing machines in his proof that no Turing machine is a halt decider.

To the best of my knowledge no one besides me ever came up with the
idea of making a simulating halt decider / emulating termination
analyzer.

Textboods may mention the idea but there is not much to say about it,
only that it does not give a complete solution. Linz' proof covers
all Turing machines. A simulating halt decider that is not a Turing
machine is not interesting because there is no known way to make it.

In other words you are saying that there is no such thing as a
UTM. Not a smart thing to say. embedded_H was adapted from a UTM.

I already said that you should not use the expression "In other wordw".
It is not clear what you mean by it but you boviously don't mean what
the phrase really means.

Besides, it is not a good idea to lie about what other people say.
Even when one says "In other words".

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There should be an "or" between the last two lines.

embedded_H does correctly determine the halt status of the
Linz ⟨Ĥ⟩ ⟨Ĥ⟩ when embedded_H computes the mapping from its
finite string input to the behavior this finite string actually
specifies.

It does not matter what a non-exstent Turing machine does. If H is
a possible Turing machine then embedded_H determines incorrectly.
If not then Ĥ is not a Turing machine and therefore not relevant.

--
Mikko

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

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in
less than 10 minutes. Do you think he read the material before
responding? A good troll would have waited a few hours before
answering.

I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar
I may politely pretend to believe.

--
Mikko

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

On 2024-10-31 01:20:40 +0000, Mike Terry said:

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code
for HHH, so it needs to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating
DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again? >>>>>>>>

When HHH (unknowingly) emulates itself emulating DDD this
emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might >>>>>> figure out that it is emulating an emulating decider, at which point it >>>>>> knows that the decider might choose to abort its conditional emulation >>>>>> to return, so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that if I don't >>>>>> abort, it never will, and thus I am stuck, so I need to abort.

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE. >>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

I read, reread again and again to make sure that my understanding
is correct. You seems to glance at a few words before spouting off a >>>>> canned rebuttal that does not even apply to my words.

No, it knows its own code because it rule for "No conditional branches" >>>> excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs,
could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are just a lie,

PO definitely has a deep-rooted problem with his thinking here.

What PO does does not look like any thingking but more like what one
could expect from ChatgPPT or a similar AI.

--
Mikko

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

On 10/30/24 11:59 PM, olcott wrote:

On 10/30/2024 10:18 PM, Richard Damon wrote:

On 10/30/24 10:28 PM, olcott wrote:

On 10/30/2024 6:35 PM, Richard Damon wrote:

On 10/30/24 8:28 AM, olcott wrote:

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

On 10/29/24 9:41 PM, olcott wrote:

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

On 10/29/24 10:41 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics >>>>>>>>>>>>>> without the code for HHH, so it needs to be part of the >>>>>>>>>>>>>> input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating >>>>>>>>>>>>> DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of >>>>>>>>>>>> DDD again?

When HHH (unknowingly) emulates itself emulating DDD this >>>>>>>>>>> emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. >>>>>>>>>> It might figure out that it is emulating an emulating decider, >>>>>>>>>> at which point it knows that the decider might choose to abort >>>>>>>>>> its conditional emulation to return, so it needs to emulate >>>>>>>>>> further.

Only by recognizing itself, does it have grounds to say that >>>>>>>>>> if I don't abort, it never will, and thus I am stuck, so I >>>>>>>>>> need to abort.

Counter-factual. This algorithm has no ability to its own code. >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801 >>>>>>>>>
*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly* >>>>>>>>> *or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

No, it knows its own code because it rule for "No conditional
branches" excludes that code.

Are you really so stupid that you think this will help
DDD reach its own return instruction?

DDD doesn't need any help to reach its own return instruction, as
the HHH that it calls DOES abort and return to it.

Are you really so stupid that you think you can keep getting
away with the strawman deception by changing the subject away
from DDD emulated by HHH?

What strawman?

I am just going to the defintions of the problem you claim to be
solving.

Do I have to repeat this a few hundred times in every post
so that you can remember from one post to the next?

*AT THIS POINT HHH IS NOT A HALT DECIDER OR A TERMINATION ANALYZER*
*AT THIS POINT HHH IS NOT A HALT DECIDER OR A TERMINATION ANALYZER*
*AT THIS POINT HHH IS NOT A HALT DECIDER OR A TERMINATION ANALYZER*

But, you haven't removed yourself from the topic, so the definitions
still apply.

HHH is each element of the set of x86 emulators that emulates zero
to infinity steps of DDD including zero to infinity emulations of
itself emulating DDD.

No, it isn't, because your published HHH is not a "set of programs".

It is *A* progrtam.

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Which means HHH can't abort its emulaiton, or it fails to meet its
requrements.

And thus the ONLY HHH that meets yor requrements is a different one
than presented, and that one returns to NOBODY.

You can't try to redefine the terms until you clearly and public
announce that you are leaving Computation Theory behind, and nothing
you talk about can be broght back in.

EVERYTHING NOT EXPRESSLY STATED IS EXPRESSLY EXCLUDED
UNLESS ENTAILED BY THE SEMANTICS OF THE X86 LANGUAGE

void DDD()
{
  HHH(DDD);
  return;
}

DDD emulated by any HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

So, you are just admitting that you don't know what you are talking
about, since NOTHING after your disclaimer that we can only evalute
everything by the "semantics of the x86 language" is in the x86 languge,
and thus not meaningful.

Sorry, it is clear you don't understand what the words you are using
mean, because it seems there is a big funny-mental filter between your
brain and the world.

Even if you replace the C function DDD with its x86 code equivalenet,
you can't evaluate your later claim, as the "call HHH" instruction in
the x86 code for DDD means EXACTLY, and nothing else, to continue in the function HHH, which hasn't been given so can't be done.

And when you DO include the code for HHH, you don't get the meaning you
want, because it STILL means do the code of HHH, ahd that doesn't let
you say that "means" emulated DDD per the x86 langugage, but it only
means that doing the steps of HHH, which by logic OUTSIDE that of the
x86 language can be seen to be an emulation of DDD (but that emulation
is never directly seen in the emulation of DDD).

Also, HHH is not then allowed to ever "abort" its emulation, and the
semantics of the x86 language don't allow for that, as EVERY instruction includes as part of its semantics what the next instruction to process
WILL be, so any stopping of the emulation is a violation of your claimed semantics.

If the code of the HHH that DDD calls happens to be code that aborts,
then the correct x86 emulation of DDD, which now isn't being done by
that HHH, but still REQUIRED by your claim, will show that the emulation
WILL reach the end, so the only valid correction of your statement that
means anything close to it is shown to be false.


Sorry, but you are just proving how stupid and ignorant you are.

You don't understand the difference between a program, which has
behavior, and the partial emulation of said program, in part because you
have shown to not understand what it "Truth" and what is "Knowledge",
confusing the two and thus getting EVERYTHING wrong.

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

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in
less than 10 minutes. Do you think he read the material before
responding? A good troll would have waited a few hours before
answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar
I may politely pretend to believe.

It's not exactly polite to describe Peter in any of these ways! Entirely personally, I see no reason to do so in any case. He is quite
often impolite in response to being called a "stupid liar" or similar,
but that's understandable. He is no worse than many a student in terms
of what he comprehends; his fault lies in [apparently] believing that he
has a unique insight. I have no reason to believe that he lies [versus
being profoundly mistaken]; YMMV. His real problem is that he cannot
[or will not] resist responding to any article here, very probably inc
this one. He is apparently not alone, which is what generates the flood
of articles. There is a simple way to avoid that.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Rimsky-Korsakov

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

On 10/31/24 8:54 AM, olcott wrote:

On 10/31/2024 6:01 AM, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in
less than 10 minutes. Do you think he read the material before
responding? A good troll would have waited a few hours before
answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar
I may politely pretend to believe.

That I state the subject of the conversation is:
[The philosophy of computation reformulates existing ideas on a new
basis ---]

and you ignore this is not my mistake.

So, are you admitting that any answer you get here has NOTHING To do
with the halting problem?

That that is a true statment even though your "programs" are the same
ones that you claimed were "correct hatl deciders" and "correct
termination analyszers"?

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

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>> less than 10 minutes. Do you think he read the material before
responding? A good troll would have waited a few hours before
answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar >>>>> I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways! >>>> Entirely personally, I see no reason to do so in any case.  He is quite >>>> often impolite in response to being called a "stupid liar" or similar, >>>> but that's understandable.  He is no worse than many a student in terms >>>> of what he comprehends;  his fault lies in [apparently] believing
that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you
might come up with has any bearing on the original halting problem
because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

Which is just a lie, so you are just admitting to not knowing what the
facts are.

(2) I am resolving the halting problem in a way that is
comparable to the way that ZFC resolved Russell's Paradox.
Establishing the foundation that the decider must report on
the behavior of its own simulation of its input to compute
the mapping from this input to its behavior.

Nope, just shows you don't understand what Z-F did, or what the problem
you are trying to solve is.

You are just proving you don't know what you are talking about.

It really seems that (1) is more apt and everyone simply
made the mistake of thinking otherwise.

Nope, the answer is you are just to stupid to understand what yor are
talking about.

I have no reason to believe that he lies [versus
being profoundly mistaken];  YMMV.  His real problem is that he cannot >>>> [or will not] resist responding to any article here, very probably inc >>>> this one.  He is apparently not alone, which is what generates the
flood
of articles.  There is a simple way to avoid that.

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

On 2024-10-30 12:46:25 +0000, olcott said:

ZFC only resolved Russell's Paradox because it tossed out
the incoherent foundation of https://en.wikipedia.org/wiki/Naive_set_theory

Actually Zermelo did it. The F and C are simply minor improvements on
other aspects of the theory.

--
Mikko

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

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>>>> less than 10 minutes. Do you think he read the material before >>>>>>>>> responding? A good troll would have waited a few hours before >>>>>>>>> answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar >>>>>>> I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways!
Entirely personally, I see no reason to do so in any case.  He is quite >>>>>> often impolite in response to being called a "stupid liar" or similar, >>>>>> but that's understandable.  He is no worse than many a student in terms >>>>>> of what he comprehends;  his fault lies in [apparently] believing that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you
might come up with has any bearing on the original halting problem
because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

Which is just a lie, so you are just admitting to not knowing what the
facts are.

It can't possibly be a lie because I am not even asserting
it as a truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

--
Mikko

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

On 2024-10-31 12:53:04 +0000, olcott said:

On 10/31/2024 5:55 AM, Mikko wrote:

On 2024-10-31 01:20:40 +0000, Mike Terry said:

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code
for HHH, so it needs to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating >>>>>>>>>>> DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again? >>>>>>>>>>

When HHH (unknowingly) emulates itself emulating DDD this
emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might
figure out that it is emulating an emulating decider, at which point it
knows that the decider might choose to abort its conditional emulation >>>>>>>> to return, so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that if I don't
abort, it never will, and thus I am stuck, so I need to abort. >>>>>>>>

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE. >>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801 >>>>>>>
*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

I read, reread again and again to make sure that my understanding >>>>>>> is correct. You seems to glance at a few words before spouting off a >>>>>>> canned rebuttal that does not even apply to my words.

No, it knows its own code because it rule for "No conditional branches" >>>>>> excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs,
could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are just a lie,

PO definitely has a deep-rooted problem with his thinking here.

What PO does does not look like any thingking but more like what one
could expect from ChatgPPT or a similar AI.

I don't have the 50 years it would take for me to replicate the work of AProVE: Non-Termination Witnesses for C Programs.

Doesn't matter. Even if you had you could not use it to prove your false
claim that there be some defect in some proof.

In other case what I am doing is called
isolating the independent variable.

You may call it that way. It does not look like that.

The program under test is DDD.
HHH is NOT the program under test it is the tester.

So far is good. But the halting problem demands that every Turng machine
can be put to the test.

--
Mikko

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

On 2024-10-31 12:54:49 +0000, olcott said:

On 10/31/2024 6:01 AM, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in
less than 10 minutes. Do you think he read the material before
responding? A good troll would have waited a few hours before
answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar
I may politely pretend to believe.

That I state the subject of the conversation is:
[The philosophy of computation reformulates existing ideas on a new basis ---]

and you ignore this is not my mistake.

It is not a mistake at all. You are a moron in either all your discussion
or none.

--
Mikko

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

On 2024-10-31 12:36:21 +0000, olcott said:

On 10/31/2024 5:45 AM, Mikko wrote:

On 2024-10-30 12:24:13 +0000, olcott said:

On 10/30/2024 5:07 AM, Mikko wrote:

On 2024-10-29 13:56:19 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>>>> finite string description, the Halting Function itself always took a >>>>>>>>>> Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider. >>>>>>>>> There are always been a distinction between the abstraction and the >>>>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects >>>>>>> simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time >>>>>> by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg >>>>>> Turing machines in his proof that no Turing machine is a halt decider. >>>>>

To the best of my knowledge no one besides me ever came up with the
idea of making a simulating halt decider / emulating termination
analyzer.

Textboods may mention the idea but there is not much to say about it,
only that it does not give a complete solution. Linz' proof covers
all Turing machines. A simulating halt decider that is not a Turing
machine is not interesting because there is no known way to make it.

In other words you are saying that there is no such thing as a
UTM. Not a smart thing to say. embedded_H was adapted from a UTM.

I already said that you should not use the expression "In other wordw".
It is not clear what you mean by it but you boviously don't mean what
the phrase really means.

The only way to verify mutual understanding is to
keep paraphrasing back and forth until there is
mutual agreement.

No. Asking about specific words and phrases is a more efficient way.
Making false statements about another topic is not useful.

If my paraphrase is inaccurate then you must point
out the exact details of the inaccuracy.

What you said cannot be interpreted as a paraphrase.

--
Mikko

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

On 2024-10-31 23:43:41 +0000, olcott said:

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>> less than 10 minutes. Do you think he read the material before
responding? A good troll would have waited a few hours before
answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar >>>>> I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways! >>>> Entirely personally, I see no reason to do so in any case.  He is quite >>>> often impolite in response to being called a "stupid liar" or similar, >>>> but that's understandable.  He is no worse than many a student in terms >>>> of what he comprehends;  his fault lies in [apparently] believing that he >>>> has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you
might come up with has any bearing on the original halting problem
because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

The finite strings specifying the behaviour are not a part
of the halting problem. Any solution is required to contain
encoding rules for the creation of those strings.

(2) I am resolving the halting problem in a way that is
comparable to the way that ZFC resolved Russell's Paradox.

Problems shall be solved, not resolved. The expression "resolving
the halting problem" does not mean anything because the types of
the words are not compatible. A paradox is a different type so
it can be resolved.

Establishing the foundation that the decider must report on
the behavior of its own simulation of its input to compute
the mapping from this input to its behavior.

Establishing another foundation means that your work is about
something else than the halting problem. Another foundation
may be useful in finding something but it cannot be a part of
any solution of the halting problem. Every solution to a halting
problem is either a Turing machine and encoding rules or a proof
that no pair of a Turing machine and encoding rules is a solution.

--
Mikko

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

On 2024-10-31 12:50:00 +0000, olcott said:

On 10/31/2024 5:49 AM, Mikko wrote:

On 2024-10-29 14:35:34 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>> finite string description, the Halting Function itself always took a >>>>>>>> Turing Machine,

That is incorrect. It has always been the finite string Turing Machine >>>>>>> description of a Turing machine is the input to the halt decider. >>>>>>> There are always been a distinction between the abstraction and the >>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects >>>>> simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time
by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg
Turing machines in his proof that no Turing machine is a halt decider.

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

- irrelevant

100% perfectly relevant within the philosophy of computation

Probably but not to anything quoted above.

*THE TITLE OF THIS THREAD*
[The philosophy of computation reformulates existing ideas on a new basis ---]

- couterfactual

You can baselessly claim that verified facts are counter-factual
you cannot show this.

Your statement was about a situation where "people fail to agree with
this and also fail to correctly point out any error". But that situation
has not happened as people have identified your errors (perhaps not all
but at least sufficiently many).

--
Mikko

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

On 10/31/24 8:12 PM, olcott wrote:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>>>> less than 10 minutes. Do you think he read the material before >>>>>>>>> responding? A good troll would have waited a few hours before >>>>>>>>> answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a >>>>>>> liar
I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways!
Entirely personally, I see no reason to do so in any case.  He is >>>>>> quite
often impolite in response to being called a "stupid liar" or
similar,
but that's understandable.  He is no worse than many a student in >>>>>> terms
of what he comprehends;  his fault lies in [apparently] believing >>>>>> that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you
might come up with has any bearing on the original halting problem
because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

Which is just a lie, so you are just admitting to not knowing what the
facts are.

It can't possibly be a lie because I am not even asserting
it as a truth only a possible truth of two possible truths.

No, the statement is counter factual, so puting it forward as even a
POSSIBLE source of the problem is just a lie.

(2) I am resolving the halting problem in a way that is
comparable to the way that ZFC resolved Russell's Paradox.
Establishing the foundation that the decider must report on
the behavior of its own simulation of its input to compute
the mapping from this input to its behavior.

Nope, just shows you don't understand what Z-F did, or what the
problem you are trying to solve is.

*Comparable to* does not mean exactly the same in every single detail.
ZFC resolved RP by changing the foundations of set theory. The HP
can be equally resolved by changing the foundations of computation.
These two are exactly the same in that they *change the foundations*

No, it needed to do a lot more than that, which just shows how little
you understand about logic.

You are just proving you don't know what you are talking about.

No I am proving that you don't know what I am talking about.
The philosophy of computation never takes any received view
as inherently infallible. It examines alternative possible
views to see where they lead.

No, you are proving that what you are talking about is devoid of
meaning, so is meaningless.

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

On 11/1/24 9:34 PM, olcott wrote:

On 11/1/2024 7:27 PM, Richard Damon wrote:

On 11/1/24 9:18 AM, olcott wrote:

On 11/1/2024 6:08 AM, Mikko wrote:

On 2024-10-31 12:53:04 +0000, olcott said:

On 10/31/2024 5:55 AM, Mikko wrote:

On 2024-10-31 01:20:40 +0000, Mike Terry said:

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics >>>>>>>>>>>>>>>> without the code for HHH, so it needs to be part of the >>>>>>>>>>>>>>>> input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating >>>>>>>>>>>>>>> DDD without knowing that it is emulating itself. >>>>>>>>>>>>>>>

Then how did it convert the call HHH into an emulation of >>>>>>>>>>>>>> DDD again?

When HHH (unknowingly) emulates itself emulating DDD this >>>>>>>>>>>>> emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a
decider. It might figure out that it is emulating an
emulating decider, at which point it knows that the decider >>>>>>>>>>>> might choose to abort its conditional emulation to return, >>>>>>>>>>>> so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that >>>>>>>>>>>> if I don't abort, it never will, and thus I am stuck, so I >>>>>>>>>>>> need to abort.

Counter-factual. This algorithm has no ability to KNOW ITS >>>>>>>>>>> OWN CODE.
https://github.com/plolcott/x86utm/blob/master/Halt7.c // >>>>>>>>>>> page 801

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly* >>>>>>>>>>> *or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86 >>>>>>>>>>> language cannot possibly reach its own "return" instruction >>>>>>>>>>> whether or not any HHH ever aborts its emulation of DDD. >>>>>>>>>>>
I read, reread again and again to make sure that my
understanding
is correct. You seems to glance at a few words before
spouting off a canned rebuttal that does not even apply to my >>>>>>>>>>> words.

No, it knows its own code because it rule for "No conditional >>>>>>>>>> branches" excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs, >>>>>>>>> could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are >>>>>>>> just a lie,

PO definitely has a deep-rooted problem with his thinking here.

What PO does does not look like any thingking but more like what one >>>>>> could expect from ChatgPPT or a similar AI.

I don't have the 50 years it would take for me to replicate the
work of
AProVE: Non-Termination Witnesses for C Programs.

Doesn't matter. Even if you had you could not use it to prove your
false
claim that there be some defect in some proof.

There has never ever been the least trace of error
in this verified fact:

Sure there has been, but you have just proven that you are too stupid
to understand it.

That you rejected the statement of fact prior to even seeing
it seems to prove that you are dishonest.

WHAT "statement of fact".

It was a statement of ERROR based on equivocation.

Since you REFUSE to clearify your equivocation, by stating clearly which
of the meanings you actually mean, it just shows that you are
deliberately lying.

The fact that you just act too stupid to understand just proves again
that you are lying, as you claim to be "smart" but then act just so
dumb. Either you are lying about your smartness, or lying by
deliberately avioding having to clarify your meaning.

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

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

On 2024-11-01 12:10:41 +0000, olcott said:

On 11/1/2024 5:40 AM, Mikko wrote:

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>>>>>> less than 10 minutes. Do you think he read the material before >>>>>>>>>>> responding? A good troll would have waited a few hours before >>>>>>>>>>> answering.

    I doubt whether Peter is either a moron or a troll. >>>>>>>>> Does it really matter? If he falsely pretends to be a moron or a liar >>>>>>>>> I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways!
Entirely personally, I see no reason to do so in any case.  He is quite
often impolite in response to being called a "stupid liar" or similar, >>>>>>>> but that's understandable.  He is no worse than many a student in terms
of what he comprehends;  his fault lies in [apparently] believing that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you >>>>>> might come up with has any bearing on the original halting problem >>>>>> because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

Which is just a lie, so you are just admitting to not knowing what the >>>> facts are.

It can't possibly be a lie because I am not even asserting
it as a truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

--
Mikko

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

On 2024-11-01 12:03:24 +0000, olcott said:

On 11/1/2024 5:37 AM, Mikko wrote:

On 2024-10-31 23:43:41 +0000, olcott said:

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>>>> less than 10 minutes. Do you think he read the material before >>>>>>>>> responding? A good troll would have waited a few hours before >>>>>>>>> answering.

    I doubt whether Peter is either a moron or a troll.

Does it really matter? If he falsely pretends to be a moron or a liar >>>>>>> I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways!
Entirely personally, I see no reason to do so in any case.  He is quite >>>>>> often impolite in response to being called a "stupid liar" or similar, >>>>>> but that's understandable.  He is no worse than many a student in terms >>>>>> of what he comprehends;  his fault lies in [apparently] believing that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you
might come up with has any bearing on the original halting problem
because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

The finite strings specifying the behaviour are not a part
of the halting problem. Any solution is required to contain
encoding rules for the creation of those strings.

Sure they are.

It is of course possible to present the problem in either way without
changing anything important. The most common way is to state that the
decider shall use descriptions of the Turing machine and the input
but the encoding rules are not specified. You can present the problem
with specific encoding rules or stating that the encoding of a specific
UTM shall be used. Doing so reduces the space of possible solutions but
does not affect the solvability.

So the most common presentation is that encoding rules are a part of
the solution but including them in the problem does not make a significant difference.

(2) I am resolving the halting problem in a way that is
comparable to the way that ZFC resolved Russell's Paradox.

Problems shall be solved, not resolved. The expression "resolving
the halting problem" does not mean anything because the types of
the words are not compatible. A paradox is a different type so
it can be resolved.

It is iffy to say that ZFC solved Russell's Paradox because
it is not solving the original problem it is redefining the
basis of the problem.

Then don't say so. It would be better to say that ZFC (and before
it ZF and Z) avoids Russell's paradox.

--
Mikko

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

On 2024-11-01 12:22:17 +0000, olcott said:

On 11/1/2024 5:49 AM, Mikko wrote:

On 2024-10-31 12:36:21 +0000, olcott said:

On 10/31/2024 5:45 AM, Mikko wrote:

On 2024-10-30 12:24:13 +0000, olcott said:

On 10/30/2024 5:07 AM, Mikko wrote:

On 2024-10-29 13:56:19 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>>>>>> finite string description, the Halting Function itself always took a
Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider. >>>>>>>>>>> There are always been a distinction between the abstraction and the >>>>>>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts? >>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects
simulation out of hand:

We cannot find the answer by simulating the action of M on w, >>>>>>>>> say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in >>>>>>>> the observation that non-halting cannot be determied in finite time >>>>>>>> by a complete simulation so someting else is needed instead of or >>>>>>>> in addition to a partial simulation. Linz does include simulationg >>>>>>>> Turing machines in his proof that no Turing machine is a halt decider. >>>>>>>

To the best of my knowledge no one besides me ever came up with the >>>>>>> idea of making a simulating halt decider / emulating termination >>>>>>> analyzer.

Textboods may mention the idea but there is not much to say about it, >>>>>> only that it does not give a complete solution. Linz' proof covers >>>>>> all Turing machines. A simulating halt decider that is not a Turing >>>>>> machine is not interesting because there is no known way to make it. >>>>>

In other words you are saying that there is no such thing as a
UTM. Not a smart thing to say. embedded_H was adapted from a UTM.

I already said that you should not use the expression "In other wordw". >>>> It is not clear what you mean by it but you boviously don't mean what
the phrase really means.

The only way to verify mutual understanding is to
keep paraphrasing back and forth until there is
mutual agreement.

No. Asking about specific words and phrases is a more efficient way.
Making false statements about another topic is not useful.

A less effective way. Rounds of paraphrase resolve to
mutual understanding.

What makes you tink so? I have seen no convergence that way.

Anything else may never resolve.

Much depends on finding the right questions.

If my paraphrase is inaccurate then you must point
out the exact details of the inaccuracy.

What you said cannot be interpreted as a paraphrase.

In the above case you may be correct.

--
Mikko

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

On 2024-11-01 12:19:03 +0000, olcott said:

On 11/1/2024 5:42 AM, Mikko wrote:

On 2024-10-30 12:46:25 +0000, olcott said:

ZFC only resolved Russell's Paradox because it tossed out
the incoherent foundation of https://en.wikipedia.org/wiki/ Naive_set_theory

Actually Zermelo did it. The F and C are simply minor improvements on
other aspects of the theory.

Thus establishing the precedent that replacing the foundational
basis of a problem is a valid way to resolve that problem.

No, that does not follow. In particular, Russell's paradox is not a
problem, just an element of the proof that the naive set theory is inconsistent. The problem then is to construct a consistent set
theory. Zermelo proposed one set theory and ZF and ZFC are two other
proposals.

The foundation of all these theories is classical logic.

--
Mikko

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

On 2024-11-01 12:26:58 +0000, olcott said:

On 11/1/2024 5:58 AM, Mikko wrote:

On 2024-10-31 12:50:00 +0000, olcott said:

On 10/31/2024 5:49 AM, Mikko wrote:

On 2024-10-29 14:35:34 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>>>> finite string description, the Halting Function itself always took a >>>>>>>>>> Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider. >>>>>>>>> There are always been a distinction between the abstraction and the >>>>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects >>>>>>> simulation out of hand:

We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time >>>>>> by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg >>>>>> Turing machines in his proof that no Turing machine is a halt decider. >>>>>

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

- irrelevant

100% perfectly relevant within the philosophy of computation

Probably but not to anything quoted above.

*THE TITLE OF THIS THREAD*
[The philosophy of computation reformulates existing ideas on a new basis ---]

- couterfactual

You can baselessly claim that verified facts are counter-factual
you cannot show this.

Your statement was about a situation where "people fail to agree with
this and also fail to correctly point out any error". But that situation
has not happened as people have identified your errors (perhaps not all
but at least sufficiently many).

Inconsistent with the currently received view is
certainly not the slightest trace of any error when
examined within the philosophy of computation.

It has always seemed quite ridiculous to me that everyone
here consistently construes the currently received view
as inherently infallible.

The currently received view that if you are asked "What is 5 + 6?"
then only an answer that tells what 5 + 6 is is correct is infallible.

They call me stupid and ignorant for not accepting the currently
received view as inherently infallible.

You are stupid if you regard your own view as infallible. If you
regard something that has been tested and found good as infallible
then the risk of error can be small enough.

--
Mikko

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

On 2024-11-01 13:18:48 +0000, olcott said:

On 11/1/2024 6:08 AM, Mikko wrote:

On 2024-10-31 12:53:04 +0000, olcott said:

On 10/31/2024 5:55 AM, Mikko wrote:

On 2024-10-31 01:20:40 +0000, Mike Terry said:

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code
for HHH, so it needs to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating >>>>>>>>>>>>> DDD without knowing that it is emulating itself.

Then how did it convert the call HHH into an emulation of DDD again?

When HHH (unknowingly) emulates itself emulating DDD this >>>>>>>>>>> emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might
figure out that it is emulating an emulating decider, at which point it
knows that the decider might choose to abort its conditional emulation
to return, so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that if I don't
abort, it never will, and thus I am stuck, so I need to abort. >>>>>>>>>>

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE. >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801 >>>>>>>>>
*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly* >>>>>>>>> *or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

I read, reread again and again to make sure that my understanding >>>>>>>>> is correct. You seems to glance at a few words before spouting off a >>>>>>>>> canned rebuttal that does not even apply to my words.

No, it knows its own code because it rule for "No conditional branches"
excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs,
could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are just a lie,

PO definitely has a deep-rooted problem with his thinking here.

What PO does does not look like any thingking but more like what one
could expect from ChatgPPT or a similar AI.

I don't have the 50 years it would take for me to replicate the work of
AProVE: Non-Termination Witnesses for C Programs.

Doesn't matter. Even if you had you could not use it to prove your false
claim that there be some defect in some proof.

There has never ever been the least trace of error
in this verified fact:

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

No, but its relevance to Linz' proof is very thin.

When we do not construe the current received view as
inherently infallible then we can begin to consider
alternative view.

You can call a strawman deception (or an attempt of one) an altenative
view but it is still a strawman deception.

If naive set theory was construed as inherently infallible then
ZFC could have never resolved Russell's Paradox.

There is no point in construing an inconsistent theory as inherently infallible.

It really is not even any change to the view of deciders
to know that they compute the mapping from their finite
string input to their own accept or reject state on the
basis of a semantic or syntactic property of this string.

It does seems to be a change to how this semantic property
is string understood when applied to the halting problem proof.

The point is that a Turing machine can only compute syntactic properties.

Everyone here seems to think that the semantic property of
this finite string is not the actual behavior that this finite
string actually specifies.

In order to get a specification of anything the string must be
interpreted. A behaviour is not a finite string so a Turing machine
cannot see it.

Instead of the actual behavior they construe it as the idealized
behavior that would occur if DDD was not calling its own termination analyzer.

No, most participant of these discussions understand that the
halting problem asks about the actual behaviour of the actual
Turing machine with the actual input.

In other case what I am doing is called
isolating the independent variable.

You may call it that way. It does not look like that.

The program under test is DDD.
HHH is NOT the program under test it is the tester.

So far is good. But the halting problem demands that every Turng machine
can be put to the test.

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

It is not 100% impossible to construe this as the reject criteria.
It is merely unconventional.

More importan is whther it is correct. If a terminating computation
is rejected as non-terminating then at least one of the criteria is
incorrect.

--
Mikko

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

On 02/11/2024 08:43, Mikko wrote:

A false assertion is a lie even if nobody asserts it.

[PO:]

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

Disagree. There is a clear advantage in distinguishing those
who make [honest] mistakes from those who wilfully mislead. We all
make mistakes; that, of itself, does not make us all liars. Not only
is there the matter of intent, there is also a need for context. Many
claims [esp, but not only, in science] veer from truth to falsity to
truth again, depending on the then-current state of knowledge, or even
the then-current state of public opinion. It would be daft if we all
had to qualify /everything/ we said by "I believe ..." to make it true
even if what I believe turns out to be false.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Lysberg

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

Am Sat, 02 Nov 2024 07:24:29 -0500 schrieb olcott:

On 11/2/2024 5:35 AM, Mikko wrote:

On 2024-11-01 13:18:48 +0000, olcott said:

On 11/1/2024 6:08 AM, Mikko wrote:

On 2024-10-31 12:53:04 +0000, olcott said:

On 10/31/2024 5:55 AM, Mikko wrote:

On 2024-10-31 01:20:40 +0000, Mike Terry said:

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

I read, reread again and again to make sure that my
understanding is correct. You seems to glance at a few words >>>>>>>>>>> before spouting off a canned rebuttal that does not even apply >>>>>>>>>>> to my words.

Comedy gold.

No, it knows its own code because it rule for "No conditional >>>>>>>>>> branches" excludes that code.

It does not know its own code. It merely knows that the machine >>>>>>>>> address that it is looking at belongs to the operating system. I >>>>>>>>> simply don't have the fifty labor years that AProVE:
Non-Termination Witnesses for C Programs,
could spend on handling conditional branches.
The stupid aspect on your part is that even knowing that its own >>>>>>>>> code halts THIS HAS NOTHING TO DO WITH DDD REACHING TS OWN
RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are >>>>>>>> just a lie,

PO definitely has a deep-rooted problem with his thinking here.

What PO does does not look like any thingking but more like what
one could expect from ChatgPPT or a similar AI.

I don't have the 50 years it would take for me to replicate the work >>>>> of AProVE: Non-Termination Witnesses for C Programs.

Doesn't matter. Even if you had you could not use it to prove your
false claim that there be some defect in some proof.

There has never ever been the least trace of error in this verified
fact:
DDD emulated by HHH according to the semantics of the x86 language
cannot possibly reach its own "return" instruction whether or not any
HHH ever aborts its emulation of DDD.

No, but its relevance to Linz' proof is very thin.

When the main motive of people like Richard is to derail any chance of
mutual agreement I cannot proceed with all of the steps achieving mutual agreement on each step one at a time in their mandatory prerequisite
order.

Block him then?
You don't need to go in order.

When we do not construe the current received view as inherently
infallible then we can begin to consider alternative view.

You can call a strawman deception (or an attempt of one) an altenative
view but it is still a strawman deception.

THE FREAKING SUBJECT OF THE FREAKING THREAD IS THE PHILOSOPHY OF
COMPUTATION.

No, the subject is that halting is undecidable.

If naive set theory was construed as inherently infallible then ZFC
could have never resolved Russell's Paradox.

There is no point in construing an inconsistent theory as inherently
infallible.

None-the-less everyone here continues to do that. Everyone here takes
the current received view on the theory of computation is if it came
directly from God himself. They cannot begin to imagine the tiniest
little trace of any error what-so-ever in the current received view.

Projecting much?

It really is not even any change to the view of deciders to know that
they compute the mapping from their finite string input to their own
accept or reject state on the basis of a semantic or syntactic
property of this string.

It does seems to be a change to how this semantic property is string
understood when applied to the halting problem proof.

The point is that a Turing machine can only compute syntactic
properties.

No that is not the actual point. That is only the current received view
not an infallible ruling. Rice's theorem is accepted as true. That is
not the same as it actually being true.

From what I recall Rice can always be reduced to the HP.

This means refuting the HP proofs can be construed as refuting Rice.

Getting into heady heights here.

Everyone here seems to think that the semantic property of this finite
string is not the actual behavior that this finite string actually
specifies.

In order to get a specification of anything the string must be
interpreted.

Thus when HHH is a C interpreter both HHH and DDD eventually crash due
to out-of-memory error.

Finite memory means it is not Turing-complete.

A behaviour is not a finite string so a Turing machine cannot see it.

[...] this UTM can see the behavior specified by
the string as a subset of its own state transitions.

A UTM does not abort.

Instead of the actual behavior they construe it as the idealized
behavior that would occur if DDD was not calling its own termination
analyzer.

No, most participant of these discussions understand that the halting
problem asks about the actual behaviour of the actual Turing machine
with the actual input.

We are still miles away from beginning to talk about the halting
problem. We must first establish mutual agreement on this.

I'd rather hear about the halting problem. I'm reluctant to agree to
your unknown reasoning up front, because you will represent it as
proof you must be right. I can agree to this first step later and
then I will have agreed to everything else.

In other case what I am doing is called isolating the independent
variable.

You may call it that way. It does not look like that.

The program under test is DDD.
HHH is NOT the program under test it is the tester.

So far is good. But the halting problem demands that every Turng
machine can be put to the test.

It is not 100% impossible to construe this as the reject criteria. It
is merely unconventional.

More importan is whther it is correct. If a terminating computation is
rejected as non-terminating then at least one of the criteria is
incorrect.

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.

The actual behaviour that the code of DDD specifies differs from what
your "decider" returns.

HHH1 does compute the mapping from its input DDD to the actual behavior
that DDD specifies and this DOES NOT INCLUDE HHH1 emulating itself
emulating DDD.

Then DDD is a different program being given the same name, but not the
same code - that of the program which simulates it.
DDD(){HHH(DDD);} is different from EEE(){HHH1(EEE);}.

It seems ridiculously stupid for everyone here to simply ignore how pathological self-reference DOES IN FACT change the behavior of DDD.

One program = one behaviour.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Sat, 02 Nov 2024 06:19:49 -0500 schrieb olcott:

On 11/2/2024 3:43 AM, Mikko wrote:

On 2024-11-01 12:10:41 +0000, olcott said:

On 11/1/2024 5:40 AM, Mikko wrote:

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

So, are you willing to state that you are admitting that nothing >>>>>>>> you might come up with has any bearing on the original halting >>>>>>>> problem because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem as not >>>>>>> applying to the behavior actually specified by the actual input
finite string.

Which is just a lie, so you are just admitting to not knowing what >>>>>> the facts are.

It can't possibly be a lie because I am not even asserting it as a
truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

Not at all. The base meaning of {lie} requires intentional deception.

That may be its base meaning but the full meaning includes all false
statements. The statement itself does not change when someone states it
so there is no clear advantage in saying that the statement was not a
lie until someone stated it.

It is also deceptive to call a statement {false} when you really only
mean that the statement is inconsistent with the current received view
and not false in every sense.
In this case the most honest thing to say is X is not the way that most experts look at it. X is not a lie and X is not even false.

It is also deceptive to call a statement true when you really only
mean that there might be a sense in which it is, without telling.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 11/2/24 6:21 AM, Andy Walker wrote:

On 02/11/2024 08:43, Mikko wrote:

A false assertion is a lie even if nobody asserts it.

[PO:]

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

    Disagree.  There is a clear advantage in distinguishing those
who make [honest] mistakes from those who wilfully mislead.  We all
make mistakes;  that, of itself, does not make us all liars.  Not only
is there the matter of intent, there is also a need for context.  Many claims [esp, but not only, in science] veer from truth to falsity to
truth again, depending on the then-current state of knowledge, or even
the then-current state of public opinion.  It would be daft if we all
had to qualify /everything/ we said by "I believe ..." to make it true
even if what I believe turns out to be false.

But apparently not so much as to create a new word that means just that.

Note, in Science, it is ESPECIALLY important to distinguish what is know
to be factual and what is just supposition and assumption.

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

On 11/2/24 9:35 AM, olcott wrote:

On 11/2/2024 8:18 AM, joes wrote:

Am Sat, 02 Nov 2024 06:19:49 -0500 schrieb olcott:

On 11/2/2024 3:43 AM, Mikko wrote:

On 2024-11-01 12:10:41 +0000, olcott said:

On 11/1/2024 5:40 AM, Mikko wrote:

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

So, are you willing to state that you are admitting that nothing >>>>>>>>>> you might come up with has any bearing on the original halting >>>>>>>>>> problem because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem as not >>>>>>>>> applying to the behavior actually specified by the actual input >>>>>>>>> finite string.

Which is just a lie, so you are just admitting to not knowing what >>>>>>>> the facts are.

It can't possibly be a lie because I am not even asserting it as a >>>>>>> truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

Not at all. The base meaning of {lie} requires intentional deception. >>>> That may be its base meaning but the full meaning includes all false

statements. The statement itself does not change when someone states it >>>> so there is no clear advantage in saying that the statement was not a
lie until someone stated it.

It is also deceptive to call a statement {false} when you really only
mean that the statement is inconsistent with the current received view
and not false in every sense.
In this case the most honest thing to say is X is not the way that most
experts look at it. X is not a lie and X is not even false.

It is also deceptive to call a statement true when you really only
mean that there might be a sense in which it is, without telling.

It is true that HHH correctly rejects DDD as non-halting
on the basis that DDD emulated by HHH cannot possibly
reach its own return instruction.

No, as has been explained, you are using an equivocation, so, until your
start saying non-PO-halting, so you can define a new meaning for
halting, the only HHH that answers is an HHH that only partially
emulates the input, and partial emulation do not show actual non-halting behavior.

Since the ACTUAL behavior of the DDD that HHH emulated will reach that
final return instuction, and the partial-emulation that HHH does of DDD
doesn't define non-halting, you statement is just false and based on an incorrect meaning tried to be assigned by equivocation.

THe fact that this concept is foreign to you, just shows how little you understand the fields you are talking about, and that you have no
problems lying about what they say because you have made yourself into a pathological liar that can't understand the difference between truth and falsehood.

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

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

When the main motive of people like Richard is to derail
any chance of mutual agreement I cannot proceed with all
of the steps achieving mutual agreement on each step one
at a time in their mandatory prerequisite order.

No, my "motive" is to hold cranks to the truth, or at least get them
to admit that they are off in some other system, that they can define.

You keep on wanting to be in the system (since it provides the proof
of the things you don't like) but can't hold yourself to actually be
in the system.

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping
[000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Equivocation between looking at the behavor of DDD being the actual
program (which include a particular version of HHH) and the behavior
of a PARTIAL emulation of DDD by HHH, which ends up not having the
property you want to show.

Partial doesn't lead to showing never.

In other words you continue to perpetually insist on
the ridiculously stupid idea of requiring the complete
emulation of a non-terminating input.

I don't think this is: stupidity, ignorance, ADD.
I don't know what this leaves besides dishonesty with malice.

No, you just need to know the RESULTS of the emulation of the input even
if you emulate it for an unlimited number of steps. You don't need to
actually do it if you can prove what it would be.

Of course, that is for this exact input, which uses the copy of H that
does abort and return.

That is the DEFINITION of a semantic property, the FINAL results of the execution (or complete emulation) of the program described by the input.

Something you new system doesn't seem to be able to handle.

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

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

When the main motive of people like Richard is to derail
any chance of mutual agreement I cannot proceed with all
of the steps achieving mutual agreement on each step one
at a time in their mandatory prerequisite order.

No, my "motive" is to hold cranks to the truth, or at least get them
to admit that they are off in some other system, that they can define. >>>>
You keep on wanting to be in the system (since it provides the proof
of the things you don't like) but can't hold yourself to actually be
in the system.

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping
[000020b3] c3         ret           ; never gets here >>>>> Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Equivocation between looking at the behavor of DDD being the actual
program (which include a particular version of HHH) and the behavior
of a PARTIAL emulation of DDD by HHH, which ends up not having the
property you want to show.

Partial doesn't lead to showing never.

In other words you continue to perpetually insist on
the ridiculously stupid idea of requiring the complete
emulation of a non-terminating input.

I don't think this is: stupidity, ignorance, ADD.
I don't know what this leaves besides dishonesty with malice.

No, you just need to know the RESULTS of the emulation of the input
even if you emulate it for an unlimited number of steps.

Yes

So, you agree that the results of only the partial emulation done by HHH doesn't define the answer, only that of the infinte emulation OF THIS
EXACT INPUT, defines the behavior, as shown by HHH1(DDD) which shows it
halts.

You don't need to actually do it if you can prove what it would be.

*Yes and ChatGPT agrees*

<ChatGPT>
  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.
</ChatGPT>

https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2

Just admitmits that HHH gets the wrong answer, because you lied, because
the HHH that DDD calls will also abort and return to DDD, so DDD would halt.

Remember, you AGREED above that it is the behavior of the INFINITE
emulation, not the finite emulation of HHH defines the answer.

Of course, that is for this exact input, which uses the copy of H that
does abort and return.

No it is not.
<ChatGPT>
  when HHH simulates DDD(), it's analyzing an
  "idealized" version of DDD() where nothing
  stops the recursion.
</ChatGPT>

In other words you are admitting that it isn't actually looking at the
input it was given.

In other words, you are just lying about what you are doing.

DDD calls the HHH that aborts, not the idealized one, and thus your
arguement ADMITS it is just lying.

That is the DEFINITION of a semantic property, the FINAL results of
the execution (or complete emulation) of the program described by the
input.

Something you new system doesn't seem to be able to handle.

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

On 11/2/24 8:38 PM, olcott wrote:

On 11/2/2024 7:21 PM, Richard Damon wrote:

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

When the main motive of people like Richard is to derail
any chance of mutual agreement I cannot proceed with all
of the steps achieving mutual agreement on each step one
at a time in their mandatory prerequisite order.

No, my "motive" is to hold cranks to the truth, or at least get
them to admit that they are off in some other system, that they
can define.

You keep on wanting to be in the system (since it provides the
proof of the things you don't like) but can't hold yourself to
actually be in the system.

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping >>>>>>> [000020b3] c3         ret           ; never gets here >>>>>>> Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Equivocation between looking at the behavor of DDD being the
actual program (which include a particular version of HHH) and the >>>>>> behavior of a PARTIAL emulation of DDD by HHH, which ends up not
having the property you want to show.

Partial doesn't lead to showing never.

In other words you continue to perpetually insist on
the ridiculously stupid idea of requiring the complete
emulation of a non-terminating input.

I don't think this is: stupidity, ignorance, ADD.
I don't know what this leaves besides dishonesty with malice.

No, you just need to know the RESULTS of the emulation of the input
even if you emulate it for an unlimited number of steps.

Yes

So, you agree that the results of only the partial emulation done by
HHH doesn't define the answer, only that of the infinte emulation OF
THIS EXACT INPUT, defines the behavior, as shown by HHH1(DDD) which
shows it halts.

You don't need to actually do it if you can prove what it would be.

*Yes and ChatGPT agrees*

<ChatGPT>
   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.
</ChatGPT>

https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2

Just admitmits that HHH gets the wrong answer, because you lied,
because the HHH that DDD calls will also abort and return to DDD, so
DDD would halt.

Remember, you AGREED above that it is the behavior of the INFINITE
emulation, not the finite emulation of HHH defines the answer.

A termination analyzer / halt decider must PREDICT
non terminating behavior not measure it.

If a termination analyzer / halt decider MEASURES
non-terminating behavior IT CANNOT REPORT THIS.

Of course, that is for this exact input, which uses the copy of H
that does abort and return.

No it is not.
<ChatGPT>
   when HHH simulates DDD(), it's analyzing an
   "idealized" version of DDD() where nothing
   stops the recursion.
</ChatGPT>

In other words you are admitting that it isn't actually looking at the
input it was given.

ChatGPT (using its own words) and I both agree that HHH
is supposed to predict the behavior of the infinite
emulation on the basis of its finite emulation.

Yes, but that behavior is DEFINED by the actual behavior of the actual
machine.

Only a knucklehead would think that HHH is supposed
to actually measure infinite behavior.

But it needs to actually prove that it would occur before it can claim it.

Your problem is you think it is ok to LIE if that is the best you know.

In other words, you are just lying about what you are doing.

DDD calls the HHH that aborts, not the idealized one, and thus your
arguement ADMITS it is just lying.

That is the DEFINITION of a semantic property, the FINAL results of
the execution (or complete emulation) of the program described by
the input.

Something you new system doesn't seem to be able to handle.

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

On 11/2/24 9:00 PM, olcott wrote:

On 11/2/2024 7:52 PM, Richard Damon wrote:

On 11/2/24 8:38 PM, olcott wrote:

On 11/2/2024 7:21 PM, Richard Damon wrote:

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

When the main motive of people like Richard is to derail
any chance of mutual agreement I cannot proceed with all
of the steps achieving mutual agreement on each step one
at a time in their mandatory prerequisite order.

No, my "motive" is to hold cranks to the truth, or at least get >>>>>>>> them to admit that they are off in some other system, that they >>>>>>>> can define.

You keep on wanting to be in the system (since it provides the >>>>>>>> proof of the things you don't like) but can't hold yourself to >>>>>>>> actually be in the system.

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[000020a2] 55         push ebp      ; housekeeping >>>>>>>>> [000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping >>>>>>>>> [000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Equivocation between looking at the behavor of DDD being the
actual program (which include a particular version of HHH) and >>>>>>>> the behavior of a PARTIAL emulation of DDD by HHH, which ends up >>>>>>>> not having the property you want to show.

Partial doesn't lead to showing never.

In other words you continue to perpetually insist on
the ridiculously stupid idea of requiring the complete
emulation of a non-terminating input.

I don't think this is: stupidity, ignorance, ADD.
I don't know what this leaves besides dishonesty with malice.

No, you just need to know the RESULTS of the emulation of the
input even if you emulate it for an unlimited number of steps.

Yes

So, you agree that the results of only the partial emulation done by
HHH doesn't define the answer, only that of the infinte emulation OF
THIS EXACT INPUT, defines the behavior, as shown by HHH1(DDD) which
shows it halts.

You don't need to actually do it if you can prove what it would be. >>>>>>

*Yes and ChatGPT agrees*

<ChatGPT>
   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.
</ChatGPT>

https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2

Just admitmits that HHH gets the wrong answer, because you lied,
because the HHH that DDD calls will also abort and return to DDD, so
DDD would halt.

Remember, you AGREED above that it is the behavior of the INFINITE
emulation, not the finite emulation of HHH defines the answer.

A termination analyzer / halt decider must PREDICT
non terminating behavior not measure it.

If a termination analyzer / halt decider MEASURES
non-terminating behavior IT CANNOT REPORT THIS.

Of course, that is for this exact input, which uses the copy of H
that does abort and return.

No it is not.
<ChatGPT>
   when HHH simulates DDD(), it's analyzing an
   "idealized" version of DDD() where nothing
   stops the recursion.
</ChatGPT>

In other words you are admitting that it isn't actually looking at
the input it was given.

ChatGPT (using its own words) and I both agree that HHH
is supposed to predict the behavior of the infinite
emulation on the basis of its finite emulation.

Yes, but that behavior is DEFINED by the actual behavior of the actual
machine.

No it is not. It is never based on the actual behavior
of the actual machine for any non-terminating inputs.

Then you don't undetstand the requirement for something to be a semantic property.

It has only ever been based on what this input would do
if its simulation was never aborted.

Right, which will be exactly what the input will do when run.

It also means not by changing the copy of the decider the input calls,
as then it its the input it was given.

If you want to change these properties, you need to first fully define
what you mean by the terms, and show they still meet the basic
requirement needed for this things.

Only a knucklehead would think that HHH is supposed
to actually measure infinite behavior.

But it needs to actually prove that it would occur before it can claim
it.

In other words that fact that DDD emulated by HHH would never
stop running unless aborted is over your head?

But since the HHH that DDD calls DOES aborr, that is a vacous statement.

The unaborted emulation of the input given to HHH will reach a final
state it HHH aborts its emulation, and thus gives up its claim to be
defining the semantic property.

I can see this, Ben can see this and ChatGPT understands it
so well that it can use entirely different words to explain
exactly how it sees this.

Nope, If you look carefully at what Ben agreed to was if you define the NON-SEMANTIC property that you have been trying to define, your decider
can be a correct POOP decider. (of course, you can't look that closely
as you don't undetstand what you have been talking about).

He NEVER agree that your decider was a correct Halt Decider.

Your problem is you think it is ok to LIE if that is the best you know.

In other words, you are just lying about what you are doing.

DDD calls the HHH that aborts, not the idealized one, and thus your
arguement ADMITS it is just lying.

That is the DEFINITION of a semantic property, the FINAL results
of the execution (or complete emulation) of the program described
by the input.

Something you new system doesn't seem to be able to handle.

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

On 11/2/24 9:33 PM, olcott wrote:

On 11/2/2024 8:22 PM, Richard Damon wrote:

On 11/2/24 9:00 PM, olcott wrote:

On 11/2/2024 7:52 PM, Richard Damon wrote:

On 11/2/24 8:38 PM, olcott wrote:

On 11/2/2024 7:21 PM, Richard Damon wrote:

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

When the main motive of people like Richard is to derail >>>>>>>>>>> any chance of mutual agreement I cannot proceed with all >>>>>>>>>>> of the steps achieving mutual agreement on each step one >>>>>>>>>>> at a time in their mandatory prerequisite order.

No, my "motive" is to hold cranks to the truth, or at least >>>>>>>>>> get them to admit that they are off in some other system, that >>>>>>>>>> they can define.

You keep on wanting to be in the system (since it provides the >>>>>>>>>> proof of the things you don't like) but can't hold yourself to >>>>>>>>>> actually be in the system.

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[000020a2] 55         push ebp      ; housekeeping >>>>>>>>>>> [000020a3] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping >>>>>>>>>>> [000020b2] 5d         pop ebp       ; housekeeping >>>>>>>>>>> [000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86 >>>>>>>>>>> language cannot possibly reach its own "return" instruction >>>>>>>>>>> whether or not any HHH ever aborts its emulation of DDD.

Equivocation between looking at the behavor of DDD being the >>>>>>>>>> actual program (which include a particular version of HHH) and >>>>>>>>>> the behavior of a PARTIAL emulation of DDD by HHH, which ends >>>>>>>>>> up not having the property you want to show.

Partial doesn't lead to showing never.

In other words you continue to perpetually insist on
the ridiculously stupid idea of requiring the complete
emulation of a non-terminating input.

I don't think this is: stupidity, ignorance, ADD.
I don't know what this leaves besides dishonesty with malice. >>>>>>>>>

No, you just need to know the RESULTS of the emulation of the
input even if you emulate it for an unlimited number of steps.

Yes

So, you agree that the results of only the partial emulation done
by HHH doesn't define the answer, only that of the infinte
emulation OF THIS EXACT INPUT, defines the behavior, as shown by
HHH1(DDD) which shows it halts.

You don't need to actually do it if you can prove what it would be. >>>>>>>>

*Yes and ChatGPT agrees*

<ChatGPT>
   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.
</ChatGPT>

https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2

Just admitmits that HHH gets the wrong answer, because you lied,
because the HHH that DDD calls will also abort and return to DDD,
so DDD would halt.

Remember, you AGREED above that it is the behavior of the INFINITE >>>>>> emulation, not the finite emulation of HHH defines the answer.

A termination analyzer / halt decider must PREDICT
non terminating behavior not measure it.

If a termination analyzer / halt decider MEASURES
non-terminating behavior IT CANNOT REPORT THIS.

Of course, that is for this exact input, which uses the copy of >>>>>>>> H that does abort and return.

No it is not.
<ChatGPT>
   when HHH simulates DDD(), it's analyzing an
   "idealized" version of DDD() where nothing
   stops the recursion.
</ChatGPT>

In other words you are admitting that it isn't actually looking at >>>>>> the input it was given.

ChatGPT (using its own words) and I both agree that HHH
is supposed to predict the behavior of the infinite
emulation on the basis of its finite emulation.

Yes, but that behavior is DEFINED by the actual behavior of the
actual machine.

No it is not. It is never based on the actual behavior
of the actual machine for any non-terminating inputs.

Then you don't undetstand the requirement for something to be a
semantic property.

The actual behavior specified by the finite string input
to HHH does include HHH emulating itself emulating DDD
such that this DD *not some other DDD somewhere else*
cannot possibly reach its own "return" instruction
whether HHH emulates DDD forever or some finite number
of times.

But, since the HHH that DDD calls DOES abort its emulation, that logic
is INVALID.

We know it does, since you claim it it correct to do so.

So, either you are lying that it does it to be correct, or you are lying
that DDD doesn't call THAT HHH, or you are lying that the input DDD even
HAS the property of halting, as that only applies to PROGRAMS, which
require it to have ALL the code used, and thus the input DDD includes
the code of HHH, so you can't change it.

It has only ever been based on what this input would do
if its simulation was never aborted.

Right, which will be exactly what the input will do when run.

It also means not by changing the copy of the decider the input calls,
as then it its the input it was given.

If you want to change these properties, you need to first fully define
what you mean by the terms, and show they still meet the basic
requirement needed for this things.

Only a knucklehead would think that HHH is supposed
to actually measure infinite behavior.

But it needs to actually prove that it would occur before it can
claim it.

In other words that fact that DDD emulated by HHH would never
stop running unless aborted is over your head?

But since the HHH that DDD calls DOES aborr, that is a vacous statement.

The unaborted emulation of the input given to HHH will reach a final
state it HHH aborts its emulation, and thus gives up its claim to be
defining the semantic property.

I can see this, Ben can see this and ChatGPT understands it
so well that it can use entirely different words to explain
exactly how it sees this.

Nope, If you look carefully at what Ben agreed to was if you define
the NON-SEMANTIC property that you have been trying to define, your
decider can be a correct POOP decider. (of course, you can't look that
closely as you don't undetstand what you have been talking about).

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

I don't think that is the shell game.  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.

Right, he is pointing out that your NON-PROGRAM P, (since the input
doesn't include the code for H) forms a template with H that creates a
result that P will not halt unless H aborts.

Since the Halting problem is about Programs, and not Non-Programs, it
doesn't say anything about the real halting problem.

The semantic property of this finite string does specify
that HHH must emulate itself emulating DDD.

And, since HHH fails to do that, it can't use its own simulation as a
measure of the real halting property, so either HHH just isn't a halt
decider.

If your requriement is that HHH is defined to emulate DDD to determine
its behavior, it just isn't allowed to abort its emulation until that
behavior has been correctly determined. And, if HHH aborts its
emulation, that behavior depends on what DDD does after HHH returns to
it, so it can't know by your algorithm, and thus to meet your stated requirement, your HHH just isn't allowed to abort its emulation.

Since HHH doesn't meet the stated requirements for your HHH, your logic
is just a LIE.

Remember, a semantic property is based on the determination of the
actual final behavior of that input (not the results of an aborted
emulation), thus if HHH does abort it emulation, the semantic property
is what happens with that exact same input (and thus the exact same code
of HHH that did that aborting) given to a complete emulator, (like
HHH1), which shows that the input WILL halt, therefore HHH was wrong to
abort, and thus failed to meet its requirements.

The direct execution of DDD DOES NOT SPECIFY THAT.

Sure it does. HHH must do what HHH does. That is the requirement in both
cases. It requires that the HHH that it calls do EXACTLY the same thing
as the HHH that looked at it, and conversly, the HHH that is analysing
this input needs to treat the call to itself as behaving like it will,
even if it doesn't realize it is actually itself.

Thus, your "rule" that tries to detect infinite recursion is incorrect,
as it has a false positive when HHH thinks that the HHH that it is
emulating will not return, when the correct (and thus complete)
emulation of that code shows that it will.

He NEVER agree that your decider was a correct Halt Decider.

*He did agree that H does meet the first half of this criteria*

Nope, because here D is a program, and thus includes the code for H, so
the H that aborts can't claim that its D is non-halting.

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

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

On 2024-11-02 10:21:09 +0000, Andy Walker said:

On 02/11/2024 08:43, Mikko wrote:

A false assertion is a lie even if nobody asserts it.

[PO:]

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

Disagree. There is a clear advantage in distinguishing those
who make [honest] mistakes from those who wilfully mislead.

That is not a disagreement.

--
Mikko

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

On 2024-11-02 13:35:57 +0000, olcott said:

On 11/2/2024 8:18 AM, joes wrote:

Am Sat, 02 Nov 2024 06:19:49 -0500 schrieb olcott:

On 11/2/2024 3:43 AM, Mikko wrote:

On 2024-11-01 12:10:41 +0000, olcott said:

On 11/1/2024 5:40 AM, Mikko wrote:

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

So, are you willing to state that you are admitting that nothing >>>>>>>>>> you might come up with has any bearing on the original halting >>>>>>>>>> problem because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem as not >>>>>>>>> applying to the behavior actually specified by the actual input >>>>>>>>> finite string.

Which is just a lie, so you are just admitting to not knowing what >>>>>>>> the facts are.

It can't possibly be a lie because I am not even asserting it as a >>>>>>> truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

Not at all. The base meaning of {lie} requires intentional deception. >>>> That may be its base meaning but the full meaning includes all false

statements. The statement itself does not change when someone states it >>>> so there is no clear advantage in saying that the statement was not a
lie until someone stated it.

It is also deceptive to call a statement {false} when you really only
mean that the statement is inconsistent with the current received view
and not false in every sense.
In this case the most honest thing to say is X is not the way that most
experts look at it. X is not a lie and X is not even false.

It is also deceptive to call a statement true when you really only
mean that there might be a sense in which it is, without telling.

It is true that HHH correctly rejects DDD as non-halting
on the basis that DDD emulated by HHH cannot possibly
reach its own return instruction.

The word "correctly" is not a part of a truth but depends on comparison
to something unspecified.

--
Mikko

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

On 2024-11-02 11:19:49 +0000, olcott said:

On 11/2/2024 3:43 AM, Mikko wrote:

On 2024-11-01 12:10:41 +0000, olcott said:

On 11/1/2024 5:40 AM, Mikko wrote:

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>>>>>>>> less than 10 minutes. Do you think he read the material before >>>>>>>>>>>>> responding? A good troll would have waited a few hours before >>>>>>>>>>>>> answering.

    I doubt whether Peter is either a moron or a troll. >>>>>>>>>>> Does it really matter? If he falsely pretends to be a moron or a liar

I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways!
Entirely personally, I see no reason to do so in any case.  He is quite
often impolite in response to being called a "stupid liar" or similar,
but that's understandable.  He is no worse than many a student in terms
of what he comprehends;  his fault lies in [apparently] believing that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you >>>>>>>> might come up with has any bearing on the original halting problem >>>>>>>> because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

Which is just a lie, so you are just admitting to not knowing what the >>>>>> facts are.

It can't possibly be a lie because I am not even asserting
it as a truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

It is deception to apply the term {lie} to any expression
of language without qualifying that {intentional deception}
it not meant only {falsity} is meant.

In order to say anything about intention one must say something
obout something other than the statement itself: the author of
the statement. To require that a sentence of the form X is Y
shall be interpreted as an assertion about something other than
X is not reasonable semantics. Of course natural language
semantics is often far from reasonable when the purpose is
other than serious discussion.

--
Mikko

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

On 2024-11-02 11:30:09 +0000, olcott said:

On 11/2/2024 4:01 AM, Mikko wrote:

On 2024-11-01 12:03:24 +0000, olcott said:

On 11/1/2024 5:37 AM, Mikko wrote:

On 2024-10-31 23:43:41 +0000, olcott said:

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your message in >>>>>>>>>>> less than 10 minutes. Do you think he read the material before >>>>>>>>>>> responding? A good troll would have waited a few hours before >>>>>>>>>>> answering.

    I doubt whether Peter is either a moron or a troll. >>>>>>>>> Does it really matter? If he falsely pretends to be a moron or a liar >>>>>>>>> I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of these ways!
Entirely personally, I see no reason to do so in any case.  He is quite
often impolite in response to being called a "stupid liar" or similar, >>>>>>>> but that's understandable.  He is no worse than many a student in terms
of what he comprehends;  his fault lies in [apparently] believing that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that nothing you >>>>>> might come up with has any bearing on the original halting problem >>>>>> because you are working in a new framework?

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

The finite strings specifying the behaviour are not a part
of the halting problem. Any solution is required to contain
encoding rules for the creation of those strings.

Sure they are.

It is of course possible to present the problem in either way without
changing anything important. The most common way is to state that the
decider shall use descriptions of the Turing machine and the input
but the encoding rules are not specified. You can present the problem
with specific encoding rules or stating that the encoding of a specific
UTM shall be used. Doing so reduces the space of possible solutions but
does not affect the solvability.

So the most common presentation is that encoding rules are a part of
the solution but including them in the problem does not make a significant >> difference.

(2) I am resolving the halting problem in a way that is
comparable to the way that ZFC resolved Russell's Paradox.

Problems shall be solved, not resolved. The expression "resolving
the halting problem" does not mean anything because the types of
the words are not compatible. A paradox is a different type so
it can be resolved.

It is iffy to say that ZFC solved Russell's Paradox because
it is not solving the original problem it is redefining the
basis of the problem.

Then don't say so. It would be better to say that ZFC (and before
it ZF and Z) avoids Russell's paradox.

It really is not even any change to the view of deciders to
know that they compute the mapping from their finite string
input to their own accept or reject state on the basis of a
semantic or syntactic property of this string.

My view does seems to be a change to how this semantic property
is string understood when applied to the halting problem proof.

It is not about how a preperty is understood but about the choice
of a property for discussion.

--
Mikko

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

On 2024-11-02 12:46:47 +0000, olcott said:

On 11/2/2024 5:49 AM, Mikko wrote:

On 2024-11-01 12:26:58 +0000, olcott said:

On 11/1/2024 5:58 AM, Mikko wrote:

On 2024-10-31 12:50:00 +0000, olcott said:

On 10/31/2024 5:49 AM, Mikko wrote:

On 2024-10-29 14:35:34 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>>>>>> finite string description, the Halting Function itself always took a
Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider. >>>>>>>>>>> There are always been a distinction between the abstraction and the >>>>>>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts? >>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects
simulation out of hand:

We cannot find the answer by simulating the action of M on w, >>>>>>>>> say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in >>>>>>>> the observation that non-halting cannot be determied in finite time >>>>>>>> by a complete simulation so someting else is needed instead of or >>>>>>>> in addition to a partial simulation. Linz does include simulationg >>>>>>>> Turing machines in his proof that no Turing machine is a halt decider. >>>>>>>

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

- irrelevant

100% perfectly relevant within the philosophy of computation

Probably but not to anything quoted above.

*THE TITLE OF THIS THREAD*
[The philosophy of computation reformulates existing ideas on a new basis ---]

- couterfactual

You can baselessly claim that verified facts are counter-factual
you cannot show this.

Your statement was about a situation where "people fail to agree with
this and also fail to correctly point out any error". But that situation >>>> has not happened as people have identified your errors (perhaps not all >>>> but at least sufficiently many).

Inconsistent with the currently received view is
certainly not the slightest trace of any error when
examined within the philosophy of computation.

It has always seemed quite ridiculous to me that everyone
here consistently construes the currently received view
as inherently infallible.

The currently received view that if you are asked "What is 5 + 6?"
then only an answer that tells what 5 + 6 is is correct is infallible.

This is simple enough that people cannot be confused.
That 5 + 6 == 11 does seem infallibly true.

They call me stupid and ignorant for not accepting the currently
received view as inherently infallible.

You are stupid if you regard your own view as infallible. If you
regard something that has been tested and found good as infallible
then the risk of error can be small enough.

I have known that equating believable with true is an error
a great consequence ever since I was 14.

It seems clear that halt deciders must compute the mapping
from their input finite strings to the actual behavior
specified by these finite strings.

It is true that when we construe the halting criteria as
requiring taking into account how a pathological relationship
changes the behavior of the input instead of simply ignoring
this behavior change that pathological inputs become decidable
as non-halting.

--
Mikko

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

On 2024-11-02 11:43:02 +0000, olcott said:

On 11/2/2024 4:09 AM, Mikko wrote:

On 2024-11-01 12:19:03 +0000, olcott said:

On 11/1/2024 5:42 AM, Mikko wrote:

On 2024-10-30 12:46:25 +0000, olcott said:

ZFC only resolved Russell's Paradox because it tossed out
the incoherent foundation of https://en.wikipedia.org/wiki/ Naive_set_theory

Actually Zermelo did it. The F and C are simply minor improvements on
other aspects of the theory.

Thus establishing the precedent that replacing the foundational
basis of a problem is a valid way to resolve that problem.

No, that does not follow. In particular, Russell's paradox is not a
problem, just an element of the proof that the naive set theory is
inconsistent. The problem then is to construct a consistent set
theory. Zermelo proposed one set theory and ZF and ZFC are two other
proposals.

My view is that the same kind of self-reference issue that
showed naive set theory was inconsistent also shows that the
current notion of a formal system is inconsistent.

From the proof of the exstence of Russell's set it is easy
to prove that 1 = 2. As long as no proof of 1 = 2 from a
self-reference in a formal system is shown there is no
reason to think that such system is inconsisten. And the
existence of insonstent formal systems does not mean that
the notion of a formal system is inconsistent.

When we handle this self-reference differently then this issue
is resolved.

No proof ot that, either.

When a formal system is ONLY a sequence of truth preserving
operations applied to a consistent set of expressions that
have been stipulated to be true then expressions that would
otherwise show incompleteness are rejected because they have
no path to true or false.

The foundation of all these theories is classical logic.

The key error of classical logic is that it diverged from the
model of the syllogism where there is always a path to true or
false or the syllogism is ill-formed.

Classical logic does not substantially diverge from the model of
syllogism. It iextends it for situations that cannot be covered
with syllogistic logic. Presentational differences follow mainly
from the needs of the additional coverage.

No error has been shown in classical logic.

--
Mikko

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

On 2024-11-02 12:46:47 +0000, olcott said:

On 11/2/2024 5:49 AM, Mikko wrote:

On 2024-11-01 12:26:58 +0000, olcott said:

On 11/1/2024 5:58 AM, Mikko wrote:

On 2024-10-31 12:50:00 +0000, olcott said:

On 10/31/2024 5:49 AM, Mikko wrote:

On 2024-10-29 14:35:34 +0000, olcott said:

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a >>>>>>>>>>>> finite string description, the Halting Function itself always took a
Turing Machine,

That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider. >>>>>>>>>>> There are always been a distinction between the abstraction and the >>>>>>>>>>> encoding.

Nope, read the problem you have quoted in the past.

Ultimately I trust Linz the most on this:

the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts? >>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>> correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects
simulation out of hand:

We cannot find the answer by simulating the action of M on w, >>>>>>>>> say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

That statement does not fully reject simulation but is correct in >>>>>>>> the observation that non-halting cannot be determied in finite time >>>>>>>> by a complete simulation so someting else is needed instead of or >>>>>>>> in addition to a partial simulation. Linz does include simulationg >>>>>>>> Turing machines in his proof that no Turing machine is a halt decider. >>>>>>>

*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

- irrelevant

100% perfectly relevant within the philosophy of computation

Probably but not to anything quoted above.

*THE TITLE OF THIS THREAD*
[The philosophy of computation reformulates existing ideas on a new basis ---]

- couterfactual

You can baselessly claim that verified facts are counter-factual
you cannot show this.

Your statement was about a situation where "people fail to agree with
this and also fail to correctly point out any error". But that situation >>>> has not happened as people have identified your errors (perhaps not all >>>> but at least sufficiently many).

Inconsistent with the currently received view is
certainly not the slightest trace of any error when
examined within the philosophy of computation.

It has always seemed quite ridiculous to me that everyone
here consistently construes the currently received view
as inherently infallible.

The currently received view that if you are asked "What is 5 + 6?"
then only an answer that tells what 5 + 6 is is correct is infallible.

This is simple enough that people cannot be confused.
That 5 + 6 == 11 does seem infallibly true.

So even you can make the ridiculous mistake to regard the currently
received view as infallible?

They call me stupid and ignorant for not accepting the currently
received view as inherently infallible.

You are stupid if you regard your own view as infallible. If you
regard something that has been tested and found good as infallible
then the risk of error can be small enough.

I have known that equating believable with true is an error
a great consequence ever since I was 14.

It seems clear that halt deciders must compute the mapping
from their input finite strings to the actual behavior
specified by these finite strings.

It is not clear at all unless you specify how those finite
strings specify the actual behaviour. It is not pspecified
in the usual formulation of the problem. Also note that
the behaviour exists before those strings so "describe"
should be and usually is used instead of "specify". The
use of latter may give the false impression that the behaviour
is determined by those strings.

It is true that when we construe the halting criteria as
requiring taking into account how a pathological relationship
changes the behavior of the input instead of simply ignoring
this behavior change that pathological inputs become decidable
as non-halting.

It is true that doing that means leaving the halting proble unsolved.

--
Mikko

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

On 2024-11-02 12:47:12 +0000, joes said:

We are still miles away from beginning to talk about the halting
problem. We must first establish mutual agreement on this.

I'd rather hear about the halting problem. I'm reluctant to agree to
your unknown reasoning up front, because you will represent it as
proof you must be right. I can agree to this first step later and
then I will have agreed to everything else.

Just make sure you don't agree with anything that can be later used
for an equivocation fallacy. Which seems to exclude everything said
in English.

--
Mikko

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

On 2024-11-02 12:24:29 +0000, olcott said:

On 11/2/2024 5:35 AM, Mikko wrote:

On 2024-11-01 13:18:48 +0000, olcott said:

On 11/1/2024 6:08 AM, Mikko wrote:

On 2024-10-31 12:53:04 +0000, olcott said:

On 10/31/2024 5:55 AM, Mikko wrote:

On 2024-10-31 01:20:40 +0000, Mike Terry said:

On 30/10/2024 23:35, Richard Damon wrote:

On 10/30/24 8:34 AM, olcott wrote:

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

On 10/29/24 10:54 AM, olcott wrote:

On 10/29/2024 5:50 AM, Richard Damon wrote:

On 10/28/24 11:08 PM, olcott wrote:

On 10/28/2024 9:56 PM, Richard Damon wrote:

On 10/28/24 9:09 PM, olcott wrote:

On 10/28/2024 6:56 PM, Richard Damon wrote:

It is IMPOSSIBLE to emulate DDD per the x86 semantics without the code
for HHH, so it needs to be part of the input.

*You seemed to be a totally Jackass here*
You are not that stupid
You are not that ignorant
and this is not your ADD

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

At machine address 0000217a HHH emulates itself emulating >>>>>>>>>>>>>>> DDD without knowing that it is emulating itself. >>>>>>>>>>>>>>>

Then how did it convert the call HHH into an emulation of DDD again?

When HHH (unknowingly) emulates itself emulating DDD this >>>>>>>>>>>>> emulated HHH is going to freaking emulate DDD.

Did you think it was going to play poker?

Which is what it would do, get stuck and fail to be a decider. It might
figure out that it is emulating an emulating decider, at which point it
knows that the decider might choose to abort its conditional emulation
to return, so it needs to emulate further.

Only by recognizing itself, does it have grounds to say that if I don't
abort, it never will, and thus I am stuck, so I need to abort. >>>>>>>>>>>>

Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE.
https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801 >>>>>>>>>>>
*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly* >>>>>>>>>>> *or lack of technical competence*

DDD emulated by HHH according to the semantics of the x86 >>>>>>>>>>> language cannot possibly reach its own "return" instruction >>>>>>>>>>> whether or not any HHH ever aborts its emulation of DDD. >>>>>>>>>>>
I read, reread again and again to make sure that my understanding >>>>>>>>>>> is correct. You seems to glance at a few words before spouting off a
canned rebuttal that does not even apply to my words.

No, it knows its own code because it rule for "No conditional branches"
excludes that code.

It does not know its own code. It merely knows that the
machine address that it is looking at belongs to the
operating system. I simply don't have the fifty labor
years that AProVE: Non-Termination Witnesses for C Programs, >>>>>>>>> could spend on handling conditional branches.

The stupid aspect on your part is that even knowing
that its own code halts THIS HAS NOTHING TO DO WITH
DDD REACHING TS OWN RETURN INSTRUCTION.

No, HHH is NOT part of the "Operating System" so your claims are just a lie,

PO definitely has a deep-rooted problem with his thinking here.

What PO does does not look like any thingking but more like what one >>>>>> could expect from ChatgPPT or a similar AI.

I don't have the 50 years it would take for me to replicate the work of >>>>> AProVE: Non-Termination Witnesses for C Programs.

Doesn't matter. Even if you had you could not use it to prove your false >>>> claim that there be some defect in some proof.

There has never ever been the least trace of error
in this verified fact:

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

No, but its relevance to Linz' proof is very thin.

When the main motive of people like Richard is to derail
any chance of mutual agreement I cannot proceed with all
of the steps achieving mutual agreement on each step one
at a time in their mandatory prerequisite order.

You don't know motives of other people unless they tell. And even if
they do tell you can't know whether they tell truthfully. It is known
that people may be mistaken about their motives and that they rarely
if ever know all their moteives.

void DDD()
{
HHH(DDD);
return;
}

_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Unless and until you have complete and total perfect
understanding the above is perfectly correct I cannot even
begin showing relevance to Linz.

To agree about an ambiguous text tends to produce more harm than benefit
and should be avoided unless one can be sure that one knows who will get
the harm and who the benefit.

When we do not construe the current received view as
inherently infallible then we can begin to consider
alternative view.

You can call a strawman deception (or an attempt of one) an altenative
view but it is still a strawman deception.

THE FREAKING SUBJECT OF THE FREAKING THREAD IS THE PHILOSOPHY
OF COMPUTATION.

Strawman deception is a valid topic but not a valid method of
philosophical discussion.

Also note that the philosophy of philosphy of computation is a
part of the philosphy of computation.

If naive set theory was construed as inherently infallible then
ZFC could have never resolved Russell's Paradox.

There is no point in construing an inconsistent theory as inherently
infallible.

None-the-less everyone here continues to do that. Everyone here
takes the current received view on the theory of computation is
if it came directly from God himself. They cannot begin to imagine
the tiniest little trace of any error what-so-ever in the current
received view.

It really is not even any change to the view of deciders
to know that they compute the mapping from their finite
string input to their own accept or reject state on the
basis of a semantic or syntactic property of this string.

It does seems to be a change to how this semantic property
is string understood when applied to the halting problem proof.

The point is that a Turing machine can only compute syntactic properties.

No that is not the actual point. That is only the current
received view not an infallible ruling. Rice's theorem is
accepted as true. That is not the same as it actually being
true.

Every decider can be regarded as a definition of a syntactic property.
Every property that can be seen in the string is a syntactic property,
and the rest are not available to any decider.

From what I recall Rice can always be reduced to the HP.
This means refuting the HP proofs can be construed as
refuting Rice.

Conversely, the HP is a special case of Rice. Whether a string describes
a halting computation is not a feature of the string but depends on the interpretation. The same string may mean a halting computation to one
UTM and non-halting computation or a non-computation to another one.

Everyone here seems to think that the semantic property of
this finite string is not the actual behavior that this finite
string actually specifies.

In order to get a specification of anything the string must be
interpreted.

Yes.

void DDD()
{
HHH(DDD);
return;
}

Thus when HHH is a C interpreter both HHH and DDD
eventually crash due to out-of-memory error.

Which can be called an abnormal termination. A C implementation may let
you set up a signal handler function that is executed in a out-or-memory situation but all implementations don't.

A behaviour is not a finite string so a Turing machine
cannot see it.

When this TM is a UTM then this UTM can see the behavior
specified by the string as a subset of its own state
transitions.

If the behaviour is non-terminating and non-repeating the UTM will never
see all of it.

Instead of the actual behavior they construe it as the idealized
behavior that would occur if DDD was not calling its own termination
analyzer.

No, most participant of these discussions understand that the
halting problem asks about the actual behaviour of the actual
Turing machine with the actual input.

We are still miles away from beginning to talk about
the halting problem. We must first establish mutual
agreement on this.

void XXX()
{
YYY(DDD);
return;
}

_XXX()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push XXX
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

Whether DDD emulated by HHH is even relevant depends on what
YYY does. If it is defined

#definine YYY(X) (1)

then XXX returns after doing almost nothing.

In other case what I am doing is called
isolating the independent variable.

You may call it that way. It does not look like that.

The program under test is DDD.
HHH is NOT the program under test it is the tester.

So far is good. But the halting problem demands that every Turng machine >>>> can be put to the test.

DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

It is not 100% impossible to construe this as the reject criteria.
It is merely unconventional.

More importan is whther it is correct. If a terminating computation
is rejected as non-terminating then at least one of the criteria is
incorrect.

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.

HHH1 does compute the mapping from its input DDD
to the actual behavior that DDD specifies and this
DOES NOT INCLUDE HHH1 emulating itself emulating DDD.

The behavour specified by DDD is the same in both cases, incuding
the behaviour of HHH(DDD). The mapping computed by HHH1 is different
from HHH so at least one of them is not the mapping required by the
halting problem (and in fact the other isn't, either).

It seems ridiculously stupid for everyone here to simply
ignore how pathological self-reference DOES IN FACT
change the behavior of DDD.

The pathological self-reference does not change anything. It just
is there. But it is not very pathological as HHH can detect it
and terminate anyway.

--
Mikko

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

Am Sat, 02 Nov 2024 20:33:40 -0500 schrieb olcott:

On 11/2/2024 8:22 PM, Richard Damon wrote:

On 11/2/24 9:00 PM, olcott wrote:

On 11/2/2024 7:52 PM, Richard Damon wrote:

On 11/2/24 8:38 PM, olcott wrote:

On 11/2/2024 7:21 PM, Richard Damon wrote:

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

Of course, that is for this exact input, which uses the copy of H >>>>>>>> that does abort and return.

No it is not.
   when HHH simulates DDD(), it's analyzing an "idealized"
   version of DDD() where nothing stops the recursion.

In other words you are admitting that it isn't actually looking at >>>>>> the input it was given.

ChatGPT (using its own words) and I both agree that HHH is supposed
to predict the behavior of the infinite emulation on the basis of
its finite emulation.

LLMs literally string words they have previously seen together.

Yes, but that behavior is DEFINED by the actual behavior of the
actual machine.

No it is not. It is never based on the actual behavior of the actual
machine for any non-terminating inputs.

Haha what? It absolutely is. For a nonterminating input a halting
decider must return that it doesn't halt.

Then you don't undetstand the requirement for something to be a
semantic property.

The actual behavior specified by the finite string input to HHH does
include HHH emulating itself emulating DDD such that this DD *not some
other DDD somewhere else*

Especially not some DDD that calls a non-aborting simulator HHH1.

cannot possibly reach its own "return" instruction whether HHH emulates
DDD forever or some finite number of times.

DDD returns, and you need to give the encoding of this DDD to HHH.

I can see this, Ben can see this and ChatGPT understands it so well
that it can use entirely different words to explain exactly how it
sees this.

Nope, If you look carefully at what Ben agreed to was if you define the
NON-SEMANTIC property that you have been trying to define, your decider
can be a correct POOP decider. (of course, you can't look that closely
as you don't undetstand what you have been talking about).

The semantic property of this finite string does specify that HHH must emulate itself emulating DDD.
The direct execution of DDD DOES NOT SPECIFY THAT.

Yes of course it does. It calls HHH.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 03/11/2024 13:19, olcott wrote:

On 11/3/2024 3:19 AM, Mikko wrote:

On 2024-11-02 10:21:09 +0000, Andy Walker said:

On 02/11/2024 08:43, Mikko wrote:

A false assertion is a lie even if nobody asserts it.

[PO:]

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

����Disagree.� There is a clear advantage in distinguishing those
who make [honest] mistakes from those who wilfully mislead.

That is not a disagreement.

The term "lie" is to only be applied to intentionally
deceitful statements. To apply the term "lie" to statements
not having intentional deceit <is> itself intentional deceit.

Not if the person making that claim sincerely believes it. :) You are being inconsistent here...

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

On 11/3/24 10:16 AM, olcott wrote:

On 11/3/2024 8:32 AM, joes wrote:

Am Sat, 02 Nov 2024 20:33:40 -0500 schrieb olcott:

On 11/2/2024 8:22 PM, Richard Damon wrote:

On 11/2/24 9:00 PM, olcott wrote:

On 11/2/2024 7:52 PM, Richard Damon wrote:

On 11/2/24 8:38 PM, olcott wrote:

On 11/2/2024 7:21 PM, Richard Damon wrote:

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

Of course, that is for this exact input, which uses the copy of H >>>>>>>>>> that does abort and return.

No it is not.
    when HHH simulates DDD(), it's analyzing an "idealized" >>>>>>>>>     version of DDD() where nothing stops the recursion.

In other words you are admitting that it isn't actually looking at >>>>>>>> the input it was given.

ChatGPT (using its own words) and I both agree that HHH is supposed >>>>>>> to predict the behavior of the infinite emulation on the basis of >>>>>>> its finite emulation.

LLMs literally string words they have previously seen together.

Yes, but that behavior is DEFINED by the actual behavior of the
actual machine.

No it is not. It is never based on the actual behavior of the actual >>>>> machine for any non-terminating inputs.

Haha what? It absolutely is. For a nonterminating input a halting
decider must return that it doesn't halt.

Then you don't undetstand the requirement for something to be a
semantic property.

The actual behavior specified by the finite string input to HHH does
include HHH emulating itself emulating DDD such that this DD *not some
other DDD somewhere else*

Especially not some DDD that calls a non-aborting simulator HHH1.

*HHH1 has identical source code to HHH*

Which proves that neither HHH or HHH1 are pure functions or eligable to
be deciders, thus your entire premise is refuted.

void DDD()
{
  HHH(DDD);
  return;
}

DDD emulated by HHH
CANNOT POSSIBLY reach its own return instruction.

Do you mean the PROGRAM DDD, that HHH did an emulation on (which means
the behavior continues after HHH aborts its emulation) or do mean

The emulation of DDD by HHH, which isn't an objective or a semantic
property of DDD, and thus not eligable to be used for that sort of criteria.

DDD emulated by HHH1
DOES REACH its own return instruction.

Because THAT emulation meets the requirments, while HHH's didn't, thus
proving HHH wrong, and you a pathological liar.

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

On 11/3/24 8:21 AM, olcott wrote:

On 11/3/2024 3:29 AM, Mikko wrote:

On 2024-11-02 11:19:49 +0000, olcott said:

On 11/2/2024 3:43 AM, Mikko wrote:

On 2024-11-01 12:10:41 +0000, olcott said:

On 11/1/2024 5:40 AM, Mikko wrote:

On 2024-11-01 00:12:37 +0000, olcott said:

On 10/31/2024 6:48 PM, Richard Damon wrote:

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

On 10/31/2024 6:08 PM, Richard Damon wrote:

On 10/31/24 12:12 PM, olcott wrote:

On 10/31/2024 11:03 AM, Andy Walker wrote:

On 31/10/2024 11:01, Mikko wrote:

On 2024-10-30 11:17:45 +0000, Andy Walker said:

On 30/10/2024 03:50, Jeff Barnett wrote:

You may have noticed that the moron responded to your >>>>>>>>>>>>>>> message in
less than 10 minutes. Do you think he read the material >>>>>>>>>>>>>>> before
responding? A good troll would have waited a few hours >>>>>>>>>>>>>>> before
answering.

    I doubt whether Peter is either a moron or a troll. >>>>>>>>>>>>> Does it really matter? If he falsely pretends to be a moron >>>>>>>>>>>>> or a liar

I may politely pretend to believe.

     It's not exactly polite to describe Peter in any of >>>>>>>>>>>> these ways!
Entirely personally, I see no reason to do so in any case. >>>>>>>>>>>> He is quite
often impolite in response to being called a "stupid liar" >>>>>>>>>>>> or similar,
but that's understandable.  He is no worse than many a >>>>>>>>>>>> student in terms
of what he comprehends;  his fault lies in [apparently] >>>>>>>>>>>> believing that he
has a unique insight.

When what I say is viewed within the perspective of
the philosophy of computation I do have new insight.

When what I say is viewed within the assumption that
the current received view of the theory of computation
is inherently infallible then what I say can only be
viewed as incorrect.

So, are you willing to state that you are admitting that
nothing you might come up with has any bearing on the original >>>>>>>>>> halting problem because you are working in a new framework? >>>>>>>>>>

I am admitting one of two things:
(1) Everyone has misconstrued the original halting problem
as not applying to the behavior actually specified by the
actual input finite string.

Which is just a lie, so you are just admitting to not knowing
what the facts are.

It can't possibly be a lie because I am not even asserting
it as a truth only a possible truth of two possible truths.

A false assertion is a lie even if nobody asserts it.

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

It is deception to apply the term {lie} to any expression
of language without qualifying that {intentional deception}
it not meant only {falsity} is meant.

In order to say anything about intention one must say something
obout something other than the statement itself: the author of
the statement. To require that a sentence of the form X is Y
shall be interpreted as an assertion about something other than
X is not reasonable semantics. Of course natural language
semantics is often far from reasonable when the purpose is
other than serious discussion.

Don't call anything a lie when you do not mean intentional
deception or you yourself are the only liar.

Nope, YOU are the liar when you make that statement, as it is untrue,
and you should know it.

Sorry, you are just proving that you are nothing but a pathological liar.

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

On 11/3/24 12:58 PM, olcott wrote:

On 11/3/2024 11:53 AM, Mike Terry wrote:

On 03/11/2024 13:19, olcott wrote:

On 11/3/2024 3:19 AM, Mikko wrote:

On 2024-11-02 10:21:09 +0000, Andy Walker said:

On 02/11/2024 08:43, Mikko wrote:

A false assertion is a lie even if nobody asserts it.

[PO:]

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

    Disagree.  There is a clear advantage in distinguishing those >>>>> who make [honest] mistakes from those who wilfully mislead.

That is not a disagreement.

The term "lie" is to only be applied to intentionally
deceitful statements. To apply the term "lie" to statements
not having intentional deceit <is> itself intentional deceit.

Not if the person making that claim sincerely believes it. :)  You are
being inconsistent here...

Richard has said that he does not mean intentional
deceit when he calls me a liar, yet uses the term
"liar" anyway knowing that others will take this
to mean intentional deceit. So Richard is a liar
for calling me a liar.

Because the word doesn't just mean intential deciet.

And you are an intentional liar to say it only means that, as you have
been shown the definition.

IF you won't accept the truth, then you become the classical case of the pathological liar that lies because he can not tell the difference
between truth and lies, and speaks with a reckless disreguard for the truth.

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

On 11/3/24 1:40 PM, olcott wrote:

On 11/3/2024 12:22 PM, Richard Damon wrote:

On 11/3/24 12:58 PM, olcott wrote:

On 11/3/2024 11:53 AM, Mike Terry wrote:

On 03/11/2024 13:19, olcott wrote:

On 11/3/2024 3:19 AM, Mikko wrote:

On 2024-11-02 10:21:09 +0000, Andy Walker said:

On 02/11/2024 08:43, Mikko wrote:

A false assertion is a lie even if nobody asserts it.

[PO:]

Not at all. The base meaning of {lie} requires intentional
deception.

That may be its base meaning but the full meaning includes
all false statements. The statement itself does not change
when someone states it so there is no clear advantage in
saying that the statement was not a lie until someone stated
it.

    Disagree.  There is a clear advantage in distinguishing those >>>>>>> who make [honest] mistakes from those who wilfully mislead.

That is not a disagreement.

The term "lie" is to only be applied to intentionally
deceitful statements. To apply the term "lie" to statements
not having intentional deceit <is> itself intentional deceit.

Not if the person making that claim sincerely believes it. :)  You
are being inconsistent here...

Richard has said that he does not mean intentional
deceit when he calls me a liar, yet uses the term
"liar" anyway knowing that others will take this
to mean intentional deceit. So Richard is a liar
for calling me a liar.

Because the word doesn't just mean intential deciet.

And you are an intentional liar to say it only means that, as you have
been shown the definition.

Unless you always qualify you use of the term "liar" as
{unintentional falsity} it is the kind of defamation suit
that you will lose because the communication process always
assumes the primary meaning of a term unless otherwise specified.

Nope, I guess you learned your law just as good as your logic,

Since a "reasonable" person will undetstand that statements that are
clearly false under the standard mean can be considered to be lies.
Since you present yourself as someone claiing enough knowledge of the
field to be able to make credibale claims about what things means, when questioned on the meaning of your statement, and comparing them with the accepted meaning of the statement, you will lose all credability.

You can't even correctly say that my statements are false.
The most that you can accurately say is that my statements
are inconsistent with conventional opinions.

Sure I can, because your statement use terms of art with well defined definition that you don't follow.

This is one big difference between converstaional English, where meaning
is based on a wide assortment of meanings under general agreement, in a
formal system, the meaning is normally fairly precise.

While you try to claim to be wanting to work in an alternate system, the
fact that you haven't (likely because you can't) define such an
alternate system well enough to use it, you are stuck being in the
system that you just misuse, which makes your statement provably false,
and your claims of them a reckless disregarug of the truth, which is
good enough to be of a similar class to intentional.

IF you won't accept the truth, then you become the classical case of
the pathological liar that lies because he can not tell the difference
between truth and lies, and speaks with a reckless disreguard for the
truth.

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