On 12/15/25 9:01 PM, Richard Damon wrote:
On 12/15/25 2:13 PM, dart200 wrote:
On 12/14/25 12:22 PM, Richard Damon wrote:
On 12/14/25 1:46 PM, dart200 wrote:
On 12/13/25 5:50 PM, Richard Damon wrote:
On 12/13/25 8:17 PM, dart200 wrote:
On 12/13/25 6:26 AM, Richard Damon wrote:
On 12/13/25 12:18 AM, dart200 wrote:
On 12/12/25 7:02 AM, Richard Damon wrote:
On 12/11/25 2:35 PM, dart200 wrote:
On 12/9/25 8:02 PM, Richard Damon wrote:
On 12/9/25 1:55 PM, dart200 wrote:
On 12/9/25 4:42 AM, Richard Damon wrote:H^ must have a behavior, so there is a correct answer. >>>>>>>>>>>>
On 12/9/25 12:23 AM, dart200 wrote:
On 12/8/25 8:12 PM, Richard Damon wrote:what ever its programs says it will.
???
Given Machine H is chosen as one partial decider then >>>>>>>>>>>>>>>> the machine:
H^(d): if H(d, d) returns halting, loop forever >>>>>>>>>>>>>>>> else halt.
i'm sorry now ur claiming H(d,d) actually returns an >>>>>>>>>>>>>>> answer???
when did this happen, and what does it return buddy??? >>>>>>>>>>>>>>
Do you not understand the concept of a parameter to an >>>>>>>>>>>>>> arguement?
My claim is if *YOU* give me a machine H, I can prove it >>>>>>>>>>>>>> wrong.
YOU need to provide some machine that my arguement will >>>>>>>>>>>>>> label as H.
Then H^(H^) will show that H was wrong for H(H^, H^) >>>>>>>>>>>>>>>>
How is that not showing the machine which that machine >>>>>>>>>>>>>>>> can not decider.
partial decidable does not fly it loses to BB
Nope, because "partial deciability" means the machine is >>>>>>>>>>>>>> allowed to not answer.
so what ur saying is H won't answer, so H^ will have an >>>>>>>>>>>>> answer? i did explore that paradigm in one of my papers, a >>>>>>>>>>>>> believe it's possible to create a program that seeks out an >>>>>>>>>>>>> contradicts any and all deciders that try to decide on it: >>>>>>>>>>>>
One semi-useful class of partial decider, which are also >>>>>>>>>>>> called recognizer, are machines that never give a wrong >>>>>>>>>>>> answer, but sometimes
yeah that's what i explored in the paper i posted
But if your modifed criteria isn't itself useful, what good is >>>>>>>>>> it. THe
idk what's with boomers and the notion that someone needs to >>>>>>>>> have literally everything worked out about a thing before
posting an idea???
Not that you need to have it all worked out, but that you
evaluate as you go if there are signs of it being useful.
Yet, you ask for help.
if it doesn't interest you yet, then it's prolly not for you yet >>>>>>>>
The problem is if you don't think of usefulness at the start, >>>>>>>> you will certainly end up with a system without usefulness.
TV reality
Nope, you are just showing your stupidity.
TV reality, also this a form of origin fallacy
look i get that debating with polcott makes u cranky, i don't
really get thru to him either.
but i'm not polcott bro. he's exactly twice my age atm, right down
to the week.
history is littered with entirely serendipitous innovation, and >>>>>>> in fact our progression depends on serendipity. which is why
creativity for the sake it, rather than with purpose, can be
required
Inovation needs to start with a knowledge of the basics, something >>>>>> you don't seem to have.
bruh "knowing the basics" doesn't require scouring the entire
existing knowledge base for obscure, nuanced arguments that may or
may not exist.
anyways, the gpts never came back with any references to things
that really discuss what i'm talking about which is probably a way
more thorough search i can do manually,
so until u actually present me with a direct example of someone who >>>>> broke turing's arguments using context-aware deciders i'm going to
presume it doesn't already exist as i'm trying to present it.
The problem is your idea of "context-aware deciders" is a self-
contradictory term. The context the decider is being asked in can't
make a difference when the question is objectively context-insensitive. >>>>
The program the input represents either halts or it doesn't,
irrespective of what you are doing when you ask about it, as
"programs" are run in a context free environment.
If you want to try to work on a version of context aware programs,
go ahead, just realize that it makes things so much harder to talk
about, as you can't say anything about the results without including
the context it was derived for.
mmmm... now that we've discussed more, perhaps to you this kind of
machine i'm trying refactor the theory of computing around, would be
better described as a *context-aware recognizer*? 😊
Which is a contradiction of terms, as the things we ask recognizers to
recognize aren't context dependent. (In this case, how a full program
executes)
their ability to answer in a coherent fashion *is* however context- dependent
If you mean to expand the problem to include context aware entities as
your programs, the programs that don't use their context are still part
the context awareness must be provided by the mechanics of the
computation, not the programs written within that mechanics
of that, and thus you still can't handle the context insensitive
program that asks the context independent question of the behavior of
the program when invoked in the null context.
they guarantee consistent truth for their TRUE response, and will
return that in all places logically coherent to do so, guaranteeing
that such return won't be contradicted for the rest of the current
computation
they guarantee nothing about their FALSE response, and will return
such when not able to truthfully return TRUE. either because FALSE is
truthful, or because returning TRUE at that specific instance would
violate their consistency guarantee by causing FALSE to be truthful
But that isn't the rignt answer to the question, so your "recognizers"
aren't answering to right problem.
And, as I have said, partial recognizer, that are always right when
the answer, are already existent, so allowing something to give wrong
answers is just a step back.
actually i think we can modify them further for ur particularities, if
they cannot give a hard, truthful halts/not answer in some context, they spin forever:
und3 = () -> {
if ( halts_context_aware(und3) ) // false because und3() does not halt
print 'it halts'
else
print 'it doesn't halt'
if ( halts_context_aware(und3) ) // undef, therefore never returns
loop_forever()
}
it's more cumbersome to use, have less use, offer no practical benefit,
but tbh u really don't seem very interested in engineering a best-case functional solution,
and are seemingly obsessed with requiring that they must answer in ways
u know can't exist
Part of your problem is that imagining this exact program doing
something other than what it actually does isn't a valid operation.
halts() recognizes halting machines, while loops() recognizes non-
halting machines
these recognizers do, as far i can tell, offer a best-case interface
into coherently accessing the information we're trying to compute,
that is as /effectively computable/ as we could hope for
pragmatically speaking, when their return value cannot then affect
the context they are trying to recognize/decide/predict/whatever,
they function as proper deciders, for the only reason they would
return FALSE in that case is when FALSE is indeed truthful. it's
*just* in those edge case self-referential paradox situations where
they need to fall back onto actually being recognizer... vs a "proper
decider" (that doesn't actually exist)
Which maybe can defeat the toy program that the proof is built on, but
they still can't not answer some of the tough proglems, like what is
needed to build BB.
so code the situation bro
wow, this kinda blowing my mind rick. i started trying to call them
oracles, then switched to deciders, and i may end up on recognizer???
If they sometimes don't answer, they are recognizers, and we have
theories about them, so you need to show yours are at least as good,
if not better.
If they sometimes give the wrong answer, because they used faulty
logic of assuming they do something other than they did, they are just
liar, and not really useful.
It seems you are making the same error of Olcott, of diving into >>>>>>>> a field that you are ignorant of. There are REASONS for the
rules you want to flaunt, and by doing so you condemn your work >>>>>>>> to the trash heap of worthless ideas.
fact that you began with a disclaimer that you weren't going >>>>>>>>>> to look at the quality of the criteria makes the rest
meaningless. After all, we HAVE a lot of existing answers like >>>>>>>>>> that, either over machines of reduced capability of partial >>>>>>>>>> results.
don't answer. This class is more useful if they always >>>>>>>>>>>> eventually answer for one side of the decision, and only >>>>>>>>>>>> not- answer sometimes for the
no, there's always going to be some machine which they cannot >>>>>>>>>>> answer for both sides
Then you concepts doesn't have Recognizers, as BY DEFIHITION, >>>>>>>>>> they always correct accept any input that satisfies the
requirement, and never incorrect accept an input that doesn't. >>>>>>>>>> They may reject an input that doesn't meet the requriement, >>>>>>>>>> but might not answer for such input.
Thus a Halting Recognizer is possible, as any machine that as >>>>>>>>>> part of its operation simulates the machine at a non-vanishing >>>>>>>>>> rate will eventually reach the halting state, and thus give >>>>>>>>>> the correct answer.
If your ideas can't reach even that standard, they are less >>>>>>>>>> useful than existing results.
please do read §2 of that paper
depends on having the time to read something that began with a >>>>>>>>>> disclaimer that indicates it likely isn't valuable.
i mean u have a bunch time to keep dicking me around on this, >>>>>>>>> richard...
No, I look at things when I have a few spare moments waiting for >>>>>>>> other things to happen. To properly read a 20 page paper takes >>>>>>>> more of an effort, and when it begins with a disclaimer that
tells me the author isn't going to even try to make things
useful, there isn't much of an incentive.
ok keep arguing about something u haven't read then, that'll
surely teach me
I have taken a quick look at it. Once you assumed that every
machine has a unique number, you were cooked, as that is a false
statement.
in turing's encoding, it didn't involve excess characters like
modern programs bro. each machine description encodes a *unique*
machine.
Yes, but one machine has many encoding.
The problem is that Turing Machines are defined with "states", but
"states" don't have fixed names, and thus can be encoded many
different ways.
other. Halting is partially decidable by this criteria, with >>>>>>>>>>>> a decider that eventually answer halting for all halting >>>>>>>>>>>> machines, and non- halting for a large class of non-halting >>>>>>>>>>>> machines. I looked at machines of this type in the late 70's >>>>>>>>>>>> in school.
Also, "beleive" is not proof, and doesn't mean you framework >>>>>>>>>>>> is useful.
It is easy to create a system where Halting can be decided, >>>>>>>>>>>> it just needs making the system less than Turing Complete, >>>>>>>>>>>> so if you idea is based on that, so what.
https://www.academia.edu/136521323/
how_to_resolve_a_halting_paradox
(partial decidability also wouldn't work in Turing's >>>>>>>>>>>>> "satisfactory" problem from the og paper /on computable >>>>>>>>>>>>> numbers/, but we'll get there later)
The Abstract talks about changing the meaning of basics of >>>>>>>>>>>> Conputation theory and the defintion of Halting (I haven't >>>>>>>>>>>> read the full paper).
All that is doing is admitting that by the definitions >>>>>>>>>>>> accepted for defining a computation and what halting means, >>>>>>>>>>>> the author is conceeding that Halting is uncomputable. >>>>>>>>>>>>
The paper than says:
This paper does not attempt to present at depth arguments or >>>>>>>>>>>> reasons for why we should accept either of these proposals >>>>>>>>>>>> vs a more conventional perspective,
because the implications are so broad my interest was to just >>>>>>>>>>> focus on the idea of the technique vs why
And if you won't do the work to see if your ideas have any >>>>>>>>>> value, why should anyone else?
i made another paper on a reason to use it, and it worked out >>>>>>>>> miraculously well. turing would have been impressed, because it >>>>>>>>> did the unfathomable in making a direct diagonal (across
computable numbers) actually computable, while leaving the
inverse still uncomputable...
What is a "Computable Number"?
How can we know if a number is "Computable"?
like turing's paper, decider D on the matter is assumed
And proved to not be able to exist.
If you understand logic, you will realize that you are allowed to >>>>>> temporarily assume something exists to prove that it can't, you
can't assume something to exist to prove that it exists.
This is the nature of proof by contradiction,
right and i'm trying to address the contradiction, so i'm showing
how the existence of D can co-exist with structure of execution
turing found so problematic
But his D isn't a singular machine, it is a machine made to prove
that a given decider was wrong.
sorry for the confusion, i meant turing's decision machine 𝓓, not the >>> paradoxes you refer to as D
i'm assuming 𝓓, to show how 𝓓 can coexist with the paradox that
stumped turing into declaring uncomputability.
it's an interface problem, not an algorithm problem.
I may need to find the paper you are talking about. It seems several
different issues have jumbled into one topic, as we started very much
on halting, and you seem to have switched to a version of computable
real numbers.
the famous one he defined turing machines in... read §8 word for word\
my response to the diagonals he got stumped over:
https://www.academia.edu/143540657
I suspect you are making the same error of assuming that you can
detect the variations of the machine that made each number.
it's not a proof that D must exist, it's a refutation of the
perceived contradiction
But Turing Shows that a D exists for every claimed decider.
he only talked about one specific paradox
It is the Decider that doesn't exist, not that you can't make a D
from one.
It seems like you are running into the problem of not understanding
how a proof by contradiction works. It aways justs straight back to
the initial assumption that was provisionally made, in this case
that H was an existing actual halt decider.
The proof shows that any actual machine H you create, isn't a halt
decider, and thus there can't be any machine that is a halt decider.
and idk how to unlearn that
https://www.academia.edu/143540657
Which begins with an error, Turing Machines do not uniquely map >>>>>>>> to finite strings, and thus do not uniquely map to numbers.
*can be*, u moron
Nope.
A given Turing Machine can be expressed in an infinite number of
string/ numbers unless it is a trivial machine.
The problem is the "name" of the states in the Turing Machine >>>>>>>> are arbitrary, but end up in some manner in the string. Since we >>>>>>>> can easily just assign the same machine different names for the >>>>>>>> states, we can create many different encodings for a given machine. >>>>>>>>
You even quote his statement:
To each computable sequence there corresponds at least one
description number, while to no description number does there >>>>>>>> correspond more than one computable sequence. The computable
sequences and numbers are therefore enumerable
bruh, ur misinterpreting his quote
a "computable sequence" is referring to the (in this case
infinitely long) output sequence of the machine, not the machine
itself. given the infinitely long nature of the output, the output
sequence was written on every alternate square on the tape (F-
squares) while E- squares were for temp work not directly the
output of the machine. and turing missed this part: but there are
not only "at least one", but in fact *infinite* machines that
correspond to each computable sequence, since it's always possible
to add in arbitrary state changes that do not affect the output
let me quote the sentence before that:
/The D.N determines the S.D and the structure of the machine
*uniquely*/ [Tur36]
Right, the NUMBER generates a unique machine.
The machine does not have a unique number.
errr ... if the number uniquely determines the S.D, the no other
number can determine it, or else is not unique?
Wrong, the uniqueness is that there is only one machine for a given N,
not that there is only 1 N for a given machine.
if two numbers determined the same machine, then it would not be
uniquely determined...
Sure it is, as there is only one possible machine for each N.
Uniqueness is not reflexive.
unfortunately ur just not entirely correct about this point. i said
"can be", and this can be done by constraining the labels, which
turing does in this paper:
/Now let us give numbers to the m-configurations [states], calling
them q1 ... qR, as in §1. The initial m-configuration is always to be
called q1/ [Tur36]
you are correct that we can produce encodings where multiple numbers
map to the same machine ... but we can also constrain the encodings
such only one number maps to any unique machine.
Nope, not unless the machine has only 1 state, as state 2... can be in
any order, and we can add "dummy" states that are never reached to
make those numbers arbitrarily large. There is nothing that forces an
order of the states
We can also add dummy intermediary states that actually do nothing.
like i said, u can concede this point
Nope, you are just showing your small mind.
ok polcott...
are you therefore trying to claim we can't create a one-to-one bijection between natural numbers and turing machines???
one-to-one means that a natural number maps to only one unique turing machine, and that a turing machine maps to only one unique natural number.
if two different numbers map to actually the same turing machine, and there's no way around that, then it's not a one-to-one bijection, just a surjection...
...big, if true there bro
each "description number" *uniquely* corresponds to the "standard
description"/code and structure of a machine, *uniquely*
lets uhhh, get a concession from you on that point, eh?
but i'll add a note in my paper that modern programming languages
which involve custom labels and spacing allow us to create an
infinite amount of descriptions/numbers corresponding to the *same* >>>>> machine. also, i think this can be entirely mitigated by replacing
labels with addresses/ line numbers, and stripping all unnecessary
spacing.
So, where does the Turing Machine define specific lables for the
states?
bottom of p239
Of what paper?
the famous one he defined turing machines in
The problem is the way you write out the definition of a Turing
Machine naturally just uses some arbitrary labeling of the states,
and thus they can be arbitrarily encoded.
If you want to try to call each different labeling a different
machine, you need to handle that it is possible to programatically
generate an infinite variation on any given machine, and thus a
machine can not detect that it has been given a machine that is
equivalent to it.
Thus it can not detect a pathological input, as that pathological
machine just needs to keep on creating new variants of the decider,
so the decider can't detect itself in the input.
yes, so the machines are *uniquely* described by each description >>>>>>> number/string 🙄🙄🙄
It seems you may need to study some of the properties of
infinite sets better.
Now, each string represents just a single machine, so we can still >>>>>>>
Nope. You have many strings each which represent the same machine, >>>>>> but no string represents more than one machine.
It is sort of like the fact that the size of the Rationals is the >>>>>> same as the size of the Natural Numbers.
iterate through all machines, we just see each machine manyno actually i can't even read
times in that infinite iteration.
u find me anything like the paper i just linked to, and i'll >>>>>>>>> delete thunderbird to leave this god-forsaking group forever
As I have said, there are MANY other results in the category >>>>>>>>>> you are talking about, and if you aren't going to compare your >>>>>>>>>> results to them and show similar usefullness, why bother.
My guess is you didn't look at much prior art, and thus your >>>>>>>>>> results are likely poorer version of the existing work based >>>>>>>>>> on smarter people working on the results of other smarter people. >>>>>>>>>
Have you looked at ANYTHING academic on infinite sets?d
Then I guess you aare just admitting to being a liar.
no idea what u just said
You have said you can't read.
And you said you did read.
This are contradictory, and thus one must be a lie.
Note, "irony" has no place in the making of claims, it just shows
that you don't have the maturity to handle the logic.
sorry can't hear you
In other words, you are admitting to being intentional obtuse, so I
reserve the right to be snarky back at you.
i'm sorry u wot now?
and please don't comment on it until you read it enough to at >>>>>>>>> least explain to me how i used a quine in the paper. and no, >>>>>>>>> the quine itself doesn't solve turing's problem, but it does do >>>>>>>>> something interesting that turing never recognized because he >>>>>>>>> never knew about quines
Since you start with:
The diagonal computation must compute the unique natural number >>>>>>>> nh that describes it,
But, as shown above, there is no such number, as compuations are >>>>>>>> represented by an infinite set of numbers, your logic is just >>>>>>>> based on a false premise.
bruh, if ever u could read more than one sentence at a time:
/The particular number that represents a machine is entirely
dependent on the specific language that the machine description >>>>>>> has been encoded by/
Nope. Even in the "specific language" (if you mean the rules for
encoding) there are many encodings for a given machine, as the
internal labeling of the states is arbitrary.
turing machine standard-descriptions do not involve labels, so
therefore the labels are not actually necessary for computing. it's >>>>> just incredibly unwieldy to program without them
How do you express the state-transition table of a Turing machine
without state labels?
The standard description of a Turing Machine is a set of tuples
listing the transitions from current-state / tape-symbol to next-
state / tape- operation.
Those states are just labels.
i cannot condense meaning into the abstract and conclusions, >>>>>>>>>>> u'd actually have to read it 🤷
But, what good is an alternate formulation if you aren't >>>>>>>>>>>> going to discuss why the alternative is going to be useful. >>>>>>>>>>>
Yes, the first step of such a project should have been a study >>>>>>>>>> of what others have done. After all, those who won't study >>>>>>>>>> history are doomed to repeat it. If you didn't look into other >>>>>>>>>> attempts, you likely went down the same dead ends that have >>>>>>>>>> been traveled in the past.
if only life proceeded like such TV reality
So instead you walked out into the void with no idea of where >>>>>>>> you are going, and hoping you will just stumble upon something >>>>>>>> useful.
like i said, i can't even read so ...
So, I guess you are just a worm. (Write Only Random Memory)
If that is your attitude, you have a great opportunity to be
Olcott II
u'd love that wouldn't you?
actually my hope with any conversation here is to find enough
consensus such that i can get help with converting polcott to the
solution i'm proposing, so there will be no more polcott 2.0s
Maybe in the paper you read (but then you said you can't read).
Sure, but that isn't BB
It seems this is just another person not understand the >>>>>>>>>>>> reasoning behind how computations were defined, and why >>>>>>>>>>>> "Halting" was an important question, but just wants to >>>>>>>>>>>> create a somewhat similar solvable problem, even if such an >>>>>>>>>>>> alternative problem has no use.
if BB has some limit L (which is must if u believe >>>>>>>>>>>>>>> halting problem), then there must be some specifically L- >>>>>>>>>>>>>>> state machine which *no* machine could decide upon, for >>>>>>>>>>>>>>> if that machine was decidable by anything, then BB could >>>>>>>>>>>>>>> find that anything and subvert the limit L
WHy does BB need to have a limit L?
my my richard, u don't know that in ur theory BB must have >>>>>>>>>>>>> a limit?
You seem to be using undefined terms.
BB is apparently the Busy Beaver problem, which since it is >>>>>>>>>>>> uncomputable, can't actually be a machine.
yeah but it's certainly computable up until a limit, as we've >>>>>>>>>>> already computed it up to 5, there cannot be any machines <6 >>>>>>>>>>> states that are not decidable
Right, but that isn't the definition of "Computable" for a >>>>>>>>>> function.
BB_up_to_5_returns_0_after(n) is a wholly computable function >>>>>>>>
"computable up to a limit" is a meaningful phrase that can be >>>>>>>>> represented by more constrained functions that are indeed fully >>>>>>>>> computable, returning some recognizable non-answer after the >>>>>>>>> "limit" to computability it reached.
It may be "meaningful", but may not be useful.
If you can prove that limit point is big enough, there might be >>>>>>>> some uses for it on small practical problems.
For uses in logic theory, which was the initial goal of the
field, ALL means ALL and not just for small numbers.
could have just read the article instead of speculated bro:
Just like "Undecidable Problems" can be correctly decided for >>>>>>>>>> a lot of possible inputs, just not for all.
BB(n) is the maximum length tape that a Turing Machine of n >>>>>>>>>>>> states can create and then halt.
technically it's steps: https://en.wikipedia.org/wiki/
Busy_beaver
No, the "input" is the number of states in the machine.
There are two versions of Busy Beaver, one is the number of >>>>>>>>>> symbols output, the other is the number of steps it can run. >>>>>>>>>>
The first is actually the original as I remember, because that >>>>>>>>>> is an actual semantic property of a machine as normally
defined. Steps are not, as the operation of a Turing Machine >>>>>>>>>> is classically looked at as a black box and thus HOW it
generated the results are not significant, just that it did. >>>>>>>>>
/Radó defined two functions related to the busy beaver game: >>>>>>>>> the score function Σ(n) and the shifts function S(n) Both take >>>>>>>>> a number of Turing machine states n and output the maximum
score attainable by a Turing machine of that number of states >>>>>>>>> by some measure. The score function Σ(n) gives the maximum >>>>>>>>> number of 1s an n-state Turing machine can output before
halting, while the shifts function S(n) gives the maximum
number of shifts (or equivalently steps, because each step
includes a shift) that an n-state Turing machine can undergo >>>>>>>>> before halting/
And neither is computable for all values.
Note, I was pointing out that you were inaccurate in your
correction to my statement.
BB, as originally stated, was about length of tape generated.
as the paragraph said: the original score function was: /maximum >>>>>>> number of 1s an n-state Turing machine can output before halting/ >>>>>>> which is analogous to but does not necessarily match "tape length" >>>>>>
But historicaly the initial score function was length of the
output tape.
/After the entry has been verified, its score is the number
of ones on the tape when it stops/ [Rad61]
https://gwern.net/doc/cs/computable/1962-rado.pdf
another concession please
Is that you conceeding, or you not understanding that this is
exactly what I was talking about.
yeah but what if the 1s aren't contiguous?
then tape length =/= number of 1s
The version I remember used total length (defined as the distance
between the first 1 and the last) instead of counting the number of
1s. I don't think it materially affect the discussion.
i don't think the rules specify that the 1s need to be contiguous. so
far we've only know up to 5, and so far they produced contiguous blocks
at maximum.
i don't think we've proven that such will always been the case,
especially given that we blew all our effort on trying to prove we can't even know that, eh???
but he also directly talked about "shifts" which is analogous to, >>>>>>> but does also not directly match, "steps"
bruh ur gunna have to step down from being a chief engineer right >>>>>>> about everything for once, because ur now making nuanced errors >>>>>>> that could have been avoided by actually reading instead of just >>>>>>> skimming + presuming
Part of my job is to notice problems before things get too far.
If you want to just continue down a failing path, go ahead.
did i explain my position yet to you? not working atm. i got 300k
in savings. burning about 10k/mo in cash. my wife is 6 mo pregnant. >>>>> no she never worked.
What does that have to do with this.
i'm committed whether i like it or not
Then you probably should buckle down to understand the basic rules of
the game, and not gamble your life on false ideas.
bruh this isn't a game to me. our future is at stake. my unborn child's future is at stake. possibly even the viability of our civilization.
I have pointed out core fundamental error that you just don't seem
to be able to understand, which makes you work invalid.
If you want to spend you life savings chasing star faeries, I can't
stop you, but I can point out that you are going the wrong way.
but for the purposes of this discussion it doesn't really >>>>>>>>>>> matter whether it's space or steps we're talking about
Right. The steps is better for talking about the Halting
Problem, and likely the source of that variant.
i mean the natural number limit L >5 at which point BB(L) >>>>>>>>>>> becomes fundamentally *unknowable* due to some L-state
BB(n) is, by definitiion a "finite" number. Talking about >>>>>>>>>>>> the "limit" of a finite number is a misuse of the term. >>>>>>>>>>>
machine being fundamentally undecidable.
But your terminolgy is just bad there.
if L doesn't exist, that would make halting generally
decidable, so therefore L must exist
if L does exist, then there must be some L-state machine U >>>>>>>>>>> which cannot be decided on *by any partial* decider, because >>>>>>>>>>> the BB computation would find it and use it
Wrong. If by "Partial Decider" you mean a machine that is >>>>>>>>>> right for some inputs, but wrong for other, ALL inputs are >>>>>>>>>> partially decidable. As the pair of machines one that says >>>>>>>>>> Halting for all inputs and one that says Non-Halting for all >>>>>>>>>> inputs would be right.
If you mean by "Partial Decider" a machine that is always >>>>>>>>>> right when it
yes
Ok, that is the more useful definition.
answers. but might not answer, your results don't follow, as >>>>>>>>>> the set of partial deciders is (at least potentially) infinte, >>>>>>>>>> and thus BB couldn't combine the whole set to get the answer. >>>>>>>>>it is infinite. heck for any single machine there are infinite >>>>>>>>> machines that compute that same function.
BB just does an unbounded search running incrementally running >>>>>>>>> more of them simultaneously. for every iteration it starts 1 >>>>>>>>> partial decider to it's list of in-progress deciders, runs them >>>>>>>>> all one step, and tests each one for an answer
But that means you need an enumerated list of all machines that >>>>>>>> ARE partial deciders, and which excludes machines that are just >>>>>>>> incorrect.
instead of searching, i'd probably generate more and more of them >>>>>>> just named differently. it's not like the difference between two >>>>>>> partial deciders is really algorithmic in nature, it's just that >>>>>>> they have different names
How do you "generate" them? That means you need to show you can
make a full decider to determine if a given machine is a partial
decider.
i mean partial deciders knowable exist, right??? therefor i should
be able to program one, correct???
from there i can just keep adding in various trivial operation/
states that do not ultimately effect the output to generate an
infinite amount of them.
Which gives you a lot of copies of the same partial decider, which
doesn't get you anywhere.
To reach your goal, you need to find NEW deciders that can correctly
decide on new inputs, with your claimed goal to find ones that can
decide on all of them.
This can't work, as we can use this grand decider as the H to build
or D on, and it MUST be wrong (or just never answer).
let's consider a basic halting paradox, set in a more constrained but
still turing-like language. specifically one that only allows for
machines who's executions always only result in a finite set of
configurations. by "configuration" i mean "step" of machine defined
by: <state, tape, head_pos>. every operation of a machine changes
this configuration in some way.
But the standard definition of a Turing Machine only has a finite set
of transformation rules, as the state machine only has a finite number
of states.
These transformation rules are constant for a given machine, it has no
way to "change" them.
If you are trying to say that the tape have a finite "length" that has
been used, the problem is because halting for Turing Machines is
undecidable, you can't always know if a machine WILL run forever and
create in infinite time an infinite tape.
no i'm talking about the set of configurations/steps produced in a
turing machine computing, which is comprised by an ordered set of
tuples: <state, tape, head_pos>, where the ordering is determined by
what step it is in the computation.
the first configuration for any machine is:
<q0, init-head-pos, init-tape>
you could also write the tuple as:
<q0, init-tape-L, head, init-tape-R>
i'm talking about machines that only have a finite number of configurations
these machines can therefore have two semantics behavior in regards
to halting/not:
1) machines that have a finite set of configuration that halt
2) machines that have a finite set of configuration that loop back at
some unique point creating an infinite loop. remember: any repeated
machine configuration implies an infinite loop due to the
deterministic nature of these machines
But finite doesn't have a defined upper bound.
The problem is even if you mean that the machine can only have a
finite length tape, the problem is that at no point in finite time,
even for a machine that is running away and continuing to grow the
tape, has the tape ever reached "infinite" size.
the algorithm to decide between these two options is finite. because
the language already guarantees that only one of those will be an
input, all the decider needs to do is run the machine until either:
But you can't know that you "conditions" of bounded tape size will be
met.
1) the machine halts
2) a repeated configuration is found
But as the length can grow without bound, it doesn't need to reach a
repeated state.
of course, despite that algorithmic certainty, the halting problem
remains elusive:
und = () -> if (h1(und)) loop_forever() else halt
Which is only a valid program if the code for h1 is defined
now ur probably gunna try to argue that therefor such language can't
be constructed blah blah blah, but i'm going to power on cause that
wasn't even my intended point (just kinda happened), i really just
wanted a hypothetically constrained language to talk about how
seemingly trivial differences between recognizers affect their output.
Right, You have the same basic engine as a Turing Machine, so you
can't know if the tape will ultimately have an upper bound on size.
i cant atm, automatically generate the language,
but i can ensure thru my own programming to only feed the recognizer machines which are of type-1 or type-2
let's first consider the decision logic h1() needs to handle this
kind of self-analysis. because h1() is given full source code
(including it's own, and how it's exported/referenced by und()), it
can recognize that it's being asked to decide on a context where it's
prediction effects the outcome... so it will have to analyze the
effects of it's prediction on the outcome it's trying to predict:
But the problem is it can't, because und was written also having full
access to the source code of h1, and can make arbitrary null-
operations to that code to obfuscate it but still get the same result.
1) replace h1(und) with true:
But only if it CAN recognize "itself". Remember, the pathological attack
quines can uniquely identify itself, they construct an in-memory symbol- by-symbol copy of the program's source code. from there it's just
testing string/numerical equality to identify itself.
program uses an equivalent of a copy of the decider. Most papers don't
talk about the obfuscation, as the comparison problem has been proven
obfuscation is irrelevant because any change to the source code changes
what the quine identifies as itself
this is something i only realized right now in our convo: quines can
ensure no other machine computes *exactly* the same function because
quines ensure the machine only recognizes it's own source code as "itself"
most machines compute functions that can be computed by an infinite
other machines ... but quines *can* be used to to produce a machine that
is wholly unique in what it computes. and i didn't realize that until
like yesterday while contemplating my reply.
i'm sure ur going to disagree because u haven't really thot that deeply about the nature of quines, but i learned from this convo yet again.
i keep on learning rick,
hopefully u might eventually learn something too
#god
uncomputable, and thus any claim that uses it has already been disproven.
Maybe you should look up that proof and see what you can learn from it.
"() -> if (true) loop_forever() else halt" => loops forever
2) replace h1(und) with false:
"() -> if (false) loop_forever() else halt" => halts
3) the injected decisions do not match the result their value
indicates, so it will loop_forever() internally to avoid returning a
bad result
ok, so und() it's not answerable to by h1(), let's try h2() ... which
is almost exactly the same logic, except recognizing itself as h2()
vs h1(). in fact they use the same subroutine: h(input, name) where
input is the context/machine being decided, and label/reference what
the algo will consider as "itself". now because it's not h1(), it
doesn't have a problem returning FALSE about und(), and that's what
it will do (because it can know that h1() will intentionally loop
forever to avoid answering, as we just computed it).
see the only difference between h1() and h2() is what it considers as
"itself"
the same can be done in turing machines using quines and trivial
changes to the machine. taking a self-identifying (using a quine)
recognizer and adding a random shift at the end (and therefore also
in the quine) changes nothing except what the recognizer will
consider "itself", and this alone will change the specific paradox
that causes it to infinite loop. therefor i can generate an infinite
amount of recognizers that will each have a unique set of a programs
that they are unable to return a value for.
each BB(n) competition only has a finite number of machines involved,
while i can trivially generate an infinite number of recognizers that
each having a different and unique set of programs they cannot answer
to ...
i'm sorry that's probably confusing, but idk how to make it more
concise/digestible atm, and i want to get the rough gist posted...
And, you started with a false concept, that the decider can recoginze
the use of itself in the program under test.
so long as the language of the machines is constructed with a one-to-one relation with ℕ, then it absolute can using a quine.
That puts you right into a dead end.
cause today's Dec 15th! the typical deadline for turing award
nominations. ya know ... i'm young enough that if i were awarded next
year, i would just edge out the venerable knuth as youngest turing
award winner 🥇😂
I don't think you are there yet.
On 12/17/25 2:09 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:54 PM, dart200 wrote:
On 12/17/25 1:24 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:14 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:07 PM, dart200 wrote:
[...]
How do you deal with a case where its not a lie, (e.g., can pass
many lie detector tests) if _they_ believe its true?
Remember what happened to that doctor in the Andromeda Strain? That
blinking red light made her miss that sample where the viral agent
sample was destroyed, no growth... She would say she missed nothing...
no idea what ur tryin to say tbh
Still not sure how you solve the halting paradox unless you already
know the answer for any path taken in a program under consideration.
because the paradox is an inability to decide between two known
branches, both of which have decidable effects (one halts, one runs
forever)
i'm concerned with showing how we can fix that inability. i'm not
concerned with deciding on paths that have no branching, as that was
never the demonstrated problem, as such u need branching to form a
decision paradox
On 12/17/25 4:31 AM, Richard Damon wrote:
On 12/17/25 12:41 AM, dart200 wrote:
On 12/16/25 6:47 PM, Richard Damon wrote:
On 12/16/25 4:27 PM, dart200 wrote:
On 12/16/25 4:04 AM, Richard Damon wrote:
On 12/16/25 1:40 AM, dart200 wrote:
On 12/15/25 12:42 PM, olcott wrote:
I totally understand what you mean by context aware.
The behavior that the input to HHH(DD) specifies
is different than the behavior that the input to
HHH1(DD) specifies because DD only calls HHH(DD)
in recursive simulation.
no context-aware would mean that HHH(DD) returns differently
based on the specific location of the runtime instance
But since the QUESTION isn't context aware, any change of answer
means it is wrong.
the interface i'm trying to specify:
true = true answer, returned in all places where coherent
false = non-answer, does not specifically convey information about
machine semantics returned
In which case always answer false would be correct, and thus the
system is meaningless.
true = true answer, *returned in all places where coherent*
that second part of the predicate isn't like fucking optional, dick
But your problem is you can't DEFINE that second predicate.
Since your Decider DOES return false here, as that is what its code
say it does, the input program DOES halt, and thus the correct answer
would have been to return true.
What isn't coherent is your logic.
idk bro u can call me polcott 2.0 all u want, but when u just ignore
what i wrote to make it blatantly clear u haven't actually fucking
read the 2nd sentence u claim ur responding to ... i just ...
I don't "ignore" it, I point out that it is meaningles.
no ur just ignoring it, while simultaneously claiming to understand
und2(). but nothing about ur response indicates u actually understand
what's going on in und2()
like fuck this species, eh??? why do i continue to waste my time when
literally everyone around me is a dribbling fucking clown, eh?????
The problem is you can't see who is the actual clown.
🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🌎
let me make this abundantly clear:
true is not a valid return*false = non-answer, does not specifically convey information about
machine semantics returned, *returned only at instances where
But True is NOT a valid return for this decider, as its code says it
returns false.
It seems your system is ignoring a fundamental rule about
computations, that they return the answer they are programmed to.
And, the problem is that in the Halting Problem, the input is a
definitive program that has difinitive behavior, and that program,
in the proof of non-computability, contains a definitive version of
a decider that has fixed behavior, and that machine is just wrong.
it contains a full description of the decider, it does not and cannot
arbitrarily control what the decider does at any runtime instance
no, but that description does. Since you say that in this condition it
DOES return false, that is what it does, and thus the program halts,
and that is a consistant answer for this code.
It seems you want your programs to be free of the bounds of their
programming.
THere is no "incoherency" as any talk of "changing" the decider to
something else is just itself nonsense.
Yes, you can talk about a different decider, but the input doesn't
change itself to use that other decider, as that would just be a
DIFFERENT input.
context-aware means the machine can take context into discretion when
answering. these are computable machines, all you need is enough
reflection built into the computing infrastructure, such that the
machine can tell what it's context truthfully is.
But since the question doesn't depend on context, the answer can't,
and thus all you are doing is claiming a right to be wrong.
It doesn't matter what context the decider is in when the question
isn't about this call to the decider, but the behavior of a well
defined program when it is run independently.
you can, for example, make a function in javascript that takes an
input string and concatenates that input string with the name of the
function that called it. the context of the function acts like an
input to the output as much as the classical input does.
Ok, but how does that actually help you answer the question about what
the program does when independently run.
the deciders i'm proposing are an *interface* into accessing the
semantic information, one that is more intelligent that just
returning a raw mapping, *and can actually fking exist*
You mean you are allowing them to just LIE to some programs that call
them.
it's not a lie that it can't respond true in a truthfully fashion at
these instances of contention... and that's all false indicates: true
was not a valid return *for that instance*
Since D halts, for H(D) to say that behavior is "inconsistant" is just
a lie. Your problem is you dropped out the meaning of the question.
it doesn't say that the input does not halt, it just says nothing
THus, the only meaning we can give to false, is that it means the
decider determine that it wasn't able to determine the answer (not
that there isn't a valid answer), nd you can't quantify the grounds
it did so, so a valid decider in your system is just to always
return false.
Questions where it is acceptable to always give the same answer are
trivial and uninteresting, and thus your interface is inherently not
useful.
idk why you keep insisting the decider must decide both cases. the
interface i'm working on returns truth in all places that truth
actually is usable
Because if it can say I don't know to everything, the question is
meaningless.
it *cannot* just do that. so learn what a strawman is, then stop
beating one up cause that's just retarded
WHY NOT?
Your decider just made the same sort of arbitrary decision that a
halting program was incoherent in its halting, because its programmer
used faulty logic.
u said u understand und2(), and in und2() the return value is not
arbitrary. there is only one runtime execution path for und2(), there is nothing arbitrary about what is returned.
let me talk about the "usability", cause requiring the decider to
return hard true/false to a paradox does not result in meaningful
information in paradox anyways:
But it isn't a paradox, as there is a right answer, just the one
that this decider doesn't give.
You (and Olcott) don't seem to understand that the input is to be a
complete program, and thus include a copy of the specific decider it
is to refute.
Thus there IS a correct answer, the opposite of the ONE answer this
decider gives. And it needs to give just one answer as that is how
programs work.
context-aware means it can and does give a different answer based on
the specific runtime instance.
But the correct answer didn't change based on that context, so you are
just admitting that you concept is that deciders are allowed to be
wrong but still considered right, and thus your system is just
inconsistant.
it's an *interface* to get the answer. there is no *need* that such
interface conforms to the *non-existant* one you keep asserting is
for whatever reason necessary despite it then not actually existing...
An interface that allowed wrong answers, as the halting behavior of a
program is NEVER "incoherent".,
The is nothing "non-existant" about the real definition of the problem.
What is non-existant is a program that meets the requirement.
god that is so mindnumbingly retarded to try to describe
Because it is something based on lies.
und0 = () -> {
res = halts_classic(und) // return is ???
if (res)
print res // not correct information, cannot be used to for >>>>> // accurate computations or knowledge production
// so why are you requiring it to given here???
if (res)
loop_forever()
}
adding context-awareness to a classic interface does not help:
und1 = () -> {
res0 = halts_classic_context_aware(und1) // return is still ??? >>>>>
res1 = halts_classic_context_aware(und1) // return is also ???
// bc what is res0 even?
if (res0)
print res0 // is this correct information?
if (res1)
print res1 // is this correct information?
if (res0)
loop_forever()
}
but a relaxed context-aware interface (that only guarantees
meaningful semantic information with it's true value) becomes both
decidable *and* knowably useful:
WHich is an meaningless interface, as it allows the always false
answer to be correct, and thus the problem falls into the "trivial"
classification.
straw. man. learn. 2. read. dick.
So, why is the always false returner not allowed, but your incorrect
answer is?
because ()->false would never give computably useful information, and u
know that, so idk why ur asking dumb questions old man
returning false *only* when true would be contradiction *at that
instance* and true all instances otherwise, grants us access to truthful information, in all instances such truth is not a contradiction. which
is a requirement for it being truth anyways!
The problem is you are imagining an incoherence where there isn't one.
it just doesn't function as a decider, and u know that
Perhaps because you forget that the input *IS* a program, by
definition, and thus when you define it, you have defined the ONE
decider that it is disproving, and talking about it doing something
other than what it does is just itself incoherent.
und2 = () -> {
res0 = halts_context_aware(und2) // false because returning true is >>>>> // a contradiction at this
instance
res1 = halts_context_aware(und2) // true because returning true >>>>> is not
// a contradiction at this
instance
if (res0)
print res0 // not "correct" information that could be used in >>>>> // in further knowledge generation, because false
// does not convey meaningful information >>>>> if (res1)
print res1 // "correct" information, because true does convey >>>>> // meaningful information
if (res0)
loop_forever()
}
what don't you understand about this?
Oh, I understand it, I have just been pointing out that your
definition is a lie.
great so apparently you understand the interface i've described
now in order to convince me i'm wrong, u'd need to show me how halts_context_aware() can be used to create a unresolvable
contradiction. anything less than that is u pathetically crying about something i couldn't care less about
admitting wrong is ofc still possible for me rick. i'm well acquainted
with being wrong at times, and i've had to go down plenty of wrong paths
to find the one i'm describing now.
unfortunately i'm not seeing my evidence ur still capable to conceding a point. i will keep trying, but maybe u wore the chief engineer helmet
for so long u forgot what being humble was like
power hierarchies do be like that
#god
Since the DEFINITION of a Halt Decider is that it return an answer
that indicates the behavior of the program described when it is, and
your program will halt, the fact it returned false in the first call
just means it is wrong, and you are trying to define that false
answers can be correct.
Remember, und2 includes as part of its algorithm the full algorithm
that determines what halts_context_aware will return, and thus that
algorithm returning false in the first case is just wrong.
You can't talk about it returning something else there, as it doesn't,
and can't and your function be an actual function, even a context-
aware function, as that context is defined here.
If HHH(DD) is supposed to ask about the behavior of DD when it is >>>>>> run, and that doesn't depend on that context you do that, then the >>>>>> answer can't change and still be correct.
Deciders aren't allowed to only be correct in only some instances.
like idk why ur crying about me not agreeing that a demonstrably
subpar interface is the sole theoretical truth of the matter...
Because it *IS* for the problem at hand.
like why are you peddling such a god damn useless fucking theory
bro? cause that's what you were taught??
Because it ISN'T useless. You are just showing you don't understand
it and blaming the errors of your own thinking on the system you
fail to understand.
the specific decider interface you claim is "theoretically-sound"
doesn't fucking exist u moron
Sure it does. What doesn't exist is a program that meets it.
You seem to confuse the problem and the implementation of an answer.
a non-existence interface is fucking useless. why can't that non-
existance come from the fact *you picked the wrong interface*???
But the INTERFACE isn't non-existant, only the program that meets it.
no dude, the interface is *what* the response should be, and since that cannot be defined on all input, it doesn't generally exist.
the machine is *how* we get that output, not *what* the output should be.
the halting problem was *always* an interface problem, but ofc it was defined before the concepts of interface vs implementation existed, so confusion got baked into the fundamentals of computing.
We can make programs that meet the interface for many inputs, and so
it can be useful.
We can even make programs that are always right when the answer, they
just sometimes never answer, which means they aren't the ultimate
answer to the problem, but may be useful for a given situation.
all halts_context_aware() does is generate a non-answer when it can't
answer correctly
this disturbs u greatly for some reason i cannot fathom. i mean, i get
that new paradigms can be triggering for whatever reason, but u just
keep repeating urself
*you shot urself in the foot by asking the question wrong,* and for
some fking ungodly reason u think shooting urself in the foot is a
good thing????
But we didn't ask the question wrong, but asked the question we want
answered, what does this program do.
Your interface seems to be trying to ask about something that doesn't
exist, the behavior of a program that doesn't do what its code says it
will do.
THAT is the incoherent.
If you want to try to define a different problem, that is fine, just
don't say it was the original problem.
Coming up with problems that have answers isn't wrong, but if you
can't show where that problem is useful, your problem isn't useful.
u keep claiming halts_context_aware() is useless because it doesn't
answer to situations where no answer exists.
the real problem is u don't actually have a use for an answer there, as und0() and und1() demonstrate
ur demanding a useless requirement the it answers to an unanswerable situation, and ur not specifying what requirement my improved version doesn't satisfy. ur just repeating urself about lies while ignoring the context-specific specification i gave.
Ultimately, you are going to need to understand the fundamental
meaning of the words you are using. It seems you have learned some
ignorance, just like Olcott has, and this has corrupted your system.
It is hard to come up for a usefulness of a system that doesn't
require programs to do what their programming says they will do, as
that woud remove the whole basis of truth and facts.
and you call urself a chief engineer????
goddamn 🤡🌎
put on ur fking engineer helmet for a second (not the "im special"
one) and tell me what more functionality you could even want out of >>>>> the halting decider???
you:
a) get usable information
b) know where the information is usable
c) get that information everywhere it is usable
what more do u need?
;
#god
didn't answer what more u need bro
;
#god
still not answering what more functionality u need
#god
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the input represents,
something you are trying to say is out of scope, but that--
means that you are trying to put semantics out of scope.
On 12/17/25 8:05 PM, dart200 wrote:
On 12/17/25 2:09 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:54 PM, dart200 wrote:
On 12/17/25 1:24 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:14 PM, Chris M. Thomasson wrote:no idea what ur tryin to say tbh
On 12/17/2025 1:07 PM, dart200 wrote:
[...]
How do you deal with a case where its not a lie, (e.g., can pass
many lie detector tests) if _they_ believe its true?
Remember what happened to that doctor in the Andromeda Strain? That >>>>> blinking red light made her miss that sample where the viral agent
sample was destroyed, no growth... She would say she missed nothing... >>>>
Still not sure how you solve the halting paradox unless you already
know the answer for any path taken in a program under consideration.
because the paradox is an inability to decide between two known
branches, both of which have decidable effects (one halts, one runs
forever)
i'm concerned with showing how we can fix that inability. i'm not
concerned with deciding on paths that have no branching, as that was
never the demonstrated problem, as such u need branching to form a
decision paradox
But there are not two branches in the behavior of the input, but only
one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
When we imagine a different decider, we can create a totally different
input that makes that one wrong too.
The two branches are only there at the meta level, not at the actual
level were we do the actual computation.
On 12/17/2025 10:29 PM, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input represents,
That has always been incorrect.
The behavior of the running program is always measured through
the proxy of a finite string machine description.
something you are trying to say is out of scope, but that means that
you are trying to put semantics out of scope.
On 12/17/2025 10:29 PM, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input represents,
That has always been incorrect.
The behavior of the running program is always measured through
the proxy of a finite string machine description.
something you are trying to say is out of scope, but that means that
you are trying to put semantics out of scope.
On 12/17/25 8:30 PM, Richard Damon wrote:
On 12/17/25 8:05 PM, dart200 wrote:
On 12/17/25 2:09 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:54 PM, dart200 wrote:
On 12/17/25 1:24 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:14 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:07 PM, dart200 wrote:
[...]
How do you deal with a case where its not a lie, (e.g., can pass >>>>>>> many lie detector tests) if _they_ believe its true?
Remember what happened to that doctor in the Andromeda Strain?
That blinking red light made her miss that sample where the viral >>>>>> agent sample was destroyed, no growth... She would say she missed >>>>>> nothing...
no idea what ur tryin to say tbh
Still not sure how you solve the halting paradox unless you already
know the answer for any path taken in a program under consideration.
because the paradox is an inability to decide between two known
branches, both of which have decidable effects (one halts, one runs
forever)
i'm concerned with showing how we can fix that inability. i'm not
concerned with deciding on paths that have no branching, as that was
never the demonstrated problem, as such u need branching to form a
decision paradox
But there are not two branches in the behavior of the input, but only
one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
dick, the classic halting decider doesn't exist, so why would a
resolution that might actually exist, be fixed to referencing a
certainly non-existent machine??? 🙄🙄🙄
When we imagine a different decider, we can create a totally different
input that makes that one wrong too.
The two branches are only there at the meta level, not at the actual
level were we do the actual computation.
obviously, because the paradox arises in meta-analysis, not actual computation 👍👍👍
except ... isn't the meta-analysis actually a computation itself? or do
u think we're doing meta-analysis that somehow transcends computation?
While no halt deciders exist, the "inteface that they define" does.
On 12/17/25 11:50 PM, dart200 wrote:
On 12/17/25 8:30 PM, Richard Damon wrote:
On 12/17/25 8:05 PM, dart200 wrote:
On 12/17/25 2:09 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:54 PM, dart200 wrote:
On 12/17/25 1:24 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:14 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:07 PM, dart200 wrote:
[...]
How do you deal with a case where its not a lie, (e.g., can pass >>>>>>>> many lie detector tests) if _they_ believe its true?
Remember what happened to that doctor in the Andromeda Strain?
That blinking red light made her miss that sample where the viral >>>>>>> agent sample was destroyed, no growth... She would say she missed >>>>>>> nothing...
no idea what ur tryin to say tbh
Still not sure how you solve the halting paradox unless you already >>>>> know the answer for any path taken in a program under consideration.
because the paradox is an inability to decide between two known
branches, both of which have decidable effects (one halts, one runs
forever)
i'm concerned with showing how we can fix that inability. i'm not
concerned with deciding on paths that have no branching, as that was
never the demonstrated problem, as such u need branching to form a
decision paradox
But there are not two branches in the behavior of the input, but only
one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
dick, the classic halting decider doesn't exist, so why would a
resolution that might actually exist, be fixed to referencing a
certainly non-existent machine??? 🙄🙄🙄
I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else.
That means any talk of some other decider, doesn't change the behavior
of the input.
Thus, imaginign that you function returns something else, doesn't change
the return value of the copy of the function inside the machine in the input, and thus you don't get your incoherence, just proof that you functions were wrong, and can't call the machie incoherent.
When we imagine a different decider, we can create a totally
different input that makes that one wrong too.
The two branches are only there at the meta level, not at the actual
level were we do the actual computation.
obviously, because the paradox arises in meta-analysis, not actual
computation 👍👍👍
except ... isn't the meta-analysis actually a computation itself? or
do u think we're doing meta-analysis that somehow transcends computation?
Nope. The Meta-Analysis is not a computation, but logic that produces
the program that does the computation.
The Meta-Analysis can add "meaning" to the purely syntactic operations
of the program, but isn't itself a computation.
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for its
logic. Does this path halt or not, well, we know, we made the damn
thing. But, there is no one universal decider...
[...]
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for its
logic. Does this path halt or not, well, we know, we made the damn
thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for its
logic. Does this path halt or not, well, we know, we made the damn
thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you call
into other programs, well, shit happens. But your own logic, you know
what you are doing when you made the program.
On 12/17/25 11:49 PM, olcott wrote:
On 12/17/2025 10:29 PM, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input represents,
That has always been incorrect.
The behavior of the running program is always measured through
the proxy of a finite string machine description.
Nope, you got a source for that claim?
It seems to be just another of your zero-principle lies.
Of course, we do have the fact that a real UTM (not the broken on inside your decider) will also recreate that behavior, but this is a secondary derivation coming out of the definition of a UTM.
All you are doing is proving you are just a liar.
something you are trying to say is out of scope, but that means that
you are trying to put semantics out of scope.
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
On 12/17/2025 11:00 PM, Richard Damon wrote:
On 12/17/25 11:49 PM, olcott wrote:
On 12/17/2025 10:29 PM, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input represents,
That has always been incorrect.
The behavior of the running program is always measured through
the proxy of a finite string machine description.
Nope, you got a source for that claim?
It is common knowledge that Turing machine
computations only transform input finite
strings into values.
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for its
logic. Does this path halt or not, well, we know, we made the damn
thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
On 12/17/25 9:06 PM, Richard Damon wrote:Only because halt deciders don't exist, which they are built on.
I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else.
That means any talk of some other decider, doesn't change the behavior
of the input.
that hypothesized input involving the classic halting decider DOES NOT
EXIST
if the fixed decider actually does exist, it only needs to decide on
machines THAT ACTUALLY EXIST, which does NOT include the hypothesized
classic haling decider
the only input a fixed decider needs to decide on are those machines
possibly involving fixed decider, NOT a classical decider
Thus, imaginign that you function returns something else, doesn't
change the return value of the copy of the function inside the machine
in the input, and thus you don't get your incoherence, just proof that
you functions were wrong, and can't call the machie incoherent.
main = () -> {
und = () -> {
if ( halts(und) ) // this instance is deciding from
loop() // within the context of main.und
else
halt()
}
if ( halts(und) ) // this instance is deciding from
print 'und halts' // within the context of main
else
print 'und does not halt'
}
the decision returned by halts(und) does not "change" the runtime of
und(). und() only has one possible runtime execution, and it never
actually runs in this example.
Am Wed, 17 Dec 2025 22:12:56 -0800 schrieb dart200:
On 12/17/25 9:06 PM, Richard Damon wrote:
Only because halt deciders don't exist, which they are built on.I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else.
That means any talk of some other decider, doesn't change the behavior
of the input.
that hypothesized input involving the classic halting decider DOES NOT
EXIST
if the fixed decider actually does exist, it only needs to decide on
machines THAT ACTUALLY EXIST, which does NOT include the hypothesized
classic haling decider
the only input a fixed decider needs to decide on are those machines
possibly involving fixed decider, NOT a classical decider
It needs to decide its counterexample input. Not sure what you mean by "classical" deciders.
Thus, imaginign that you function returns something else, doesn't
change the return value of the copy of the function inside the machine
in the input, and thus you don't get your incoherence, just proof that
you functions were wrong, and can't call the machie incoherent.
main = () -> {
und = () -> {
if ( halts(und) ) // this instance is deciding from
loop() // within the context of main.und
else
halt()
}
if ( halts(und) ) // this instance is deciding from
print 'und halts' // within the context of main
else
print 'und does not halt'
}
the decision returned by halts(und) does not "change" the runtime of
und(). und() only has one possible runtime execution, and it never
actually runs in this example.
If that is just a definition, why is it inside main? To have the
execution context as a hidden input?
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
On 12/17/25 11:49 PM, olcott wrote:
On 12/17/2025 10:29 PM, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input represents,
That has always been incorrect.
The behavior of the running program is always measured through
the proxy of a finite string machine description.
Nope, just shows you don't know the meaming of semantics.
That is like saying the meaning of a words is determined by the letters
that spell it.
Note, that meaning CAN be gotten from the finite string representation
by the use of a UTM, so even with your definition, it still means what
the direct execution does, because that is what the UTM simulation does.
And if A == B, and B == C, then A == C
I guess you don't understand what you are talking about.
something you are trying to say is out of scope, but that means that
you are trying to put semantics out of scope.
Am Wed, 17 Dec 2025 22:12:56 -0800 schrieb dart200:
On 12/17/25 9:06 PM, Richard Damon wrote:
Only because halt deciders don't exist, which they are built on.I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else.
That means any talk of some other decider, doesn't change the behavior
of the input.
that hypothesized input involving the classic halting decider DOES NOT
EXIST
if the fixed decider actually does exist, it only needs to decide on
machines THAT ACTUALLY EXIST, which does NOT include the hypothesized
classic haling decider
the only input a fixed decider needs to decide on are those machines
possibly involving fixed decider, NOT a classical decider
It needs to decide its counterexample input. Not sure what you mean by "classical" deciders.
Thus, imaginign that you function returns something else, doesn't
change the return value of the copy of the function inside the machine
in the input, and thus you don't get your incoherence, just proof that
you functions were wrong, and can't call the machie incoherent.
main = () -> {
und = () -> {
if ( halts(und) ) // this instance is deciding from
loop() // within the context of main.und
else
halt()
}
if ( halts(und) ) // this instance is deciding from
print 'und halts' // within the context of main
else
print 'und does not halt'
}
the decision returned by halts(und) does not "change" the runtime of
und(). und() only has one possible runtime execution, and it never
actually runs in this example.
If that is just a definition, why is it inside main? To have the
execution context as a hidden input?
On 12/18/25 4:33 AM, joes wrote:
Am Wed, 17 Dec 2025 22:12:56 -0800 schrieb dart200:
On 12/17/25 9:06 PM, Richard Damon wrote:Only because halt deciders don't exist, which they are built on.
I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else. >>>> That means any talk of some other decider, doesn't change the behavior >>>> of the input.
that hypothesized input involving the classic halting decider DOES NOT
EXIST
*classic halting deciders do not exist, correct
if the fixed decider actually does exist, it only needs to decide on
machines THAT ACTUALLY EXIST, which does NOT include the hypothesized
classic haling decider
the only input a fixed decider needs to decide on are those machines
possibly involving fixed decider, NOT a classical decider
It needs to decide its counterexample input. Not sure what you mean by
"classical" deciders.
the classic halting decider is the one you already know: returns true
iff input halts, and false iff input does not halt, with no further conditions on how they return
i'm exploring alternative context-aware deciders to in order to mitigate
the halting paradox problem (and decision paradoxes more generally)
Thus, imaginign that you function returns something else, doesn't
change the return value of the copy of the function inside the machine >>>> in the input, and thus you don't get your incoherence, just proof that >>>> you functions were wrong, and can't call the machie incoherent.
main = () -> {
und = () -> {
if ( halts(und) ) // this instance is deciding from >>> loop() // within the context of main.und
else
halt()
}
if ( halts(und) ) // this instance is deciding from >>> print 'und halts' // within the context of main
else
print 'und does not halt'
}
the decision returned by halts(und) does not "change" the runtime of
und(). und() only has one possible runtime execution, and it never
actually runs in this example.
If that is just a definition, why is it inside main? To have the
execution context as a hidden input?
so i could have contexts of main.und vs just main. a bit arbitrary sure, just what i felt at time of writing
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for
its logic. Does this path halt or not, well, we know, we made the
damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you
call into other programs, well, shit happens. But your own logic, you
know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>For a given program, the creator can create a halting decider for
its logic. Does this path halt or not, well, we know, we made the
damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you
call into other programs, well, shit happens. But your own logic, you
know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
There can be a specialized halting decider for a program, but not one decider for any program.
On 12/18/25 4:35 PM, Chris M. Thomasson wrote:
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>>For a given program, the creator can create a halting decider for >>>>>> its logic. Does this path halt or not, well, we know, we made the >>>>>> damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you
call into other programs, well, shit happens. But your own logic,
you know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
There can be a specialized halting decider for a program, but not one
decider for any program.
thank you for repeating the consensus that has been repeated at me 100s
of times now
also there are semantic paradoxes that no program could decide upon
On 12/18/25 4:35 PM, Chris M. Thomasson wrote:
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>>For a given program, the creator can create a halting decider for >>>>>> its logic. Does this path halt or not, well, we know, we made the >>>>>> damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you
call into other programs, well, shit happens. But your own logic,
you know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
There can be a specialized halting decider for a program, but not one
decider for any program.
thank you for repeating the consensus that has been repeated at me 100s
of times now
also there are semantic paradoxes that no program could decide upon
On 12/17/2025 10:53 PM, Richard Damon wrote:
On 12/17/25 11:49 PM, olcott wrote:
On 12/17/2025 10:29 PM, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input represents,
That has always been incorrect.
The behavior of the running program is always measured through
the proxy of a finite string machine description.
Nope, just shows you don't know the meaming of semantics.
In computability theory, Rice's theorem
states that all non-trivial semantic properties
of programs are undecidable. A semantic property
is one about the program's behavior.
https://en.wikipedia.org/wiki/Rice%27s_theorem
That is like saying the meaning of a words is determined by the
letters that spell it.
Note, that meaning CAN be gotten from the finite string representation
by the use of a UTM, so even with your definition, it still means what
the direct execution does, because that is what the UTM simulation does.
And if A == B, and B == C, then A == C
I guess you don't understand what you are talking about.
something you are trying to say is out of scope, but that means that
you are trying to put semantics out of scope.
On 12/18/2025 5:03 AM, Mikko wrote:
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
That is the wrong question.
The correct question is what does Rice
meaning by semantic meaning?
On 12/18/2025 6:33 AM, joes wrote:
Am Wed, 17 Dec 2025 22:12:56 -0800 schrieb dart200:
On 12/17/25 9:06 PM, Richard Damon wrote:Only because halt deciders don't exist, which they are built on.
I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else. >>>> That means any talk of some other decider, doesn't change the behavior >>>> of the input.
that hypothesized input involving the classic halting decider DOES NOT
EXIST
A halt decider can have a domain of one input.
if the fixed decider actually does exist, it only needs to decide on
machines THAT ACTUALLY EXIST, which does NOT include the hypothesized
classic haling decider
the only input a fixed decider needs to decide on are those machines
possibly involving fixed decider, NOT a classical decider
It needs to decide its counterexample input. Not sure what you mean by
"classical" deciders.
Thus, imaginign that you function returns something else, doesn't
change the return value of the copy of the function inside the machine >>>> in the input, and thus you don't get your incoherence, just proof that >>>> you functions were wrong, and can't call the machie incoherent.
main = () -> {
und = () -> {
if ( halts(und) ) // this instance is deciding from >>> loop() // within the context of main.und
else
halt()
}
if ( halts(und) ) // this instance is deciding from >>> print 'und halts' // within the context of main
else
print 'und does not halt'
}
the decision returned by halts(und) does not "change" the runtime of
und(). und() only has one possible runtime execution, and it never
actually runs in this example.
If that is just a definition, why is it inside main? To have the
execution context as a hidden input?
On 12/18/2025 6:39 PM, dart200 wrote:
On 12/18/25 4:35 PM, Chris M. Thomasson wrote:
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>>>For a given program, the creator can create a halting decider for >>>>>>> its logic. Does this path halt or not, well, we know, we made the >>>>>>> damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you
call into other programs, well, shit happens. But your own logic,
you know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
There can be a specialized halting decider for a program, but not one
decider for any program.
thank you for repeating the consensus that has been repeated at me
100s of times now
It is best to think of most of them as not very smart bots.
On the other hand Claude AI is so fabulous at semantic
entailment from a correct basis that I got it to override
its own bias and admit its own mistake this way. It was
actually capable of introspection.
also there are semantic paradoxes that no program could decide upon
On 12/18/25 4:45 PM, polcott wrote:
On 12/18/2025 6:39 PM, dart200 wrote:
On 12/18/25 4:35 PM, Chris M. Thomasson wrote:
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" >>>>>>>>> does.
For a given program, the creator can create a halting decider >>>>>>>> for its logic. Does this path halt or not, well, we know, we
made the damn thing. But, there is no one universal decider... >>>>>>>>
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you >>>>>> call into other programs, well, shit happens. But your own logic, >>>>>> you know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
There can be a specialized halting decider for a program, but not
one decider for any program.
thank you for repeating the consensus that has been repeated at me
100s of times now
It is best to think of most of them as not very smart bots.
On the other hand Claude AI is so fabulous at semantic
entailment from a correct basis that I got it to override
its own bias and admit its own mistake this way. It was
actually capable of introspection.
bro convincing an AI to say what u want is kinda trivial,
other people
are not, and i've learned a lot more in responding to real people vs AI
and i don't feel like having that debate, so we can just agree to
disagree on that point
also there are semantic paradoxes that no program could decide upon
On 12/18/2025 6:54 PM, dart200 wrote:
On 12/18/25 4:45 PM, polcott wrote:
On 12/18/2025 6:39 PM, dart200 wrote:
On 12/18/25 4:35 PM, Chris M. Thomasson wrote:
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" >>>>>>>>>> does.
For a given program, the creator can create a halting decider >>>>>>>>> for its logic. Does this path halt or not, well, we know, we >>>>>>>>> made the damn thing. But, there is no one universal decider... >>>>>>>>>
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If
you call into other programs, well, shit happens. But your own
logic, you know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't >>>>>> written down because "muh undecidability"
There can be a specialized halting decider for a program, but not
one decider for any program.
thank you for repeating the consensus that has been repeated at me
100s of times now
It is best to think of most of them as not very smart bots.
On the other hand Claude AI is so fabulous at semantic
entailment from a correct basis that I got it to override
its own bias and admit its own mistake this way. It was
actually capable of introspection.
bro convincing an AI to say what u want is kinda trivial,
I got forty pages of pushback before I could rephrase
my point from first principles derived from standard
definitions.
other people are not, and i've learned a lot more in responding to
real people vs AI
I have not actually learned anything from anyone
here except the most important notion of a computable
function.
Besides that everyone has consistently remained as a
broken record of "you are wrong and we can't show why".
and i don't feel like having that debate, so we can just agree to
disagree on that point
also there are semantic paradoxes that no program could decide upon
On 12/18/2025 4:39 PM, dart200 wrote:
On 12/18/25 4:35 PM, Chris M. Thomasson wrote:
On 12/17/2025 11:13 PM, dart200 wrote:
On 12/17/25 10:17 PM, Chris M. Thomasson wrote:
On 12/17/2025 10:14 PM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>>>For a given program, the creator can create a halting decider for >>>>>>> its logic. Does this path halt or not, well, we know, we made the >>>>>>> damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
If you create a program you know what paths its going down. If you
call into other programs, well, shit happens. But your own logic,
you know what you are doing when you made the program.
w/e, i think "your own logic" is following an algo we just haven't
written down because "muh undecidability"
There can be a specialized halting decider for a program, but not one
decider for any program.
thank you for repeating the consensus that has been repeated at me
100s of times now
also there are semantic paradoxes that no program could decide upon
Well, think of a program that uses a TRNG for its logic. WE as the
creator know what path means what, but we do not know what paths its--
going to take as it runs. Think of of a weighted IFS.
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for its
logic. Does this path halt or not, well, we know, we made the damn
thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to be able
to get very far.
The key point is that with logic, we can sometimes find "inductive"
paths that let us look into the infinite that we can't evaluate all of individually,
On 12/17/25 9:06 PM, Richard Damon wrote:
On 12/17/25 11:50 PM, dart200 wrote:
On 12/17/25 8:30 PM, Richard Damon wrote:
On 12/17/25 8:05 PM, dart200 wrote:
On 12/17/25 2:09 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:54 PM, dart200 wrote:
On 12/17/25 1:24 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:14 PM, Chris M. Thomasson wrote:
On 12/17/2025 1:07 PM, dart200 wrote:
[...]
How do you deal with a case where its not a lie, (e.g., can >>>>>>>>> pass many lie detector tests) if _they_ believe its true?
Remember what happened to that doctor in the Andromeda Strain? >>>>>>>> That blinking red light made her miss that sample where the
viral agent sample was destroyed, no growth... She would say she >>>>>>>> missed nothing...
no idea what ur tryin to say tbh
Still not sure how you solve the halting paradox unless you
already know the answer for any path taken in a program under
consideration.
because the paradox is an inability to decide between two known
branches, both of which have decidable effects (one halts, one runs >>>>> forever)
i'm concerned with showing how we can fix that inability. i'm not
concerned with deciding on paths that have no branching, as that
was never the demonstrated problem, as such u need branching to
form a decision paradox
But there are not two branches in the behavior of the input, but
only one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
dick, the classic halting decider doesn't exist, so why would a
resolution that might actually exist, be fixed to referencing a
certainly non-existent machine??? 🙄🙄🙄
I guess you just don't know what you are talking about.
While no halt deciders exist, the "inteface that they define" does.
Note, part of that interface is that the input is a PROGRAM, which
contains ALL of its code, and not a "external link" to something else.
That means any talk of some other decider, doesn't change the behavior
of the input.
that hypothesized input involving the classic halting decider DOES NOT
EXIST
if the fixed decider actually does exist, it only needs to decide on machines THAT ACTUALLY EXIST, which does NOT include the hypothesized classic haling decider
the only input a fixed decider needs to decide on are those machines possibly involving fixed decider, NOT a classical decider
Thus, imaginign that you function returns something else, doesn't
change the return value of the copy of the function inside the machine
in the input, and thus you don't get your incoherence, just proof that
you functions were wrong, and can't call the machie incoherent.
main = () -> {
und = () -> {
if ( halts(und) ) // this instance is deciding from
loop() // within the context of main.und
else
halt()
}
if ( halts(und) ) // this instance is deciding from
print 'und halts' // within the context of main
else
print 'und does not halt'
}
the decision returned by halts(und) does not "change" the runtime of
und(). und() only has one possible runtime execution, and it never
actually runs in this example. to let me know u actually are following
what i'm trying to propose:
what do *i* propose main() prints when run?
i'm not interested in whether you accept my viewpoint this time, i--
already know u don't, so please don't explain, i'm sure you will
anyways... but what i'm interested in is whether you actually have
actually understood the proposal i'm trying to make
When we imagine a different decider, we can create a totally
different input that makes that one wrong too.
The two branches are only there at the meta level, not at the actual
level were we do the actual computation.
obviously, because the paradox arises in meta-analysis, not actual
computation 👍👍👍
except ... isn't the meta-analysis actually a computation itself? or
do u think we're doing meta-analysis that somehow transcends
computation?
Nope. The Meta-Analysis is not a computation, but logic that produces
the program that does the computation.
The Meta-Analysis can add "meaning" to the purely syntactic operations
of the program, but isn't itself a computation.
i don't agree our meta-analysis of hypothetical computing machines transcends computing
we may have to leave off just disagreeing on these points. i'm not sure
how we can make progress if u keep insisting a real decider would need
to decide on hypothesized machines that can't exist
On 12/18/2025 5:03 AM, Mikko wrote:
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
That is the wrong question.
On 18/12/2025 15:06, olcott wrote:
On 12/18/2025 5:03 AM, Mikko wrote:
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
That is the wrong question.
That is a perfietly vailid question about your "semantic meaning".
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does.
For a given program, the creator can create a halting decider for
its logic. Does this path halt or not, well, we know, we made the
damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to be
able to get very far.
The key point is that with logic, we can sometimes find "inductive"
paths that let us look into the infinite that we can't evaluate all of
individually,
we're not doing any analysis that transcends computing
we're just intuitively creating directed graph models representative of
the computational flow, which we then use internally to reckon about computations and create the discussions we're having
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>For a given program, the creator can create a halting decider for
its logic. Does this path halt or not, well, we know, we made the
damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to be
able to get very far.
The key point is that with logic, we can sometimes find "inductive"
paths that let us look into the infinite that we can't evaluate all
of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely mechanical operation, and thus isn't "analysis" in form.
we're just intuitively creating directed graph models representative
of the computational flow, which we then use internally to reckon
about computations and create the discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works.
The only "Graph" you can draw is of the state machine, which is
dependent on the input on how you traverse it.
Or, you create a list (not a graph) of the execution history of the
machine running. Such a list, of course, might be infinite in length if
the machine doesn't halt, and doesn't leave a lot to "discuss".
And when one machine uses another, you don't graph over to the other as
a sub-graph like a "call" instruction in a higher level language, but by making a copy of that machine, relabeling the states to keep them unique
in the machine, and embedding it.
Thus, pieces of machines can't know if there section of graph represents
a given graph, as that sort of identity doesn't exist as something computable.
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>>For a given program, the creator can create a halting decider for >>>>>> its logic. Does this path halt or not, well, we know, we made the >>>>>> damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to be
able to get very far.
The key point is that with logic, we can sometimes find "inductive"
paths that let us look into the infinite that we can't evaluate all
of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely mechanical
operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
we're just intuitively creating directed graph models representative
of the computational flow, which we then use internally to reckon
about computations and create the discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works.
The only "Graph" you can draw is of the state machine, which is
dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable sets of input,
2) or u can just require "inputs" to be baked into the initial part of
the machine-description, in which case sets of machines would map to
various results of the machine with input that ur trying to analyze
claiming that halitng problem to be fundamental undecidable is claiming
that there is some machine at some point, that takes no input, that is
yet still undecidable
Or, you create a list (not a graph) of the execution history of the
machine running. Such a list, of course, might be infinite in length
if the machine doesn't halt, and doesn't leave a lot to "discuss".
And when one machine uses another, you don't graph over to the other
as a sub-graph like a "call" instruction in a higher level language,
but by making a copy of that machine, relabeling the states to keep
them unique in the machine, and embedding it.
one can also just embed the sub-function description into the main
function directly without the simulation infrastructure.
Thus, pieces of machines can't know if there section of graph
represents a given graph, as that sort of identity doesn't exist as
something computable.
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the input represents, something you are trying to say is out of scope, but that
means that you are trying to put semantics out of scope.
On 12/18/25 4:46 PM, Chris M. Thomasson wrote:[...]
Well, think of a program that uses a TRNG for its logic. WE as the
chris: turing machines are fully deterministic and cannot involve TRNGs
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the input
represents, something you are trying to say is out of scope, but that
means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you directly
run it, and other properties. You may infer them by other means such as
by translating the program to an input for a different machine and
running that which then reports or fails to report on properties of the original program; that includes, but is not limited to, halting with the
same final state as the original program would on.
On 12/18/2025 8:57 PM, dart200 wrote:
On 12/18/25 4:46 PM, Chris M. Thomasson wrote:[...]
Well, think of a program that uses a TRNG for its logic. WE as the
chris: turing machines are fully deterministic and cannot involve TRNGs
What about a PRNG? ;^)
[...]
On 12/18/2025 8:57 PM, dart200 wrote:
On 12/18/25 4:46 PM, Chris M. Thomasson wrote:[...]
Well, think of a program that uses a TRNG for its logic. WE as the
chris: turing machines are fully deterministic and cannot involve TRNGs
What about a PRNG? ;^)
[...]
On 12/19/25 2:09 PM, Chris M. Thomasson wrote:
On 12/18/2025 8:57 PM, dart200 wrote:
On 12/18/25 4:46 PM, Chris M. Thomasson wrote:[...]
Well, think of a program that uses a TRNG for its logic. WE as the
chris: turing machines are fully deterministic and cannot involve TRNGs
What about a PRNG? ;^)
ofc but undecidability never involved that either,
"hard to compute" is not the same as "impossible to compute"
[...]
On 12/19/25 2:09 PM, Chris M. Thomasson wrote:
On 12/18/2025 8:57 PM, dart200 wrote:
On 12/18/25 4:46 PM, Chris M. Thomasson wrote:[...]
Well, think of a program that uses a TRNG for its logic. WE as the
chris: turing machines are fully deterministic and cannot involve TRNGs
What about a PRNG? ;^)
ofc but undecidability never involved that either,
"hard to compute" is not the same as "impossible to compute"
[...]
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" does. >>>>>>>For a given program, the creator can create a halting decider for >>>>>>> its logic. Does this path halt or not, well, we know, we made the >>>>>>> damn thing. But, there is no one universal decider...
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to be
able to get very far.
The key point is that with logic, we can sometimes find "inductive" >>>>> paths that let us look into the infinite that we can't evaluate all >>>>> of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely mechanical
operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental error in
your reasoning.
we're just intuitively creating directed graph models representative
of the computational flow, which we then use internally to reckon
about computations and create the discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works.
The only "Graph" you can draw is of the state machine, which is
dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable sets
of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can duplicate a computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding will
specify a unique set of equivalent modules, but not any one in
particular, since they are duplicatable.
2) or u can just require "inputs" to be baked into the initial part of
the machine-description, in which case sets of machines would map to
various results of the machine with input that ur trying to analyze
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
problem, but by further logic from the undecability of the problem, we
get that there does exist machines whose behavior is unknowable.
If you try to limit the problem to just one machine, then it is ALWAYS decidable, as either Accept(x) or Reject(x) will be right (were
Accept(x) accepts all inputs, and Reject(x) rejects all inputs), we just won't know which one was right.
For any decider, we CAN create an input that it will not correctly
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
Or, you create a list (not a graph) of the execution history of the
machine running. Such a list, of course, might be infinite in length
if the machine doesn't halt, and doesn't leave a lot to "discuss".
And when one machine uses another, you don't graph over to the other
as a sub-graph like a "call" instruction in a higher level language,
but by making a copy of that machine, relabeling the states to keep
them unique in the machine, and embedding it.
one can also just embed the sub-function description into the main
function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its
equivalence class within an input. Thus, can't use detection of such a "self-reference" (which is a misuse of the term) as part of its algorithm.
Thus, pieces of machines can't know if there section of graph
represents a given graph, as that sort of identity doesn't exist as
something computable.
On 12/19/2025 4:02 AM, Mikko wrote:
On 18/12/2025 15:06, olcott wrote:
On 12/18/2025 5:03 AM, Mikko wrote:
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
That is the wrong question.
That is a perfietly vailid question about your "semantic meaning".
In computability theory, Rice's theorem states
that all non-trivial semantic properties of
programs are undecidable. A semantic property
is one about the program's behavior (for
instance, "does the program terminate for
all inputs?"), unlike a syntactic property
(for instance, "does the program contain an
if-then-else statement?"). A non-trivial
property is one that is neither true for
every program, nor false for every program. https://en.wikipedia.org/wiki/Rice%27s_theorem
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Those which the partial decider runs forever on.problem, but by further logic from the undecability of the problem, we
get that there does exist machines whose behavior is unknowable.
For any decider, we CAN create an input that it will not correctlyi mean if partial deciders exist, which i believe u agree they do...
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
then don't the programs they cannot decide on also exist??? because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look
like?
On 19/12/2025 16:44, olcott wrote:
On 12/19/2025 4:02 AM, Mikko wrote:
On 18/12/2025 15:06, olcott wrote:
On 12/18/2025 5:03 AM, Mikko wrote:
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
That is the wrong question.
That is a perfietly vailid question about your "semantic meaning".
In computability theory, Rice's theorem states
that all non-trivial semantic properties of
programs are undecidable. A semantic property
is one about the program's behavior (for
instance, "does the program terminate for
all inputs?"), unlike a syntactic property
(for instance, "does the program contain an
if-then-else statement?"). A non-trivial
property is one that is neither true for
every program, nor false for every program.
https://en.wikipedia.org/wiki/Rice%27s_theorem
Irrelevant to the question whether there are meanings other than
semantic.
This is the core of most of his logic, that it is ok to lie about^^^
something, because he tries to redefine a term, because he doesn't
understand the real definition of it, as he intentionally made himself
ignorant.
On 12/19/25 5:07 PM, Tristan Wibberley wrote:
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the input >>> represents, something you are trying to say is out of scope, but that
means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you directly
run it, and other properties. You may infer them by other means such as
by translating the program to an input for a different machine and
running that which then reports or fails to report on properties of the
original program; that includes, but is not limited to, halting with the
same final state as the original program would on.
"Meaning" should have a single source of truth. There may be alternate
ways to determine it, but those are shown to be correct, by being able
to trace it back to that original source.
Rice's proof was based on defined "Semantics" of strings representing machines, as having that meaning established by the running of the
program the input represents.
And thus, since H's "simulation" of the input doesn't match the actual behavior of running the program it represents, it is NOT possible for it--
to be a semanticc property of the machine.
UTMs, by there definition replicate the behavior of the machine their
input represents.
Since his H.UTM(w) did not do that, it can't be a UTM and thus it can't "override" the meaning of that property as given by the actual UTM.
His "definition" is just an attempt to say we are allowed to lie about properties.
This is the core of most of his logic, that it is ok to lie about
something, because he tries to redefine a term, because he doesn't understand the real definition of it, as he intentionally made himself ignorant.
On 19/12/2025 22:55, Richard Damon wrote:
This is the core of most of his logic, that it is ok to lie about^^^
something, because he tries to redefine a term, because he doesn't
understand the real definition of it, as he intentionally made himself
ignorant.
You have to use 'a' nearly all the time, rather than "the". Often we say
"the definition" when we mean "my mother's definition" or "/my/
professor's definition", or else "my search engine's definition" or "my
book seller's definition" when a school is pushed by such librarians in
the form of covertly selective search results.
On 12/19/2025 4:55 PM, Richard Damon wrote:
On 12/19/25 5:07 PM, Tristan Wibberley wrote:
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input
represents, something you are trying to say is out of scope, but that
means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you directly
run it, and other properties. You may infer them by other means such as
by translating the program to an input for a different machine and
running that which then reports or fails to report on properties of the
original program; that includes, but is not limited to, halting with the >>> same final state as the original program would on.
"Meaning" should have a single source of truth. There may be alternate
ways to determine it, but those are shown to be correct, by being able
to trace it back to that original source.
Rice's proof was based on defined "Semantics" of strings representing
machines, as having that meaning established by the running of the
program the input represents.
The halt decider cannot run a machine it can
only apply finite string transformation rules
to input finite strings.
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" >>>>>>>>> does.
For a given program, the creator can create a halting decider >>>>>>>> for its logic. Does this path halt or not, well, we know, we
made the damn thing. But, there is no one universal decider... >>>>>>>>
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to be >>>>>> able to get very far.
The key point is that with logic, we can sometimes find
"inductive" paths that let us look into the infinite that we can't >>>>>> evaluate all of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely mechanical
operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental error in
your reasoning.
this is doubling down on unbecoming semantic quibbling. for someone
who's had a career longer than i've been alive ... 🤡🌎
we're just intuitively creating directed graph models
representative of the computational flow, which we then use
internally to reckon about computations and create the discussions
we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works.
The only "Graph" you can draw is of the state machine, which is
dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable sets
of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can duplicate a
computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding will
specify a unique set of equivalent modules, but not any one in
particular, since they are duplicatable.
bruh u disagree with the one-to-one bijection between TMs and ℕ? for any given machine there are *possibly* infinite /equivalent/ machines (tho certain machines involving quines may not have equivalents) ... but
machines themselves are unique
2) or u can just require "inputs" to be baked into the initial part
of the machine-description, in which case sets of machines would map
to various results of the machine with input that ur trying to analyze
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
problem, but by further logic from the undecability of the problem, we
get that there does exist machines whose behavior is unknowable.
If you try to limit the problem to just one machine, then it is ALWAYS
decidable, as either Accept(x) or Reject(x) will be right (were
Accept(x) accepts all inputs, and Reject(x) rejects all inputs), we
just won't know which one was right.
For any decider, we CAN create an input that it will not correctly
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
i mean if partial deciders exist, which i believe u agree they do...
then don't the programs they cannot decide on also exist??? because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look like?
or is this another dumb case of u can't actually tell me what machine
the decider can't decide on cause then ur whole house of cards falls
apart again? sheesh 😒😒😒
Or, you create a list (not a graph) of the execution history of the
machine running. Such a list, of course, might be infinite in length
if the machine doesn't halt, and doesn't leave a lot to "discuss".
And when one machine uses another, you don't graph over to the other
as a sub-graph like a "call" instruction in a higher level language,
but by making a copy of that machine, relabeling the states to keep
them unique in the machine, and embedding it.
one can also just embed the sub-function description into the main
function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its
quines allow for a machines (and therefore deciders) that are wholly
unique in their output (*any* change to the machine changes it's output
on at least one input in a way that no other machine can match)
i went over that in another post u didn't respond to
equivalence class within an input. Thus, can't use detection of such a
"self-reference" (which is a misuse of the term) as part of its
algorithm.
Thus, pieces of machines can't know if there section of graph
represents a given graph, as that sort of identity doesn't exist as
something computable.
On 12/20/25 8:00 AM, polcott wrote:
On 12/19/2025 4:55 PM, Richard Damon wrote:
On 12/19/25 5:07 PM, Tristan Wibberley wrote:
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about
a meaning, which is a computation. Therefore the measure of the
behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the
input
represents, something you are trying to say is out of scope, but that >>>>> means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you directly
run it, and other properties. You may infer them by other means such as >>>> by translating the program to an input for a different machine and
running that which then reports or fails to report on properties of the >>>> original program; that includes, but is not limited to, halting with
the
same final state as the original program would on.
"Meaning" should have a single source of truth. There may be
alternate ways to determine it, but those are shown to be correct, by
being able to trace it back to that original source.
Rice's proof was based on defined "Semantics" of strings representing
machines, as having that meaning established by the running of the
program the input represents.
The halt decider cannot run a machine it can
only apply finite string transformation rules
to input finite strings.
So?
It doesn't need to run the machine, only give an answer that is
correctly determined by doing so.
It isn't much of a test if you require that every question include the answer as part of the question.--
You don't seem to understand the concept of REQUIREMENTS.
But then, since you seem to reject the basic concept of Truth and Correctness, that seems consistant with your logic system.
On 12/20/2025 7:32 AM, Richard Damon wrote:
On 12/20/25 8:00 AM, polcott wrote:
On 12/19/2025 4:55 PM, Richard Damon wrote:
On 12/19/25 5:07 PM, Tristan Wibberley wrote:
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about >>>>>>>> a meaning, which is a computation. Therefore the measure of the >>>>>>>> behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program the >>>>>> input
represents, something you are trying to say is out of scope, but that >>>>>> means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you directly >>>>> run it, and other properties. You may infer them by other means
such as
by translating the program to an input for a different machine and
running that which then reports or fails to report on properties of >>>>> the
original program; that includes, but is not limited to, halting
with the
same final state as the original program would on.
"Meaning" should have a single source of truth. There may be
alternate ways to determine it, but those are shown to be correct,
by being able to trace it back to that original source.
Rice's proof was based on defined "Semantics" of strings
representing machines, as having that meaning established by the
running of the program the input represents.
The halt decider cannot run a machine it can
only apply finite string transformation rules
to input finite strings.
So?
It doesn't need to run the machine, only give an answer that is
correctly determined by doing so.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
In cases of a pathological self-reference relationship
between Decider H and Input P such that there are no
finite string transformation rules that H can apply to
P to derive the behavior of UTM(P) the behavior of UTM(P)
is overruled as out-of-scope for Turing machine deciders.
It isn't much of a test if you require that every question include the
answer as part of the question.
You don't seem to understand the concept of REQUIREMENTS.
But then, since you seem to reject the basic concept of Truth and
Correctness, that seems consistant with your logic system.
On 12/20/25 9:07 AM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote:
On 12/20/25 8:00 AM, polcott wrote:
On 12/19/2025 4:55 PM, Richard Damon wrote:
On 12/19/25 5:07 PM, Tristan Wibberley wrote:
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about >>>>>>>>> a meaning, which is a computation. Therefore the measure of the >>>>>>>>> behaviour is the computation asked about. If the input string >>>>>>>>> does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program
the input
represents, something you are trying to say is out of scope, but >>>>>>> that
means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you directly >>>>>> run it, and other properties. You may infer them by other means
such as
by translating the program to an input for a different machine and >>>>>> running that which then reports or fails to report on properties
of the
original program; that includes, but is not limited to, halting
with the
same final state as the original program would on.
"Meaning" should have a single source of truth. There may be
alternate ways to determine it, but those are shown to be correct,
by being able to trace it back to that original source.
Rice's proof was based on defined "Semantics" of strings
representing machines, as having that meaning established by the
running of the program the input represents.
The halt decider cannot run a machine it can
only apply finite string transformation rules
to input finite strings.
So?
It doesn't need to run the machine, only give an answer that is
correctly determined by doing so.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
Right,
In cases of a pathological self-reference relationship
between Decider H and Input P such that there are no
finite string transformation rules that H can apply to
P to derive the behavior of UTM(P) the behavior of UTM(P)
is overruled as out-of-scope for Turing machine deciders.
But since H is (or needs to be) a Turing Machine, the copy of it in P
gives some definite answer,
and thus P has a definite behavior, and thus
UTM(P) does have a definite behavior, defining the right answer that H should have given.
The fact that H didn't give that answer, just makes H wrong.
The fact that the claimed "UTM" at H.UTM doesn't match the behavior of
the actual P just says you LIE when you call it a UTM.
All you are doing is proving you are just a stupid liar.
LIES do not overrule truth, except in the mind of a pathological liar.
Note, the behavior of UTM(P) is NOT out of scope of Turing Machine
deciders, just not computable with finite work.
There is a difference, but that seems to be beyond your self-imposed ignorant understanding.
It isn't much of a test if you require that every question include
the answer as part of the question.
You don't seem to understand the concept of REQUIREMENTS.
But then, since you seem to reject the basic concept of Truth and
Correctness, that seems consistant with your logic system.
On 12/20/2025 8:41 AM, Richard Damon wrote:
On 12/20/25 9:07 AM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote:
On 12/20/25 8:00 AM, polcott wrote:
On 12/19/2025 4:55 PM, Richard Damon wrote:
On 12/19/25 5:07 PM, Tristan Wibberley wrote:
On 18/12/2025 04:29, Richard Damon wrote:
On 12/17/25 11:08 PM, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
The halting problem does not ask about a string. It asks about >>>>>>>>>> a meaning, which is a computation. Therefore the measure of the >>>>>>>>>> behaviour is the computation asked about. If the input string >>>>>>>>>> does not specify that behaviour then it is a wrong string. >>>>>>>>>>
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within >>>>>>>>>>> finite string transformation rules) than P simulated by H. >>>>>>>>>>
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
And "Semantic Meaning" relates to directly running the program >>>>>>>> the input
represents, something you are trying to say is out of scope, but >>>>>>>> that
means that you are trying to put semantics out of scope.
eh? I'm sure it relates to what /would/ have happened if you
directly
run it, and other properties. You may infer them by other means >>>>>>> such as
by translating the program to an input for a different machine and >>>>>>> running that which then reports or fails to report on properties >>>>>>> of the
original program; that includes, but is not limited to, halting >>>>>>> with the
same final state as the original program would on.
"Meaning" should have a single source of truth. There may be
alternate ways to determine it, but those are shown to be correct, >>>>>> by being able to trace it back to that original source.
Rice's proof was based on defined "Semantics" of strings
representing machines, as having that meaning established by the
running of the program the input represents.
The halt decider cannot run a machine it can
only apply finite string transformation rules
to input finite strings.
So?
It doesn't need to run the machine, only give an answer that is
correctly determined by doing so.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
Right,
In cases of a pathological self-reference relationship
between Decider H and Input P such that there are no
finite string transformation rules that H can apply to
P to derive the behavior of UTM(P) the behavior of UTM(P)
is overruled as out-of-scope for Turing machine deciders.
But since H is (or needs to be) a Turing Machine, the copy of it in P
gives some definite answer,
P simulated by H cannot possibly receive
any return value from H because it remains
stuck in recursive simulation until aborted.
The caller of H cannot possibly be one-and-the-same
thing as the argument to H.
and thus P has a definite behavior, and thus
That cannot be derived by H applying finite string
transformation rules to its input P.
UTM(P) does have a definite behavior, defining the right answer that H
should have given.
Yet UTM(P) specifies a different sequence of steps.
After the simulation of P has been aborted as opposed
to and contrast with before the simulation has been
aborted.
The fact that H didn't give that answer, just makes H wrong.
The fact that the claimed "UTM" at H.UTM doesn't match the behavior of
the actual P just says you LIE when you call it a UTM.
All you are doing is proving you are just a stupid liar.
LIES do not overrule truth, except in the mind of a pathological liar.
Note, the behavior of UTM(P) is NOT out of scope of Turing Machine
deciders, just not computable with finite work.
There is a difference, but that seems to be beyond your self-imposed
ignorant understanding.
It isn't much of a test if you require that every question include
the answer as part of the question.
You don't seem to understand the concept of REQUIREMENTS.
But then, since you seem to reject the basic concept of Truth and
Correctness, that seems consistant with your logic system.
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
No, of *sets* of instances.
problem, but by further logic from the undecability of the problem, we
get that there does exist machines whose behavior is unknowable.
Those which the partial decider runs forever on.For any decider, we CAN create an input that it will not correctlyi mean if partial deciders exist, which i believe u agree they do...
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
then don't the programs they cannot decide on also exist??? because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look
like?
On 12/20/25 3:21 AM, joes wrote:
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
No, of *sets* of instances.
Those which the partial decider runs forever on.problem, but by further logic from the undecability of the problem, we >>>> get that there does exist machines whose behavior is unknowable.
For any decider, we CAN create an input that it will not correctlyi mean if partial deciders exist, which i believe u agree they do...
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
then don't the programs they cannot decide on also exist??? because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look
like?
example?
On 12/20/25 2:32 PM, dart200 wrote:
On 12/20/25 3:21 AM, joes wrote:
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
No, of *sets* of instances.
Those which the partial decider runs forever on.problem, but by further logic from the undecability of the problem, we >>>>> get that there does exist machines whose behavior is unknowable.
For any decider, we CAN create an input that it will not correctlyi mean if partial deciders exist, which i believe u agree they do...
decider, as the proof shows, and thus for ANY possible decider there >>>>> EXIST an input it will not be correct for, and thus, we can say that >>>>> there is NO decider that is correct for ALL inputs.
then don't the programs they cannot decide on also exist??? because if >>>> they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look
like?
example?
PD(x) { UTM(x); return true; }
int looper() { while (1) continue; }
int main() {
return PD(looper);
}
PD, since it uses a poor decider, that will only succeed on halting
input, will just loop forever when given a non-halting input.
The programs that make a given partial decider loop forever depend on
the particular decider.
On 12/20/25 11:50 AM, Richard Damon wrote:
On 12/20/25 2:32 PM, dart200 wrote:
On 12/20/25 3:21 AM, joes wrote:
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no >>>>>>> input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
No, of *sets* of instances.
Those which the partial decider runs forever on.problem, but by further logic from the undecability of the
problem, we
get that there does exist machines whose behavior is unknowable.
For any decider, we CAN create an input that it will not correctly >>>>>> decider, as the proof shows, and thus for ANY possible decider there >>>>>> EXIST an input it will not be correct for, and thus, we can say that >>>>>> there is NO decider that is correct for ALL inputs.i mean if partial deciders exist, which i believe u agree they do... >>>>> then don't the programs they cannot decide on also exist??? because if >>>>> they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look >>>>> like?
example?
PD(x) { UTM(x); return true; }
int looper() { while (1) continue; }
int main() {
return PD(looper);
}
PD, since it uses a poor decider, that will only succeed on halting
input, will just loop forever when given a non-halting input.
The programs that make a given partial decider loop forever depend on
the particular decider.
can it really be called a decider, partial or otherwise, if it *never* returns false when the input is non-terminating???
at best i think you might be able to call it a recognizer, but it's the
most trivial one you could make.
On 12/20/25 4:16 PM, dart200 wrote:
On 12/20/25 11:50 AM, Richard Damon wrote:
On 12/20/25 2:32 PM, dart200 wrote:
On 12/20/25 3:21 AM, joes wrote:
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
claiming that halitng problem to be fundamental undecidable is >>>>>>>> claiming that there is some machine at some point, that takes no >>>>>>>> input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
No, of *sets* of instances.
Those which the partial decider runs forever on.problem, but by further logic from the undecability of the
problem, we
get that there does exist machines whose behavior is unknowable.
For any decider, we CAN create an input that it will not correctly >>>>>>> decider, as the proof shows, and thus for ANY possible decider there >>>>>>> EXIST an input it will not be correct for, and thus, we can say that >>>>>>> there is NO decider that is correct for ALL inputs.i mean if partial deciders exist, which i believe u agree they do... >>>>>> then don't the programs they cannot decide on also exist???
because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look >>>>>> like?
example?
PD(x) { UTM(x); return true; }
int looper() { while (1) continue; }
int main() {
return PD(looper);
}
PD, since it uses a poor decider, that will only succeed on halting
input, will just loop forever when given a non-halting input.
The programs that make a given partial decider loop forever depend on
the particular decider.
can it really be called a decider, partial or otherwise, if it *never*
returns false when the input is non-terminating???
Sure. Partial deciders only need to only give correct answer, and never wrong one. (At least that is the more useful version of the definition).
--
at best i think you might be able to call it a recognizer, but it's
the most trivial one you could make.
In this case it also is a recognizer. That is defined to ALWAYS accept
if the input matches the condition, but might not answer for some reject cases.
Recognizers are sort of a special case of partial deciders.
Just like full deciders are a special case of Recognizers, that never
use the option of not answering.
On 12/20/2025 4:02 PM, Richard Damon wrote:
On 12/20/25 4:16 PM, dart200 wrote:
On 12/20/25 11:50 AM, Richard Damon wrote:
On 12/20/25 2:32 PM, dart200 wrote:
On 12/20/25 3:21 AM, joes wrote:
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
well it's a property of hypothetical instancesclaiming that halitng problem to be fundamental undecidable is >>>>>>>>> claiming that there is some machine at some point, that takes no >>>>>>>>> input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a >>>>>>>
No, of *sets* of instances.
Those which the partial decider runs forever on.problem, but by further logic from the undecability of thei mean if partial deciders exist, which i believe u agree they do... >>>>>>> then don't the programs they cannot decide on also exist???
problem, we
get that there does exist machines whose behavior is unknowable. >>>>>>
For any decider, we CAN create an input that it will not correctly >>>>>>>> decider, as the proof shows, and thus for ANY possible decider >>>>>>>> there
EXIST an input it will not be correct for, and thus, we can say >>>>>>>> that
there is NO decider that is correct for ALL inputs.
because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually look >>>>>>> like?
example?
PD(x) { UTM(x); return true; }
int looper() { while (1) continue; }
int main() {
return PD(looper);
}
PD, since it uses a poor decider, that will only succeed on halting
input, will just loop forever when given a non-halting input.
The programs that make a given partial decider loop forever depend
on the particular decider.
can it really be called a decider, partial or otherwise, if it
*never* returns false when the input is non-terminating???
Sure. Partial deciders only need to only give correct answer, and
never wrong one. (At least that is the more useful version of the
definition).
You do know this stuff pretty well.
Even a decider that simulates its input and
returns true and gets stuck in a loop for
all non-halting inputs may be a correct partial
halt decider.
at best i think you might be able to call it a recognizer, but it's
the most trivial one you could make.
In this case it also is a recognizer. That is defined to ALWAYS accept
if the input matches the condition, but might not answer for some
reject cases.
Recognizers are sort of a special case of partial deciders.
Just like full deciders are a special case of Recognizers, that never
use the option of not answering.
On 12/20/25 5:41 PM, olcott wrote:
On 12/20/2025 4:02 PM, Richard Damon wrote:
On 12/20/25 4:16 PM, dart200 wrote:
On 12/20/25 11:50 AM, Richard Damon wrote:
On 12/20/25 2:32 PM, dart200 wrote:
On 12/20/25 3:21 AM, joes wrote:
Am Sat, 20 Dec 2025 01:17:22 -0800 schrieb dart200:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
well it's a property of hypothetical instancesclaiming that halitng problem to be fundamental undecidable is >>>>>>>>>> claiming that there is some machine at some point, that takes no >>>>>>>>>> input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a >>>>>>>>
No, of *sets* of instances.
Those which the partial decider runs forever on.problem, but by further logic from the undecability of thei mean if partial deciders exist, which i believe u agree they >>>>>>>> do...
problem, we
get that there does exist machines whose behavior is unknowable. >>>>>>>
For any decider, we CAN create an input that it will not correctly >>>>>>>>> decider, as the proof shows, and thus for ANY possible decider >>>>>>>>> there
EXIST an input it will not be correct for, and thus, we can say >>>>>>>>> that
there is NO decider that is correct for ALL inputs.
then don't the programs they cannot decide on also exist???
because if
they don't, then they aren't actually partial deciders.
furthermore ... what form does those kinds of programs actually >>>>>>>> look
like?
example?
PD(x) { UTM(x); return true; }
int looper() { while (1) continue; }
int main() {
return PD(looper);
}
PD, since it uses a poor decider, that will only succeed on halting >>>>> input, will just loop forever when given a non-halting input.
The programs that make a given partial decider loop forever depend
on the particular decider.
can it really be called a decider, partial or otherwise, if it
*never* returns false when the input is non-terminating???
Sure. Partial deciders only need to only give correct answer, and
never wrong one. (At least that is the more useful version of the
definition).
You do know this stuff pretty well.
Even a decider that simulates its input and
returns true and gets stuck in a loop for
all non-halting inputs may be a correct partial
halt decider.
Sure, but partial halt deciders are nothing new.
We have done much better that that for decades, we can make halt
deciders that get all Halting Machines correctly (but might take a long time) and get many non-halting machines correctly (and all that keep themselves bounded in tape usage), and NEVER get an input wrong.
Thus, there is nothing wrong with the criteria of deciding on the
behavior of the machine described by the input, irregardless of your
failure to accept that fact. It just shows that you are just a
pathological liar.
at best i think you might be able to call it a recognizer, but it's
the most trivial one you could make.
In this case it also is a recognizer. That is defined to ALWAYS
accept if the input matches the condition, but might not answer for
some reject cases.
Recognizers are sort of a special case of partial deciders.
Just like full deciders are a special case of Recognizers, that never
use the option of not answering.
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" >>>>>>>>>> does.
For a given program, the creator can create a halting decider >>>>>>>>> for its logic. Does this path halt or not, well, we know, we >>>>>>>>> made the damn thing. But, there is no one universal decider... >>>>>>>>>
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to >>>>>>> be able to get very far.
The key point is that with logic, we can sometimes find
"inductive" paths that let us look into the infinite that we
can't evaluate all of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely
mechanical operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental error
in your reasoning.
this is doubling down on unbecoming semantic quibbling. for someone
who's had a career longer than i've been alive ... 🤡🌎
In other words, you are just saying it is ok to lie.
THAT isn't quibbling, that is just a fact proven by your statements.
You should respect those with far greater knowledge than you, rather
than thinking they are unimportant.
we're just intuitively creating directed graph models
representative of the computational flow, which we then use
internally to reckon about computations and create the discussions >>>>>> we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works. >>>>>
The only "Graph" you can draw is of the state machine, which is
dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable sets
of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can duplicate a
computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding will
specify a unique set of equivalent modules, but not any one in
particular, since they are duplicatable.
bruh u disagree with the one-to-one bijection between TMs and ℕ? for
any given machine there are *possibly* infinite /equivalent/ machines
(tho certain machines involving quines may not have equivalents) ...
but machines themselves are unique
No, only with the computableness of that bijection.
The problem with quines is that while they can produce A copy of one of their source codes, you can make many other programs that produce that identical source code, and thus, the code they produce is NOT a unique representation of them as a program.
The sub-class of programs called quines is NOT a Turing Complete system
by themselves, and thus is a less than interesting category.
2) or u can just require "inputs" to be baked into the initial part
of the machine-description, in which case sets of machines would map
to various results of the machine with input that ur trying to analyze
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that
yo0u refuse to learn it.
problem, but by further logic from the undecability of the problem,
we get that there does exist machines whose behavior is unknowable.
If you try to limit the problem to just one machine, then it is
ALWAYS decidable, as either Accept(x) or Reject(x) will be right
(were Accept(x) accepts all inputs, and Reject(x) rejects all
inputs), we just won't know which one was right.
For any decider, we CAN create an input that it will not correctly
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
i mean if partial deciders exist, which i believe u agree they do...
then don't the programs they cannot decide on also exist??? because if
they don't, then they aren't actually partial deciders.
Sure partial deciders exist. And we can find programs they will fail to decide on.
furthermore ... what form does those kinds of programs actually look
like?
WHy do they need a generic form?
or is this another dumb case of u can't actually tell me what machine
the decider can't decide on cause then ur whole house of cards falls
apart again? sheesh 😒😒😒
And that is your problem, you can't understand that there are things you
can not know.
For example, given a Halt Decider built on just using a UTM, and if it
halt, accept, ANY non-halting program, like a simple loop, will be a
machie that decider can't decide on.
Or, you create a list (not a graph) of the execution history of the >>>>> machine running. Such a list, of course, might be infinite in
length if the machine doesn't halt, and doesn't leave a lot to
"discuss".
And when one machine uses another, you don't graph over to the
other as a sub-graph like a "call" instruction in a higher level
language, but by making a copy of that machine, relabeling the
states to keep them unique in the machine, and embedding it.
one can also just embed the sub-function description into the main
function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its
quines allow for a machines (and therefore deciders) that are wholly
unique in their output (*any* change to the machine changes it's
output on at least one input in a way that no other machine can match)
But Quines are not a Turing Complete class of Programs.
There are alternative programs that generate the same output as a given Quine, so they are not unique PROGRAMS.
There are may examples of successful Halt Deciding on less than Turing Complete systems, so you need to show that your idea is at least as interesting and useful as some of those.
i went over that in another post u didn't respond to
Sometime you are just being to wordy and I don't have the time.
equivalence class within an input. Thus, can't use detection of such
a "self-reference" (which is a misuse of the term) as part of its
algorithm.
Thus, pieces of machines can't know if there section of graph
represents a given graph, as that sort of identity doesn't exist as >>>>> something computable.
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they define" >>>>>>>>>>> does.
For a given program, the creator can create a halting decider >>>>>>>>>> for its logic. Does this path halt or not, well, we know, we >>>>>>>>>> made the damn thing. But, there is no one universal decider... >>>>>>>>>>
[...]
how do we know that if there is no algo to compute that???
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to >>>>>>>> be able to get very far.
The key point is that with logic, we can sometimes find
"inductive" paths that let us look into the infinite that we
can't evaluate all of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely
mechanical operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental error
in your reasoning.
this is doubling down on unbecoming semantic quibbling. for someone
who's had a career longer than i've been alive ... 🤡🌎
In other words, you are just saying it is ok to lie.
not an argument
THAT isn't quibbling, that is just a fact proven by your statements.
still not an argument
You should respect those with far greater knowledge than you, rather
than thinking they are unimportant.
how can u be /of far greater knowledge/ when ur telling me to accept
origin fallacies instead of actual arguments???
inb4 u pathetically claim that arguments from authority aren't origin fallacies ... like, ok boomer ...
we're just intuitively creating directed graph models
representative of the computational flow, which we then use
internally to reckon about computations and create the
discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works. >>>>>>
The only "Graph" you can draw is of the state machine, which is
dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable
sets of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can duplicate a
computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding will
specify a unique set of equivalent modules, but not any one in
particular, since they are duplicatable.
bruh u disagree with the one-to-one bijection between TMs and ℕ? for
any given machine there are *possibly* infinite /equivalent/ machines
(tho certain machines involving quines may not have equivalents) ...
but machines themselves are unique
No, only with the computableness of that bijection.
we can enumerate that bijection. an inability to prove equivalence (same input->output) does not mean we cannot iterate over the machines in a
unique fashion.
The problem with quines is that while they can produce A copy of one
of their source codes, you can make many other programs that produce
that identical source code, and thus, the code they produce is NOT a
unique representation of them as a program.
The sub-class of programs called quines is NOT a Turing Complete
system by themselves, and thus is a less than interesting category.
a quine is a technique that can be used to produce an exact copy of a machine's source code *on the tape* (which may or may not form the
machines output). a quine computation can be stuck on the front of any arbitrary program, and therefore the class of programs that contain
quines is turing complete.
if all u did was read the wikipedia definition, then i get why ur trying
to argue it's a "class" of programs that output it's own source code.
the wikipedia article is wrong, it's a technique that integrated into
any machine for computation purposes (like recognizing itself)
2) or u can just require "inputs" to be baked into the initial part >>>>> of the machine-description, in which case sets of machines would
map to various results of the machine with input that ur trying to
analyze
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that
yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
we can compute this semantic property with a simple algo:
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the computation.
if the semantic results from (1) and (2) diverge from the injected prediction, the hypothetical machine is undecidable.
problem, but by further logic from the undecability of the problem,
we get that there does exist machines whose behavior is unknowable.
If you try to limit the problem to just one machine, then it is
ALWAYS decidable, as either Accept(x) or Reject(x) will be right
(were Accept(x) accepts all inputs, and Reject(x) rejects all
inputs), we just won't know which one was right.
For any decider, we CAN create an input that it will not correctly
decider, as the proof shows, and thus for ANY possible decider there
EXIST an input it will not be correct for, and thus, we can say that
there is NO decider that is correct for ALL inputs.
i mean if partial deciders exist, which i believe u agree they do...
then don't the programs they cannot decide on also exist??? because
if they don't, then they aren't actually partial deciders.
Sure partial deciders exist. And we can find programs they will fail
to decide on.
furthermore ... what form does those kinds of programs actually look
like?
WHy do they need a generic form?
do they have *any* form??? the fact u can't say what is actually
undecidable and are just asserting it *must* exist based on purely hypotheticals is just ... absurd
or is this another dumb case of u can't actually tell me what machine
the decider can't decide on cause then ur whole house of cards falls
apart again? sheesh 😒😒😒
And that is your problem, you can't understand that there are things
you can not know.
i don't believe in ghosts either
For example, given a Halt Decider built on just using a UTM, and if it
halt, accept, ANY non-halting program, like a simple loop, will be a
machie that decider can't decide on.
Or, you create a list (not a graph) of the execution history of
the machine running. Such a list, of course, might be infinite in >>>>>> length if the machine doesn't halt, and doesn't leave a lot to
"discuss".
And when one machine uses another, you don't graph over to the
other as a sub-graph like a "call" instruction in a higher level
language, but by making a copy of that machine, relabeling the
states to keep them unique in the machine, and embedding it.
one can also just embed the sub-function description into the main
function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its
quines allow for a machines (and therefore deciders) that are wholly
unique in their output (*any* change to the machine changes it's
output on at least one input in a way that no other machine can match)
But Quines are not a Turing Complete class of Programs.
There are alternative programs that generate the same output as a
given Quine, so they are not unique PROGRAMS.
There are may examples of successful Halt Deciding on less than Turing
Complete systems, so you need to show that your idea is at least as
interesting and useful as some of those.
i went over that in another post u didn't respond to
Sometime you are just being to wordy and I don't have the time.
equivalence class within an input. Thus, can't use detection of such
a "self-reference" (which is a misuse of the term) as part of its
algorithm.
Thus, pieces of machines can't know if there section of graph
represents a given graph, as that sort of identity doesn't exist
as something computable.
On 12/20/25 7:17 PM, dart200 wrote:
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they >>>>>>>>>>>> define" does.
For a given program, the creator can create a halting decider >>>>>>>>>>> for its logic. Does this path halt or not, well, we know, we >>>>>>>>>>> made the damn thing. But, there is no one universal decider... >>>>>>>>>>>
[...]
how do we know that if there is no algo to compute that??? >>>>>>>>>>
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going to >>>>>>>>> be able to get very far.
The key point is that with logic, we can sometimes find
"inductive" paths that let us look into the infinite that we >>>>>>>>> can't evaluate all of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely
mechanical operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental error >>>>> in your reasoning.
this is doubling down on unbecoming semantic quibbling. for someone
who's had a career longer than i've been alive ... 🤡🌎
In other words, you are just saying it is ok to lie.
not an argument
So, you admit your error.
THAT isn't quibbling, that is just a fact proven by your statements.
still not an argument
Again, you admit your error.
You should respect those with far greater knowledge than you, rather
than thinking they are unimportant.
how can u be /of far greater knowledge/ when ur telling me to accept
origin fallacies instead of actual arguments???
Because I am just rejecting your attempts to ignore the basics of the system.
inb4 u pathetically claim that arguments from authority aren't origin
fallacies ... like, ok boomer ...
Right, because I don't argue from "authority", I argue from definitions.
we're just intuitively creating directed graph models
representative of the computational flow, which we then use
internally to reckon about computations and create the
discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory works. >>>>>>>
The only "Graph" you can draw is of the state machine, which is >>>>>>> dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable
sets of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can duplicate
a computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding will >>>>> specify a unique set of equivalent modules, but not any one in
particular, since they are duplicatable.
bruh u disagree with the one-to-one bijection between TMs and ℕ? for >>>> any given machine there are *possibly* infinite /equivalent/
machines (tho certain machines involving quines may not have
equivalents) ... but machines themselves are unique
No, only with the computableness of that bijection.
we can enumerate that bijection. an inability to prove equivalence
(same input->output) does not mean we cannot iterate over the machines
in a unique fashion.
No you can't, as it is infinite in lenght, with an uncomputable basis.
To iterate over the machines, you need a detector function that tells
you if a given string is one of these machines. That is an undecidable proposition.
The problem with quines is that while they can produce A copy of one
of their source codes, you can make many other programs that produce
that identical source code, and thus, the code they produce is NOT a
unique representation of them as a program.
The sub-class of programs called quines is NOT a Turing Complete
system by themselves, and thus is a less than interesting category.
a quine is a technique that can be used to produce an exact copy of a
machine's source code *on the tape* (which may or may not form the
machines output). a quine computation can be stuck on the front of any
arbitrary program, and therefore the class of programs that contain
quines is turing complete.
Right, but since not all programs are quines, you can't use that
property of quines to number programs.
And if the output of the machine isn't supposed to be a representation
of it, you can't do that operation.
if all u did was read the wikipedia definition, then i get why ur
trying to argue it's a "class" of programs that output it's own source
code. the wikipedia article is wrong, it's a technique that integrated
into any machine for computation purposes (like recognizing itself)
You don't understand it as a class of programs?
And where do you see that it allows a general program to identify itself?
You might be able to generate a finite subset of the various
representations of the program, but that still doesn't meet your requirements.
2) or u can just require "inputs" to be baked into the initial
part of the machine-description, in which case sets of machines
would map to various results of the machine with input that ur
trying to analyze
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no
input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that
yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
No, und is a non-existant instance of an inpossible machine, since there
is not clasical halting decider.
You can't assume the existance of something that doesn't exist.
we can compute this semantic property with a simple algo:
You can't compute the property of a program that doesn't exist.
The problem that as a PROGRAM "und" includes the code for the decider
that it is calling, and thus trying to change it make your program/input something different than what it is.
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the computation.
if the semantic results from (1) and (2) diverge from the injected
prediction, the hypothetical machine is undecidable.
But that just make a major category error of looking at several
DIFFERENT programs and claiming they give the answer about an input that none of them were.
problem, but by further logic from the undecability of the problem, >>>>> we get that there does exist machines whose behavior is unknowable.
If you try to limit the problem to just one machine, then it is
ALWAYS decidable, as either Accept(x) or Reject(x) will be right
(were Accept(x) accepts all inputs, and Reject(x) rejects all
inputs), we just won't know which one was right.
For any decider, we CAN create an input that it will not correctly
decider, as the proof shows, and thus for ANY possible decider
there EXIST an input it will not be correct for, and thus, we can
say that there is NO decider that is correct for ALL inputs.
i mean if partial deciders exist, which i believe u agree they do...
then don't the programs they cannot decide on also exist??? because
if they don't, then they aren't actually partial deciders.
Sure partial deciders exist. And we can find programs they will fail
to decide on.
furthermore ... what form does those kinds of programs actually look
like?
WHy do they need a generic form?
do they have *any* form??? the fact u can't say what is actually
undecidable and are just asserting it *must* exist based on purely
hypotheticals is just ... absurd
The are programs of the system. That is there form. They will grow in
memory usage without bound, but that is somethig that can only be
deterimend with unbounded time.
They must exist, or we could create the proven impossible to create halt
decider. We just can never prove that a given program is in that class,
as being able to do so answers its halting question.
Yes, you are getting into the realm of hard to comprehend, but that is
the nature of dealing with the undecidable infinite.
or is this another dumb case of u can't actually tell me what
machine the decider can't decide on cause then ur whole house of
cards falls apart again? sheesh 😒😒😒
And that is your problem, you can't understand that there are things
you can not know.
i don't believe in ghosts either
That is your error. It means there will be things that you think you
know, but are wrong about, which is worse than not knowing.
For example, given a Halt Decider built on just using a UTM, and if
it halt, accept, ANY non-halting program, like a simple loop, will be
a machie that decider can't decide on.
Or, you create a list (not a graph) of the execution history of >>>>>>> the machine running. Such a list, of course, might be infinite in >>>>>>> length if the machine doesn't halt, and doesn't leave a lot to
"discuss".
And when one machine uses another, you don't graph over to the
other as a sub-graph like a "call" instruction in a higher level >>>>>>> language, but by making a copy of that machine, relabeling the
states to keep them unique in the machine, and embedding it.
one can also just embed the sub-function description into the main >>>>>> function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its
quines allow for a machines (and therefore deciders) that are wholly
unique in their output (*any* change to the machine changes it's
output on at least one input in a way that no other machine can match)
But Quines are not a Turing Complete class of Programs.
There are alternative programs that generate the same output as a
given Quine, so they are not unique PROGRAMS.
There are may examples of successful Halt Deciding on less than
Turing Complete systems, so you need to show that your idea is at
least as interesting and useful as some of those.
i went over that in another post u didn't respond to
Sometime you are just being to wordy and I don't have the time.
equivalence class within an input. Thus, can't use detection of
such a "self-reference" (which is a misuse of the term) as part of
its algorithm.
Thus, pieces of machines can't know if there section of graph
represents a given graph, as that sort of identity doesn't exist >>>>>>> as something computable.
On 12/20/25 4:42 PM, Richard Damon wrote:
On 12/20/25 7:17 PM, dart200 wrote:
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they >>>>>>>>>>>>> define" does.
For a given program, the creator can create a halting >>>>>>>>>>>> decider for its logic. Does this path halt or not, well, we >>>>>>>>>>>> know, we made the damn thing. But, there is no one universal >>>>>>>>>>>> decider...
[...]
how do we know that if there is no algo to compute that??? >>>>>>>>>>>
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going >>>>>>>>>> to be able to get very far.
The key point is that with logic, we can sometimes find
"inductive" paths that let us look into the infinite that we >>>>>>>>>> can't evaluate all of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely
mechanical operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental
error in your reasoning.
this is doubling down on unbecoming semantic quibbling. for someone >>>>> who's had a career longer than i've been alive ... 🤡🌎
In other words, you are just saying it is ok to lie.
not an argument
So, you admit your error.
THAT isn't quibbling, that is just a fact proven by your statements.
still not an argument
Again, you admit your error.
You should respect those with far greater knowledge than you, rather
than thinking they are unimportant.
how can u be /of far greater knowledge/ when ur telling me to accept
origin fallacies instead of actual arguments???
Because I am just rejecting your attempts to ignore the basics of the
system.
i refuse to accept ur moronic semantic quibbling.
if a machine inputs a machine and uses an algorithm more complex than
just running the damn thing to produce a decision on whether it halts or
not ... i'm going to consider that "analysis"
inb4 u pathetically claim that arguments from authority aren't origin
fallacies ... like, ok boomer ...
Right, because I don't argue from "authority", I argue from definitions.
defined by what? a dictionary? the authority on the matter???
we're just intuitively creating directed graph models
representative of the computational flow, which we then use >>>>>>>>> internally to reckon about computations and create the
discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory >>>>>>>> works.
The only "Graph" you can draw is of the state machine, which is >>>>>>>> dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable >>>>>>> sets of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can duplicate >>>>>> a computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding
will specify a unique set of equivalent modules, but not any one
in particular, since they are duplicatable.
bruh u disagree with the one-to-one bijection between TMs and ℕ?
for any given machine there are *possibly* infinite /equivalent/
machines (tho certain machines involving quines may not have
equivalents) ... but machines themselves are unique
No, only with the computableness of that bijection.
we can enumerate that bijection. an inability to prove equivalence
(same input->output) does not mean we cannot iterate over the
machines in a unique fashion.
No you can't, as it is infinite in lenght, with an uncomputable basis.
one can enumerate infinite sets, do u know what enumeration is?
and u don't need to compute equivalent to enumerate *all* TMs uniquely.
To iterate over the machines, you need a detector function that tells
you if a given string is one of these machines. That is an undecidable
proposition.
if u have more questions on how to enumerate all *TMs* uniquely, please
do read turing original paper /on computable numbers/ because he
discusses how to do this sufficient detail.
The problem with quines is that while they can produce A copy of one
of their source codes, you can make many other programs that produce
that identical source code, and thus, the code they produce is NOT a
unique representation of them as a program.
The sub-class of programs called quines is NOT a Turing Complete
system by themselves, and thus is a less than interesting category.
a quine is a technique that can be used to produce an exact copy of a
machine's source code *on the tape* (which may or may not form the
machines output). a quine computation can be stuck on the front of
any arbitrary program, and therefore the class of programs that
contain quines is turing complete.
Right, but since not all programs are quines, you can't use that
property of quines to number programs.
And if the output of the machine isn't supposed to be a representation
of it, you can't do that operation.
u have have a machine do computation and then erase it all??? the
machine can use a quine to create a directly copy of it's source code in memory ... and then it can erase that memory completely before doing any arbitrary computation next
therefore the class of machines that involves quines is turing complete.
if all u did was read the wikipedia definition, then i get why ur
trying to argue it's a "class" of programs that output it's own
source code. the wikipedia article is wrong, it's a technique that
integrated into any machine for computation purposes (like
recognizing itself)
You don't understand it as a class of programs?
And where do you see that it allows a general program to identify itself?
You might be able to generate a finite subset of the various
representations of the program, but that still doesn't meet your
requirements.
what requirement does it not meet?
2) or u can just require "inputs" to be baked into the initial
part of the machine-description, in which case sets of machines >>>>>>> would map to various results of the machine with input that ur
trying to analyze
claiming that halitng problem to be fundamental undecidable is
claiming that there is some machine at some point, that takes no >>>>>>> input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and
that yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
No, und is a non-existant instance of an inpossible machine, since
there is not clasical halting decider.
You can't assume the existance of something that doesn't exist.
unless to prove it's non-existence, i guess? bro the fucking hypocrisy u constantly assert. i don't even know if ur thinking critically at this
point
we can compute this semantic property with a simple algo:
You can't compute the property of a program that doesn't exist.
The problem that as a PROGRAM "und" includes the code for the decider
that it is calling, and thus trying to change it make your program/
input something different than what it is.
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the
computation. if the semantic results from (1) and (2) diverge from
the injected prediction, the hypothetical machine is undecidable.
But that just make a major category error of looking at several
DIFFERENT programs and claiming they give the answer about an input
that none of them were.
i don't even know how to deal with this level of hypocricy.
ur rejecting me in proposing an algo for the analysis that u *already* directly use to demonstrate undecidability in the first place!!!??? 🙄🙄🙄
this like reach anti-intellectualism levels of stupidity, and that's
exactly why i'm furious how much fucking tards like u have fucked up my fucking planet you stupid fucking piece of fucking corpo dipshit.
problem, but by further logic from the undecability of the
problem, we get that there does exist machines whose behavior is
unknowable.
If you try to limit the problem to just one machine, then it is
ALWAYS decidable, as either Accept(x) or Reject(x) will be right
(were Accept(x) accepts all inputs, and Reject(x) rejects all
inputs), we just won't know which one was right.
For any decider, we CAN create an input that it will not correctly >>>>>> decider, as the proof shows, and thus for ANY possible decider
there EXIST an input it will not be correct for, and thus, we can >>>>>> say that there is NO decider that is correct for ALL inputs.
i mean if partial deciders exist, which i believe u agree they
do... then don't the programs they cannot decide on also exist???
because if they don't, then they aren't actually partial deciders.
Sure partial deciders exist. And we can find programs they will fail
to decide on.
furthermore ... what form does those kinds of programs actually
look like?
WHy do they need a generic form?
do they have *any* form??? the fact u can't say what is actually
undecidable and are just asserting it *must* exist based on purely
hypotheticals is just ... absurd
The are programs of the system. That is there form. They will grow in
memory usage without bound, but that is somethig that can only be
deterimend with unbounded time.
They must exist, or we could create the proven impossible to create halt
or just we fucked up the fundamentals and u refuse to consider fixing it
for some beyond ungodly reason
decider. We just can never prove that a given program is in that
class, as being able to do so answers its halting question.
Yes, you are getting into the realm of hard to comprehend, but that is
the nature of dealing with the undecidable infinite.
whatever fuck u and fuck u fucking ghosts ur so fucking convinced exist
but cannot demonstrate because then ur entire shitpile of a theory falls apart
fucking paaaa-thetic
or is this another dumb case of u can't actually tell me what
machine the decider can't decide on cause then ur whole house of
cards falls apart again? sheesh 😒😒😒
And that is your problem, you can't understand that there are things
you can not know.
i don't believe in ghosts either
That is your error. It means there will be things that you think you
know, but are wrong about, which is worse than not knowing.
i have not seen you admit error in regards to even on thing, this entire convo
i know ur full of it, 100%
i see it all time useless fucking boomer
For example, given a Halt Decider built on just using a UTM, and if
it halt, accept, ANY non-halting program, like a simple loop, will
be a machie that decider can't decide on.
quines allow for a machines (and therefore deciders) that are
Or, you create a list (not a graph) of the execution history of >>>>>>>> the machine running. Such a list, of course, might be infinite >>>>>>>> in length if the machine doesn't halt, and doesn't leave a lot >>>>>>>> to "discuss".
And when one machine uses another, you don't graph over to the >>>>>>>> other as a sub-graph like a "call" instruction in a higher level >>>>>>>> language, but by making a copy of that machine, relabeling the >>>>>>>> states to keep them unique in the machine, and embedding it.
one can also just embed the sub-function description into the
main function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its >>>>>
wholly unique in their output (*any* change to the machine changes
it's output on at least one input in a way that no other machine
can match)
But Quines are not a Turing Complete class of Programs.
There are alternative programs that generate the same output as a
given Quine, so they are not unique PROGRAMS.
There are may examples of successful Halt Deciding on less than
Turing Complete systems, so you need to show that your idea is at
least as interesting and useful as some of those.
i went over that in another post u didn't respond to
Sometime you are just being to wordy and I don't have the time.
equivalence class within an input. Thus, can't use detection of
such a "self-reference" (which is a misuse of the term) as part of >>>>>> its algorithm.
Thus, pieces of machines can't know if there section of graph >>>>>>>> represents a given graph, as that sort of identity doesn't exist >>>>>>>> as something computable.
On 12/20/25 8:21 PM, dart200 wrote:
On 12/20/25 4:42 PM, Richard Damon wrote:
On 12/20/25 7:17 PM, dart200 wrote:
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:In other words, you are just saying it is ok to lie.
On 12/19/25 2:10 PM, dart200 wrote:
On 12/19/25 7:11 AM, Richard Damon wrote:
On 12/19/25 12:11 AM, dart200 wrote:
On 12/18/25 4:22 AM, Richard Damon wrote:
On 12/18/25 1:14 AM, dart200 wrote:
On 12/17/25 10:04 PM, Chris M. Thomasson wrote:
On 12/17/2025 9:06 PM, Richard Damon wrote:
[...]
While no halt deciders exist, the "inteface that they >>>>>>>>>>>>>> define" does.
For a given program, the creator can create a halting >>>>>>>>>>>>> decider for its logic. Does this path halt or not, well, we >>>>>>>>>>>>> know, we made the damn thing. But, there is no one
universal decider...
[...]
how do we know that if there is no algo to compute that??? >>>>>>>>>>>>
Because we created a proof of it.
If you don't beleive in the truth of logic, you aren't going >>>>>>>>>>> to be able to get very far.
The key point is that with logic, we can sometimes find >>>>>>>>>>> "inductive" paths that let us look into the infinite that we >>>>>>>>>>> can't evaluate all of individually,
we're not doing any analysis that transcends computing
Then you aren't doing any analysis. Computing is a purely
mechanical operation, and thus isn't "analysis" in form.
this is unbecoming semantic quibbling
No, it is just being ACCURATE, and pointing out a fundamental
error in your reasoning.
this is doubling down on unbecoming semantic quibbling. for
someone who's had a career longer than i've been alive ... 🤡🌎 >>>>>
not an argument
So, you admit your error.
THAT isn't quibbling, that is just a fact proven by your statements.
still not an argument
Again, you admit your error.
You should respect those with far greater knowledge than you,
rather than thinking they are unimportant.
how can u be /of far greater knowledge/ when ur telling me to accept
origin fallacies instead of actual arguments???
Because I am just rejecting your attempts to ignore the basics of the
system.
i refuse to accept ur moronic semantic quibbling.
In other words, you can't stand being wrong, so you will just ignore
things your don't like and us fallicies to try to belittle it.
if a machine inputs a machine and uses an algorithm more complex than
just running the damn thing to produce a decision on whether it halts
or not ... i'm going to consider that "analysis"
But, how can you KNOW the results are correct. That requires using
actual logic, unless you just run it until it stops.
inb4 u pathetically claim that arguments from authority aren't
origin fallacies ... like, ok boomer ...
Right, because I don't argue from "authority", I argue from definitions.
defined by what? a dictionary? the authority on the matter???
The basic rules of Computation Theory.
Something it seems you don't actually understand.
we're just intuitively creating directed graph models
representative of the computational flow, which we then use >>>>>>>>>> internally to reckon about computations and create the
discussions we're having
Which isn't "Computing".
The problem is that your "model" doesn't match how the theory >>>>>>>>> works.
The only "Graph" you can draw is of the state machine, which is >>>>>>>>> dependent on the input on how you traverse it.
1) each branch in the machines graph selects between computable >>>>>>>> sets of input,
So, your "Node" are just computable modules.
Note, this means that Nodes are not "unique", as you can
duplicate a computable module to create a copy of it.
Also, there is not a unique encoding for a module. An encoding
will specify a unique set of equivalent modules, but not any one >>>>>>> in particular, since they are duplicatable.
bruh u disagree with the one-to-one bijection between TMs and ℕ? >>>>>> for any given machine there are *possibly* infinite /equivalent/
machines (tho certain machines involving quines may not have
equivalents) ... but machines themselves are unique
No, only with the computableness of that bijection.
we can enumerate that bijection. an inability to prove equivalence
(same input->output) does not mean we cannot iterate over the
machines in a unique fashion.
No you can't, as it is infinite in lenght, with an uncomputable basis.
one can enumerate infinite sets, do u know what enumeration is?
Sure, but do you not understand the limitation of COMPUTING such an enumeration?
Yes, you can use the axiom of Choice to generate such an enumeration.
But that list can't be accessed programatically.
You can count through all possible programs to enumerate them, but then
you need a computable predicate to decide if that arbitrary description
is a program in that set.
In other words, you can't use an enumeration of an infinte set until you
can programatically generate it.
and u don't need to compute equivalent to enumerate *all* TMs uniquely.
Sure you do. And you don't want "All TMs", you want all TMs with a
specific property.
To iterate over the machines, you need a detector function that tells
you if a given string is one of these machines. That is an
undecidable proposition.
if u have more questions on how to enumerate all *TMs* uniquely,
please do read turing original paper /on computable numbers/ because
he discusses how to do this sufficient detail.
No, he talks about how to enumerate all TMs. Every number has only one
TM, but not every TM has only one number.
The problem with quines is that while they can produce A copy of
one of their source codes, you can make many other programs that
produce that identical source code, and thus, the code they produce >>>>> is NOT a unique representation of them as a program.
The sub-class of programs called quines is NOT a Turing Complete
system by themselves, and thus is a less than interesting category.
a quine is a technique that can be used to produce an exact copy of
a machine's source code *on the tape* (which may or may not form the
machines output). a quine computation can be stuck on the front of
any arbitrary program, and therefore the class of programs that
contain quines is turing complete.
Right, but since not all programs are quines, you can't use that
property of quines to number programs.
And if the output of the machine isn't supposed to be a
representation of it, you can't do that operation.
u have have a machine do computation and then erase it all??? the
machine can use a quine to create a directly copy of it's source code
in memory ... and then it can erase that memory completely before
doing any arbitrary computation next
But that gets it just ONE of the infinite encodings of it.
therefore the class of machines that involves quines is turing complete.
Nope.
if all u did was read the wikipedia definition, then i get why ur
trying to argue it's a "class" of programs that output it's own
source code. the wikipedia article is wrong, it's a technique that
integrated into any machine for computation purposes (like
recognizing itself)
You don't understand it as a class of programs?
And where do you see that it allows a general program to identify
itself?
You might be able to generate a finite subset of the various
representations of the program, but that still doesn't meet your
requirements.
what requirement does it not meet?
That the input can use one of the infinite number that it doesn't check.
well it's a property of hypothetical instances
2) or u can just require "inputs" to be baked into the initial >>>>>>>> part of the machine-description, in which case sets of machines >>>>>>>> would map to various results of the machine with input that ur >>>>>>>> trying to analyze
claiming that halitng problem to be fundamental undecidable is >>>>>>>> claiming that there is some machine at some point, that takes no >>>>>>>> input, that is yet still undecidable
Nope, as "undecidable" isn't a property of an instance, but of a >>>>>>
Nope. You clearly don't understand what "undecidable" means, and
that yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
No, und is a non-existant instance of an inpossible machine, since
there is not clasical halting decider.
You can't assume the existance of something that doesn't exist.
unless to prove it's non-existence, i guess? bro the fucking hypocrisy
u constantly assert. i don't even know if ur thinking critically at
this point
No, to assume something exists, you need to prove that it does.
It seems the one not "thinking" is you. The fact you can't actually put together a coherent arguement is a good sign of that.
we can compute this semantic property with a simple algo:
You can't compute the property of a program that doesn't exist.
The problem that as a PROGRAM "und" includes the code for the decider
that it is calling, and thus trying to change it make your program/
input something different than what it is.
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the
computation. if the semantic results from (1) and (2) diverge from
the injected prediction, the hypothetical machine is undecidable.
But that just make a major category error of looking at several
DIFFERENT programs and claiming they give the answer about an input
that none of them were.
i don't even know how to deal with this level of hypocricy.
What hypocracy?
ur rejecting me in proposing an algo for the analysis that u *already*
directly use to demonstrate undecidability in the first place!!!??? 🙄
🙄🙄
You just don't understand what you are doing then.
this like reach anti-intellectualism levels of stupidity, and that's
exactly why i'm furious how much fucking tards like u have fucked up
my fucking planet you stupid fucking piece of fucking corpo dipshit.
The fact that your arguement need to begin by assuming ideas proven
wrong, shows who is the anti-intelectual.
It seems you are just to stupid to do what you have set out to do, and
are trying to blame others.
You are the one that set yourself on a hopeless journey. If you don't
want help to get on the right road, just go off and die.
or just we fucked up the fundamentals and u refuse to consider fixing
problem, but by further logic from the undecability of the
problem, we get that there does exist machines whose behavior is >>>>>>> unknowable.
If you try to limit the problem to just one machine, then it is >>>>>>> ALWAYS decidable, as either Accept(x) or Reject(x) will be right >>>>>>> (were Accept(x) accepts all inputs, and Reject(x) rejects all
inputs), we just won't know which one was right.
For any decider, we CAN create an input that it will not
correctly decider, as the proof shows, and thus for ANY possible >>>>>>> decider there EXIST an input it will not be correct for, and
thus, we can say that there is NO decider that is correct for ALL >>>>>>> inputs.
i mean if partial deciders exist, which i believe u agree they
do... then don't the programs they cannot decide on also exist??? >>>>>> because if they don't, then they aren't actually partial deciders.
Sure partial deciders exist. And we can find programs they will
fail to decide on.
furthermore ... what form does those kinds of programs actually
look like?
WHy do they need a generic form?
do they have *any* form??? the fact u can't say what is actually
undecidable and are just asserting it *must* exist based on purely
hypotheticals is just ... absurd
The are programs of the system. That is there form. They will grow in
memory usage without bound, but that is somethig that can only be
deterimend with unbounded time.
They must exist, or we could create the proven impossible to create halt >>
it for some beyond ungodly reason
No, YOU have fucked the fundamentals, by trying to just ignore the rules that fundamentally exist.
decider. We just can never prove that a given program is in that
class, as being able to do so answers its halting question.
Yes, you are getting into the realm of hard to comprehend, but that
is the nature of dealing with the undecidable infinite.
whatever fuck u and fuck u fucking ghosts ur so fucking convinced
exist but cannot demonstrate because then ur entire shitpile of a
theory falls apart
fucking paaaa-thetic
You are showing how "smart" you are, with your langauge.
or is this another dumb case of u can't actually tell me what
machine the decider can't decide on cause then ur whole house of
cards falls apart again? sheesh 😒😒😒
And that is your problem, you can't understand that there are
things you can not know.
i don't believe in ghosts either
That is your error. It means there will be things that you think you
know, but are wrong about, which is worse than not knowing.
i have not seen you admit error in regards to even on thing, this
entire convo
i know ur full of it, 100%
i see it all time useless fucking boomer
Maybe because you haven't seen me make a mistake?
Of course, someone as commited as you to holding onto error won't be
able to see such a thing.
For example, given a Halt Decider built on just using a UTM, and if >>>>> it halt, accept, ANY non-halting program, like a simple loop, will
be a machie that decider can't decide on.
quines allow for a machines (and therefore deciders) that are
Or, you create a list (not a graph) of the execution history of >>>>>>>>> the machine running. Such a list, of course, might be infinite >>>>>>>>> in length if the machine doesn't halt, and doesn't leave a lot >>>>>>>>> to "discuss".
And when one machine uses another, you don't graph over to the >>>>>>>>> other as a sub-graph like a "call" instruction in a higher
level language, but by making a copy of that machine,
relabeling the states to keep them unique in the machine, and >>>>>>>>> embedding it.
one can also just embed the sub-function description into the >>>>>>>> main function directly without the simulation infrastructure.
So? All this shows is that a decider can't detect all copies of its >>>>>>
wholly unique in their output (*any* change to the machine changes >>>>>> it's output on at least one input in a way that no other machine
can match)
But Quines are not a Turing Complete class of Programs.
There are alternative programs that generate the same output as a
given Quine, so they are not unique PROGRAMS.
There are may examples of successful Halt Deciding on less than
Turing Complete systems, so you need to show that your idea is at
least as interesting and useful as some of those.
i went over that in another post u didn't respond to
Sometime you are just being to wordy and I don't have the time.
equivalence class within an input. Thus, can't use detection of >>>>>>> such a "self-reference" (which is a misuse of the term) as part >>>>>>> of its algorithm.
Thus, pieces of machines can't know if there section of graph >>>>>>>>> represents a given graph, as that sort of identity doesn't
exist as something computable.
my retarded nigger, there are no fucking "basic rules of computationWow.
theory" on what "analysis" consists of ....
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
On 12/20/2025 4:05 AM, Mikko wrote:
On 19/12/2025 16:44, olcott wrote:
On 12/19/2025 4:02 AM, Mikko wrote:
On 18/12/2025 15:06, olcott wrote:
On 12/18/2025 5:03 AM, Mikko wrote:
On 18/12/2025 06:08, olcott wrote:
On 12/17/2025 4:01 AM, Mikko wrote:
On 16/12/2025 19:30, olcott wrote:
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
The halting problem does not ask about a string. It asks about >>>>>>>> a meaning, which is a computation. Therefore the measure of the >>>>>>>> behaviour is the computation asked about. If the input string
does not specify that behaviour then it is a wrong string.
It asks about the semantic meaning that its
input finite string specifies. (See Rice)
What other manings there are than semantic?
That is the wrong question.
That is a perfietly vailid question about your "semantic meaning".
In computability theory, Rice's theorem states
that all non-trivial semantic properties of
programs are undecidable. A semantic property
is one about the program's behavior (for
instance, "does the program terminate for
all inputs?"), unlike a syntactic property
(for instance, "does the program contain an
if-then-else statement?"). A non-trivial
property is one that is neither true for
every program, nor false for every program.
https://en.wikipedia.org/wiki/Rice%27s_theorem
Irrelevant to the question whether there are meanings other than
semantic.
There are meanings other than semantic
in linguistics not the theory of computation.
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me to
snuff myself out.
amen
#god
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me to
snuff myself out.
my fellow african american, please live out ur life as long as possible
amen
#god
😂
On 12/21/2025 1:14 PM, dart200 wrote:
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me to
snuff myself out.
my fellow african american, please live out ur life as long as possible
Whatever. You seem to be able to get really pissed of and end up writing some crazy/strange shit. You said the N word on a public forum. Decorum,
a bit? Do you tend to get really mad in real life as well?
--
amen
;
#god
😂
Okay... ;^o
On 12/21/25 5:32 PM, Chris M. Thomasson wrote:
On 12/21/2025 1:14 PM, dart200 wrote:
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me
to snuff myself out.
my fellow african american, please live out ur life as long as possible
Whatever. You seem to be able to get really pissed of and end up
writing some crazy/strange shit. You said the N word on a public
forum. Decorum,
nigger nigger nigger nigger nigger nigger nigger nigger nigger nigger
it's a just a word dude
a bit? Do you tend to get really mad in real life as well?
i'm fairly conflict avoidant irl
amen
;
#god
😂
Okay... ;^o
On 12/21/25 5:32 PM, Chris M. Thomasson wrote:
On 12/21/2025 1:14 PM, dart200 wrote:
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me
to snuff myself out.
my fellow african american, please live out ur life as long as possible
Whatever. You seem to be able to get really pissed of and end up
writing some crazy/strange shit. You said the N word on a public
forum. Decorum,
nigger nigger nigger nigger nigger nigger nigger nigger nigger nigger
it's a just a word dude
a bit? Do you tend to get really mad in real life as well?
i'm fairly conflict avoidant irl
On 12/21/25 5:32 PM, Chris M. Thomasson wrote:
On 12/21/2025 1:14 PM, dart200 wrote:
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me
to snuff myself out.
my fellow african american, please live out ur life as long as possible
Whatever. You seem to be able to get really pissed of and end up
writing some crazy/strange shit. You said the N word on a public
forum. Decorum,
nigger nigger nigger nigger nigger nigger nigger nigger nigger nigger
it's a just a word dude
a bit? Do you tend to get really mad in real life as well?
i'm fairly conflict avoidant irl
It seems clear that you are just too stupid to want to actually discuss this, but just want to vent.
Go ahead, KILL YOURSELF this way if you want.
IT is clear if you goal is to make a name for yourself, you already
have, but not the one you want.
You clearly don't actually understand what you have been reading, and
the basics of the theory behind it.
Since the "pathological" program doesn't need to use the exact instance
that is the decider, just an equivalent, and as you have admitted, there
are an infinite number of equivalent, your decide can never tell if the input is using an equivalent to itself.
Thus, your definition of incoherent can't be used, because the input
uses the decider as it is, not as how it could imagine itself to alternatively be to see the issue.
Thus, your ideas just fail because you think you can do things that are
just impossible.
No "re-imagining" things will get around this.
It seems your brain is just to small to grapple with the issue of the infinite that comes up in the proofs. The program can't have an
enumeration of the programs if you can't build a decider that classifies
the programs correctly.
Part of your problem is your refusal to believe in the "ghost" that come--
up, but they WILL haunt you through out your work. You might not believe they are there, but they are, and they will make your work just break.
On 12/20/25 7:58 PM, Richard Damon wrote:
It seems clear that you are just too stupid to want to actually
discuss this, but just want to vent.
Go ahead, KILL YOURSELF this way if you want.
IT is clear if you goal is to make a name for yourself, you already
have, but not the one you want.
You clearly don't actually understand what you have been reading, and
the basics of the theory behind it.
Since the "pathological" program doesn't need to use the exact
instance that is the decider, just an equivalent, and as you have
admitted, there are an infinite number of equivalent, your decide can
never tell if the input is using an equivalent to itself.
how could we know it to be undecidable if nothing can definitively know
it's equivalent to what's being made undecidable?
sounds like hypocritical nonsense to me: ur trying to assert they must
be undecidable due to unknowable equivalence...
but like how can you know they are undecidable if nothing can know the equivalence?
in order for them to end up in an undecidable situation, they'd have to
be able to compute that they are equivalent to the machine being made undecidable
Thus, your definition of incoherent can't be used, because the input
uses the decider as it is, not as how it could imagine itself to
alternatively be to see the issue.
Thus, your ideas just fail because you think you can do things that
are just impossible.
No "re-imagining" things will get around this.
It seems your brain is just to small to grapple with the issue of the
infinite that comes up in the proofs. The program can't have an
enumeration of the programs if you can't build a decider that
classifies the programs correctly.
the only thing u've shown they can't classify are programs you then
assert don't actually exist, and then assert actually the
"undecidability" is really an unknowable form of machine u can't even reference (how convenient)
Part of your problem is your refusal to believe in the "ghost" that
come up, but they WILL haunt you through out your work. You might not
believe they are there, but they are, and they will make your work
just break.
On 12/21/25 9:39 PM, dart200 wrote:
On 12/20/25 7:58 PM, Richard Damon wrote:
It seems clear that you are just too stupid to want to actually
discuss this, but just want to vent.
Go ahead, KILL YOURSELF this way if you want.
IT is clear if you goal is to make a name for yourself, you already
have, but not the one you want.
You clearly don't actually understand what you have been reading, and
the basics of the theory behind it.
Since the "pathological" program doesn't need to use the exact
instance that is the decider, just an equivalent, and as you have
admitted, there are an infinite number of equivalent, your decide can
never tell if the input is using an equivalent to itself.
how could we know it to be undecidable if nothing can definitively
know it's equivalent to what's being made undecidable?
We don't. Note, the "pathological" program is not itself undecidable. It
is just a program that the given decider gets wrong.
What the undecidable program is, would be some other more complicated program, that grows without bound, but not so fast that we can prove it grows without bound.
sounds like hypocritical nonsense to me: ur trying to assert they must
be undecidable due to unknowable equivalence...
It seems you can't follow logic, as you keep confusing the
"pathological" program of the proof, that proves a single decider wrong,
but the algorithm to generate it can be applied to any decider, and the concept that this implies that there exist somewhere out there in the
realm of machines we haven't been about to figure out yet, some that we
can never figure out, or even identify which of that set we will not be
able to figure out.
but like how can you know they are undecidable if nothing can know the
equivalence?
Because the pathological program isn't undecidable, just not decided by
this decider.
Part of your problem is you seem to forget that the operation goes at
having to put forward a decider you are going to try to claim to be
correct, possible by just iterating through all possible machines. An operation while not computable, is logially analyzable.
in order for them to end up in an undecidable situation, they'd have
to be able to compute that they are equivalent to the machine being
made undecidable
Again, the input that proves the decider wrong is not undeciable, just
one that the chosen decider gets wrong.
As such, we CAN fully analyse and determine its behavior, just like we
can determine what that decider WILL give as its answer.
Thus, your definition of incoherent can't be used, because the input
uses the decider as it is, not as how it could imagine itself to
alternatively be to see the issue.
Thus, your ideas just fail because you think you can do things that
are just impossible.
No "re-imagining" things will get around this.
It seems your brain is just to small to grapple with the issue of the
infinite that comes up in the proofs. The program can't have an
enumeration of the programs if you can't build a decider that
classifies the programs correctly.
the only thing u've shown they can't classify are programs you then
assert don't actually exist, and then assert actually the
"undecidability" is really an unknowable form of machine u can't even
reference (how convenient)
So, you are just showing that you don't understand the proof.
The machine shown not to exist is the correct halt decider.
This shows that the PROBLEM of Halt Deciding is undeciable.
This does not mean that any given machine is undecidable, just that no machine can get the right answers for all inputs, as we can tailor make
an input that it will get wrong.
It is a subsequent proof from this fact that shows there must exist some machine, that we can not know what it is, that is in fact, truly
unknowable as to its halting status.
Part of your problem is your refusal to believe in the "ghost" that
come up, but they WILL haunt you through out your work. You might not
believe they are there, but they are, and they will make your work
just break.
On 12/21/2025 5:40 PM, dart200 wrote:
On 12/21/25 5:32 PM, Chris M. Thomasson wrote:
On 12/21/2025 1:14 PM, dart200 wrote:
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:Whatever. You seem to be able to get really pissed of and end up
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me
to snuff myself out.
my fellow african american, please live out ur life as long as possible >>>
writing some crazy/strange shit. You said the N word on a public
forum. Decorum,
nigger nigger nigger nigger nigger nigger nigger nigger nigger nigger
it's a just a word dude
a bit? Do you tend to get really mad in real life as well?
i'm fairly conflict avoidant irl
Say it to other people out there? Here is some music for ya. More
cowbell? lol:
https://youtu.be/QtjhyO547iw?list=RDQtjhyO547iw
[...]
On 12/21/25 6:54 PM, Richard Damon wrote:
On 12/21/25 9:39 PM, dart200 wrote:
On 12/20/25 7:58 PM, Richard Damon wrote:
It seems clear that you are just too stupid to want to actually
discuss this, but just want to vent.
Go ahead, KILL YOURSELF this way if you want.
IT is clear if you goal is to make a name for yourself, you already
have, but not the one you want.
You clearly don't actually understand what you have been reading,
and the basics of the theory behind it.
Since the "pathological" program doesn't need to use the exact
instance that is the decider, just an equivalent, and as you have
admitted, there are an infinite number of equivalent, your decide
can never tell if the input is using an equivalent to itself.
how could we know it to be undecidable if nothing can definitively
know it's equivalent to what's being made undecidable?
We don't. Note, the "pathological" program is not itself undecidable.
It is just a program that the given decider gets wrong.
What the undecidable program is, would be some other more complicated
program, that grows without bound, but not so fast that we can prove
it grows without bound.
sounds like hypocritical nonsense to me: ur trying to assert they
must be undecidable due to unknowable equivalence...
It seems you can't follow logic, as you keep confusing the
"pathological" program of the proof, that proves a single decider
wrong, but the algorithm to generate it can be applied to any decider,
and the concept that this implies that there exist somewhere out there
in the realm of machines we haven't been about to figure out yet, some
that we can never figure out, or even identify which of that set we
will not be able to figure out.
but like how can you know they are undecidable if nothing can know
the equivalence?
Because the pathological program isn't undecidable, just not decided
by this decider.
Part of your problem is you seem to forget that the operation goes at
having to put forward a decider you are going to try to claim to be
correct, possible by just iterating through all possible machines. An
operation while not computable, is logially analyzable.
in order for them to end up in an undecidable situation, they'd have
to be able to compute that they are equivalent to the machine being
made undecidable
Again, the input that proves the decider wrong is not undeciable, just
one that the chosen decider gets wrong.
As such, we CAN fully analyse and determine its behavior, just like we
can determine what that decider WILL give as its answer.
Thus, your definition of incoherent can't be used, because the input
uses the decider as it is, not as how it could imagine itself to
alternatively be to see the issue.
Thus, your ideas just fail because you think you can do things that
are just impossible.
No "re-imagining" things will get around this.
It seems your brain is just to small to grapple with the issue of
the infinite that comes up in the proofs. The program can't have an
enumeration of the programs if you can't build a decider that
classifies the programs correctly.
the only thing u've shown they can't classify are programs you then
assert don't actually exist, and then assert actually the
"undecidability" is really an unknowable form of machine u can't even
reference (how convenient)
So, you are just showing that you don't understand the proof.
understanding and accepting are different things
The machine shown not to exist is the correct halt decider.
This shows that the PROBLEM of Halt Deciding is undeciable.
This does not mean that any given machine is undecidable, just that no
machine can get the right answers for all inputs, as we can tailor
make an input that it will get wrong.
It is a subsequent proof from this fact that shows there must exist
some machine, that we can not know what it is, that is in fact, truly
unknowable as to its halting status.
Part of your problem is your refusal to believe in the "ghost" that
come up, but they WILL haunt you through out your work. You might
not believe they are there, but they are, and they will make your
work just break.
On 12/22/25 12:30 AM, dart200 wrote:
On 12/21/25 6:54 PM, Richard Damon wrote:
On 12/21/25 9:39 PM, dart200 wrote:
On 12/20/25 7:58 PM, Richard Damon wrote:
It seems clear that you are just too stupid to want to actually
discuss this, but just want to vent.
Go ahead, KILL YOURSELF this way if you want.
IT is clear if you goal is to make a name for yourself, you already >>>>> have, but not the one you want.
You clearly don't actually understand what you have been reading,
and the basics of the theory behind it.
Since the "pathological" program doesn't need to use the exact
instance that is the decider, just an equivalent, and as you have
admitted, there are an infinite number of equivalent, your decide
can never tell if the input is using an equivalent to itself.
how could we know it to be undecidable if nothing can definitively
know it's equivalent to what's being made undecidable?
We don't. Note, the "pathological" program is not itself undecidable.
It is just a program that the given decider gets wrong.
What the undecidable program is, would be some other more complicated
program, that grows without bound, but not so fast that we can prove
it grows without bound.
sounds like hypocritical nonsense to me: ur trying to assert they
must be undecidable due to unknowable equivalence...
It seems you can't follow logic, as you keep confusing the
"pathological" program of the proof, that proves a single decider
wrong, but the algorithm to generate it can be applied to any
decider, and the concept that this implies that there exist somewhere
out there in the realm of machines we haven't been about to figure
out yet, some that we can never figure out, or even identify which of
that set we will not be able to figure out.
but like how can you know they are undecidable if nothing can know
the equivalence?
Because the pathological program isn't undecidable, just not decided
by this decider.
Part of your problem is you seem to forget that the operation goes at
having to put forward a decider you are going to try to claim to be
correct, possible by just iterating through all possible machines. An
operation while not computable, is logially analyzable.
in order for them to end up in an undecidable situation, they'd have
to be able to compute that they are equivalent to the machine being
made undecidable
Again, the input that proves the decider wrong is not undeciable,
just one that the chosen decider gets wrong.
As such, we CAN fully analyse and determine its behavior, just like
we can determine what that decider WILL give as its answer.
Thus, your definition of incoherent can't be used, because the
input uses the decider as it is, not as how it could imagine itself >>>>> to alternatively be to see the issue.
Thus, your ideas just fail because you think you can do things that >>>>> are just impossible.
No "re-imagining" things will get around this.
It seems your brain is just to small to grapple with the issue of
the infinite that comes up in the proofs. The program can't have an >>>>> enumeration of the programs if you can't build a decider that
classifies the programs correctly.
the only thing u've shown they can't classify are programs you then
assert don't actually exist, and then assert actually the
"undecidability" is really an unknowable form of machine u can't
even reference (how convenient)
So, you are just showing that you don't understand the proof.
understanding and accepting are different things
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a person
a liar.
The machine shown not to exist is the correct halt decider.
This shows that the PROBLEM of Halt Deciding is undeciable.
This does not mean that any given machine is undecidable, just that
no machine can get the right answers for all inputs, as we can tailor
make an input that it will get wrong.
It is a subsequent proof from this fact that shows there must exist
some machine, that we can not know what it is, that is in fact, truly
unknowable as to its halting status.
Part of your problem is your refusal to believe in the "ghost" that >>>>> come up, but they WILL haunt you through out your work. You might
not believe they are there, but they are, and they will make your
work just break.
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a
person a liar.
refusal to acknowledge how much i've demonstrated in terms of working knowledge, even if i don't agree, is just mean bro
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a
person a liar.
refusal to acknowledge how much i've demonstrated in terms of working
knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a
person a liar.
refusal to acknowledge how much i've demonstrated in terms of working
knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it cannot be implemented on basic turing machines. and ur really just being a massive dick suggesting i haven't demonstrated *any* knowledge of the field,
that's really just u being mean
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a
person a liar.
refusal to acknowledge how much i've demonstrated in terms of
working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it cannot
be implemented on basic turing machines. and ur really just being a
massive dick suggesting i haven't demonstrated *any* knowledge of the
field, that's really just u being mean
No, it is an interface based on assuming things that are impossible,
because you don't understand some of the basics of the field.
The problem is what you are trying to "extend" it to, breaks the
fundamental purpose of it, something you apperently don't grasp.
If you were then going to look at usefulness of you new field, it might
be one thing, but you start off saying you aren't going to do that.
All it seems you want to do is take a real and important problem, and
try to find a toy system where a toy version of that problem can be made solvable.
No one cares about making toy system that can solve toy problem.
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a
person a liar.
refusal to acknowledge how much i've demonstrated in terms of
working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it cannot
be implemented on basic turing machines. and ur really just being a
massive dick suggesting i haven't demonstrated *any* knowledge of the
field, that's really just u being mean
No, it is an interface based on assuming things that are impossible,
because you don't understand some of the basics of the field.
The problem is what you are trying to "extend" it to, breaks the
fundamental purpose of it, something you apperently don't grasp.
If you were then going to look at usefulness of you new field, it
might be one thing, but you start off saying you aren't going to do that.
All it seems you want to do is take a real and important problem, and
try to find a toy system where a toy version of that problem can be
made solvable.
No one cares about making toy system that can solve toy problem.
i'm sorry, the problem of pathological input like:
und = () -> halts(und) && loop_forever()
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy" problem???
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a >>>>>>> person a liar.
refusal to acknowledge how much i've demonstrated in terms of
working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it cannot
be implemented on basic turing machines. and ur really just being a
massive dick suggesting i haven't demonstrated *any* knowledge of
the field, that's really just u being mean
No, it is an interface based on assuming things that are impossible,
because you don't understand some of the basics of the field.
The problem is what you are trying to "extend" it to, breaks the
fundamental purpose of it, something you apperently don't grasp.
If you were then going to look at usefulness of you new field, it
might be one thing, but you start off saying you aren't going to do
that.
All it seems you want to do is take a real and important problem, and
try to find a toy system where a toy version of that problem can be
made solvable.
No one cares about making toy system that can solve toy problem.
i'm sorry, the problem of pathological input like:
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy" problem???
The problem is you don't understand the system the program is define in.
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't misteriously do something different
And thus, since halts has a defined algorithm and thus a defined--
behavior when it is called ther, und has defined behavior, and thus
trying to call it "incoherent" is just to make a toy system that
violates determinism.
When you play with the definition of halts, either you are creating NEW inputs, and thus can't actually talk about comparisons between them
being significant, after all 1 isn't the sane aa 2.
Or you leave the input alone, and you find that other versions of halt
can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
On 12/22/25 11:02 AM, Richard Damon wrote:
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes a >>>>>>>> person a liar.
refusal to acknowledge how much i've demonstrated in terms of
working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it
cannot be implemented on basic turing machines. and ur really just
being a massive dick suggesting i haven't demonstrated *any*
knowledge of the field, that's really just u being mean
No, it is an interface based on assuming things that are impossible,
because you don't understand some of the basics of the field.
The problem is what you are trying to "extend" it to, breaks the
fundamental purpose of it, something you apperently don't grasp.
If you were then going to look at usefulness of you new field, it
might be one thing, but you start off saying you aren't going to do
that.
All it seems you want to do is take a real and important problem,
and try to find a toy system where a toy version of that problem can
be made solvable.
No one cares about making toy system that can solve toy problem.
i'm sorry, the problem of pathological input like:
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
then all ur proofs for undecidability are based on "toy" problems???
these "toy problems" are ur limits to computability ... and yet ur
deride me for trying address them???
mean
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy" problem???
The problem is you don't understand the system the program is define in.
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't misteriously
do something different
bruh, there's nothing "mysterious" about console.trace() printing the
stack based on where it's called.
mean
And thus, since halts has a defined algorithm and thus a defined
behavior when it is called ther, und has defined behavior, and thus
trying to call it "incoherent" is just to make a toy system that
violates determinism.
When you play with the definition of halts, either you are creating
NEW inputs, and thus can't actually talk about comparisons between
them being significant, after all 1 isn't the sane aa 2.
Or you leave the input alone, and you find that other versions of halt
can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
On 12/22/25 2:11 PM, dart200 wrote:
On 12/22/25 11:02 AM, Richard Damon wrote:
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity.
Trying to assert that which has been shown false is what makes >>>>>>>>> a person a liar.
refusal to acknowledge how much i've demonstrated in terms of >>>>>>>> working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it
cannot be implemented on basic turing machines. and ur really just >>>>>> being a massive dick suggesting i haven't demonstrated *any*
knowledge of the field, that's really just u being mean
No, it is an interface based on assuming things that are
impossible, because you don't understand some of the basics of the
field.
The problem is what you are trying to "extend" it to, breaks the
fundamental purpose of it, something you apperently don't grasp.
If you were then going to look at usefulness of you new field, it
might be one thing, but you start off saying you aren't going to do >>>>> that.
All it seems you want to do is take a real and important problem,
and try to find a toy system where a toy version of that problem
can be made solvable.
No one cares about making toy system that can solve toy problem.
i'm sorry, the problem of pathological input like:
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
then all ur proofs for undecidability are based on "toy" problems???
these "toy problems" are ur limits to computability ... and yet ur
deride me for trying address them???
mean
Nope, just shows your problem is you miss the details of the proof.
The proof works in the system with the actually accepted definitions,
which have shown themselves to be good models of what we can do and know.
Then the proof STARTS with assuming a specific, but arbitrary,
definition of "halts", and then shows that we can make an input that
makes it not actually a halt decider. That such an input is always realisable given we have a realizable machine.
It then uses basic logic to show that since for any machine given as a possible decider, we can show that there is at least one case it doesn't
get rignt, then all possible decider do not get all answer right,
therefore there are NO deciders that get ALL answer right.
No need to toys that broke the system.
Yes, the original, and may versions, work under the priciple of proof by contradiction, and that method can be hard to understand for people
lacking the basic understanding of the logic, but that doesn't make it
use a "toy"
Your problem is you just don't understand the basic nature of the
elements of the proof, You want to be changing the fixed machine in the
middle of the proof, but that is logically like saying, now, if we let 1
be equal to 2, then we can show...
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy" problem???
The problem is you don't understand the system the program is define in. >>>
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't misteriously
do something different
bruh, there's nothing "mysterious" about console.trace() printing the
stack based on where it's called.
mean
And thus, since halts has a defined algorithm and thus a defined
behavior when it is called ther, und has defined behavior, and thus
trying to call it "incoherent" is just to make a toy system that
violates determinism.
When you play with the definition of halts, either you are creating
NEW inputs, and thus can't actually talk about comparisons between
them being significant, after all 1 isn't the sane aa 2.
Or you leave the input alone, and you find that other versions of
halt can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
On 12/22/25 11:45 AM, Richard Damon wrote:
On 12/22/25 2:11 PM, dart200 wrote:
On 12/22/25 11:02 AM, Richard Damon wrote:
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity. >>>>>>>>>>
Trying to assert that which has been shown false is what makes >>>>>>>>>> a person a liar.
refusal to acknowledge how much i've demonstrated in terms of >>>>>>>>> working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it
cannot be implemented on basic turing machines. and ur really
just being a massive dick suggesting i haven't demonstrated *any* >>>>>>> knowledge of the field, that's really just u being mean
No, it is an interface based on assuming things that are
impossible, because you don't understand some of the basics of the >>>>>> field.
The problem is what you are trying to "extend" it to, breaks the
fundamental purpose of it, something you apperently don't grasp.
If you were then going to look at usefulness of you new field, it >>>>>> might be one thing, but you start off saying you aren't going to
do that.
All it seems you want to do is take a real and important problem, >>>>>> and try to find a toy system where a toy version of that problem
can be made solvable.
No one cares about making toy system that can solve toy problem.
i'm sorry, the problem of pathological input like:
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
then all ur proofs for undecidability are based on "toy" problems???
these "toy problems" are ur limits to computability ... and yet ur
deride me for trying address them???
mean
Nope, just shows your problem is you miss the details of the proof.
The proof works in the system with the actually accepted definitions,
which have shown themselves to be good models of what we can do and know.
how do u know a theoretical limit is "working"??? how does declaring "it works" after not trying to test an observed "limit" prove anything about
how well the limit works?
Then the proof STARTS with assuming a specific, but arbitrary,
definition of "halts", and then shows that we can make an input that
makes it not actually a halt decider. That such an input is always
realisable given we have a realizable machine.
It then uses basic logic to show that since for any machine given as a
possible decider, we can show that there is at least one case it
doesn't get rignt, then all possible decider do not get all answer
right, therefore there are NO deciders that get ALL answer right.
No need to toys that broke the system.
bruh u just rephrased the toy with english words instead of a pseudo-
code because for some reason u think that matters.
Yes, the original, and may versions, work under the priciple of proof
by contradiction, and that method can be hard to understand for people
lacking the basic understanding of the logic, but that doesn't make it
use a "toy"
ur honestly just arbitrarily labeling my idea a toy and ur ideas not
because ... reasons ???
or u confused a bandwagon with correctness
Your problem is you just don't understand the basic nature of the
elements of the proof, You want to be changing the fixed machine in the
again, i DO understand the elements??? i've literally given u an
algorithm in which that inability to answer to a pathological input is computed, which u just arbitrarily rejected, which u just rejected out
of hand even though it's literally thot process anyone uses to
understand semantic paradoxes...
maybe u should consider being less mean
middle of the proof, but that is logically like saying, now, if we let
1 be equal to 2, then we can show...
except it's not because u've never used the ideas i have to actually
show 1 = 2, ur literally just making a wild claim because whatever environment u hail from has a rather lacking sense of critical thot.
i would love for u to produce an actual counter proof to my ideas,
because that would at least indicate u playing around with them. so far
u haven't shown any indication u've understood anything i've tried to suggest
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy" problem??? >>>>>
The problem is you don't understand the system the program is define
in.
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't misteriously
do something different
bruh, there's nothing "mysterious" about console.trace() printing the
stack based on where it's called.
mean
And thus, since halts has a defined algorithm and thus a defined
behavior when it is called ther, und has defined behavior, and thus
trying to call it "incoherent" is just to make a toy system that
violates determinism.
When you play with the definition of halts, either you are creating
NEW inputs, and thus can't actually talk about comparisons between
them being significant, after all 1 isn't the sane aa 2.
Or you leave the input alone, and you find that other versions of
halt can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
On 12/22/25 3:06 PM, dart200 wrote:
On 12/22/25 11:45 AM, Richard Damon wrote:
On 12/22/25 2:11 PM, dart200 wrote:
On 12/22/25 11:02 AM, Richard Damon wrote:
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:
Refusal to accept proven truth is just a sign of stupidity. >>>>>>>>>>>
Trying to assert that which has been shown false is what >>>>>>>>>>> makes a person a liar.
refusal to acknowledge how much i've demonstrated in terms of >>>>>>>>>> working knowledge, even if i don't agree, is just mean bro
No, you haven't demonstrated knowledge of the field.
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it >>>>>>>> cannot be implemented on basic turing machines. and ur really >>>>>>>> just being a massive dick suggesting i haven't demonstrated
*any* knowledge of the field, that's really just u being mean
No, it is an interface based on assuming things that are
impossible, because you don't understand some of the basics of
the field.
The problem is what you are trying to "extend" it to, breaks the >>>>>>> fundamental purpose of it, something you apperently don't grasp. >>>>>>>
If you were then going to look at usefulness of you new field, it >>>>>>> might be one thing, but you start off saying you aren't going to >>>>>>> do that.
All it seems you want to do is take a real and important problem, >>>>>>> and try to find a toy system where a toy version of that problem >>>>>>> can be made solvable.
No one cares about making toy system that can solve toy problem.
i'm sorry, the problem of pathological input like:
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
then all ur proofs for undecidability are based on "toy" problems???
these "toy problems" are ur limits to computability ... and yet ur
deride me for trying address them???
mean
Nope, just shows your problem is you miss the details of the proof.
The proof works in the system with the actually accepted definitions,
which have shown themselves to be good models of what we can do and
know.
how do u know a theoretical limit is "working"??? how does declaring
"it works" after not trying to test an observed "limit" prove anything
about how well the limit works?
I guess you have the same problem as Olcott about "Truth".
SInce you don't understand it, you won't believe it.
Maybe if you spend some time actually understanding what Computation
Theory was developed for, you could see how it succeeded in its goal.
The proof that there *IS* a limit was a major acheveemnt, even if we
later worked on refining where it is.
Since you don't understand how the system works, your experements" tend
to be based on incorrect concepts.
Then the proof STARTS with assuming a specific, but arbitrary,
definition of "halts", and then shows that we can make an input that
makes it not actually a halt decider. That such an input is always
realisable given we have a realizable machine.
It then uses basic logic to show that since for any machine given as
a possible decider, we can show that there is at least one case it
doesn't get rignt, then all possible decider do not get all answer
right, therefore there are NO deciders that get ALL answer right.
No need to toys that broke the system.
bruh u just rephrased the toy with english words instead of a pseudo-
code because for some reason u think that matters.
Nope.
Real: Following the actual definitions of Computation Theory as
developed over the years.
Toy: Assuming we can break/change some of these requirements because we
want to.
Your "Toy" is built on assuming you can do things that theory says you can't. You can't show you actually can, you just assume you can.
Thus, your toy system is based on error.
Yes, the original, and may versions, work under the priciple of proof
by contradiction, and that method can be hard to understand for
people lacking the basic understanding of the logic, but that doesn't
make it use a "toy"
ur honestly just arbitrarily labeling my idea a toy and ur ideas not
because ... reasons ???
IF IT ISN'T THE REAL SYSTEM AS DEFINED, it is just a toy.
It seems you don't understand the nature of definitions.
or u confused a bandwagon with correctness
Your problem is you just don't understand the basic nature of the
elements of the proof, You want to be changing the fixed machine in the
again, i DO understand the elements??? i've literally given u an
algorithm in which that inability to answer to a pathological input is
computed, which u just arbitrarily rejected, which u just rejected out
of hand even though it's literally thot process anyone uses to
understand semantic paradoxes...
No, you didn't as your input wasn't complete.
You forget that the pathological program needs to be a complete program, including the code for the specific unchangable after define, decider it
is built on.
Then you talk about the fixed thing changing, and thus show your ignorance.
maybe u should consider being less mean
When you get less stupid.
middle of the proof, but that is logically like saying, now, if we
let 1 be equal to 2, then we can show...
except it's not because u've never used the ideas i have to actually
show 1 = 2, ur literally just making a wild claim because whatever
environment u hail from has a rather lacking sense of critical thot.
Nope, you show 1 = 2 after assuming a similar error
i would love for u to produce an actual counter proof to my ideas,
because that would at least indicate u playing around with them. so
far u haven't shown any indication u've understood anything i've tried
to suggest
I did. I pointed out how it doesn't meet the requirements of the system.
You can make you broken system if you want to, and prove all sorts of nonsense in it, but then it is just a toy until you show how it can be useful.
You need to choose:
Work IN the system, and follow its rules and definitions
Make a NEW system, and show it is useful or it is just a toy.
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy" problem??? >>>>>>
The problem is you don't understand the system the program is
define in.
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't
misteriously do something different
bruh, there's nothing "mysterious" about console.trace() printing
the stack based on where it's called.
mean
And thus, since halts has a defined algorithm and thus a defined
behavior when it is called ther, und has defined behavior, and thus >>>>> trying to call it "incoherent" is just to make a toy system that
violates determinism.
When you play with the definition of halts, either you are creating >>>>> NEW inputs, and thus can't actually talk about comparisons between
them being significant, after all 1 isn't the sane aa 2.
Or you leave the input alone, and you find that other versions of
halt can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
On 12/22/25 12:37 PM, Richard Damon wrote:
On 12/22/25 3:06 PM, dart200 wrote:
On 12/22/25 11:45 AM, Richard Damon wrote:
On 12/22/25 2:11 PM, dart200 wrote:
On 12/22/25 11:02 AM, Richard Damon wrote:
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:i'm sorry, the problem of pathological input like:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:No, you haven't demonstrated knowledge of the field.
Refusal to accept proven truth is just a sign of stupidity. >>>>>>>>>>>>
Trying to assert that which has been shown false is what >>>>>>>>>>>> makes a person a liar.
refusal to acknowledge how much i've demonstrated in terms of >>>>>>>>>>> working knowledge, even if i don't agree, is just mean bro >>>>>>>>>>
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it >>>>>>>>> cannot be implemented on basic turing machines. and ur really >>>>>>>>> just being a massive dick suggesting i haven't demonstrated >>>>>>>>> *any* knowledge of the field, that's really just u being mean >>>>>>>>>
No, it is an interface based on assuming things that are
impossible, because you don't understand some of the basics of >>>>>>>> the field.
The problem is what you are trying to "extend" it to, breaks the >>>>>>>> fundamental purpose of it, something you apperently don't grasp. >>>>>>>>
If you were then going to look at usefulness of you new field, >>>>>>>> it might be one thing, but you start off saying you aren't going >>>>>>>> to do that.
All it seems you want to do is take a real and important
problem, and try to find a toy system where a toy version of
that problem can be made solvable.
No one cares about making toy system that can solve toy problem. >>>>>>>
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
then all ur proofs for undecidability are based on "toy"
problems??? these "toy problems" are ur limits to computability ... >>>>> and yet ur deride me for trying address them???
mean
Nope, just shows your problem is you miss the details of the proof.
The proof works in the system with the actually accepted
definitions, which have shown themselves to be good models of what
we can do and know.
how do u know a theoretical limit is "working"??? how does declaring
"it works" after not trying to test an observed "limit" prove
anything about how well the limit works?
I guess you have the same problem as Olcott about "Truth".
SInce you don't understand it, you won't believe it.
Maybe if you spend some time actually understanding what Computation
Theory was developed for, you could see how it succeeded in its goal.
our application of computing to society is fucking shitshow orders of magnitude more complicated that it should be, because we don't have the ability to find agreement on canonicalized machines due thinking we disproved our general ability to agree semantic truths
where u see "success" is see a steaming shitpile of stupidty. here's
alan kay complaining about how retarded we are at coding over a decade ago:
https://www.youtube.com/watch?v=ubaX1Smg6pY
The proof that there *IS* a limit was a major acheveemnt, even if we
later worked on refining where it is.
and if it actually wrong because our perspective is too narrow, than
it's actually a major failure
Since you don't understand how the system works, your experements"
tend to be based on incorrect concepts.
bruh ur really are fucking massive dick for continually claiming i don't understand computability theory 101 level concepts.
someday i hope u apologize for how u've treated me
Then the proof STARTS with assuming a specific, but arbitrary,
definition of "halts", and then shows that we can make an input that
makes it not actually a halt decider. That such an input is always
realisable given we have a realizable machine.
It then uses basic logic to show that since for any machine given as
a possible decider, we can show that there is at least one case it
doesn't get rignt, then all possible decider do not get all answer
right, therefore there are NO deciders that get ALL answer right.
No need to toys that broke the system.
bruh u just rephrased the toy with english words instead of a pseudo-
code because for some reason u think that matters.
Nope.
cope
Real: Following the actual definitions of Computation Theory as
developed over the years.
Toy: Assuming we can break/change some of these requirements because
we want to.
Your "Toy" is built on assuming you can do things that theory says you
can't. You can't show you actually can, you just assume you can.
Thus, your toy system is based on error.
u don't know what a bandwagon argument is, eh???
i mean, u laugh at polcott for bringing up 22 years all the time, and
yet here u are talking about length of time as if that's a valid argument
fucking a dude. *learn what a bandwagon argument is*
Yes, the original, and may versions, work under the priciple of
proof by contradiction, and that method can be hard to understand
for people lacking the basic understanding of the logic, but that
doesn't make it use a "toy"
ur honestly just arbitrarily labeling my idea a toy and ur ideas not
because ... reasons ???
IF IT ISN'T THE REAL SYSTEM AS DEFINED, it is just a toy.
It seems you don't understand the nature of definitions.
yeah, better definitions give u more ability
or u confused a bandwagon with correctness
again, i DO understand the elements??? i've literally given u an
Your problem is you just don't understand the basic nature of the
elements of the proof, You want to be changing the fixed machine in the >>>
algorithm in which that inability to answer to a pathological input
is computed, which u just arbitrarily rejected, which u just rejected
out of hand even though it's literally thot process anyone uses to
understand semantic paradoxes...
No, you didn't as your input wasn't complete.
You forget that the pathological program needs to be a complete
program, including the code for the specific unchangable after define,
decider it is built on.
Then you talk about the fixed thing changing, and thus show your
ignorance.
maybe u should consider being less mean
When you get less stupid.
mean
middle of the proof, but that is logically like saying, now, if we
let 1 be equal to 2, then we can show...
except it's not because u've never used the ideas i have to actually
show 1 = 2, ur literally just making a wild claim because whatever
environment u hail from has a rather lacking sense of critical thot.
Nope, you show 1 = 2 after assuming a similar error
i have no idea what ur talking about, i never claimed 1=2 or that my proposal leads to 1=2
literally pulling random ass claims our ur asshole again. ur such
dishonest person.
i would love for u to produce an actual counter proof to my ideas,
because that would at least indicate u playing around with them. so
far u haven't shown any indication u've understood anything i've
tried to suggest
I did. I pointed out how it doesn't meet the requirements of the system.
crying about "requirements" isn't showing it causes a contradiction
You can make you broken system if you want to, and prove all sorts of
nonsense in it, but then it is just a toy until you show how it can be
useful.
You need to choose:
Work IN the system, and follow its rules and definitions
Make a NEW system, and show it is useful or it is just a toy.
u don't even discuss with enough good faith to acknowledge that i
actually do understand computability 101 level concepts, and that would
be incredibly frustrating for anyone
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy"
problem???
The problem is you don't understand the system the program is
define in.
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't
misteriously do something different
bruh, there's nothing "mysterious" about console.trace() printing
the stack based on where it's called.
mean
And thus, since halts has a defined algorithm and thus a defined
behavior when it is called ther, und has defined behavior, and
thus trying to call it "incoherent" is just to make a toy system
that violates determinism.
When you play with the definition of halts, either you are
creating NEW inputs, and thus can't actually talk about
comparisons between them being significant, after all 1 isn't the >>>>>> sane aa 2.
Or you leave the input alone, and you find that other versions of >>>>>> halt can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
On 12/21/25 6:22 PM, Chris M. Thomasson wrote:
On 12/21/2025 5:40 PM, dart200 wrote:
On 12/21/25 5:32 PM, Chris M. Thomasson wrote:
On 12/21/2025 1:14 PM, dart200 wrote:
On 12/21/25 12:07 PM, Chris M. Thomasson wrote:
On 12/20/2025 9:52 PM, dart200 wrote:
On 12/20/25 9:23 PM, Chris M. Thomasson wrote:
On 12/20/2025 7:58 PM, Richard Damon wrote:
[...]
Casting pearls before swine? Yikes! ;^o
says the literal troll. keep up the good work!
Let me guess, you are going to call me the N word and then tell me >>>>>> to snuff myself out.
my fellow african american, please live out ur life as long as
possible
Whatever. You seem to be able to get really pissed of and end up
writing some crazy/strange shit. You said the N word on a public
forum. Decorum,
nigger nigger nigger nigger nigger nigger nigger nigger nigger nigger
it's a just a word dude
a bit? Do you tend to get really mad in real life as well?
i'm fairly conflict avoidant irl
Say it to other people out there? Here is some music for ya. More
cowbell? lol:
https://youtu.be/QtjhyO547iw?list=RDQtjhyO547iw
[...]
nah nigga
https://www.youtube.com/watch?v=FvNCXgJZbT0
On 12/19/2025 7:33 PM, dart200 wrote:
On 12/19/25 2:09 PM, Chris M. Thomasson wrote:To the guy who invented the zero. Thanks for nothing.
On 12/18/2025 8:57 PM, dart200 wrote:
On 12/18/25 4:46 PM, Chris M. Thomasson wrote:[...]
What about a PRNG? ;^)Well, think of a program that uses a TRNG for its logic. WE as the
chris: turing machines are fully deterministic and cannot involve TRNGs >>>
ofc but undecidability never involved that either,
"hard to compute" is not the same as "impossible to compute"
[...]
On 12/22/25 3:58 PM, dart200 wrote:
On 12/22/25 12:37 PM, Richard Damon wrote:
On 12/22/25 3:06 PM, dart200 wrote:
On 12/22/25 11:45 AM, Richard Damon wrote:
On 12/22/25 2:11 PM, dart200 wrote:
On 12/22/25 11:02 AM, Richard Damon wrote:
On 12/22/25 1:57 PM, dart200 wrote:
On 12/22/25 10:49 AM, Richard Damon wrote:
On 12/22/25 1:39 PM, dart200 wrote:i'm sorry, the problem of pathological input like:
On 12/22/25 10:33 AM, Richard Damon wrote:
On 12/22/25 1:24 PM, dart200 wrote:
On 12/22/25 7:10 AM, Richard Damon wrote:No, you haven't demonstrated knowledge of the field.
Refusal to accept proven truth is just a sign of stupidity. >>>>>>>>>>>>>
Trying to assert that which has been shown false is what >>>>>>>>>>>>> makes a person a liar.
refusal to acknowledge how much i've demonstrated in terms >>>>>>>>>>>> of working knowledge, even if i don't agree, is just mean bro >>>>>>>>>>>
You have show a decider ignorance of basic properties.
i'm well aware it's a novel interface, i'm even well aware it >>>>>>>>>> cannot be implemented on basic turing machines. and ur really >>>>>>>>>> just being a massive dick suggesting i haven't demonstrated >>>>>>>>>> *any* knowledge of the field, that's really just u being mean >>>>>>>>>>
No, it is an interface based on assuming things that are
impossible, because you don't understand some of the basics of >>>>>>>>> the field.
The problem is what you are trying to "extend" it to, breaks >>>>>>>>> the fundamental purpose of it, something you apperently don't >>>>>>>>> grasp.
If you were then going to look at usefulness of you new field, >>>>>>>>> it might be one thing, but you start off saying you aren't
going to do that.
All it seems you want to do is take a real and important
problem, and try to find a toy system where a toy version of >>>>>>>>> that problem can be made solvable.
No one cares about making toy system that can solve toy problem. >>>>>>>>
und = () -> halts(und) && loop_forever()
When the halts that it references isn't actually defined it is.
then all ur proofs for undecidability are based on "toy"
problems??? these "toy problems" are ur limits to
computability ... and yet ur deride me for trying address them???
mean
Nope, just shows your problem is you miss the details of the proof.
The proof works in the system with the actually accepted
definitions, which have shown themselves to be good models of what
we can do and know.
how do u know a theoretical limit is "working"??? how does declaring
"it works" after not trying to test an observed "limit" prove
anything about how well the limit works?
I guess you have the same problem as Olcott about "Truth".
SInce you don't understand it, you won't believe it.
Maybe if you spend some time actually understanding what Computation
Theory was developed for, you could see how it succeeded in its goal.
our application of computing to society is fucking shitshow orders of
magnitude more complicated that it should be, because we don't have
the ability to find agreement on canonicalized machines due thinking
we disproved our general ability to agree semantic truths
Who says we apply computing to "Society". It is a theory of mathematics
and logic.
That you don't want to agree to the already defined canonical machine
form is your own problem.
Note, the classical machine form IS linked to semantic truth in formal systems. That you don't understand the link is your own problem.
where u see "success" is see a steaming shitpile of stupidty. here's
alan kay complaining about how retarded we are at coding over a decade
ago:
https://www.youtube.com/watch?v=ubaX1Smg6pY
But "Computing" is not about "Coding"
Maybe your problem is you think Computing is about how we use Computers.
It does show some of the ultimate limiations of what we can do with computers.
The proof that there *IS* a limit was a major acheveemnt, even if we
later worked on refining where it is.
and if it actually wrong because our perspective is too narrow, than
it's actually a major failure
But it is PROVEN, and thus known to be true in the logic system. While
we can't know for sure that our fundamentals of logic aren't
inconsistent, they have held up well.
You can, of course, try to work in a new logic system, but then you need
to start at the basics and work up.
As I have said, break out of the standard system and one of the first
things is you need to show it is useful, or it is just a toy.
Since you don't understand how the system works, your experements"
tend to be based on incorrect concepts.
bruh ur really are fucking massive dick for continually claiming i
don't understand computability theory 101 level concepts.
Because you keep makes 101 level errors.
someday i hope u apologize for how u've treated me
You first have to show you know something.
Then the proof STARTS with assuming a specific, but arbitrary,
definition of "halts", and then shows that we can make an input
that makes it not actually a halt decider. That such an input is
always realisable given we have a realizable machine.
It then uses basic logic to show that since for any machine given
as a possible decider, we can show that there is at least one case
it doesn't get rignt, then all possible decider do not get all
answer right, therefore there are NO deciders that get ALL answer
right.
No need to toys that broke the system.
bruh u just rephrased the toy with english words instead of a
pseudo- code because for some reason u think that matters.
Nope.
cope
I guess you are just proving your ignorance.
Real: Following the actual definitions of Computation Theory as
developed over the years.
Toy: Assuming we can break/change some of these requirements because
we want to.
Your "Toy" is built on assuming you can do things that theory says
you can't. You can't show you actually can, you just assume you can.
Thus, your toy system is based on error.
u don't know what a bandwagon argument is, eh???
Sure I do.
But "Bandwagon" deals with opinion issue, not definitions.
i mean, u laugh at polcott for bringing up 22 years all the time, and
yet here u are talking about length of time as if that's a valid argument
The STANDARD DEFINITION are the basis, as they are what has been agreed
to as the foundation.
fucking a dude. *learn what a bandwagon argument is*
Maybe you need to learn the difference between ESTABLISHED FACTS, and
ideas of opinion which are subject to the bandwagon fallacy.
Yes, the original, and may versions, work under the priciple of
proof by contradiction, and that method can be hard to understand
for people lacking the basic understanding of the logic, but that
doesn't make it use a "toy"
ur honestly just arbitrarily labeling my idea a toy and ur ideas not
because ... reasons ???
IF IT ISN'T THE REAL SYSTEM AS DEFINED, it is just a toy.
It seems you don't understand the nature of definitions.
yeah, better definitions give u more ability
by "better" you should mean more accurate.
"DIFFERENT" in a formal system is rarely "Correct" unless it actually is just an equivalent for the original.
or u confused a bandwagon with correctness
Your problem is you just don't understand the basic nature of the
elements of the proof, You want to be changing the fixed machine in >>>>> the
again, i DO understand the elements??? i've literally given u an
algorithm in which that inability to answer to a pathological input
is computed, which u just arbitrarily rejected, which u just
rejected out of hand even though it's literally thot process anyone
uses to understand semantic paradoxes...
No, you didn't as your input wasn't complete.
You forget that the pathological program needs to be a complete
program, including the code for the specific unchangable after
define, decider it is built on.
Then you talk about the fixed thing changing, and thus show your
ignorance.
maybe u should consider being less mean
When you get less stupid.
mean
Accurate
mean
#god
middle of the proof, but that is logically like saying, now, if we
let 1 be equal to 2, then we can show...
except it's not because u've never used the ideas i have to actually
show 1 = 2, ur literally just making a wild claim because whatever
environment u hail from has a rather lacking sense of critical thot.
Nope, you show 1 = 2 after assuming a similar error
i have no idea what ur talking about, i never claimed 1=2 or that my
proposal leads to 1=2
But it does the equivalent. You assume something to be true that isn't
literally pulling random ass claims our ur asshole again. ur such
dishonest person.
Note, I started as a simile. Your error makes the same category of
error, just a bit more hidden.
i would love for u to produce an actual counter proof to my ideas,
because that would at least indicate u playing around with them. so
far u haven't shown any indication u've understood anything i've
tried to suggest
I did. I pointed out how it doesn't meet the requirements of the system.
crying about "requirements" isn't showing it causes a contradiction
If your input doesn't meet the requirments of the problem, then your arguement is just an unsound category error.
Your "Proof" shows nothing, as it is just unsound. I don't need to show
the conclusion is wrong, I can destroy the arguement by showing it was unsound in its basis, thus the results have not actually be proven.
You can make you broken system if you want to, and prove all sorts of
nonsense in it, but then it is just a toy until you show how it can
be useful.
You need to choose:
Work IN the system, and follow its rules and definitions
Make a NEW system, and show it is useful or it is just a toy.
u don't even discuss with enough good faith to acknowledge that i
actually do understand computability 101 level concepts, and that
would be incredibly frustrating for anyone
No, you don't, as you still seem to think you can build your concept on
the decider recognizing the input using an equivalent version of itself.
You talk about "changing" parts of the input, but still try to talk as
if it is the THE input.
Sorry, but you basic logic just fails, and it seems you just don't care.
is just a "toy" problem to you?
cause that's the "toy" problem i'm trying to solve ...
ok, so what kind of pathological input wouldn't be a "toy"
problem???
The problem is you don't understand the system the program is
define in.
In that system:
Programs are FULLY defined with all their algoritms part of it.
Programs are deterministic in there behavior, and don't
misteriously do something different
bruh, there's nothing "mysterious" about console.trace() printing >>>>>> the stack based on where it's called.
mean
And thus, since halts has a defined algorithm and thus a defined >>>>>>> behavior when it is called ther, und has defined behavior, and
thus trying to call it "incoherent" is just to make a toy system >>>>>>> that violates determinism.
When you play with the definition of halts, either you are
creating NEW inputs, and thus can't actually talk about
comparisons between them being significant, after all 1 isn't the >>>>>>> sane aa 2.
Or you leave the input alone, and you find that other versions of >>>>>>> halt can show you that your original halt was just wrong,
Your concept of incoherency is based on toy logic.
the philosophy of how we go about implementing computer systems with
society stems from the theory of computing, especially including in
regards to ti's systems.
On 12/22/25 10:12 PM, dart200 wrote:
the philosophy of how we go about implementing computer systems with
society stems from the theory of computing, especially including in
regards to ti's systems.
That is nonsense since Computation Theory has almost nothing to do with
the typical practical matters of a modern computer and its use.
I think you are sadly mistaken about what you talk about.
There may be a lot in "Computer Science" that affects things, but that
isn't Computation Theory, which is just in a corner of the field, even
if somewhat foundational.
it is related u narrow minded retard,
go ask any language designer why we don't do total halting analysis
and the halting problem is surely to be mentioned. i get that
professional programmers are one step removed from the language
writer, but the way they code is invariable influenced by the way the language is written.
ur not very good at systemic thot my dude, so ur just gunna deny the causality here. but it exists, and the disgusting facade of
rationality found with modern computing system is my *main*
motivation.
On 12/22/25 7:16 PM, Richard Damon wrote:
On 12/22/25 10:12 PM, dart200 wrote:
the philosophy of how we go about implementing computer systems with
society stems from the theory of computing, especially including in
regards to ti's systems.
That is nonsense since Computation Theory has almost nothing to do
with the typical practical matters of a modern computer and its use.
I think you are sadly mistaken about what you talk about.
There may be a lot in "Computer Science" that affects things, but that
isn't Computation Theory, which is just in a corner of the field, even
if somewhat foundational.
from later on in that same post:
it is related u narrow minded retard,
go ask any language designer why we don't do total halting analysis
and the halting problem is surely to be mentioned. i get that
professional programmers are one step removed from the language
writer, but the way they code is invariable influenced by the way the language is written.
ur not very good at systemic thot my dude, so ur just gunna deny the causality here. but it exists, and the disgusting facade of
rationality found with modern computing system is my *main*
motivation.
called that u'd just deny it
how predicable
On 12/22/25 10:24 PM, dart200 wrote:
On 12/22/25 7:16 PM, Richard Damon wrote:
On 12/22/25 10:12 PM, dart200 wrote:
the philosophy of how we go about implementing computer systems with
society stems from the theory of computing, especially including in
regards to ti's systems.
That is nonsense since Computation Theory has almost nothing to do
with the typical practical matters of a modern computer and its use.
I think you are sadly mistaken about what you talk about.
There may be a lot in "Computer Science" that affects things, but
that isn't Computation Theory, which is just in a corner of the
field, even if somewhat foundational.
from later on in that same post:
it is related u narrow minded retard,
;
go ask any language designer why we don't do total halting analysis
and the halting problem is surely to be mentioned. i get that
professional programmers are one step removed from the language
writer, but the way they code is invariable influenced by the way the
language is written.
;
ur not very good at systemic thot my dude, so ur just gunna deny the
causality here. but it exists, and the disgusting facade of
rationality found with modern computing system is my *main*
motivation.
called that u'd just deny it
how predicable
Yep, and you are just wrong because you just deny the truth that you
don't like.
You may THINK that computation theory is behind this, but that is just showing your ignorance of the field. What you are looking at are many
other aspects of computer science, but NOT computaiton theory.
Yes, we KNOW that total halting analysis can't be done, so we don't try
to do that.
Arw you sayng we should be putting effort into things that we know can't
be solved and doom ourselves to no progress?
That was the trap that these discoveries freed us from, knowing we can't
to the perfect job, allowed the computer engineering disciplines to look
at "how good" can we do, and not worry about the need to be perfect,
since we can't be.
Defining a toy version of the problem wont' solve the actual problems,
but if people think it does, then we have the error of thinking we are
safe when we aren't.
I guess you are just following the classic error of ignoring history, so dooming yourself to repeating it.
You may keep of finding ideas that just seem so close to being the
answer, but there will always be that ghost of a case that catches you unawares.
ye have little faith
#god
On 12/17/25 8:30 PM, Richard Damon wrote:
But there are not two branches in the behavior of the input, but only
one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
dick, the classic halting decider doesn't exist, so why would a
resolution that might actually exist, be fixed to referencing a
certainly non-existent machine??? 🙄🙄🙄
Am Wed, 17 Dec 2025 20:50:56 -0800 schrieb dart200:
On 12/17/25 8:30 PM, Richard Damon wrote:
But there are not two branches in the behavior of the input, but only
one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
dick, the classic halting decider doesn't exist, so why would a
resolution that might actually exist, be fixed to referencing a
certainly non-existent machine??? 🙄🙄🙄
You're begging the question. You needn't worry about a "resolution"
if you already accept that halt deciders are impossible.
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that
yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
we can compute this semantic property with a simple algo:
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the computation.
if the semantic results from (1) and (2) diverge from the injected prediction, the hypothetical machine is undecidable.
On 12/24/25 2:56 PM, joes wrote:
Am Wed, 17 Dec 2025 20:50:56 -0800 schrieb dart200:
On 12/17/25 8:30 PM, Richard Damon wrote:
But there are not two branches in the behavior of the input, but only
one of them.
The one that is the opposite of what the decider predicts.
You are making the Olcottian mistake of forgetting that the input
doesn't "reference" the decider, and thus changes as we imagine
different deciders, but is fixed on the one we started with.
dick, the classic halting decider doesn't exist, so why would a
resolution that might actually exist, be fixed to referencing a
certainly non-existent machine??? 🙄🙄🙄
You're begging the question. You needn't worry about a "resolution"
if you already accept that halt deciders are impossible.
i'm trying to propose a resolution that doesn't even involve making
classic halting decider "exist". we all agree the classic halting
decider does not exist, even polcott
dickard was trying to demand on my proposed context-aware classifier
decide on a pathological input involving the classic halting decider ... that which none of us even thinks exist. it's an unobtainable goalpost
none of us are even trying to hit, because we all agree it doesn't exist.
please tell me what question i'm begging
Am Sat, 20 Dec 2025 16:17:52 -0800 schrieb dart200:
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that
yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
No, und() is concrete and decidable, given halts(). That one
is hypothetical.
we can compute this semantic property with a simple algo:
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the computation.
if the semantic results from (1) and (2) diverge from the injected
prediction, the hypothetical machine is undecidable.
...for this decider.
On 12/24/25 4:34 PM, joes wrote:
Am Sat, 20 Dec 2025 16:17:52 -0800 schrieb dart200:
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that
yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
No, und() is concrete and decidable, given halts(). That one
is hypothetical.
therefore und() is hypothetical, given that halts() is hypothetical
given the real enumeration of machines, und() is not a concrete example
of halting machine that cannot be proven functionally equivalent to
other machines are functionally equivalent.
we can compute this semantic property with a simple algo:
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the computation.
if the semantic results from (1) and (2) diverge from the injected
prediction, the hypothetical machine is undecidable.
...for this decider.
On 12/24/25 9:12 PM, dart200 wrote:
On 12/24/25 4:34 PM, joes wrote:
Am Sat, 20 Dec 2025 16:17:52 -0800 schrieb dart200:
On 12/20/25 5:32 AM, Richard Damon wrote:
On 12/20/25 4:17 AM, dart200 wrote:
On 12/19/25 2:01 PM, Richard Damon wrote:
Nope, as "undecidable" isn't a property of an instance, but of a
well it's a property of hypothetical instances
Nope. You clearly don't understand what "undecidable" means, and that >>>>> yo0u refuse to learn it.
und = () -> {
if ( halts(und) ) loop_forever()
}
und() is a hypothetical instance of a machine that is provably
undecidable (given that halts() is a classic halting decider)
No, und() is concrete and decidable, given halts(). That one
is hypothetical.
therefore und() is hypothetical, given that halts() is hypothetical
given the real enumeration of machines, und() is not a concrete
example of halting machine that cannot be proven functionally
equivalent to other machines are functionally equivalent.
this whole thing is a bunch of freaking smoke and mirrors...
like i have a bunch of problem machines that are supposed to exists,
that prevent me from generally deciding on machines, in regards to any
kind of semantic decider u can imagine...
but literally none of them are concretely tangible machines cause if
even one was, and i could know it specifically... the whole thing falls apart into incongruity,
YET at the same them you keep asserting you have proof they all *must* exist!
sheesh
i just need to find one fuck-up my dudes, and the whole house of cards
is gunna come falling down
we can compute this semantic property with a simple algo:
1) inject in /true/ for halts(und):
() -> if (true) loop_forever
this runs forever
2) inject in /false/ for halts(und):
() -> if (false) loop_forever
this halts
3) compare the injected prediction with the result of the computation. >>>> if the semantic results from (1) and (2) diverge from the injected
prediction, the hypothetical machine is undecidable.
...for this decider.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,090 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 59:51:24 |
| Calls: | 13,948 |
| Calls today: | 1 |
| Files: | 187,035 |
| D/L today: |
2,695 files (773M bytes) |
| Messages: | 2,461,296 |