From Newsgroup: comp.theory

previously i wrote about a classifier variation i called the ghost
detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a total
ghost detector by doing an unbounded search via the reduction techniques
used to compute the machine that is functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is going
to claim this is just kicking the can down the road. but that's not
actually true. many machines are directly computable. many not directly computable, are *still* REDUCIBLE by computation (those that only
contradict a finite amount of detector calls in the chain of
functionally equivalent machines found by injection/reduction), while
only a final (but still identifiable) class of machines paradoxes *all* functionally equivalent machines found by value injection, and are
therefore not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine will do,
just that we just can't determine them generally via computable algo
because UNCOMPUTABLE machines will defeat that aglo.

so a halting ghost detector now has the form:

gd_halts(machine) -> {
HALTS: if machine halts
LOOPS: if machine does not halt
REDUCIBLE: if machine semantics can be decided thru
reduction by decider value injection
UNCOMPUTABLE: if machine semantics cannot be decided
by computation (because it would take
infinite reductions)
}

an example of a reducible machine is DR:

DR = () -> {
gdi = gd_halts(DR)
if (gdi == HALTS || gdi == LOOPS)
goto paradox

DR' = inject(DR, gd_halts(DR), REDUCIBLE)
gdi = gd_halts(DR')
if (gdi == HALTS || gdi == LOOPS)
goto paradox

DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
gdi = gd_halts(DR'')
if (gdi == HALTS || gdi == LOOPS)
goto paradox

paradox:
if (gdi == HALT)
loop()
else
halt()
}

which can be computably reduced to the decidedly halting function:

DR''' = () -> {
gdi = REDUCIBLE
if (gdi == HALTS || gdi == LOOPS)
goto paradox

DR' = inject(DR, gd_halts(DR), REDUCIBLE)
gdi = REDUCIBLE
if (gdi == HALTS || gdi == LOOPS)
goto paradox

DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
gdi = REDUCIBLE
if (gdi == HALTS || gdi == LOOPS)
goto paradox

paradox:
if (gdi == HALT)
loop()
else
halt()
}

gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

DU = () -> {
// loop until valid result
d = DU
loop:
gdi = gd_halts(d)
if (gdi != HALTS && gdi != LOOPS) {
d = inject(d, gd_halts(d), UNCOMPUTABLE)
goto loop
}

paradox:
if (gdi == HALT)
loop()
else
halt()
}

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in DU to
see if it's possible compute this value somehow. since this call happens
in an unbounded search, there's two forms we could try:

a) a single inject() for the specific value of d that was last tested
against. this would cause DU to infinite loop, as the discovery loop
would just keep injecting the values that had just been tested, the
result of which on the next cycle would then be required to find still UNCOMPUTABLE. because there are an unbounded amount of detector calls,
it would take an unbounded amount of injections to reduce them all out,
so the end would never be reached.

the same would be true for any other discovery loop done in this manner:
DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative:

b) why stick to singular injections? what if we tried to preempt this
result by replacing all the calls with an UNCOMPUTABLE value:

DU' = () -> {
// loop until valid result
d = DU
loop:
gdi = UNCOMPUTABLE
if (gdi != HALTS && gdi != LOOPS) {
d = inject(d, gd_halts(d), UNCOMPUTABLE)
goto loop
}

paradox:
if (gdi == HALT)
loop()
else
halt()
}

this doens't work either. when tried from within DU, then on the second iteration of loop, where d = DU', gd_halts(d) will return LOOPS which
will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ... from
a perspective which perhaps cannot be referenced by a machine, then DU'
does represent a machine that is functionally equivalent to DU running
method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that these
machines are *always* functionally equivalent to some *less-complex*
machine that does not form a decision paradox. surely all the REDUCIBLE
ones are since that is directly computable, but the only difference
between REDUCIBLE and UNCOMPUTABLE machines are that REDUCIBLE machines
only contradict a bounded amount of reductions, whereas UNCOMPUTABLE
machines contradict an unbounded amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run for infinite time as they must all get stuck in unbounded "searches" for the functionally equivalent machine to contradict, so therefore this
paradigm does not get contradicted by the fact we can enumerate all
halting machines.

at least, that's most we can do without reflective computing. if the
decision algo could tell it was running within DU vs externally, then it
could choose between the unbounded injection and bounded injection on an instance by instance basis to possibly execute a fully computable
paradigm...

i'm fairly happy with this change. now it's truly a ghost *detector* and
not a ghost /decider/ eh??? my previous incarnation tried to make it so
that all machine semantics could be effectively computable thru
reduction, but that's just not possible when operating strictly with
turing machines. but perhaps we actually can still detect it, which is
what this classifier was named for.

ahhh richard, this haunted house of cards we got going on is gunna start crumbling any day now...
--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ nick

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the ghost
detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a total
ghost detector by doing an unbounded search via the reduction techniques used to compute the machine that is functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is going
to claim this is just kicking the can down the road. but that's not
actually true. many machines are directly computable. many not directly computable, are *still* REDUCIBLE by computation (those that only
contradict a finite amount of detector calls in the chain of
functionally equivalent machines found by injection/reduction), while
only a final (but still identifiable) class of machines paradoxes *all* functionally equivalent machines found by value injection, and are
therefore not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine will do,
just that we just can't determine them generally via computable algo
because UNCOMPUTABLE machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is uncomputable,
namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem becomes computable, but you system blows up in a contradiction, as such an
"oracle" doesn't exist, and can't exist in the system.

-a gd_halts(machine) -> {
-a-a-a HALTS: if machine halts
-a-a-a LOOPS: if machine does not halt
-a-a-a REDUCIBLE: if machine semantics can be decided thru
-a-a-a-a-a-a-a-a-a-a-a-a-a-a reduction by decider value injection
-a-a-a UNCOMPUTABLE: if machine semantics cannot be decided
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a by computation (because it would take
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a infinite reductions)
-a }

an example of a reducible machine is DR:

-a DR = () -> {
-a-a-a gdi = gd_halts(DR)
-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a goto paradox

-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a gdi = gd_halts(DR')
-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a goto paradox

-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a gdi = gd_halts(DR'')
-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a goto paradox

-a paradox:
-a-a-a if (gdi == HALT)
-a-a-a-a-a loop()
-a-a-a else
-a-a-a-a-a halt()
-a }

which can be computably reduced to the decidedly halting function:

-a DR''' = () -> {
-a-a-a gdi = REDUCIBLE
-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a goto paradox

-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a gdi = REDUCIBLE
-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a goto paradox

-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a gdi = REDUCIBLE
-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a goto paradox

-a paradox:
-a-a-a if (gdi == HALT)
-a-a-a-a-a loop()
-a-a-a else
-a-a-a-a-a halt()
-a }

-a gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

-a DU = () -> {
-a-a-a // loop until valid result
-a-a-a d = DU
-a loop:
-a-a-a gdi = gd_halts(d)
-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a goto loop
-a-a-a }

-a paradox:
-a-a-a if (gdi == HALT)
-a-a-a-a-a loop()
-a-a-a else
-a-a-a-a-a halt()
-a }

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in DU to
see if it's possible compute this value somehow. since this call happens
in an unbounded search, there's two forms we could try:

a) a single inject() for the specific value of d that was last tested against. this would cause DU to infinite loop, as the discovery loop
would just keep injecting the values that had just been tested, the
result of which on the next cycle would then be required to find still UNCOMPUTABLE. because there are an unbounded amount of detector calls,
it would take an unbounded amount of injections to reduce them all out,
so the end would never be reached.

the same would be true for any other discovery loop done in this manner: DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative:

b) why stick to singular injections? what if we tried to preempt this
result by replacing all the calls with an UNCOMPUTABLE value:

-a DU' = () -> {
-a-a-a // loop until valid result
-a-a-a d = DU
-a loop:
-a-a-a gdi = UNCOMPUTABLE
-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a goto loop
-a-a-a }

-a paradox:
-a-a-a if (gdi == HALT)
-a-a-a-a-a loop()
-a-a-a else
-a-a-a-a-a halt()
-a }

this doens't work either. when tried from within DU, then on the second iteration of loop, where d = DU', gd_halts(d) will return LOOPS which
will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ... from
a perspective which perhaps cannot be referenced by a machine, then DU'
does represent a machine that is functionally equivalent to DU running method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that these machines are *always* functionally equivalent to some *less-complex*
machine that does not form a decision paradox. surely all the REDUCIBLE
ones are since that is directly computable, but the only difference
between REDUCIBLE and UNCOMPUTABLE machines are that REDUCIBLE machines
only contradict a bounded amount of reductions, whereas UNCOMPUTABLE machines contradict an unbounded amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run for infinite time as they must all get stuck in unbounded "searches" for the functionally equivalent machine to contradict, so therefore this
paradigm does not get contradicted by the fact we can enumerate all
halting machines.

at least, that's most we can do without reflective computing. if the decision algo could tell it was running within DU vs externally, then it could choose between the unbounded injection and bounded injection on an instance by instance basis to possibly execute a fully computable paradigm...

i'm fairly happy with this change. now it's truly a ghost *detector* and
not a ghost /decider/ eh??? my previous incarnation tried to make it so
that all machine semantics could be effectively computable thru
reduction, but that's just not possible when operating strictly with
turing machines. but perhaps we actually can still detect it, which is
what this classifier was named for.

ahhh richard, this haunted house of cards we got going on is gunna start crumbling any day now...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the ghost
detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a total
ghost detector by doing an unbounded search via the reduction
techniques used to compute the machine that is functionally equivalent
to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is going
to claim this is just kicking the can down the road. but that's not
actually true. many machines are directly computable. many not
directly computable, are *still* REDUCIBLE by computation (those that
only contradict a finite amount of detector calls in the chain of
functionally equivalent machines found by injection/reduction), while
only a final (but still identifiable) class of machines paradoxes
*all* functionally equivalent machines found by value injection, and
are therefore not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine will
do, just that we just can't determine them generally via computable
algo because UNCOMPUTABLE machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem becomes computable, but you system blows up in a contradiction, as such an
"oracle" doesn't exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a specific, identifiable semantic structure.

-a-a gd_halts(machine) -> {
-a-a-a-a HALTS: if machine halts
-a-a-a-a LOOPS: if machine does not halt
-a-a-a-a REDUCIBLE: if machine semantics can be decided thru
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a reduction by decider value injection
-a-a-a-a UNCOMPUTABLE: if machine semantics cannot be decided
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a by computation (because it would take >> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a infinite reductions)
-a-a }

an example of a reducible machine is DR:

-a-a DR = () -> {
-a-a-a-a gdi = gd_halts(DR)
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR'')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

which can be computably reduced to the decidedly halting function:

-a-a DR''' = () -> {
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

-a-a gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

-a-a DU = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = gd_halts(d)
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the
opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in DU
to see if it's possible compute this value somehow. since this call
happens in an unbounded search, there's two forms we could try:

a) a single inject() for the specific value of d that was last tested
against. this would cause DU to infinite loop, as the discovery loop
would just keep injecting the values that had just been tested, the
result of which on the next cycle would then be required to find still
UNCOMPUTABLE. because there are an unbounded amount of detector calls,
it would take an unbounded amount of injections to reduce them all
out, so the end would never be reached.

the same would be true for any other discovery loop done in this
manner: DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative:

b) why stick to singular injections? what if we tried to preempt this
result by replacing all the calls with an UNCOMPUTABLE value:

-a-a DU' = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = UNCOMPUTABLE
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

this doens't work either. when tried from within DU, then on the
second iteration of loop, where d = DU', gd_halts(d) will return LOOPS
which will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ...
from a perspective which perhaps cannot be referenced by a machine,
then DU' does represent a machine that is functionally equivalent to
DU running method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that these
machines are *always* functionally equivalent to some *less-complex*
machine that does not form a decision paradox. surely all the
REDUCIBLE ones are since that is directly computable, but the only
difference between REDUCIBLE and UNCOMPUTABLE machines are that
REDUCIBLE machines only contradict a bounded amount of reductions,
whereas UNCOMPUTABLE machines contradict an unbounded amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run for
infinite time as they must all get stuck in unbounded "searches" for
the functionally equivalent machine to contradict, so therefore this
paradigm does not get contradicted by the fact we can enumerate all
halting machines.

at least, that's most we can do without reflective computing. if the
decision algo could tell it was running within DU vs externally, then
it could choose between the unbounded injection and bounded injection
on an instance by instance basis to possibly execute a fully
computable paradigm...

i'm fairly happy with this change. now it's truly a ghost *detector*
and not a ghost /decider/ eh??? my previous incarnation tried to make
it so that all machine semantics could be effectively computable thru
reduction, but that's just not possible when operating strictly with
turing machines. but perhaps we actually can still detect it, which is
what this classifier was named for.

ahhh richard, this haunted house of cards we got going on is gunna
start crumbling any day now...

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the ghost
detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a total
ghost detector by doing an unbounded search via the reduction
techniques used to compute the machine that is functionally
equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is
going to claim this is just kicking the can down the road. but that's
not actually true. many machines are directly computable. many not
directly computable, are *still* REDUCIBLE by computation (those that
only contradict a finite amount of detector calls in the chain of
functionally equivalent machines found by injection/reduction), while
only a final (but still identifiable) class of machines paradoxes
*all* functionally equivalent machines found by value injection, and
are therefore not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine will
do, just that we just can't determine them generally via computable
algo because UNCOMPUTABLE machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem
becomes computable, but you system blows up in a contradiction, as
such an "oracle" doesn't exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific set
of functions it is based on. Remember, it is only actually a machine if
it includes ALL the code it uses, incuding that "decider" you are
talking about.

You want to call this UNCOMPUTABLE, but that is just because you don't understand what that word means.

Since another (and better) version of the decider can get that one
correctly, it isn't "Uncomputable", a term that means that NO always
correct decider can get the answer.

Your problem is you think you can detect that it will take an infinite
number of reductions to get to the answer, but that requires you to
first HAVE a halt decider to tell you that.

Since the only machines that are truly UNDECIDABLE will be machines that
will never halt (but not all non-halting machines, some can be decided),
being able to detect that the machine is undecidable means halting
itself is decidable, which has been proved impossible.

-a-a gd_halts(machine) -> {
-a-a-a-a HALTS: if machine halts
-a-a-a-a LOOPS: if machine does not halt
-a-a-a-a REDUCIBLE: if machine semantics can be decided thru
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a reduction by decider value injection
-a-a-a-a UNCOMPUTABLE: if machine semantics cannot be decided
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a by computation (because it would take >>> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a infinite reductions)
-a-a }

an example of a reducible machine is DR:

-a-a DR = () -> {
-a-a-a-a gdi = gd_halts(DR)
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR'')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

which can be computably reduced to the decidedly halting function:

-a-a DR''' = () -> {
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

-a-a gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

-a-a DU = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = gd_halts(d)
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the
opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in DU
to see if it's possible compute this value somehow. since this call
happens in an unbounded search, there's two forms we could try:

a) a single inject() for the specific value of d that was last tested
against. this would cause DU to infinite loop, as the discovery loop
would just keep injecting the values that had just been tested, the
result of which on the next cycle would then be required to find
still UNCOMPUTABLE. because there are an unbounded amount of detector
calls, it would take an unbounded amount of injections to reduce them
all out, so the end would never be reached.

the same would be true for any other discovery loop done in this
manner: DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative:

b) why stick to singular injections? what if we tried to preempt this
result by replacing all the calls with an UNCOMPUTABLE value:

-a-a DU' = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = UNCOMPUTABLE
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

this doens't work either. when tried from within DU, then on the
second iteration of loop, where d = DU', gd_halts(d) will return
LOOPS which will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ...
from a perspective which perhaps cannot be referenced by a machine,
then DU' does represent a machine that is functionally equivalent to
DU running method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that these
machines are *always* functionally equivalent to some *less-complex*
machine that does not form a decision paradox. surely all the
REDUCIBLE ones are since that is directly computable, but the only
difference between REDUCIBLE and UNCOMPUTABLE machines are that
REDUCIBLE machines only contradict a bounded amount of reductions,
whereas UNCOMPUTABLE machines contradict an unbounded amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run
for infinite time as they must all get stuck in unbounded "searches"
for the functionally equivalent machine to contradict, so therefore
this paradigm does not get contradicted by the fact we can enumerate
all halting machines.

at least, that's most we can do without reflective computing. if the
decision algo could tell it was running within DU vs externally, then
it could choose between the unbounded injection and bounded injection
on an instance by instance basis to possibly execute a fully
computable paradigm...

i'm fairly happy with this change. now it's truly a ghost *detector*
and not a ghost /decider/ eh??? my previous incarnation tried to make
it so that all machine semantics could be effectively computable thru
reduction, but that's just not possible when operating strictly with
turing machines. but perhaps we actually can still detect it, which
is what this classifier was named for.

ahhh richard, this haunted house of cards we got going on is gunna
start crumbling any day now...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the ghost
detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a total
ghost detector by doing an unbounded search via the reduction
techniques used to compute the machine that is functionally
equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is
going to claim this is just kicking the can down the road. but
that's not actually true. many machines are directly computable.
many not directly computable, are *still* REDUCIBLE by computation
(those that only contradict a finite amount of detector calls in the
chain of functionally equivalent machines found by injection/
reduction), while only a final (but still identifiable) class of
machines paradoxes *all* functionally equivalent machines found by
value injection, and are therefore not reducible in a computable
fashion.

that doesn't mean we cannot know what the uncomputable machine will
do, just that we just can't determine them generally via computable
algo because UNCOMPUTABLE machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem
becomes computable, but you system blows up in a contradiction, as
such an "oracle" doesn't exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a
specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific set
of functions it is based on. Remember, it is only actually a machine if > it includes ALL the code it uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code needs to
be entirely in the input to the decider, it certainly can identify
itself. identical/self-equivalent (and code-isomorphic machines) are
fairly trivial to identify.

yeah yeah yeah ur gunna move muh goalpost to functionally equivalent
machines, Ef2-Ef2-Ef2- but there's no point moving to that until we find agreement on the self-paradoxing machine.

You want to call this UNCOMPUTABLE, but that is just because you don't understand what that word means.

Since another (and better) version of the decider can get that one correctly, it isn't "Uncomputable", a term that means that NO always
correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct answer
for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Your problem is you think you can detect that it will take an infinite number of reductions to get to the answer, but that requires you to
first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

presume there is one... so we can examine how it can co-exist with self-referential set-classification paradoxes, to refute the
contradictions asserted by earlier proofs.

Since the only machines that are truly UNDECIDABLE will be machines that will never halt (but not all non-halting machines, some can be decided), being able to detect that the machine is undecidable means halting
itself is decidable, which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically fails
when put in the paradox itself and leads to an invalid answer.

which is why i'd want to prove it outside of TM computing rather than
compute it from within,

incompleteness provides for that, eh???

-a-a gd_halts(machine) -> {
-a-a-a-a HALTS: if machine halts
-a-a-a-a LOOPS: if machine does not halt
-a-a-a-a REDUCIBLE: if machine semantics can be decided thru
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a reduction by decider value injection
-a-a-a-a UNCOMPUTABLE: if machine semantics cannot be decided
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a by computation (because it would take >>>> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a infinite reductions)
-a-a }

an example of a reducible machine is DR:

-a-a DR = () -> {
-a-a-a-a gdi = gd_halts(DR)
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR'')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

which can be computably reduced to the decidedly halting function:

-a-a DR''' = () -> {
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

-a-a gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

-a-a DU = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = gd_halts(d)
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the
opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in
DU to see if it's possible compute this value somehow. since this
call happens in an unbounded search, there's two forms we could try:

a) a single inject() for the specific value of d that was last
tested against. this would cause DU to infinite loop, as the
discovery loop would just keep injecting the values that had just
been tested, the result of which on the next cycle would then be
required to find still UNCOMPUTABLE. because there are an unbounded
amount of detector calls, it would take an unbounded amount of
injections to reduce them all out, so the end would never be reached.

the same would be true for any other discovery loop done in this
manner: DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative:

b) why stick to singular injections? what if we tried to preempt
this result by replacing all the calls with an UNCOMPUTABLE value:

-a-a DU' = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = UNCOMPUTABLE
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

this doens't work either. when tried from within DU, then on the
second iteration of loop, where d = DU', gd_halts(d) will return
LOOPS which will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ...
from a perspective which perhaps cannot be referenced by a machine,
then DU' does represent a machine that is functionally equivalent to
DU running method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that these
machines are *always* functionally equivalent to some *less-complex*
machine that does not form a decision paradox. surely all the
REDUCIBLE ones are since that is directly computable, but the only
difference between REDUCIBLE and UNCOMPUTABLE machines are that
REDUCIBLE machines only contradict a bounded amount of reductions,
whereas UNCOMPUTABLE machines contradict an unbounded amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run
for infinite time as they must all get stuck in unbounded "searches"
for the functionally equivalent machine to contradict, so therefore
this paradigm does not get contradicted by the fact we can enumerate
all halting machines.

at least, that's most we can do without reflective computing. if the
decision algo could tell it was running within DU vs externally,
then it could choose between the unbounded injection and bounded
injection on an instance by instance basis to possibly execute a
fully computable paradigm...

i'm fairly happy with this change. now it's truly a ghost *detector*
and not a ghost /decider/ eh??? my previous incarnation tried to
make it so that all machine semantics could be effectively
computable thru reduction, but that's just not possible when
operating strictly with turing machines. but perhaps we actually can
still detect it, which is what this classifier was named for.

ahhh richard, this haunted house of cards we got going on is gunna
start crumbling any day now...

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

https://www.youtube.com/watch?v=ui-9YQzeTA8
--
arising us out of the computing dark ages,
please excuse my pseudo-pyscript,
~ nick

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the ghost
detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a
total ghost detector by doing an unbounded search via the reduction >>>>> techniques used to compute the machine that is functionally
equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is
going to claim this is just kicking the can down the road. but
that's not actually true. many machines are directly computable.
many not directly computable, are *still* REDUCIBLE by computation
(those that only contradict a finite amount of detector calls in
the chain of functionally equivalent machines found by injection/
reduction), while only a final (but still identifiable) class of
machines paradoxes *all* functionally equivalent machines found by
value injection, and are therefore not reducible in a computable
fashion.

that doesn't mean we cannot know what the uncomputable machine will >>>>> do, just that we just can't determine them generally via computable >>>>> algo because UNCOMPUTABLE machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem
becomes computable, but you system blows up in a contradiction, as
such an "oracle" doesn't exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a
specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific set
of functions it is based on. Remember, it is only actually a machine
if > it includes ALL the code it uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code needs to
be entirely in the input to the decider, it certainly can identify
itself. identical/self-equivalent (and code-isomorphic machines) are
fairly trivial to identify.

No, the problem is the input only needs the functional equivalent of the decider, and thus that fact can be undetectable.

yeah yeah yeah ur gunna move muh goalpost to functionally equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to that until we find agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you don't
understand what that word means.

Since another (and better) version of the decider can get that one
correctly, it isn't "Uncomputable", a term that means that NO always
correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct answer
for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for any
answer other than halting (which you design will not generate), then we
just need to run a UTM on the self-paradoxing machine, and when it
reaches the final state, it reports halting.

Your problem is you think you can detect that it will take an infinite
number of reductions to get to the answer, but that requires you to
first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the requirements of
the question you are claiming to try to find a way to answer. By
assuming there is an answer, and ignoring the contradictions that can
come out of that, all you are doing is showing you are willing to work
in a contradictory logic system, which means one that can ultmately
prove ANYTHING, including know false statements.

presume there is one... so we can examine how it can co-exist with self- referential set-classification paradoxes, to refute the contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the final
result was to prove it can't be.

Since the only machines that are truly UNDECIDABLE will be machines
that will never halt (but not all non-halting machines, some can be
decided), being able to detect that the machine is undecidable means
halting itself is decidable, which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically fails
when put in the paradox itself and leads to an invalid answer.

Only because you begged the question, and are handling just a minor
sub-case of the actual problem.

It doesn't matter that you can give the answer you want if the input was cooked to give it to you, that means nothing.

which is why i'd want to prove it outside of TM computing rather than compute it from within,

But then, you need to actual show you are in a Turing Equivalent system,
or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the action of
a modern computer, but what can be done with fixed finite deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific Mapping of
Input to Output.

For Halting, the input is a Computation as defined above, and the output
is whether or not that algorithm will reach a final state in a finite
number of steps or continue for an unbounded number of steps.

If your machine model doesn't match that, it isn't computing.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is uncomputable. How do you intend to use the fact that your system is
incomplete to help you answer the question.

-a-a gd_halts(machine) -> {
-a-a-a-a HALTS: if machine halts
-a-a-a-a LOOPS: if machine does not halt
-a-a-a-a REDUCIBLE: if machine semantics can be decided thru
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a reduction by decider value injection
-a-a-a-a UNCOMPUTABLE: if machine semantics cannot be decided
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a by computation (because it would take
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a infinite reductions)
-a-a }

an example of a reducible machine is DR:

-a-a DR = () -> {
-a-a-a-a gdi = gd_halts(DR)
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR'')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

which can be computably reduced to the decidedly halting function:

-a-a DR''' = () -> {
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

-a-a gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

-a-a DU = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = gd_halts(d)
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the
opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in
DU to see if it's possible compute this value somehow. since this
call happens in an unbounded search, there's two forms we could try: >>>>>
a) a single inject() for the specific value of d that was last
tested against. this would cause DU to infinite loop, as the
discovery loop would just keep injecting the values that had just
been tested, the result of which on the next cycle would then be
required to find still UNCOMPUTABLE. because there are an unbounded >>>>> amount of detector calls, it would take an unbounded amount of
injections to reduce them all out, so the end would never be reached. >>>>>
the same would be true for any other discovery loop done in this
manner: DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative:

b) why stick to singular injections? what if we tried to preempt
this result by replacing all the calls with an UNCOMPUTABLE value:

-a-a DU' = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = UNCOMPUTABLE
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

this doens't work either. when tried from within DU, then on the
second iteration of loop, where d = DU', gd_halts(d) will return
LOOPS which will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ...
from a perspective which perhaps cannot be referenced by a machine, >>>>> then DU' does represent a machine that is functionally equivalent
to DU running method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that
these machines are *always* functionally equivalent to some *less-
complex* machine that does not form a decision paradox. surely all
the REDUCIBLE ones are since that is directly computable, but the
only difference between REDUCIBLE and UNCOMPUTABLE machines are
that REDUCIBLE machines only contradict a bounded amount of
reductions, whereas UNCOMPUTABLE machines contradict an unbounded
amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run
for infinite time as they must all get stuck in unbounded
"searches" for the functionally equivalent machine to contradict,
so therefore this paradigm does not get contradicted by the fact we >>>>> can enumerate all halting machines.

at least, that's most we can do without reflective computing. if
the decision algo could tell it was running within DU vs
externally, then it could choose between the unbounded injection
and bounded injection on an instance by instance basis to possibly
execute a fully computable paradigm...

i'm fairly happy with this change. now it's truly a ghost
*detector* and not a ghost /decider/ eh??? my previous incarnation
tried to make it so that all machine semantics could be effectively >>>>> computable thru reduction, but that's just not possible when
operating strictly with turing machines. but perhaps we actually
can still detect it, which is what this classifier was named for.

ahhh richard, this haunted house of cards we got going on is gunna
start crumbling any day now...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

I'm not into this stuff, but at a friend's birthday party
once they claimed his mom's ghost appeared as a blue light on
the cel cams
--
Vasos Panagiotopoulos panix.com/~vjp2/vasos.htm
---{Nothing herein constitutes advice. Everything fully disclaimed.}---
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/2025 9:53 AM, dart200 wrote:

https://www.youtube.com/watch?v=ui-9YQzeTA8

Pretty good! Thanks. For some reason it reminds me Origa.

(Rise)
https://youtu.be/-rFW2Df5iRs?list=RD-rFW2Df5iRs

Actually, this person Laura Shigihara did a pretty good job for Voices
by Yoko Kanno. Different vibe, more put you to sleep, put good. Love
Macross movies. ;^D

https://youtu.be/3i_m9H2lll8?list=RD3i_m9H2lll8
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the ghost >>>>>> detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a
total ghost detector by doing an unbounded search via the
reduction techniques used to compute the machine that is
functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost
detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is >>>>>> going to claim this is just kicking the can down the road. but
that's not actually true. many machines are directly computable.
many not directly computable, are *still* REDUCIBLE by computation >>>>>> (those that only contradict a finite amount of detector calls in
the chain of functionally equivalent machines found by injection/ >>>>>> reduction), while only a final (but still identifiable) class of
machines paradoxes *all* functionally equivalent machines found by >>>>>> value injection, and are therefore not reducible in a computable
fashion.

that doesn't mean we cannot know what the uncomputable machine
will do, just that we just can't determine them generally via
computable algo because UNCOMPUTABLE machines will defeat that aglo. >>>>>>
so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem
becomes computable, but you system blows up in a contradiction, as
such an "oracle" doesn't exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a
specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific
set of functions it is based on. Remember, it is only actually a
machine if > it includes ALL the code it uses, incuding that
"decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code needs to
be entirely in the input to the decider, it certainly can identify
itself. identical/self-equivalent (and code-isomorphic machines) are
fairly trivial to identify.

No, the problem is the input only needs the functional equivalent of the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

the proof against turing equivalence deciders is *also* a semantic
paradox, just like the halting problem. this detector form is ultimately
going to be generalized to all semantic problems.

deal with the identity case first, pulling out the turing equivalent
problem on top is just u throwing out disingenuous gish gallop

yeah yeah yeah ur gunna move muh goalpost to functionally equivalent
machines, Ef2-Ef2-Ef2- but there's no point moving to that until we find
agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you
don't understand what that word means.

Since another (and better) version of the decider can get that one
correctly, it isn't "Uncomputable", a term that means that NO always
correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct answer
for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for any answer other than halting (which you design will not generate), then we
just need to run a UTM on the self-paradoxing machine, and when it
reaches the final state, it reports halting.

the self-paradoxing machine never halts, which u'd know if u'd actually
read this and not just assumed everything like the massive dick you are

Your problem is you think you can detect that it will take an
infinite number of reductions to get to the answer, but that requires
you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the requirements of
the question you are claiming to try to find a way to answer. By
assuming there is an answer, and ignoring the contradictions that can
come out of that, all you are doing is showing you are willing to work
in a contradictory logic system, which means one that can ultmately
prove ANYTHING, including know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur paragraphs dick

presume there is one... so we can examine how it can co-exist with
self- referential set-classification paradoxes, to refute the
contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the final
result was to prove it can't be.

yes dick, you are one special pleading motherfucker

Since the only machines that are truly UNDECIDABLE will be machines
that will never halt (but not all non-halting machines, some can be
decided), being able to detect that the machine is undecidable means
halting itself is decidable, which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically fails
when put in the paradox itself and leads to an invalid answer.

Only because you begged the question, and are handling just a minor sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the input was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

which is why i'd want to prove it outside of TM computing rather than
compute it from within,

But then, you need to actual show you are in a Turing Equivalent system,
or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the action of
a modern computer, but what can be done with fixed finite deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and the output
is whether or not that algorithm will reach a final state in a finite
number of steps or continue for an unbounded number of steps.

If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but u
didn't actually read this, so u don't know what i'm talking about

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is uncomputable. How do you intend to use the fact that your system is incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that cannot be
proven by *any* system u moron

-a-a gd_halts(machine) -> {
-a-a-a-a HALTS: if machine halts
-a-a-a-a LOOPS: if machine does not halt
-a-a-a-a REDUCIBLE: if machine semantics can be decided thru
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a reduction by decider value injection >>>>>> -a-a-a-a UNCOMPUTABLE: if machine semantics cannot be decided
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a by computation (because it would take
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a infinite reductions)
-a-a }

an example of a reducible machine is DR:

-a-a DR = () -> {
-a-a-a-a gdi = gd_halts(DR)
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = gd_halts(DR'')
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

which can be computably reduced to the decidedly halting function: >>>>>>
-a-a DR''' = () -> {
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR' = inject(DR, gd_halts(DR), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a-a-a DR'' = inject(DR', gd_halts(DR'), REDUCIBLE)
-a-a-a-a gdi = REDUCIBLE
-a-a-a-a if (gdi == HALTS || gdi == LOOPS)
-a-a-a-a-a-a goto paradox

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

-a-a gd_halts(DR''') => halts

an example of an uncomputable machine is DU:

-a-a DU = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = gd_halts(d)
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

clearly injecting in HALTS/LOOPS for gd_halts(DU) leads to the
opposite semantic result.

let us consider injecting UNCOMPUTABLE in for gd_halts(d) calls in >>>>>> DU to see if it's possible compute this value somehow. since this >>>>>> call happens in an unbounded search, there's two forms we could try: >>>>>>
a) a single inject() for the specific value of d that was last
tested against. this would cause DU to infinite loop, as the
discovery loop would just keep injecting the values that had just >>>>>> been tested, the result of which on the next cycle would then be
required to find still UNCOMPUTABLE. because there are an
unbounded amount of detector calls, it would take an unbounded
amount of injections to reduce them all out, so the end would
never be reached.

the same would be true for any other discovery loop done in this
manner: DU's UNCOMPUTABLE semantics would stay UNCOMPUTABLE

this may be the proper solution, but let's explore an alternative: >>>>>>
b) why stick to singular injections? what if we tried to preempt
this result by replacing all the calls with an UNCOMPUTABLE value: >>>>>>
-a-a DU' = () -> {
-a-a-a-a // loop until valid result
-a-a-a-a d = DU
-a-a loop:
-a-a-a-a gdi = UNCOMPUTABLE
-a-a-a-a if (gdi != HALTS && gdi != LOOPS) {
-a-a-a-a-a-a-a-a d = inject(d, gd_halts(d), UNCOMPUTABLE)
-a-a-a-a-a-a-a-a goto loop
-a-a-a-a }

-a-a paradox:
-a-a-a-a if (gdi == HALT)
-a-a-a-a-a-a loop()
-a-a-a-a else
-a-a-a-a-a-a halt()
-a-a }

this doens't work either. when tried from within DU, then on the
second iteration of loop, where d = DU', gd_halts(d) will return
LOOPS which will cause the loop to break and DU to halt: not good

curiously if the "unbounded" injection is done from outside DU ... >>>>>> from a perspective which perhaps cannot be referenced by a
machine, then DU' does represent a machine that is functionally
equivalent to DU running method (a) we explored.

this leaves me thinking that perhaps instead of *computing* the
decision... we can just *prove* it, outside of computing, that
these machines are *always* functionally equivalent to some *less- >>>>>> complex* machine that does not form a decision paradox. surely all >>>>>> the REDUCIBLE ones are since that is directly computable, but the >>>>>> only difference between REDUCIBLE and UNCOMPUTABLE machines are
that REDUCIBLE machines only contradict a bounded amount of
reductions, whereas UNCOMPUTABLE machines contradict an unbounded >>>>>> amount.

it's worth noting that *all* of the UNCOMPUTABLE machines will run >>>>>> for infinite time as they must all get stuck in unbounded
"searches" for the functionally equivalent machine to contradict, >>>>>> so therefore this paradigm does not get contradicted by the fact
we can enumerate all halting machines.

at least, that's most we can do without reflective computing. if
the decision algo could tell it was running within DU vs
externally, then it could choose between the unbounded injection
and bounded injection on an instance by instance basis to possibly >>>>>> execute a fully computable paradigm...

i'm fairly happy with this change. now it's truly a ghost
*detector* and not a ghost /decider/ eh??? my previous incarnation >>>>>> tried to make it so that all machine semantics could be
effectively computable thru reduction, but that's just not
possible when operating strictly with turing machines. but perhaps >>>>>> we actually can still detect it, which is what this classifier was >>>>>> named for.

ahhh richard, this haunted house of cards we got going on is gunna >>>>>> start crumbling any day now...

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the
ghost detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a
total ghost detector by doing an unbounded search via the
reduction techniques used to compute the machine that is
functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost >>>>>>> detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is >>>>>>> going to claim this is just kicking the can down the road. but
that's not actually true. many machines are directly computable. >>>>>>> many not directly computable, are *still* REDUCIBLE by
computation (those that only contradict a finite amount of
detector calls in the chain of functionally equivalent machines >>>>>>> found by injection/ reduction), while only a final (but still
identifiable) class of machines paradoxes *all* functionally
equivalent machines found by value injection, and are therefore >>>>>>> not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine
will do, just that we just can't determine them generally via
computable algo because UNCOMPUTABLE machines will defeat that aglo. >>>>>>>
so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem
becomes computable, but you system blows up in a contradiction, as >>>>>> such an "oracle" doesn't exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a
specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific
set of functions it is based on. Remember, it is only actually a
machine if > it includes ALL the code it uses, incuding that
"decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code needs
to be entirely in the input to the decider, it certainly can identify
itself. identical/self-equivalent (and code-isomorphic machines) are
fairly trivial to identify.

No, the problem is the input only needs the functional equivalent of
the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

the proof against turing equivalence deciders is *also* a semantic
paradox, just like the halting problem. this detector form is ultimately going to be generalized to all semantic problems.

No, it isn't. Your problem is you keep on assuming you can do infinite
work which you can't.

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing equivalent
problem on top is just u throwing out disingenuous gish gallop

It just shows that if you beg the question and don't handle the proper arguement, you can show that you can answer for some cases.

That doesn't prove your point, as you haven't actually handled the case
that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally equivalent
machines, Ef2-Ef2-Ef2- but there's no point moving to that until we find >>> agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to that
machine must be correct, or your decider fails. Thus your idea of a
"context dependent decider" is just a way to try to frame incorrectness
as being correct.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you
don't understand what that word means.

Since another (and better) version of the decider can get that one
correctly, it isn't "Uncomputable", a term that means that NO always
correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct answer
for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for any
answer other than halting (which you design will not generate), then
we just need to run a UTM on the self-paradoxing machine, and when it
reaches the final state, it reports halting.

the self-paradoxing machine never halts, which u'd know if u'd actually
read this and not just assumed everything like the massive dick you are

Sure it does, if the decider says anything but that it halts, then the
proper "paradoxical" machine will halt.

And, a decider that only answers halting if it can prove the machine it
has been given halts, can't do that for a machine that doesn't halt, so
if your construction rules or the decider don't allow it to make that
error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt is
because your "decider' isn't actually a decider, and never gave an answer.

Your problem is you think you can detect that it will take an
infinite number of reductions to get to the answer, but that
requires you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the requirements of
the question you are claiming to try to find a way to answer. By
assuming there is an answer, and ignoring the contradictions that can
come out of that, all you are doing is showing you are willing to work
in a contradictory logic system, which means one that can ultmately
prove ANYTHING, including know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur paragraphs dick

We have it. Remember that it contains a COPY of the decider, and thus
when you argue about changing the decider that copy doesn't change.

Thus the contradiction machine has definite behavior, and thus can not
be correctly defined to be incoherent or undecidable.

presume there is one... so we can examine how it can co-exist with
self- referential set-classification paradoxes, to refute the
contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the final
result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to use, and
have fallen to the guttter language of the idiot.

Since the only machines that are truly UNDECIDABLE will be machines
that will never halt (but not all non-halting machines, some can be
decided), being able to detect that the machine is undecidable means
halting itself is decidable, which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically fails
when put in the paradox itself and leads to an invalid answer.

Only because you begged the question, and are handling just a minor
sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the input
was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it isn't
that.

Since YOU can't show an actual factual basis, as it all falls on your
umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing rather than
compute it from within,

But then, you need to actual show you are in a Turing Equivalent
system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the action
of a modern computer, but what can be done with fixed finite
deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific Mapping
of Input to Output.

For Halting, the input is a Computation as defined above, and the
output is whether or not that algorithm will reach a final state in a
finite number of steps or continue for an unbounded number of steps.

If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but u
didn't actually read this, so u don't know what i'm talking about

So, I guess you are convinced that there must be a teapot out in the
asteroid belt.

To prove something about results in a system without reference to the
system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is still a
field of definite algorithms processing realizable finite steps of
finite algorithms. And it deals with the problem of trying to "Compute"
by such a method, fixed mappings of an input domain to an output domain.

Turing Machines just turn out to be a good model of that system, as it
seems that anything that could be done in the general system, can be
done with a Turing Machine, and it is impossible to make a Turing
Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is
uncomputable. How do you intend to use the fact that your system is
incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that cannot be proven by *any* system u moron

Godel's proof showed that within a system (that supports the properties
of Natural Numbers) there must exist statements, which are true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the statements
might be provable in a "higher order" meta-system, the creation of such meta-system show the existance of further true statements in the base
system that can not be answered in that meta-system, and thus, while we
can continue to add higher and higher order meta-systems to prove more
and more of these true statements, there will ALWAYS be more true
statments that are not provable.

Thus there will ALWAYS be some statement which is true in the base
system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include that it
have a finite number of initial truths (the axioms), and higher-order
systems work by adding additional initial truths, we can only form finite-order higher order system, and not an "infinite-order
meta-system", we can show that there must exist some statement which are
true in the base system that can NEVER be proved in ANY higher order system.

We also can not show that a statement is one of these, as to do so would
be to prove it, as they must be true.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the
ghost detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a >>>>>>>> total ghost detector by doing an unbounded search via the
reduction techniques used to compute the machine that is
functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this ghost >>>>>>>> detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< is >>>>>>>> going to claim this is just kicking the can down the road. but >>>>>>>> that's not actually true. many machines are directly computable. >>>>>>>> many not directly computable, are *still* REDUCIBLE by
computation (those that only contradict a finite amount of
detector calls in the chain of functionally equivalent machines >>>>>>>> found by injection/ reduction), while only a final (but still >>>>>>>> identifiable) class of machines paradoxes *all* functionally
equivalent machines found by value injection, and are therefore >>>>>>>> not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine >>>>>>>> will do, just that we just can't determine them generally via >>>>>>>> computable algo because UNCOMPUTABLE machines will defeat that >>>>>>>> aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem >>>>>>> becomes computable, but you system blows up in a contradiction, >>>>>>> as such an "oracle" doesn't exist, and can't exist in the system. >>>>>>

richard u tard, actually read it. UNCOMPUTABLE machines have a
specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific
set of functions it is based on. Remember, it is only actually a
machine if > it includes ALL the code it uses, incuding that
"decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code needs
to be entirely in the input to the decider, it certainly can
identify itself. identical/self-equivalent (and code-isomorphic
machines) are fairly trivial to identify.

No, the problem is the input only needs the functional equivalent of
the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

the proof against turing equivalence deciders is *also* a semantic
paradox, just like the halting problem. this detector form is
ultimately going to be generalized to all semantic problems.

No, it isn't. Your problem is you keep on assuming you can do infinite
work which you can't.

where is infinite work required???

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing equivalent
problem on top is just u throwing out disingenuous gish gallop

It just shows that if you beg the question and don't handle the proper arguement, you can show that you can answer for some cases.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

That doesn't prove your point, as you haven't actually handled the case
that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally equivalent
machines, Ef2-Ef2-Ef2- but there's no point moving to that until we find >>>> agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to that
machine must be correct, or your decider fails. Thus your idea of a
"context dependent decider" is just a way to try to frame incorrectness
as being correct.

this is a ghost *detector* rick, not a ghost *decider*

and it's a *huge* step up from before because it break's rice's theorem:
it detects a non-trivial semantic property of a machine: that such
machine semantics can be computed

that's the best we can do from within TM computing.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you
don't understand what that word means.

Since another (and better) version of the decider can get that one
correctly, it isn't "Uncomputable", a term that means that NO
always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct
answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for
any answer other than halting (which you design will not generate),
then we just need to run a UTM on the self-paradoxing machine, and
when it reaches the final state, it reports halting.

the self-paradoxing machine never halts, which u'd know if u'd
actually read this and not just assumed everything like the massive
dick you are

Sure it does, if the decider says anything but that it halts, then the proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually post
code and not just randomass ideas in a paragraph

And, a decider that only answers halting if it can prove the machine it
has been given halts, can't do that for a machine that doesn't halt, so
if your construction rules or the decider don't allow it to make that
error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt is because your "decider' isn't actually a decider, and never gave an answer.

yeah it's a partial classifier + ghost detector

Your problem is you think you can detect that it will take an
infinite number of reductions to get to the answer, but that
requires you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the requirements
of the question you are claiming to try to find a way to answer. By
assuming there is an answer, and ignoring the contradictions that can
come out of that, all you are doing is showing you are willing to
work in a contradictory logic system, which means one that can
ultmately prove ANYTHING, including know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur paragraphs dick

We have it. Remember that it contains a COPY of the decider, and thus
when you argue about changing the decider that copy doesn't change.

Thus the contradiction machine has definite behavior, and thus can not
be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from the reply

presume there is one... so we can examine how it can co-exist with
self- referential set-classification paradoxes, to refute the
contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the final
result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to use, and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Since the only machines that are truly UNDECIDABLE will be machines >>>>> that will never halt (but not all non-halting machines, some can be >>>>> decided), being able to detect that the machine is undecidable
means halting itself is decidable, which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically
fails when put in the paradox itself and leads to an invalid answer.

Only because you begged the question, and are handling just a minor
sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the input
was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it isn't that.

Since YOU can't show an actual factual basis, as it all falls on your umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing rather
than compute it from within,

But then, you need to actual show you are in a Turing Equivalent
system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the action
of a modern computer, but what can be done with fixed finite
deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific Mapping
of Input to Output.

For Halting, the input is a Computation as defined above, and the
output is whether or not that algorithm will reach a final state in a
finite number of steps or continue for an unbounded number of steps.

If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but u
didn't actually read this, so u don't know what i'm talking about

So, I guess you are convinced that there must be a teapot out in the asteroid belt.

To prove something about results in a system without reference to the
system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is still a field of definite algorithms processing realizable finite steps of
finite algorithms. And it deals with the problem of trying to "Compute"
by such a method, fixed mappings of an input domain to an output domain.

Turing Machines just turn out to be a good model of that system, as it
seems that anything that could be done in the general system, can be
done with a Turing Machine, and it is impossible to make a Turing
Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is
uncomputable. How do you intend to use the fact that your system is
incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that cannot be
proven by *any* system u moron

Godel's proof showed that within a system (that supports the properties
of Natural Numbers) there must exist statements, which are true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the statements
might be provable in a "higher order" meta-system, the creation of such meta-system show the existance of further true statements in the base
system that can not be answered in that meta-system, and thus, while we
can continue to add higher and higher order meta-systems to prove more
and more of these true statements, there will ALWAYS be more true
statments that are not provable.

Thus there will ALWAYS be some statement which is true in the base
system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include that it
have a finite number of initial truths (the axioms), and higher-order systems work by adding additional initial truths, we can only form finite-order higher order system, and not an "infinite-order meta-
system", we can show that there must exist some statement which are true
in the base system that can NEVER be proved in ANY higher order system.

We also can not show that a statement is one of these, as to do so would
be to prove it, as they must be true.

thanks gpt Efai
--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the >>>>>>>>> ghost detector with 3 return values: HALTS/LOOPS/UNRELIABLE

this unfortunately got stumped by a paradox that invalidated a >>>>>>>>> total ghost detector by doing an unbounded search via the
reduction techniques used to compute the machine that is
functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this
ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< >>>>>>>>> is going to claim this is just kicking the can down the road. >>>>>>>>> but that's not actually true. many machines are directly
computable. many not directly computable, are *still* REDUCIBLE >>>>>>>>> by computation (those that only contradict a finite amount of >>>>>>>>> detector calls in the chain of functionally equivalent machines >>>>>>>>> found by injection/ reduction), while only a final (but still >>>>>>>>> identifiable) class of machines paradoxes *all* functionally >>>>>>>>> equivalent machines found by value injection, and are therefore >>>>>>>>> not reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable machine >>>>>>>>> will do, just that we just can't determine them generally via >>>>>>>>> computable algo because UNCOMPUTABLE machines will defeat that >>>>>>>>> aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem >>>>>>>> becomes computable, but you system blows up in a contradiction, >>>>>>>> as such an "oracle" doesn't exist, and can't exist in the system. >>>>>>>

richard u tard, actually read it. UNCOMPUTABLE machines have a
specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the specific >>>>>> set of functions it is based on. Remember, it is only actually a
machine if > it includes ALL the code it uses, incuding that
"decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code needs >>>>> to be entirely in the input to the decider, it certainly can
identify itself. identical/self-equivalent (and code-isomorphic
machines) are fairly trivial to identify.

No, the problem is the input only needs the functional equivalent of
the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

the proof against turing equivalence deciders is *also* a semantic
paradox, just like the halting problem. this detector form is
ultimately going to be generalized to all semantic problems.

No, it isn't. Your problem is you keep on assuming you can do infinite
work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are uncompuational.

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing equivalent
problem on top is just u throwing out disingenuous gish gallop

It just shows that if you beg the question and don't handle the proper
arguement, you can show that you can answer for some cases.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

What REAL question am I begging?

All I am doing is pointing out that you are ignoring the requirements.

That doesn't prove your point, as you haven't actually handled the
case that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally
equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to that >>>>> until we find agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to that
machine must be correct, or your decider fails. Thus your idea of a
"context dependent decider" is just a way to try to frame
incorrectness as being correct.

this is a ghost *detector* rick, not a ghost *decider*

And thus, must answer for EVERY ghost.

All you are doing is admitting that you system fails to meet the
definition of Computations. That is that a given machine always gives
the same answer to a given input.

What good is a system if it can change its answer "arbitrarily"

It means you can never prove that a machine is correct.

and it's a *huge* step up from before because it break's rice's theorem:
it detects a non-trivial semantic property of a machine: that such
machine semantics can be computed

No it doesn't, as it sometimes doesn't answer.

that's the best we can do from within TM computing.

But doesn't meet the claim.

We KNOW that we can't compute some things.

Trying to say there are some undefinable categories where we can answer doesn't help.

That doesn't actually provide anything more that what was previously there.

If you could come up with a valid definition of the category you can
answer, perhaps it could be interesting, if that category is interesting.

Detecting only a trivial subset of the contrary program isn't actually interesting as the contrary program is only interesting as it is a
simple example showing uncomputability.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you
don't understand what that word means.

Since another (and better) version of the decider can get that one >>>>>> correctly, it isn't "Uncomputable", a term that means that NO
always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct
answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for
any answer other than halting (which you design will not generate),
then we just need to run a UTM on the self-paradoxing machine, and
when it reaches the final state, it reports halting.

the self-paradoxing machine never halts, which u'd know if u'd
actually read this and not just assumed everything like the massive
dick you are

Sure it does, if the decider says anything but that it halts, then the
proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually post
code and not just randomass ideas in a paragraph

Yes, the paradoxical input IS DECIDABLE by other machines. It just foils
that one decider.

This is something I have mentioned repeatedly but you don't seem to understand.

The "paradoxical program" isn't the "ghost input" we have been talking
about.

And, a decider that only answers halting if it can prove the machine
it has been given halts, can't do that for a machine that doesn't
halt, so if your construction rules or the decider don't allow it to
make that error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt is
because your "decider' isn't actually a decider, and never gave an
answer.

yeah it's a partial classifier + ghost detector

But it isn't, as it can never actually detect the real ghosts.

It seems you don't understand what the ghosts are.

Your problem is you think you can detect that it will take an
infinite number of reductions to get to the answer, but that
requires you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the requirements
of the question you are claiming to try to find a way to answer. By
assuming there is an answer, and ignoring the contradictions that
can come out of that, all you are doing is showing you are willing
to work in a contradictory logic system, which means one that can
ultmately prove ANYTHING, including know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur paragraphs
dick

We have it. Remember that it contains a COPY of the decider, and thus
when you argue about changing the decider that copy doesn't change.

Thus the contradiction machine has definite behavior, and thus can not
be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from the reply

But your problem is that until you post ALL the code of your decider, I
can't post the code of the contradictory machine.

Until you show how gd_halts actually works (and not just its
requirements) the code afterwords is meaningless.

Note, the problem is that the code of the "paradoxical" machine doesn't
just "call" the base routines of your decider, but use copies of the
algorithm in them, which means that your decide can only check a finite
list of variants of it, which the copy will inherently make itself not
one of because it will include that set within itself, and no set can
include itself.

presume there is one... so we can examine how it can co-exist with
self- referential set-classification paradoxes, to refute the
contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the final
result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to use,
and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Seems to be a self-description of yourself.

Since the only machines that are truly UNDECIDABLE will be
machines that will never halt (but not all non-halting machines,
some can be decided), being able to detect that the machine is
undecidable means halting itself is decidable, which has been
proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically
fails when put in the paradox itself and leads to an invalid answer.

Only because you begged the question, and are handling just a minor
sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the input
was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it
isn't that.

Since YOU can't show an actual factual basis, as it all falls on your
umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing rather
than compute it from within,

But then, you need to actual show you are in a Turing Equivalent
system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the action
of a modern computer, but what can be done with fixed finite
deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific
Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and the
output is whether or not that algorithm will reach a final state in
a finite number of steps or continue for an unbounded number of steps. >>>>
If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but u
didn't actually read this, so u don't know what i'm talking about

So, I guess you are convinced that there must be a teapot out in the
asteroid belt.

To prove something about results in a system without reference to the
system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is still
a field of definite algorithms processing realizable finite steps of
finite algorithms. And it deals with the problem of trying to
"Compute" by such a method, fixed mappings of an input domain to an
output domain.

Turing Machines just turn out to be a good model of that system, as it
seems that anything that could be done in the general system, can be
done with a Turing Machine, and it is impossible to make a Turing
Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is
uncomputable. How do you intend to use the fact that your system is
incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that cannot
be proven by *any* system u moron

Godel's proof showed that within a system (that supports the
properties of Natural Numbers) there must exist statements, which are
true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the statements
might be provable in a "higher order" meta-system, the creation of
such meta-system show the existance of further true statements in the
base system that can not be answered in that meta-system, and thus,
while we can continue to add higher and higher order meta-systems to
prove more and more of these true statements, there will ALWAYS be
more true statments that are not provable.

Thus there will ALWAYS be some statement which is true in the base
system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include that
it have a finite number of initial truths (the axioms), and higher-
order systems work by adding additional initial truths, we can only
form finite-order higher order system, and not an "infinite-order
meta- system", we can show that there must exist some statement which
are true in the base system that can NEVER be proved in ANY higher
order system.

We also can not show that a statement is one of these, as to do so
would be to prove it, as they must be true.

thanks gpt Efai

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the >>>>>>>>>> ghost detector with 3 return values: HALTS/LOOPS/UNRELIABLE >>>>>>>>>>
this unfortunately got stumped by a paradox that invalidated a >>>>>>>>>> total ghost detector by doing an unbounded search via the >>>>>>>>>> reduction techniques used to compute the machine that is
functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this >>>>>>>>>> ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< >>>>>>>>>> is going to claim this is just kicking the can down the road. >>>>>>>>>> but that's not actually true. many machines are directly
computable. many not directly computable, are *still*
REDUCIBLE by computation (those that only contradict a finite >>>>>>>>>> amount of detector calls in the chain of functionally
equivalent machines found by injection/ reduction), while only >>>>>>>>>> a final (but still identifiable) class of machines paradoxes >>>>>>>>>> *all* functionally equivalent machines found by value
injection, and are therefore not reducible in a computable >>>>>>>>>> fashion.

that doesn't mean we cannot know what the uncomputable machine >>>>>>>>>> will do, just that we just can't determine them generally via >>>>>>>>>> computable algo because UNCOMPUTABLE machines will defeat that >>>>>>>>>> aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is
uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any problem >>>>>>>>> becomes computable, but you system blows up in a contradiction, >>>>>>>>> as such an "oracle" doesn't exist, and can't exist in the system. >>>>>>>>

richard u tard, actually read it. UNCOMPUTABLE machines have a >>>>>>>> specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the
specific set of functions it is based on. Remember, it is only
actually a machine if > it includes ALL the code it uses,
incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code
needs to be entirely in the input to the decider, it certainly can >>>>>> identify itself. identical/self-equivalent (and code-isomorphic
machines) are fairly trivial to identify.

No, the problem is the input only needs the functional equivalent
of the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

the proof against turing equivalence deciders is *also* a semantic
paradox, just like the halting problem. this detector form is
ultimately going to be generalized to all semantic problems.

No, it isn't. Your problem is you keep on assuming you can do
infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are uncompuational.

you haven't shown that dick

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing equivalent
problem on top is just u throwing out disingenuous gish gallop

It just shows that if you beg the question and don't handle the
proper arguement, you can show that you can answer for some cases.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

What REAL question am I begging?

All I am doing is pointing out that you are ignoring the requirements.

by continually trying to refute my detector with a problem it aims to
solve, and never actually posting code...

because that would require actual work instead of gishgallop fallacies

That doesn't prove your point, as you haven't actually handled the
case that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally
equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to that >>>>>> until we find agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to that
machine must be correct, or your decider fails. Thus your idea of a
"context dependent decider" is just a way to try to frame
incorrectness as being correct.

this is a ghost *detector* rick, not a ghost *decider*

And thus, must answer for EVERY ghost.

u haven't shown a UNCOMPUTABLE machine it can't decide is UNCOMPUTABLE

and ur still writing paragraphs instead of posting executable logic

All you are doing is admitting that you system fails to meet the
definition of Computations. That is that a given machine always gives
the same answer to a given input.

What good is a system if it can change its answer "arbitrarily"

It means you can never prove that a machine is correct.

and it's a *huge* step up from before because it break's rice's
theorem: it detects a non-trivial semantic property of a machine: that
such machine semantics can be computed

No it doesn't, as it sometimes doesn't answer.

that's the best we can do from within TM computing.

But doesn't meet the claim.

We KNOW that we can't compute some things.

Trying to say there are some undefinable categories where we can answer doesn't help.

That doesn't actually provide anything more that what was previously there.

If you could come up with a valid definition of the category you can
answer, perhaps it could be interesting, if that category is interesting.

Detecting only a trivial subset of the contrary program isn't actually interesting as the contrary program is only interesting as it is a
simple example showing uncomputability.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you >>>>>>> don't understand what that word means.

Since another (and better) version of the decider can get that
one correctly, it isn't "Uncomputable", a term that means that NO >>>>>>> always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct
answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for
any answer other than halting (which you design will not generate), >>>>> then we just need to run a UTM on the self-paradoxing machine, and
when it reaches the final state, it reports halting.

the self-paradoxing machine never halts, which u'd know if u'd
actually read this and not just assumed everything like the massive
dick you are

Sure it does, if the decider says anything but that it halts, then
the proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually post
code and not just randomass ideas in a paragraph

Yes, the paradoxical input IS DECIDABLE by other machines. It just foils that one decider.

This is something I have mentioned repeatedly but you don't seem to understand.

The "paradoxical program" isn't the "ghost input" we have been talking about.

And, a decider that only answers halting if it can prove the machine
it has been given halts, can't do that for a machine that doesn't
halt, so if your construction rules or the decider don't allow it to
make that error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt is
because your "decider' isn't actually a decider, and never gave an
answer.

yeah it's a partial classifier + ghost detector

But it isn't, as it can never actually detect the real ghosts.

It seems you don't understand what the ghosts are.

Your problem is you think you can detect that it will take an
infinite number of reductions to get to the answer, but that
requires you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the requirements >>>>> of the question you are claiming to try to find a way to answer. By >>>>> assuming there is an answer, and ignoring the contradictions that
can come out of that, all you are doing is showing you are willing
to work in a contradictory logic system, which means one that can
ultmately prove ANYTHING, including know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur paragraphs
dick

We have it. Remember that it contains a COPY of the decider, and thus
when you argue about changing the decider that copy doesn't change.

Thus the contradiction machine has definite behavior, and thus can
not be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from the reply

But your problem is that until you post ALL the code of your decider, I can't post the code of the contradictory machine.

Until you show how gd_halts actually works (and not just its
requirements) the code afterwords is meaningless.

Note, the problem is that the code of the "paradoxical" machine doesn't
just "call" the base routines of your decider, but use copies of the algorithm in them, which means that your decide can only check a finite
list of variants of it, which the copy will inherently make itself not
one of because it will include that set within itself, and no set can include itself.

presume there is one... so we can examine how it can co-exist with >>>>>> self- referential set-classification paradoxes, to refute the
contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the final >>>>> result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to use,
and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Seems to be a self-description of yourself.

Since the only machines that are truly UNDECIDABLE will be
machines that will never halt (but not all non-halting machines, >>>>>>> some can be decided), being able to detect that the machine is
undecidable means halting itself is decidable, which has been
proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically
fails when put in the paradox itself and leads to an invalid answer. >>>>>

Only because you begged the question, and are handling just a minor >>>>> sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the
input was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it
isn't that.

Since YOU can't show an actual factual basis, as it all falls on your
umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing rather
than compute it from within,

But then, you need to actual show you are in a Turing Equivalent
system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the
action of a modern computer, but what can be done with fixed finite >>>>> deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific
Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and the
output is whether or not that algorithm will reach a final state in >>>>> a finite number of steps or continue for an unbounded number of steps. >>>>>
If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but u
didn't actually read this, so u don't know what i'm talking about

So, I guess you are convinced that there must be a teapot out in the
asteroid belt.

To prove something about results in a system without reference to the
system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is still
a field of definite algorithms processing realizable finite steps of
finite algorithms. And it deals with the problem of trying to
"Compute" by such a method, fixed mappings of an input domain to an
output domain.

Turing Machines just turn out to be a good model of that system, as
it seems that anything that could be done in the general system, can
be done with a Turing Machine, and it is impossible to make a Turing
Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is
uncomputable. How do you intend to use the fact that your system is >>>>> incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that cannot
be proven by *any* system u moron

Godel's proof showed that within a system (that supports the
properties of Natural Numbers) there must exist statements, which are
true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the statements
might be provable in a "higher order" meta-system, the creation of
such meta-system show the existance of further true statements in the
base system that can not be answered in that meta-system, and thus,
while we can continue to add higher and higher order meta-systems to
prove more and more of these true statements, there will ALWAYS be
more true statments that are not provable.

Thus there will ALWAYS be some statement which is true in the base
system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include that
it have a finite number of initial truths (the axioms), and higher-
order systems work by adding additional initial truths, we can only
form finite-order higher order system, and not an "infinite-order
meta- system", we can show that there must exist some statement which
are true in the base system that can NEVER be proved in ANY higher
order system.

We also can not show that a statement is one of these, as to do so
would be to prove it, as they must be true.

thanks gpt Efai

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the >>>>>>>>>>> ghost detector with 3 return values: HALTS/LOOPS/UNRELIABLE >>>>>>>>>>>
this unfortunately got stumped by a paradox that invalidated >>>>>>>>>>> a total ghost detector by doing an unbounded search via the >>>>>>>>>>> reduction techniques used to compute the machine that is >>>>>>>>>>> functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this >>>>>>>>>>> ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts Efn< >>>>>>>>>>> is going to claim this is just kicking the can down the road. >>>>>>>>>>> but that's not actually true. many machines are directly >>>>>>>>>>> computable. many not directly computable, are *still*
REDUCIBLE by computation (those that only contradict a finite >>>>>>>>>>> amount of detector calls in the chain of functionally
equivalent machines found by injection/ reduction), while >>>>>>>>>>> only a final (but still identifiable) class of machines >>>>>>>>>>> paradoxes *all* functionally equivalent machines found by >>>>>>>>>>> value injection, and are therefore not reducible in a
computable fashion.

that doesn't mean we cannot know what the uncomputable
machine will do, just that we just can't determine them >>>>>>>>>>> generally via computable algo because UNCOMPUTABLE machines >>>>>>>>>>> will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is >>>>>>>>>> uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any
problem becomes computable, but you system blows up in a
contradiction, as such an "oracle" doesn't exist, and can't >>>>>>>>>> exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a >>>>>>>>> specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that. >>>>>>>>
DU is NOT UNCOMPUTABLE, it is only wrongly decided by the
specific set of functions it is based on. Remember, it is only >>>>>>>> actually a machine if > it includes ALL the code it uses,
incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code
needs to be entirely in the input to the decider, it certainly
can identify itself. identical/self-equivalent (and code-
isomorphic machines) are fairly trivial to identify.

No, the problem is the input only needs the functional equivalent >>>>>> of the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

the proof against turing equivalence deciders is *also* a semantic
paradox, just like the halting problem. this detector form is
ultimately going to be generalized to all semantic problems.

No, it isn't. Your problem is you keep on assuming you can do
infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable assumption.

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you are doing.

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing
equivalent problem on top is just u throwing out disingenuous gish
gallop

It just shows that if you beg the question and don't handle the
proper arguement, you can show that you can answer for some cases.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

What REAL question am I begging?

All I am doing is pointing out that you are ignoring the requirements.

by continually trying to refute my detector with a problem it aims to
solve, and never actually posting code...

Since you never define your detector, but only assume it exists, you
show that you don't actually know what you are doing.

because that would require actual work instead of gishgallop fallacies

The problem is I can't do my work, as it first needs you to do yours.

If you are going to just assume your dectector exist, then I can just
also assume I can make my side, and that includes that it makes an undetectable copy.

That doesn't prove your point, as you haven't actually handled the
case that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally
equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to that >>>>>>> until we find agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to that
machine must be correct, or your decider fails. Thus your idea of a
"context dependent decider" is just a way to try to frame
incorrectness as being correct.

this is a ghost *detector* rick, not a ghost *decider*

And thus, must answer for EVERY ghost.

u haven't shown a UNCOMPUTABLE machine it can't decide is UNCOMPUTABLE

I don't need to.

I guess you beleive in the teapot in the asteroid belt must exist.

and ur still writing paragraphs instead of posting executable logic

Since my executable logic needs your executable logic to be defined, the problem is on your end.

That, or you need to accept that I can make a copy of your code that
isn't your same instacne, and thus not detectable as one.

All you are doing is admitting that you system fails to meet the
definition of Computations. That is that a given machine always gives
the same answer to a given input.

What good is a system if it can change its answer "arbitrarily"

It means you can never prove that a machine is correct.

and it's a *huge* step up from before because it break's rice's
theorem: it detects a non-trivial semantic property of a machine:
that such machine semantics can be computed

No it doesn't, as it sometimes doesn't answer.

that's the best we can do from within TM computing.

But doesn't meet the claim.

We KNOW that we can't compute some things.

Trying to say there are some undefinable categories where we can
answer doesn't help.

That doesn't actually provide anything more that what was previously
there.

If you could come up with a valid definition of the category you can
answer, perhaps it could be interesting, if that category is interesting.

Detecting only a trivial subset of the contrary program isn't actually
interesting as the contrary program is only interesting as it is a
simple example showing uncomputability.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because you >>>>>>>> don't understand what that word means.

Since another (and better) version of the decider can get that >>>>>>>> one correctly, it isn't "Uncomputable", a term that means that >>>>>>>> NO always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct
answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt for >>>>>> any answer other than halting (which you design will not
generate), then we just need to run a UTM on the self-paradoxing
machine, and when it reaches the final state, it reports halting.

the self-paradoxing machine never halts, which u'd know if u'd
actually read this and not just assumed everything like the massive >>>>> dick you are

Sure it does, if the decider says anything but that it halts, then
the proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually post
code and not just randomass ideas in a paragraph

Yes, the paradoxical input IS DECIDABLE by other machines. It just
foils that one decider.

This is something I have mentioned repeatedly but you don't seem to
understand.

The "paradoxical program" isn't the "ghost input" we have been talking
about.

And, a decider that only answers halting if it can prove the machine
it has been given halts, can't do that for a machine that doesn't
halt, so if your construction rules or the decider don't allow it to
make that error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt
is because your "decider' isn't actually a decider, and never gave
an answer.

yeah it's a partial classifier + ghost detector

But it isn't, as it can never actually detect the real ghosts.

It seems you don't understand what the ghosts are.

Your problem is you think you can detect that it will take an >>>>>>>> infinite number of reductions to get to the answer, but that
requires you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the
requirements of the question you are claiming to try to find a way >>>>>> to answer. By assuming there is an answer, and ignoring the
contradictions that can come out of that, all you are doing is
showing you are willing to work in a contradictory logic system,
which means one that can ultmately prove ANYTHING, including know >>>>>> false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur
paragraphs dick

We have it. Remember that it contains a COPY of the decider, and
thus when you argue about changing the decider that copy doesn't
change.

Thus the contradiction machine has definite behavior, and thus can
not be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from the
reply

But your problem is that until you post ALL the code of your decider,
I can't post the code of the contradictory machine.

Until you show how gd_halts actually works (and not just its
requirements) the code afterwords is meaningless.

Note, the problem is that the code of the "paradoxical" machine
doesn't just "call" the base routines of your decider, but use copies
of the algorithm in them, which means that your decide can only check
a finite list of variants of it, which the copy will inherently make
itself not one of because it will include that set within itself, and
no set can include itself.

presume there is one... so we can examine how it can co-exist
with self- referential set-classification paradoxes, to refute
the contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the
final result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to use,
and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Seems to be a self-description of yourself.

Since the only machines that are truly UNDECIDABLE will be
machines that will never halt (but not all non-halting machines, >>>>>>>> some can be decided), being able to detect that the machine is >>>>>>>> undecidable means halting itself is decidable, which has been >>>>>>>> proved impossible.

no it's not, the algo that can sometimes decide the unbounded
UNCOMPUTABLE case doesn't work generally ... ei it specifically >>>>>>> fails when put in the paradox itself and leads to an invalid answer. >>>>>>

Only because you begged the question, and are handling just a
minor sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the
input was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it
isn't that.

Since YOU can't show an actual factual basis, as it all falls on
your umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing rather >>>>>>> than compute it from within,

But then, you need to actual show you are in a Turing Equivalent
system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the
action of a modern computer, but what can be done with fixed
finite deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific
Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and the >>>>>> output is whether or not that algorithm will reach a final state
in a finite number of steps or continue for an unbounded number of >>>>>> steps.

If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but u >>>>> didn't actually read this, so u don't know what i'm talking about

So, I guess you are convinced that there must be a teapot out in the
asteroid belt.

To prove something about results in a system without reference to
the system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is
still a field of definite algorithms processing realizable finite
steps of finite algorithms. And it deals with the problem of trying
to "Compute" by such a method, fixed mappings of an input domain to
an output domain.

Turing Machines just turn out to be a good model of that system, as
it seems that anything that could be done in the general system, can
be done with a Turing Machine, and it is impossible to make a Turing
Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is >>>>>> uncomputable. How do you intend to use the fact that your system
is incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that cannot >>>>> be proven by *any* system u moron

Godel's proof showed that within a system (that supports the
properties of Natural Numbers) there must exist statements, which
are true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the statements
might be provable in a "higher order" meta-system, the creation of
such meta-system show the existance of further true statements in
the base system that can not be answered in that meta-system, and
thus, while we can continue to add higher and higher order meta-
systems to prove more and more of these true statements, there will
ALWAYS be more true statments that are not provable.

Thus there will ALWAYS be some statement which is true in the base
system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include that
it have a finite number of initial truths (the axioms), and higher-
order systems work by adding additional initial truths, we can only
form finite-order higher order system, and not an "infinite-order
meta- system", we can show that there must exist some statement
which are true in the base system that can NEVER be proved in ANY
higher order system.

We also can not show that a statement is one of these, as to do so
would be to prove it, as they must be true.

thanks gpt Efai

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called the >>>>>>>>>>>> ghost detector with 3 return values: HALTS/LOOPS/UNRELIABLE >>>>>>>>>>>>
this unfortunately got stumped by a paradox that invalidated >>>>>>>>>>>> a total ghost detector by doing an unbounded search via the >>>>>>>>>>>> reduction techniques used to compute the machine that is >>>>>>>>>>>> functionally equivalent to the "paradoxical" machine.

and so i propose a truly radical 4th return value for this >>>>>>>>>>>> ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts >>>>>>>>>>>> Efn< is going to claim this is just kicking the can down the >>>>>>>>>>>> road. but that's not actually true. many machines are >>>>>>>>>>>> directly computable. many not directly computable, are >>>>>>>>>>>> *still* REDUCIBLE by computation (those that only contradict >>>>>>>>>>>> a finite amount of detector calls in the chain of
functionally equivalent machines found by injection/
reduction), while only a final (but still identifiable) >>>>>>>>>>>> class of machines paradoxes *all* functionally equivalent >>>>>>>>>>>> machines found by value injection, and are therefore not >>>>>>>>>>>> reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>> machine will do, just that we just can't determine them >>>>>>>>>>>> generally via computable algo because UNCOMPUTABLE machines >>>>>>>>>>>> will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is >>>>>>>>>>> uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any >>>>>>>>>>> problem becomes computable, but you system blows up in a >>>>>>>>>>> contradiction, as such an "oracle" doesn't exist, and can't >>>>>>>>>>> exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have a >>>>>>>>>> specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that. >>>>>>>>>
DU is NOT UNCOMPUTABLE, it is only wrongly decided by the
specific set of functions it is based on. Remember, it is only >>>>>>>>> actually a machine if > it includes ALL the code it uses,
incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code >>>>>>>> needs to be entirely in the input to the decider, it certainly >>>>>>>> can identify itself. identical/self-equivalent (and code-
isomorphic machines) are fairly trivial to identify.

No, the problem is the input only needs the functional equivalent >>>>>>> of the decider, and thus that fact can be undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION??? >>>>>>
the proof against turing equivalence deciders is *also* a semantic >>>>>> paradox, just like the halting problem. this detector form is
ultimately going to be generalized to all semantic problems.

No, it isn't. Your problem is you keep on assuming you can do
infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable assumption.

by showing how a decider/detector can co-exist with paradoxical input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you are doing.

so u have no burden but to continually throw out gish gallop???

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing
equivalent problem on top is just u throwing out disingenuous gish >>>>>> gallop

It just shows that if you beg the question and don't handle the
proper arguement, you can show that you can answer for some cases.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

What REAL question am I begging?

All I am doing is pointing out that you are ignoring the requirements.

by continually trying to refute my detector with a problem it aims to
solve, and never actually posting code...

Since you never define your detector, but only assume it exists, you
show that you don't actually know what you are doing.

you mean specifically state the algo??? i'm trying to figure out how the
algo *should* respond to problematic input...

how can i write an aglo i haven't figured out the interface to yet???

freaking ludicrous expectations you have. why do you even bother
participating if ur just gunna shift all burden on the other person?

because that would require actual work instead of gishgallop fallacies

The problem is I can't do my work, as it first needs you to do yours.

If you are going to just assume your dectector exist, then I can just
also assume I can make my side, and that includes that it makes an undetectable copy.

That doesn't prove your point, as you haven't actually handled the
case that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally
equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to that >>>>>>>> until we find agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to
that machine must be correct, or your decider fails. Thus your idea >>>>> of a "context dependent decider" is just a way to try to frame
incorrectness as being correct.

this is a ghost *detector* rick, not a ghost *decider*

And thus, must answer for EVERY ghost.

u haven't shown a UNCOMPUTABLE machine it can't decide is UNCOMPUTABLE

I don't need to.

I guess you beleive in the teapot in the asteroid belt must exist.

and ur still writing paragraphs instead of posting executable logic

Since my executable logic needs your executable logic to be defined, the problem is on your end.

i gave you the interface to work with ... tell me how it doesn't work!

or shut the fuck up honestly

That, or you need to accept that I can make a copy of your code that
isn't your same instacne, and thus not detectable as one.

All you are doing is admitting that you system fails to meet the
definition of Computations. That is that a given machine always gives
the same answer to a given input.

What good is a system if it can change its answer "arbitrarily"

It means you can never prove that a machine is correct.

and it's a *huge* step up from before because it break's rice's
theorem: it detects a non-trivial semantic property of a machine:
that such machine semantics can be computed

No it doesn't, as it sometimes doesn't answer.

that's the best we can do from within TM computing.

But doesn't meet the claim.

We KNOW that we can't compute some things.

Trying to say there are some undefinable categories where we can
answer doesn't help.

That doesn't actually provide anything more that what was previously
there.

If you could come up with a valid definition of the category you can
answer, perhaps it could be interesting, if that category is
interesting.

Detecting only a trivial subset of the contrary program isn't
actually interesting as the contrary program is only interesting as
it is a simple example showing uncomputability.

Trying to define your case, without handling this undefinable
relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because >>>>>>>>> you don't understand what that word means.

Since another (and better) version of the decider can get that >>>>>>>>> one correctly, it isn't "Uncomputable", a term that means that >>>>>>>>> NO always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct >>>>>>>> answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt
for any answer other than halting (which you design will not
generate), then we just need to run a UTM on the self-paradoxing >>>>>>> machine, and when it reaches the final state, it reports halting. >>>>>>

the self-paradoxing machine never halts, which u'd know if u'd
actually read this and not just assumed everything like the
massive dick you are

Sure it does, if the decider says anything but that it halts, then
the proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually
post code and not just randomass ideas in a paragraph

Yes, the paradoxical input IS DECIDABLE by other machines. It just
foils that one decider.

This is something I have mentioned repeatedly but you don't seem to
understand.

The "paradoxical program" isn't the "ghost input" we have been
talking about.

And, a decider that only answers halting if it can prove the
machine it has been given halts, can't do that for a machine that
doesn't halt, so if your construction rules or the decider don't
allow it to make that error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt
is because your "decider' isn't actually a decider, and never gave
an answer.

yeah it's a partial classifier + ghost detector

But it isn't, as it can never actually detect the real ghosts.

It seems you don't understand what the ghosts are.

Your problem is you think you can detect that it will take an >>>>>>>>> infinite number of reductions to get to the answer, but that >>>>>>>>> requires you to first HAVE a halt decider to tell you that.

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the
requirements of the question you are claiming to try to find a
way to answer. By assuming there is an answer, and ignoring the >>>>>>> contradictions that can come out of that, all you are doing is
showing you are willing to work in a contradictory logic system, >>>>>>> which means one that can ultmately prove ANYTHING, including know >>>>>>> false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur
paragraphs dick

We have it. Remember that it contains a COPY of the decider, and
thus when you argue about changing the decider that copy doesn't
change.

Thus the contradiction machine has definite behavior, and thus can
not be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from the
reply

But your problem is that until you post ALL the code of your decider,
I can't post the code of the contradictory machine.

Until you show how gd_halts actually works (and not just its
requirements) the code afterwords is meaningless.

Note, the problem is that the code of the "paradoxical" machine
doesn't just "call" the base routines of your decider, but use copies
of the algorithm in them, which means that your decide can only check
a finite list of variants of it, which the copy will inherently make
itself not one of because it will include that set within itself, and
no set can include itself.

presume there is one... so we can examine how it can co-exist >>>>>>>> with self- referential set-classification paradoxes, to refute >>>>>>>> the contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the
final result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to
use, and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Seems to be a self-description of yourself.

Since the only machines that are truly UNDECIDABLE will be
machines that will never halt (but not all non-halting
machines, some can be decided), being able to detect that the >>>>>>>>> machine is undecidable means halting itself is decidable, which >>>>>>>>> has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded >>>>>>>> UNCOMPUTABLE case doesn't work generally ... ei it specifically >>>>>>>> fails when put in the paradox itself and leads to an invalid
answer.

Only because you begged the question, and are handling just a
minor sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the
input was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it
isn't that.

Since YOU can't show an actual factual basis, as it all falls on
your umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing rather >>>>>>>> than compute it from within,

But then, you need to actual show you are in a Turing Equivalent >>>>>>> system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the
action of a modern computer, but what can be done with fixed
finite deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific
Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and the >>>>>>> output is whether or not that algorithm will reach a final state >>>>>>> in a finite number of steps or continue for an unbounded number >>>>>>> of steps.

If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but >>>>>> u didn't actually read this, so u don't know what i'm talking about >>>>>

So, I guess you are convinced that there must be a teapot out in
the asteroid belt.

To prove something about results in a system without reference to
the system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is
still a field of definite algorithms processing realizable finite
steps of finite algorithms. And it deals with the problem of trying >>>>> to "Compute" by such a method, fixed mappings of an input domain to >>>>> an output domain.

Turing Machines just turn out to be a good model of that system, as >>>>> it seems that anything that could be done in the general system,
can be done with a Turing Machine, and it is impossible to make a
Turing Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting is >>>>>>> uncomputable. How do you intend to use the fact that your system >>>>>>> is incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that
cannot be proven by *any* system u moron

Godel's proof showed that within a system (that supports the
properties of Natural Numbers) there must exist statements, which
are true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the
statements might be provable in a "higher order" meta-system, the
creation of such meta-system show the existance of further true
statements in the base system that can not be answered in that
meta-system, and thus, while we can continue to add higher and
higher order meta- systems to prove more and more of these true
statements, there will ALWAYS be more true statments that are not
provable.

Thus there will ALWAYS be some statement which is true in the base
system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include
that it have a finite number of initial truths (the axioms), and
higher- order systems work by adding additional initial truths, we
can only form finite-order higher order system, and not an
"infinite-order meta- system", we can show that there must exist
some statement which are true in the base system that can NEVER be
proved in ANY higher order system.

We also can not show that a statement is one of these, as to do so
would be to prove it, as they must be true.

thanks gpt Efai

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called >>>>>>>>>>>>> the ghost detector with 3 return values: HALTS/LOOPS/ >>>>>>>>>>>>> UNRELIABLE

this unfortunately got stumped by a paradox that
invalidated a total ghost detector by doing an unbounded >>>>>>>>>>>>> search via the reduction techniques used to compute the >>>>>>>>>>>>> machine that is functionally equivalent to the
"paradoxical" machine.

and so i propose a truly radical 4th return value for this >>>>>>>>>>>>> ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts >>>>>>>>>>>>> Efn< is going to claim this is just kicking the can down the >>>>>>>>>>>>> road. but that's not actually true. many machines are >>>>>>>>>>>>> directly computable. many not directly computable, are >>>>>>>>>>>>> *still* REDUCIBLE by computation (those that only
contradict a finite amount of detector calls in the chain >>>>>>>>>>>>> of functionally equivalent machines found by injection/ >>>>>>>>>>>>> reduction), while only a final (but still identifiable) >>>>>>>>>>>>> class of machines paradoxes *all* functionally equivalent >>>>>>>>>>>>> machines found by value injection, and are therefore not >>>>>>>>>>>>> reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>>> machine will do, just that we just can't determine them >>>>>>>>>>>>> generally via computable algo because UNCOMPUTABLE machines >>>>>>>>>>>>> will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is >>>>>>>>>>>> uncomputable, namely that something is uncomputable.

Yes, if you assume someone can give you the answer, any >>>>>>>>>>>> problem becomes computable, but you system blows up in a >>>>>>>>>>>> contradiction, as such an "oracle" doesn't exist, and can't >>>>>>>>>>>> exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have >>>>>>>>>>> a specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that. >>>>>>>>>>
DU is NOT UNCOMPUTABLE, it is only wrongly decided by the >>>>>>>>>> specific set of functions it is based on. Remember, it is only >>>>>>>>>> actually a machine if > it includes ALL the code it uses, >>>>>>>>>> incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code >>>>>>>>> needs to be entirely in the input to the decider, it certainly >>>>>>>>> can identify itself. identical/self-equivalent (and code-
isomorphic machines) are fairly trivial to identify.

No, the problem is the input only needs the functional
equivalent of the decider, and thus that fact can be undetectable. >>>>>>>

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION??? >>>>>>>
the proof against turing equivalence deciders is *also* a
semantic paradox, just like the halting problem. this detector
form is ultimately going to be generalized to all semantic problems. >>>>>>

No, it isn't. Your problem is you keep on assuming you can do
infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable assumption.

by showing how a decider/detector can co-exist with paradoxical input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK

But the point is that the "paradoxical input" shows that the decider is
just incorrect / fails to meet its requirements.

For instance, how can you get a "reducible" value, as either the machine
halt or it doesn't based on the answer the particular implmentation of
your decider that it is based on answers.

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make wrong.

And, how can your decider return UNCOMPUTABLE, since the only machines
whose result can't be computed would be a LOOPING machines, as ANY
machine that HALTS can be computed to halt by a simple UTM, which would
be an always right recognizer for halting.

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of
computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you are
doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature.

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing
equivalent problem on top is just u throwing out disingenuous
gish gallop

It just shows that if you beg the question and don't handle the
proper arguement, you can show that you can answer for some cases.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION???

What REAL question am I begging?

All I am doing is pointing out that you are ignoring the requirements.

by continually trying to refute my detector with a problem it aims to
solve, and never actually posting code...

Since you never define your detector, but only assume it exists, you
show that you don't actually know what you are doing.

you mean specifically state the algo??? i'm trying to figure out how the algo *should* respond to problematic input...

And you know the basic structure of the problimatic input.

IT seems, part of you problem is you don't actually understand the
problem as you don't understand the basics of what a computation is.

how can i write an aglo i haven't figured out the interface to yet???

You HAVE defined the interface, but you need to correct you definition
of some of your terms.

freaking ludicrous expectations you have. why do you even bother participating if ur just gunna shift all burden on the other person?

Just giving you the expectations of the problem you tried to handle,
thinking you could solve what has been proven to be unsolvable.

because that would require actual work instead of gishgallop fallacies

The problem is I can't do my work, as it first needs you to do yours.

If you are going to just assume your dectector exist, then I can just
also assume I can make my side, and that includes that it makes an
undetectable copy.

That doesn't prove your point, as you haven't actually handled the >>>>>> case that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally
equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to that
until we find agreement on the self-paradoxing machine.

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to
that machine must be correct, or your decider fails. Thus your
idea of a "context dependent decider" is just a way to try to
frame incorrectness as being correct.

this is a ghost *detector* rick, not a ghost *decider*

And thus, must answer for EVERY ghost.

u haven't shown a UNCOMPUTABLE machine it can't decide is UNCOMPUTABLE

I don't need to.

I guess you beleive in the teapot in the asteroid belt must exist.

and ur still writing paragraphs instead of posting executable logic

Since my executable logic needs your executable logic to be defined,
the problem is on your end.

i gave you the interface to work with ... tell me how it doesn't work!

Because the paradoxica program isn't based on an "Interface" but on an algorithm to defeat.

Since the program is based on COPYING the algorithm, you need to either
give the algorithm, or admit I can call yours and you can't detect this calling.

or shut the fuck up honestly

Maybe you should, as you show you don't understand the problem you are
trying to solve.

That, or you need to accept that I can make a copy of your code that
isn't your same instacne, and thus not detectable as one.

All you are doing is admitting that you system fails to meet the
definition of Computations. That is that a given machine always
gives the same answer to a given input.

What good is a system if it can change its answer "arbitrarily"

It means you can never prove that a machine is correct.

and it's a *huge* step up from before because it break's rice's
theorem: it detects a non-trivial semantic property of a machine:
that such machine semantics can be computed

No it doesn't, as it sometimes doesn't answer.

that's the best we can do from within TM computing.

But doesn't meet the claim.

We KNOW that we can't compute some things.

Trying to say there are some undefinable categories where we can
answer doesn't help.

That doesn't actually provide anything more that what was previously
there.

If you could come up with a valid definition of the category you can
answer, perhaps it could be interesting, if that category is
interesting.

Detecting only a trivial subset of the contrary program isn't
actually interesting as the contrary program is only interesting as
it is a simple example showing uncomputability.

Trying to define your case, without handling this undefinable >>>>>>>> relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because >>>>>>>>>> you don't understand what that word means.

Since another (and better) version of the decider can get that >>>>>>>>>> one correctly, it isn't "Uncomputable", a term that means that >>>>>>>>>> NO always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct >>>>>>>>> answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt >>>>>>>> for any answer other than halting (which you design will not
generate), then we just need to run a UTM on the self-paradoxing >>>>>>>> machine, and when it reaches the final state, it reports halting. >>>>>>>

the self-paradoxing machine never halts, which u'd know if u'd
actually read this and not just assumed everything like the
massive dick you are

Sure it does, if the decider says anything but that it halts, then >>>>>> the proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually
post code and not just randomass ideas in a paragraph

Yes, the paradoxical input IS DECIDABLE by other machines. It just
foils that one decider.

This is something I have mentioned repeatedly but you don't seem to
understand.

The "paradoxical program" isn't the "ghost input" we have been
talking about.

And, a decider that only answers halting if it can prove the
machine it has been given halts, can't do that for a machine that >>>>>> doesn't halt, so if your construction rules or the decider don't
allow it to make that error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't halt >>>>>> is because your "decider' isn't actually a decider, and never gave >>>>>> an answer.

yeah it's a partial classifier + ghost detector

But it isn't, as it can never actually detect the real ghosts.

It seems you don't understand what the ghosts are.

Your problem is you think you can detect that it will take an >>>>>>>>>> infinite number of reductions to get to the answer, but that >>>>>>>>>> requires you to first HAVE a halt decider to tell you that. >>>>>>>>>

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the
requirements of the question you are claiming to try to find a >>>>>>>> way to answer. By assuming there is an answer, and ignoring the >>>>>>>> contradictions that can come out of that, all you are doing is >>>>>>>> showing you are willing to work in a contradictory logic system, >>>>>>>> which means one that can ultmately prove ANYTHING, including
know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur
paragraphs dick

We have it. Remember that it contains a COPY of the decider, and
thus when you argue about changing the decider that copy doesn't
change.

Thus the contradiction machine has definite behavior, and thus can >>>>>> not be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from the >>>>> reply

But your problem is that until you post ALL the code of your
decider, I can't post the code of the contradictory machine.

Until you show how gd_halts actually works (and not just its
requirements) the code afterwords is meaningless.

Note, the problem is that the code of the "paradoxical" machine
doesn't just "call" the base routines of your decider, but use
copies of the algorithm in them, which means that your decide can
only check a finite list of variants of it, which the copy will
inherently make itself not one of because it will include that set
within itself, and no set can include itself.

presume there is one... so we can examine how it can co-exist >>>>>>>>> with self- referential set-classification paradoxes, to refute >>>>>>>>> the contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the >>>>>>>> final result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to
use, and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Seems to be a self-description of yourself.

Since the only machines that are truly UNDECIDABLE will be >>>>>>>>>> machines that will never halt (but not all non-halting
machines, some can be decided), being able to detect that the >>>>>>>>>> machine is undecidable means halting itself is decidable, >>>>>>>>>> which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded >>>>>>>>> UNCOMPUTABLE case doesn't work generally ... ei it specifically >>>>>>>>> fails when put in the paradox itself and leads to an invalid >>>>>>>>> answer.

Only because you begged the question, and are handling just a >>>>>>>> minor sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the >>>>>>>> input was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it >>>>>> isn't that.

Since YOU can't show an actual factual basis, as it all falls on
your umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing
rather than compute it from within,

But then, you need to actual show you are in a Turing Equivalent >>>>>>>> system, or just admit you aren't talking about "Computing"

Remember, for Computabity Theory, "Computing" isn't about the >>>>>>>> action of a modern computer, but what can be done with fixed
finite deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific >>>>>>>> Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and >>>>>>>> the output is whether or not that algorithm will reach a final >>>>>>>> state in a finite number of steps or continue for an unbounded >>>>>>>> number of steps.

If your machine model doesn't match that, it isn't computing.

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. but >>>>>>> u didn't actually read this, so u don't know what i'm talking about >>>>>>

So, I guess you are convinced that there must be a teapot out in
the asteroid belt.

To prove something about results in a system without reference to >>>>>> the system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is
still a field of definite algorithms processing realizable finite >>>>>> steps of finite algorithms. And it deals with the problem of
trying to "Compute" by such a method, fixed mappings of an input
domain to an output domain.

Turing Machines just turn out to be a good model of that system,
as it seems that anything that could be done in the general
system, can be done with a Turing Machine, and it is impossible to >>>>>> make a Turing Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting >>>>>>>> is uncomputable. How do you intend to use the fact that your
system is incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that
cannot be proven by *any* system u moron

Godel's proof showed that within a system (that supports the
properties of Natural Numbers) there must exist statements, which >>>>>> are true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the
statements might be provable in a "higher order" meta-system, the >>>>>> creation of such meta-system show the existance of further true
statements in the base system that can not be answered in that
meta-system, and thus, while we can continue to add higher and
higher order meta- systems to prove more and more of these true
statements, there will ALWAYS be more true statments that are not >>>>>> provable.

Thus there will ALWAYS be some statement which is true in the base >>>>>> system that can not be proven in ANY finite-order meta-system.

Since the definition of a logic system under discussion include
that it have a finite number of initial truths (the axioms), and
higher- order systems work by adding additional initial truths, we >>>>>> can only form finite-order higher order system, and not an
"infinite-order meta- system", we can show that there must exist
some statement which are true in the base system that can NEVER be >>>>>> proved in ANY higher order system.

We also can not show that a statement is one of these, as to do so >>>>>> would be to prove it, as they must be true.

thanks gpt Efai

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/31/2025 1:56 PM, Chris M. Thomasson wrote:

On 12/31/2025 9:53 AM, dart200 wrote:

https://www.youtube.com/watch?v=ui-9YQzeTA8

Pretty good! Thanks. For some reason it reminds me Origa.

(Rise)
https://youtu.be/-rFW2Df5iRs?list=RD-rFW2Df5iRs

Actually, this person Laura Shigihara did a pretty good job for Voices
by Yoko Kanno. Different vibe, more put you to sleep, put good. Love
Macross movies. ;^D

https://youtu.be/3i_m9H2lll8?list=RD3i_m9H2lll8

Fwiw, this is damn good to me, at least. Well, its has fairly
interesting lyrics almost about an AI female:

(lithium flower)
https://youtu.be/Wolcpa9s6NU?list=RD-rFW2Df5iRs


Also, are you familiar with the 8-bit band? They rock! Jazzzzzzy for sure:

(Aquatic Ambiance - Big Band Jazz Piano ft. Smart Game Piano (The 8-Bit
Big Band))

btw, Smart Game Piano is VERY good, she happens to be pretty as well:

https://youtu.be/5znrVdAtEDI?list=RD5znrVdAtEDI


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 4:20 PM, Richard Damon wrote:

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called >>>>>>>>>>>>>> the ghost detector with 3 return values: HALTS/LOOPS/ >>>>>>>>>>>>>> UNRELIABLE

this unfortunately got stumped by a paradox that
invalidated a total ghost detector by doing an unbounded >>>>>>>>>>>>>> search via the reduction techniques used to compute the >>>>>>>>>>>>>> machine that is functionally equivalent to the
"paradoxical" machine.

and so i propose a truly radical 4th return value for this >>>>>>>>>>>>>> ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these parts >>>>>>>>>>>>>> Efn< is going to claim this is just kicking the can down the >>>>>>>>>>>>>> road. but that's not actually true. many machines are >>>>>>>>>>>>>> directly computable. many not directly computable, are >>>>>>>>>>>>>> *still* REDUCIBLE by computation (those that only >>>>>>>>>>>>>> contradict a finite amount of detector calls in the chain >>>>>>>>>>>>>> of functionally equivalent machines found by injection/ >>>>>>>>>>>>>> reduction), while only a final (but still identifiable) >>>>>>>>>>>>>> class of machines paradoxes *all* functionally equivalent >>>>>>>>>>>>>> machines found by value injection, and are therefore not >>>>>>>>>>>>>> reducible in a computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>>>> machine will do, just that we just can't determine them >>>>>>>>>>>>>> generally via computable algo because UNCOMPUTABLE >>>>>>>>>>>>>> machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is >>>>>>>>>>>>> uncomputable, namely that something is uncomputable. >>>>>>>>>>>>>
Yes, if you assume someone can give you the answer, any >>>>>>>>>>>>> problem becomes computable, but you system blows up in a >>>>>>>>>>>>> contradiction, as such an "oracle" doesn't exist, and can't >>>>>>>>>>>>> exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines have >>>>>>>>>>>> a specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that. >>>>>>>>>>>
DU is NOT UNCOMPUTABLE, it is only wrongly decided by the >>>>>>>>>>> specific set of functions it is based on. Remember, it is >>>>>>>>>>> only actually a machine if > it includes ALL the code it >>>>>>>>>>> uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code >>>>>>>>>> needs to be entirely in the input to the decider, it certainly >>>>>>>>>> can identify itself. identical/self-equivalent (and code- >>>>>>>>>> isomorphic machines) are fairly trivial to identify.

No, the problem is the input only needs the functional
equivalent of the decider, and thus that fact can be undetectable. >>>>>>>>

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION??? >>>>>>>>
the proof against turing equivalence deciders is *also* a
semantic paradox, just like the halting problem. this detector >>>>>>>> form is ultimately going to be generalized to all semantic
problems.

No, it isn't. Your problem is you keep on assuming you can do
infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are uncompuational. >>>>

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable assumption.

by showing how a decider/detector can co-exist with paradoxical input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK

But the point is that the "paradoxical input" shows that the decider is
just incorrect / fails to meet its requirements.

AND??? THE POINT OF THE MACHINE IS UNCOMPUTABLE BY A GENERAL ALGO *ARE* IDENTIFIABLE,

WHICH IS SOMETHING U CLAIM TO NOT BE COMPUTABLE

For instance, how can you get a "reducible" value, as either the machine halt or it doesn't based on the answer the particular implmentation of
your decider that it is based on answers.

UR ASKING QUESTIONS THAT WOULD BE ANSWERED BY THE SPECIFIC EXAMPLES U
NEVER READ, DICK

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make wrong.

And, how can your decider return UNCOMPUTABLE, since the only machines
whose result can't be computed would be a LOOPING machines, as ANY
machine that HALTS can be computed to halt by a simple UTM, which would
be an always right recognizer for halting.

BECAUSE THE INFINITE REDUCTION PARADOX IS IDENTIFIABLE

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of
computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you are
doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature.

I DON'T KNOW WHY THE FUCK UR POSTING, TBH

IF YOU WANT TO HAVE A DISCUSSION THEN SOME BURDEN IS ON YOU TO
UNDERSTAND WHAT I'M SAYING IN ORDER TO MAKE COHERENT REPLIES.

IF UR NOT WILLING TO ACCEPT THAT BURDEN THEN DON'T FUCK REPLY YOU DICK

fucking idk why i need to explain this to retards who've been
shitposting on usenet longer than i've even been alive...

seriously what a fucking EfniEfiA

All you are doing is showing you don't understand infinity.

deal with the identity case first, pulling out the turing
equivalent problem on top is just u throwing out disingenuous >>>>>>>> gish gallop

It just shows that if you beg the question and don't handle the >>>>>>> proper arguement, you can show that you can answer for some cases. >>>>>>

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING QUESTION??? >>>>>>

What REAL question am I begging?

All I am doing is pointing out that you are ignoring the requirements. >>>>

by continually trying to refute my detector with a problem it aims
to solve, and never actually posting code...

Since you never define your detector, but only assume it exists, you
show that you don't actually know what you are doing.

you mean specifically state the algo??? i'm trying to figure out how
the algo *should* respond to problematic input...

And you know the basic structure of the problimatic input.

IT seems, part of you problem is you don't actually understand the
problem as you don't understand the basics of what a computation is.

how can i write an aglo i haven't figured out the interface to yet???

You HAVE defined the interface, but you need to correct you definition
of some of your terms.

freaking ludicrous expectations you have. why do you even bother
participating if ur just gunna shift all burden on the other person?

Just giving you the expectations of the problem you tried to handle, thinking you could solve what has been proven to be unsolvable.

because that would require actual work instead of gishgallop fallacies

The problem is I can't do my work, as it first needs you to do yours.

If you are going to just assume your dectector exist, then I can just
also assume I can make my side, and that includes that it makes an
undetectable copy.

That doesn't prove your point, as you haven't actually handled
the case that proves you wrong, only limits it.

yeah yeah yeah ur gunna move muh goalpost to functionally >>>>>>>>>> equivalent machines, Ef2-Ef2-Ef2- but there's no point moving to >>>>>>>>>> that until we find agreement on the self-paradoxing machine. >>>>>>>>>>

But that *IS* the self-paradoxing machine.

No, it is your misunderstanding of the self-paradoxing machine.

Note, even if you do detect the machine, the answer you give to >>>>>>> that machine must be correct, or your decider fails. Thus your
idea of a "context dependent decider" is just a way to try to
frame incorrectness as being correct.

this is a ghost *detector* rick, not a ghost *decider*

And thus, must answer for EVERY ghost.

u haven't shown a UNCOMPUTABLE machine it can't decide is UNCOMPUTABLE

I don't need to.

I guess you beleive in the teapot in the asteroid belt must exist.

and ur still writing paragraphs instead of posting executable logic

Since my executable logic needs your executable logic to be defined,
the problem is on your end.

i gave you the interface to work with ... tell me how it doesn't work!

Because the paradoxica program isn't based on an "Interface" but on an algorithm to defeat.

Since the program is based on COPYING the algorithm, you need to either
give the algorithm, or admit I can call yours and you can't detect this calling.

or shut the fuck up honestly

Maybe you should, as you show you don't understand the problem you are trying to solve.

That, or you need to accept that I can make a copy of your code that
isn't your same instacne, and thus not detectable as one.

All you are doing is admitting that you system fails to meet the
definition of Computations. That is that a given machine always
gives the same answer to a given input.

What good is a system if it can change its answer "arbitrarily"

It means you can never prove that a machine is correct.

and it's a *huge* step up from before because it break's rice's
theorem: it detects a non-trivial semantic property of a machine: >>>>>> that such machine semantics can be computed

No it doesn't, as it sometimes doesn't answer.

that's the best we can do from within TM computing.

But doesn't meet the claim.

We KNOW that we can't compute some things.

Trying to say there are some undefinable categories where we can
answer doesn't help.

That doesn't actually provide anything more that what was
previously there.

If you could come up with a valid definition of the category you
can answer, perhaps it could be interesting, if that category is
interesting.

Detecting only a trivial subset of the contrary program isn't
actually interesting as the contrary program is only interesting as >>>>> it is a simple example showing uncomputability.

Trying to define your case, without handling this undefinable >>>>>>>>> relationship is just an error.

You want to call this UNCOMPUTABLE, but that is just because >>>>>>>>>>> you don't understand what that word means.

Since another (and better) version of the decider can get >>>>>>>>>>> that one correctly, it isn't "Uncomputable", a term that >>>>>>>>>>> means that NO always correct decider can get the answer.

you can't make a decider that *guarantees* computing a correct >>>>>>>>>> answer for the UNCOMPUTABLE cases,

if you think u can: pseudo-code or shut up, eh???

Sure we can, if the self-paradoxing machine is defined to halt >>>>>>>>> for any answer other than halting (which you design will not >>>>>>>>> generate), then we just need to run a UTM on the self-
paradoxing machine, and when it reaches the final state, it >>>>>>>>> reports halting.

the self-paradoxing machine never halts, which u'd know if u'd >>>>>>>> actually read this and not just assumed everything like the
massive dick you are

Sure it does, if the decider says anything but that it halts,
then the proper "paradoxical" machine will halt.

that would make it REDUCIBLE rick, unless idk u want to actually
post code and not just randomass ideas in a paragraph

Yes, the paradoxical input IS DECIDABLE by other machines. It just
foils that one decider.

This is something I have mentioned repeatedly but you don't seem to >>>>> understand.

The "paradoxical program" isn't the "ghost input" we have been
talking about.

And, a decider that only answers halting if it can prove the
machine it has been given halts, can't do that for a machine that >>>>>>> doesn't halt, so if your construction rules or the decider don't >>>>>>> allow it to make that error, it can't do that,

Thus, the only way that the "self-paradoxing" machine doesn't
halt is because your "decider' isn't actually a decider, and
never gave an answer.

yeah it's a partial classifier + ghost detector

But it isn't, as it can never actually detect the real ghosts.

It seems you don't understand what the ghosts are.

Your problem is you think you can detect that it will take an >>>>>>>>>>> infinite number of reductions to get to the answer, but that >>>>>>>>>>> requires you to first HAVE a halt decider to tell you that. >>>>>>>>>>

when we gunna stop endlessly begging the question richard?

It is YOU who "begs the question" since you ignore the
requirements of the question you are claiming to try to find a >>>>>>>>> way to answer. By assuming there is an answer, and ignoring the >>>>>>>>> contradictions that can come out of that, all you are doing is >>>>>>>>> showing you are willing to work in a contradictory logic
system, which means one that can ultmately prove ANYTHING,
including know false statements.

blah blah blah blah blah:

code the actual contradiction or shut the fuck up with ur
paragraphs dick

We have it. Remember that it contains a COPY of the decider, and >>>>>>> thus when you argue about changing the decider that copy doesn't >>>>>>> change.

Thus the contradiction machine has definite behavior, and thus
can not be correctly defined to be incoherent or undecidable.

that's not posting code, and u in fact deleted all my code from
the reply

But your problem is that until you post ALL the code of your
decider, I can't post the code of the contradictory machine.

Until you show how gd_halts actually works (and not just its
requirements) the code afterwords is meaningless.

Note, the problem is that the code of the "paradoxical" machine
doesn't just "call" the base routines of your decider, but use
copies of the algorithm in them, which means that your decide can
only check a finite list of variants of it, which the copy will
inherently make itself not one of because it will include that set
within itself, and no set can include itself.

presume there is one... so we can examine how it can co-exist >>>>>>>>>> with self- referential set-classification paradoxes, to refute >>>>>>>>>> the contradictions asserted by earlier proofs.

But presuming the answer is just a logical falicy, UNLESS the >>>>>>>>> final result was to prove it can't be.

yes dick, you are one special pleading motherfucker

It seems you are just proving that you have run out of logic to >>>>>>> use, and have fallen to the guttter language of the idiot.

you keep on special pleading motherfucker

Seems to be a self-description of yourself.

Since the only machines that are truly UNDECIDABLE will be >>>>>>>>>>> machines that will never halt (but not all non-halting
machines, some can be decided), being able to detect that the >>>>>>>>>>> machine is undecidable means halting itself is decidable, >>>>>>>>>>> which has been proved impossible.

no it's not, the algo that can sometimes decide the unbounded >>>>>>>>>> UNCOMPUTABLE case doesn't work generally ... ei it
specifically fails when put in the paradox itself and leads to >>>>>>>>>> an invalid answer.

Only because you begged the question, and are handling just a >>>>>>>>> minor sub- case of the actual problem.

It doesn't matter that you can give the answer you want if the >>>>>>>>> input was cooked to give it to you, that means nothing.

do you know what repetition fallacy is?

Sure, but since my arguement isn't just based on repeating it, it >>>>>>> isn't that.

Since YOU can't show an actual factual basis, as it all falls on >>>>>>> your umerited assumptions is just the repetition fallacy.

which is why i'd want to prove it outside of TM computing >>>>>>>>>> rather than compute it from within,

But then, you need to actual show you are in a Turing
Equivalent system, or just admit you aren't talking about
"Computing"

Remember, for Computabity Theory, "Computing" isn't about the >>>>>>>>> action of a modern computer, but what can be done with fixed >>>>>>>>> finite deterministic algorithms.

It talks about trying to "Compute" (use the above) a Specific >>>>>>>>> Mapping of Input to Output.

For Halting, the input is a Computation as defined above, and >>>>>>>>> the output is whether or not that algorithm will reach a final >>>>>>>>> state in a finite number of steps or continue for an unbounded >>>>>>>>> number of steps.

If your machine model doesn't match that, it isn't computing. >>>>>>>>

when i said "prove from outside computing" in regards to the
UNCOMPUTABLE machines i really did mean not within computing. >>>>>>>> but u didn't actually read this, so u don't know what i'm
talking about

So, I guess you are convinced that there must be a teapot out in >>>>>>> the asteroid belt.

To prove something about results in a system without reference to >>>>>>> the system is just a nonsense question.

Note, "Computing" even without reference to Turing Machines" is >>>>>>> still a field of definite algorithms processing realizable finite >>>>>>> steps of finite algorithms. And it deals with the problem of
trying to "Compute" by such a method, fixed mappings of an input >>>>>>> domain to an output domain.

Turing Machines just turn out to be a good model of that system, >>>>>>> as it seems that anything that could be done in the general
system, can be done with a Turing Machine, and it is impossible >>>>>>> to make a Turing Machine do something outside that system.

incompleteness provides for that, eh???

How?

Incompleteness just says that it is very possible that Halting >>>>>>>>> is uncomputable. How do you intend to use the fact that your >>>>>>>>> system is incomplete to help you answer the question.

incompleteness never demonstrated certainty for a truth that
cannot be proven by *any* system u moron

Godel's proof showed that within a system (that supports the
properties of Natural Numbers) there must exist statements, which >>>>>>> are true in that system, that are not provable in that system.

Tarski extended that proof to show that while some of the
statements might be provable in a "higher order" meta-system, the >>>>>>> creation of such meta-system show the existance of further true >>>>>>> statements in the base system that can not be answered in that
meta-system, and thus, while we can continue to add higher and
higher order meta- systems to prove more and more of these true >>>>>>> statements, there will ALWAYS be more true statments that are not >>>>>>> provable.

Thus there will ALWAYS be some statement which is true in the
base system that can not be proven in ANY finite-order meta-system. >>>>>>>
Since the definition of a logic system under discussion include >>>>>>> that it have a finite number of initial truths (the axioms), and >>>>>>> higher- order systems work by adding additional initial truths, >>>>>>> we can only form finite-order higher order system, and not an
"infinite-order meta- system", we can show that there must exist >>>>>>> some statement which are true in the base system that can NEVER >>>>>>> be proved in ANY higher order system.

We also can not show that a statement is one of these, as to do >>>>>>> so would be to prove it, as they must be true.

thanks gpt Efai

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 10:11 PM, dart200 wrote:

On 1/1/26 4:20 PM, Richard Damon wrote:

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called >>>>>>>>>>>>>>> the ghost detector with 3 return values: HALTS/LOOPS/ >>>>>>>>>>>>>>> UNRELIABLE

this unfortunately got stumped by a paradox that >>>>>>>>>>>>>>> invalidated a total ghost detector by doing an unbounded >>>>>>>>>>>>>>> search via the reduction techniques used to compute the >>>>>>>>>>>>>>> machine that is functionally equivalent to the
"paradoxical" machine.

and so i propose a truly radical 4th return value for >>>>>>>>>>>>>>> this ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these >>>>>>>>>>>>>>> parts Efn< is going to claim this is just kicking the can >>>>>>>>>>>>>>> down the road. but that's not actually true. many >>>>>>>>>>>>>>> machines are directly computable. many not directly >>>>>>>>>>>>>>> computable, are *still* REDUCIBLE by computation (those >>>>>>>>>>>>>>> that only contradict a finite amount of detector calls in >>>>>>>>>>>>>>> the chain of functionally equivalent machines found by >>>>>>>>>>>>>>> injection/ reduction), while only a final (but still >>>>>>>>>>>>>>> identifiable) class of machines paradoxes *all* >>>>>>>>>>>>>>> functionally equivalent machines found by value >>>>>>>>>>>>>>> injection, and are therefore not reducible in a >>>>>>>>>>>>>>> computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>>>>> machine will do, just that we just can't determine them >>>>>>>>>>>>>>> generally via computable algo because UNCOMPUTABLE >>>>>>>>>>>>>>> machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is >>>>>>>>>>>>>> uncomputable, namely that something is uncomputable. >>>>>>>>>>>>>>
Yes, if you assume someone can give you the answer, any >>>>>>>>>>>>>> problem becomes computable, but you system blows up in a >>>>>>>>>>>>>> contradiction, as such an "oracle" doesn't exist, and >>>>>>>>>>>>>> can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines >>>>>>>>>>>>> have a specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand that. >>>>>>>>>>>>
DU is NOT UNCOMPUTABLE, it is only wrongly decided by the >>>>>>>>>>>> specific set of functions it is based on. Remember, it is >>>>>>>>>>>> only actually a machine if > it includes ALL the code it >>>>>>>>>>>> uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider code >>>>>>>>>>> needs to be entirely in the input to the decider, it
certainly can identify itself. identical/self-equivalent (and >>>>>>>>>>> code- isomorphic machines) are fairly trivial to identify. >>>>>>>>>>

No, the problem is the input only needs the functional
equivalent of the decider, and thus that fact can be
undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING
QUESTION???

the proof against turing equivalence deciders is *also* a
semantic paradox, just like the halting problem. this detector >>>>>>>>> form is ultimately going to be generalized to all semantic
problems.

No, it isn't. Your problem is you keep on assuming you can do >>>>>>>> infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are
uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable assumption.

by showing how a decider/detector can co-exist with paradoxical input??? >>>
THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK

But the point is that the "paradoxical input" shows that the decider
is just incorrect / fails to meet its requirements.

AND??? THE POINT OF THE MACHINE IS UNCOMPUTABLE BY A GENERAL ALGO *ARE* IDENTIFIABLE,

How? Since you can't make a machine that does something that isn't
computable, you are just tring to define something that doesn't exst.

Note, the "Contrary" machine is NOT "uncompuable", just that it makes
the one machine it was defined to make wrong give the wrong answer.

You seem to be mixing up two very different concept.

WHICH IS SOMETHING U CLAIM TO NOT BE COMPUTABLE

Detecting the "Ghosts" is uncomputable.

Detecting that that two machies are functionally equivalent is uncomputable.

Sincd the contrary machine given to the decider it was built to
contradict has a definite behavior, it saying it is incoherent is just
wrong, as there IS a correct answer.

Trying to detect all possible contrary machines is not computable, so it
can't give a "Contray" answer to all such machines, and that answer is actually just wrong.

For instance, how can you get a "reducible" value, as either the
machine halt or it doesn't based on the answer the particular
implmentation of your decider that it is based on answers.

UR ASKING QUESTIONS THAT WOULD BE ANSWERED BY THE SPECIFIC EXAMPLES U
NEVER READ, DICK

So, give me the code of your claimed decider. That is the pre-requesit
for making the contrary machine.

Or agree, that you machine isn't allowed to try to detect the posible undetectable copy of it.

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make wrong.

And, how can your decider return UNCOMPUTABLE, since the only machines
whose result can't be computed would be a LOOPING machines, as ANY
machine that HALTS can be computed to halt by a simple UTM, which
would be an always right recognizer for halting.

BECAUSE THE INFINITE REDUCTION PARADOX IS IDENTIFIABLE

How?

That is just your claim.

You might be able to detect some cases of it, but that is insufficent.

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of
computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you are
doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature.

I DON'T KNOW WHY THE FUCK UR POSTING, TBH

IF YOU WANT TO HAVE A DISCUSSION THEN SOME BURDEN IS ON YOU TO
UNDERSTAND WHAT I'M SAYING IN ORDER TO MAKE COHERENT REPLIES.

But I can only do that if you are being coherent, and that means stop
just claiming you can do things that you can't.

IF UR NOT WILLING TO ACCEPT THAT BURDEN THEN DON'T FUCK REPLY YOU DICK

I will accept the burden when you meet yours first.

Rememver, the input is based on the decider, so the decider must exist
first.

fucking idk why i need to explain this to retards who've been
shitposting on usenet longer than i've even been alive...

seriously what a fucking EfniEfiA

It seems you are the one that is stuck and ruining your life.


And perhaps if you took the time to understand what you are talking
about, and the netiquette of asking about things, you might get better results.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 7:34 PM, Richard Damon wrote:

On 1/1/26 10:11 PM, dart200 wrote:

On 1/1/26 4:20 PM, Richard Damon wrote:

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i called >>>>>>>>>>>>>>>> the ghost detector with 3 return values: HALTS/LOOPS/ >>>>>>>>>>>>>>>> UNRELIABLE

this unfortunately got stumped by a paradox that >>>>>>>>>>>>>>>> invalidated a total ghost detector by doing an unbounded >>>>>>>>>>>>>>>> search via the reduction techniques used to compute the >>>>>>>>>>>>>>>> machine that is functionally equivalent to the >>>>>>>>>>>>>>>> "paradoxical" machine.

and so i propose a truly radical 4th return value for >>>>>>>>>>>>>>>> this ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these >>>>>>>>>>>>>>>> parts Efn< is going to claim this is just kicking the can >>>>>>>>>>>>>>>> down the road. but that's not actually true. many >>>>>>>>>>>>>>>> machines are directly computable. many not directly >>>>>>>>>>>>>>>> computable, are *still* REDUCIBLE by computation (those >>>>>>>>>>>>>>>> that only contradict a finite amount of detector calls >>>>>>>>>>>>>>>> in the chain of functionally equivalent machines found >>>>>>>>>>>>>>>> by injection/ reduction), while only a final (but still >>>>>>>>>>>>>>>> identifiable) class of machines paradoxes *all* >>>>>>>>>>>>>>>> functionally equivalent machines found by value >>>>>>>>>>>>>>>> injection, and are therefore not reducible in a >>>>>>>>>>>>>>>> computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>>>>>> machine will do, just that we just can't determine them >>>>>>>>>>>>>>>> generally via computable algo because UNCOMPUTABLE >>>>>>>>>>>>>>>> machines will defeat that aglo.

so a halting ghost detector now has the form:

Which just assumes that you can compute something that is >>>>>>>>>>>>>>> uncomputable, namely that something is uncomputable. >>>>>>>>>>>>>>>
Yes, if you assume someone can give you the answer, any >>>>>>>>>>>>>>> problem becomes computable, but you system blows up in a >>>>>>>>>>>>>>> contradiction, as such an "oracle" doesn't exist, and >>>>>>>>>>>>>>> can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines >>>>>>>>>>>>>> have a specific, identifiable semantic structure.

NO they don't, but I guess you are too tard to understand >>>>>>>>>>>>> that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the >>>>>>>>>>>>> specific set of functions it is based on. Remember, it is >>>>>>>>>>>>> only actually a machine if > it includes ALL the code it >>>>>>>>>>>>> uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider >>>>>>>>>>>> code needs to be entirely in the input to the decider, it >>>>>>>>>>>> certainly can identify itself. identical/self-equivalent >>>>>>>>>>>> (and code- isomorphic machines) are fairly trivial to identify. >>>>>>>>>>>

No, the problem is the input only needs the functional
equivalent of the decider, and thus that fact can be
undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING
QUESTION???

the proof against turing equivalence deciders is *also* a >>>>>>>>>> semantic paradox, just like the halting problem. this detector >>>>>>>>>> form is ultimately going to be generalized to all semantic >>>>>>>>>> problems.

No, it isn't. Your problem is you keep on assuming you can do >>>>>>>>> infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are
uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable assumption. >>>>

by showing how a decider/detector can co-exist with paradoxical
input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK

But the point is that the "paradoxical input" shows that the decider
is just incorrect / fails to meet its requirements.

AND??? THE POINT OF THE MACHINE IS UNCOMPUTABLE BY A GENERAL ALGO
*ARE* IDENTIFIABLE,

How? Since you can't make a machine that does something that isn't computable, you are just tring to define something that doesn't exst.

Note, the "Contrary" machine is NOT "uncompuable", just that it makes
the one machine it was defined to make wrong give the wrong answer.

You seem to be mixing up two very different concept.

WHICH IS SOMETHING U CLAIM TO NOT BE COMPUTABLE

Detecting the "Ghosts" is uncomputable.

Detecting that that two machies are functionally equivalent is
uncomputable.

WHEN ARE WE GOING TO STOP BEGGING THE DAMN QUESTION, DICK???

BOTH OF THOSE ARE SEMANTIC QUESTIONS, BOTH PROOFS AGAINST THEM INVOLVE SEMANTIC PARADOXES, AND THE GHOST DETECTOR IS MEANT TO FACILITATE WHEN
WE CAN AND CANNOT ANSWER THE SEMANTIC QUESTIONS THUR A GENERAL INTERFACE

Sincd the contrary machine given to the decider it was built to
contradict has a definite behavior, it saying it is incoherent is just wrong, as there IS a correct answer.

Trying to detect all possible contrary machines is not computable, so it can't give a "Contray" answer to all such machines, and that answer is actually just wrong.

For instance, how can you get a "reducible" value, as either the
machine halt or it doesn't based on the answer the particular
implmentation of your decider that it is based on answers.

UR ASKING QUESTIONS THAT WOULD BE ANSWERED BY THE SPECIFIC EXAMPLES U
NEVER READ, DICK

So, give me the code of your claimed decider. That is the pre-requesit
for making the contrary machine.

WHAT IN THE FUCK ARE YOU SMOKING DICK???

SINCE WHEN IS PRODUCING THE CODE FOR A DECIDER NECESSARY TO BUILD THE CONTRADICTION??? ALL THAT'S EVER BEEN CONTRADICTED IS THE INTERFACE,
WHICH I ALREADY GAVE.

Or agree, that you machine isn't allowed to try to detect the posible undetectable copy of it.

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make wrong.

And, how can your decider return UNCOMPUTABLE, since the only
machines whose result can't be computed would be a LOOPING machines,
as ANY machine that HALTS can be computed to halt by a simple UTM,
which would be an always right recognizer for halting.

BECAUSE THE INFINITE REDUCTION PARADOX IS IDENTIFIABLE

How?

That is just your claim.

You might be able to detect some cases of it, but that is insufficent.

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of
computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you are >>>>> doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature.

I DON'T KNOW WHY THE FUCK UR POSTING, TBH

IF YOU WANT TO HAVE A DISCUSSION THEN SOME BURDEN IS ON YOU TO
UNDERSTAND WHAT I'M SAYING IN ORDER TO MAKE COHERENT REPLIES.

But I can only do that if you are being coherent, and that means stop
just claiming you can do things that you can't.

IF UR NOT WILLING TO ACCEPT THAT BURDEN THEN DON'T FUCK REPLY YOU DICK

I will accept the burden when you meet yours first.

Rememver, the input is based on the decider, so the decider must exist first.

fucking idk why i need to explain this to retards who've been
shitposting on usenet longer than i've even been alive...

seriously what a fucking EfniEfiA

It seems you are the one that is stuck and ruining your life.

And perhaps if you took the time to understand what you are talking
about, and the netiquette of asking about things, you might get better results.

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 11:17 PM, dart200 wrote:

On 1/1/26 7:34 PM, Richard Damon wrote:

On 1/1/26 10:11 PM, dart200 wrote:

On 1/1/26 4:20 PM, Richard Damon wrote:

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i >>>>>>>>>>>>>>>>> called the ghost detector with 3 return values: HALTS/ >>>>>>>>>>>>>>>>> LOOPS/ UNRELIABLE

this unfortunately got stumped by a paradox that >>>>>>>>>>>>>>>>> invalidated a total ghost detector by doing an >>>>>>>>>>>>>>>>> unbounded search via the reduction techniques used to >>>>>>>>>>>>>>>>> compute the machine that is functionally equivalent to >>>>>>>>>>>>>>>>> the "paradoxical" machine.

and so i propose a truly radical 4th return value for >>>>>>>>>>>>>>>>> this ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these >>>>>>>>>>>>>>>>> parts Efn< is going to claim this is just kicking the can >>>>>>>>>>>>>>>>> down the road. but that's not actually true. many >>>>>>>>>>>>>>>>> machines are directly computable. many not directly >>>>>>>>>>>>>>>>> computable, are *still* REDUCIBLE by computation (those >>>>>>>>>>>>>>>>> that only contradict a finite amount of detector calls >>>>>>>>>>>>>>>>> in the chain of functionally equivalent machines found >>>>>>>>>>>>>>>>> by injection/ reduction), while only a final (but still >>>>>>>>>>>>>>>>> identifiable) class of machines paradoxes *all* >>>>>>>>>>>>>>>>> functionally equivalent machines found by value >>>>>>>>>>>>>>>>> injection, and are therefore not reducible in a >>>>>>>>>>>>>>>>> computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>>>>>>> machine will do, just that we just can't determine them >>>>>>>>>>>>>>>>> generally via computable algo because UNCOMPUTABLE >>>>>>>>>>>>>>>>> machines will defeat that aglo.

so a halting ghost detector now has the form: >>>>>>>>>>>>>>>>

Which just assumes that you can compute something that >>>>>>>>>>>>>>>> is uncomputable, namely that something is uncomputable. >>>>>>>>>>>>>>>>
Yes, if you assume someone can give you the answer, any >>>>>>>>>>>>>>>> problem becomes computable, but you system blows up in a >>>>>>>>>>>>>>>> contradiction, as such an "oracle" doesn't exist, and >>>>>>>>>>>>>>>> can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines >>>>>>>>>>>>>>> have a specific, identifiable semantic structure. >>>>>>>>>>>>>>

NO they don't, but I guess you are too tard to understand >>>>>>>>>>>>>> that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the >>>>>>>>>>>>>> specific set of functions it is based on. Remember, it is >>>>>>>>>>>>>> only actually a machine if > it includes ALL the code it >>>>>>>>>>>>>> uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider >>>>>>>>>>>>> code needs to be entirely in the input to the decider, it >>>>>>>>>>>>> certainly can identify itself. identical/self-equivalent >>>>>>>>>>>>> (and code- isomorphic machines) are fairly trivial to >>>>>>>>>>>>> identify.

No, the problem is the input only needs the functional >>>>>>>>>>>> equivalent of the decider, and thus that fact can be
undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING >>>>>>>>>>> QUESTION???

the proof against turing equivalence deciders is *also* a >>>>>>>>>>> semantic paradox, just like the halting problem. this
detector form is ultimately going to be generalized to all >>>>>>>>>>> semantic problems.

No, it isn't. Your problem is you keep on assuming you can do >>>>>>>>>> infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are
uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable
assumption.

by showing how a decider/detector can co-exist with paradoxical
input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK

But the point is that the "paradoxical input" shows that the decider
is just incorrect / fails to meet its requirements.

AND??? THE POINT OF THE MACHINE IS UNCOMPUTABLE BY A GENERAL ALGO
*ARE* IDENTIFIABLE,

How? Since you can't make a machine that does something that isn't
computable, you are just tring to define something that doesn't exst.

Note, the "Contrary" machine is NOT "uncompuable", just that it makes
the one machine it was defined to make wrong give the wrong answer.

You seem to be mixing up two very different concept.

WHICH IS SOMETHING U CLAIM TO NOT BE COMPUTABLE

Detecting the "Ghosts" is uncomputable.

Detecting that that two machies are functionally equivalent is
uncomputable.

WHEN ARE WE GOING TO STOP BEGGING THE DAMN QUESTION, DICK???

BOTH OF THOSE ARE SEMANTIC QUESTIONS, BOTH PROOFS AGAINST THEM INVOLVE SEMANTIC PARADOXES, AND THE GHOST DETECTOR IS MEANT TO FACILITATE WHEN
WE CAN AND CANNOT ANSWER THE SEMANTIC QUESTIONS THUR A GENERAL INTERFACE

But you confuse the two.

The "Ghost" machine isn't based on the decider, as it is undecidable to
every machine, not just this one.

The Contrary machine, uses a functional copy of the decider, and makes
that one machine wrong. It is not undeciable unless that decider is
itself an undeciable machine,

Sincd the contrary machine given to the decider it was built to
contradict has a definite behavior, it saying it is incoherent is just
wrong, as there IS a correct answer.

Trying to detect all possible contrary machines is not computable, so
it can't give a "Contray" answer to all such machines, and that answer
is actually just wrong.

For instance, how can you get a "reducible" value, as either the
machine halt or it doesn't based on the answer the particular
implmentation of your decider that it is based on answers.

UR ASKING QUESTIONS THAT WOULD BE ANSWERED BY THE SPECIFIC EXAMPLES U
NEVER READ, DICK

So, give me the code of your claimed decider. That is the pre-requesit
for making the contrary machine.

WHAT IN THE FUCK ARE YOU SMOKING DICK???

SINCE WHEN IS PRODUCING THE CODE FOR A DECIDER NECESSARY TO BUILD THE CONTRADICTION??? ALL THAT'S EVER BEEN CONTRADICTED IS THE INTERFACE,
WHICH I ALREADY GAVE.

Since it was ever defined. Read the paper.

The Contray program STARTS with a COPY of the decider (not its
interface) and that is then modified.

You can't build a "program" based on another "programs" interface, since
the definition of a "program" in the theory requires it to include ALL
of the detalied algorithm it uses, and NOT just a reference to something
else.

Sometimes it is simplifed to be shown as a call, but to actually
implement the code needs to be copied in to form the actual "program"

Or agree, that you machine isn't allowed to try to detect the posible
undetectable copy of it.

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make wrong. >>>>
And, how can your decider return UNCOMPUTABLE, since the only
machines whose result can't be computed would be a LOOPING machines,
as ANY machine that HALTS can be computed to halt by a simple UTM,
which would be an always right recognizer for halting.

BECAUSE THE INFINITE REDUCTION PARADOX IS IDENTIFIABLE

How?

That is just your claim.

You might be able to detect some cases of it, but that is insufficent.

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of >>>>>> computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you
are doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature.

I DON'T KNOW WHY THE FUCK UR POSTING, TBH

IF YOU WANT TO HAVE A DISCUSSION THEN SOME BURDEN IS ON YOU TO
UNDERSTAND WHAT I'M SAYING IN ORDER TO MAKE COHERENT REPLIES.

But I can only do that if you are being coherent, and that means stop
just claiming you can do things that you can't.

IF UR NOT WILLING TO ACCEPT THAT BURDEN THEN DON'T FUCK REPLY YOU DICK

I will accept the burden when you meet yours first.

Rememver, the input is based on the decider, so the decider must exist
first.

fucking idk why i need to explain this to retards who've been
shitposting on usenet longer than i've even been alive...

seriously what a fucking EfniEfiA

It seems you are the one that is stuck and ruining your life.


And perhaps if you took the time to understand what you are talking
about, and the netiquette of asking about things, you might get better
results.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/1/26 8:38 PM, Richard Damon wrote:

On 1/1/26 11:17 PM, dart200 wrote:

On 1/1/26 7:34 PM, Richard Damon wrote:

On 1/1/26 10:11 PM, dart200 wrote:

On 1/1/26 4:20 PM, Richard Damon wrote:

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i >>>>>>>>>>>>>>>>>> called the ghost detector with 3 return values: HALTS/ >>>>>>>>>>>>>>>>>> LOOPS/ UNRELIABLE

this unfortunately got stumped by a paradox that >>>>>>>>>>>>>>>>>> invalidated a total ghost detector by doing an >>>>>>>>>>>>>>>>>> unbounded search via the reduction techniques used to >>>>>>>>>>>>>>>>>> compute the machine that is functionally equivalent to >>>>>>>>>>>>>>>>>> the "paradoxical" machine.

and so i propose a truly radical 4th return value for >>>>>>>>>>>>>>>>>> this ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these >>>>>>>>>>>>>>>>>> parts Efn< is going to claim this is just kicking the >>>>>>>>>>>>>>>>>> can down the road. but that's not actually true. many >>>>>>>>>>>>>>>>>> machines are directly computable. many not directly >>>>>>>>>>>>>>>>>> computable, are *still* REDUCIBLE by computation >>>>>>>>>>>>>>>>>> (those that only contradict a finite amount of >>>>>>>>>>>>>>>>>> detector calls in the chain of functionally equivalent >>>>>>>>>>>>>>>>>> machines found by injection/ reduction), while only a >>>>>>>>>>>>>>>>>> final (but still identifiable) class of machines >>>>>>>>>>>>>>>>>> paradoxes *all* functionally equivalent machines found >>>>>>>>>>>>>>>>>> by value injection, and are therefore not reducible in >>>>>>>>>>>>>>>>>> a computable fashion.

that doesn't mean we cannot know what the uncomputable >>>>>>>>>>>>>>>>>> machine will do, just that we just can't determine >>>>>>>>>>>>>>>>>> them generally via computable algo because >>>>>>>>>>>>>>>>>> UNCOMPUTABLE machines will defeat that aglo. >>>>>>>>>>>>>>>>>>
so a halting ghost detector now has the form: >>>>>>>>>>>>>>>>>

Which just assumes that you can compute something that >>>>>>>>>>>>>>>>> is uncomputable, namely that something is uncomputable. >>>>>>>>>>>>>>>>>
Yes, if you assume someone can give you the answer, any >>>>>>>>>>>>>>>>> problem becomes computable, but you system blows up in >>>>>>>>>>>>>>>>> a contradiction, as such an "oracle" doesn't exist, and >>>>>>>>>>>>>>>>> can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines >>>>>>>>>>>>>>>> have a specific, identifiable semantic structure. >>>>>>>>>>>>>>>

NO they don't, but I guess you are too tard to understand >>>>>>>>>>>>>>> that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by the >>>>>>>>>>>>>>> specific set of functions it is based on. Remember, it is >>>>>>>>>>>>>>> only actually a machine if > it includes ALL the code it >>>>>>>>>>>>>>> uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider >>>>>>>>>>>>>> code needs to be entirely in the input to the decider, it >>>>>>>>>>>>>> certainly can identify itself. identical/self-equivalent >>>>>>>>>>>>>> (and code- isomorphic machines) are fairly trivial to >>>>>>>>>>>>>> identify.

No, the problem is the input only needs the functional >>>>>>>>>>>>> equivalent of the decider, and thus that fact can be >>>>>>>>>>>>> undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING >>>>>>>>>>>> QUESTION???

the proof against turing equivalence deciders is *also* a >>>>>>>>>>>> semantic paradox, just like the halting problem. this >>>>>>>>>>>> detector form is ultimately going to be generalized to all >>>>>>>>>>>> semantic problems.

No, it isn't. Your problem is you keep on assuming you can do >>>>>>>>>>> infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are
uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable
assumption.

by showing how a decider/detector can co-exist with paradoxical
input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK >>>>>

But the point is that the "paradoxical input" shows that the
decider is just incorrect / fails to meet its requirements.

AND??? THE POINT OF THE MACHINE IS UNCOMPUTABLE BY A GENERAL ALGO
*ARE* IDENTIFIABLE,

How? Since you can't make a machine that does something that isn't
computable, you are just tring to define something that doesn't exst.

Note, the "Contrary" machine is NOT "uncompuable", just that it makes
the one machine it was defined to make wrong give the wrong answer.

You seem to be mixing up two very different concept.

WHICH IS SOMETHING U CLAIM TO NOT BE COMPUTABLE

Detecting the "Ghosts" is uncomputable.

Detecting that that two machies are functionally equivalent is
uncomputable.

WHEN ARE WE GOING TO STOP BEGGING THE DAMN QUESTION, DICK???

BOTH OF THOSE ARE SEMANTIC QUESTIONS, BOTH PROOFS AGAINST THEM INVOLVE
SEMANTIC PARADOXES, AND THE GHOST DETECTOR IS MEANT TO FACILITATE WHEN
WE CAN AND CANNOT ANSWER THE SEMANTIC QUESTIONS THUR A GENERAL INTERFACE

But you confuse the two.

The "Ghost" machine isn't based on the decider, as it is undecidable to every machine, not just this one.

until you actually post code for this "ghost" that confounds the
interface i gave ...

you can keep up the good work in repeating urself ad nausium EfaiEfaiEfai

The Contrary machine, uses a functional copy of the decider, and makes
that one machine wrong. It is not undeciable unless that decider is
itself an undeciable machine,

Sincd the contrary machine given to the decider it was built to
contradict has a definite behavior, it saying it is incoherent is
just wrong, as there IS a correct answer.

Trying to detect all possible contrary machines is not computable, so
it can't give a "Contray" answer to all such machines, and that
answer is actually just wrong.

For instance, how can you get a "reducible" value, as either the
machine halt or it doesn't based on the answer the particular
implmentation of your decider that it is based on answers.

UR ASKING QUESTIONS THAT WOULD BE ANSWERED BY THE SPECIFIC EXAMPLES
U NEVER READ, DICK

So, give me the code of your claimed decider. That is the pre-
requesit for making the contrary machine.

WHAT IN THE FUCK ARE YOU SMOKING DICK???

SINCE WHEN IS PRODUCING THE CODE FOR A DECIDER NECESSARY TO BUILD THE
CONTRADICTION??? ALL THAT'S EVER BEEN CONTRADICTED IS THE INTERFACE,
WHICH I ALREADY GAVE.

Since it was ever defined. Read the paper.

no paper gave code for a decider they then claim to then contradict u
moron, as the contradiction means it then doesn't exist.

what in the fuck are you talking about chard?

The Contray program STARTS with a COPY of the decider (not its
interface) and that is then modified.

You can't build a "program" based on another "programs" interface, since
the definition of a "program" in the theory requires it to include ALL
of the detalied algorithm it uses, and NOT just a reference to something else.

Sometimes it is simplifed to be shown as a call, but to actually
implement the code needs to be copied in to form the actual "program"

Or agree, that you machine isn't allowed to try to detect the posible
undetectable copy of it.

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make wrong. >>>>>
And, how can your decider return UNCOMPUTABLE, since the only
machines whose result can't be computed would be a LOOPING
machines, as ANY machine that HALTS can be computed to halt by a
simple UTM, which would be an always right recognizer for halting.

BECAUSE THE INFINITE REDUCTION PARADOX IS IDENTIFIABLE

How?

That is just your claim.

You might be able to detect some cases of it, but that is insufficent.

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory of >>>>>>> computaition, and thus nothing you say actually applies to it.

And then, you have the burden to actually FULLY define what you >>>>>>> are doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature.

I DON'T KNOW WHY THE FUCK UR POSTING, TBH

IF YOU WANT TO HAVE A DISCUSSION THEN SOME BURDEN IS ON YOU TO
UNDERSTAND WHAT I'M SAYING IN ORDER TO MAKE COHERENT REPLIES.

But I can only do that if you are being coherent, and that means stop
just claiming you can do things that you can't.

IF UR NOT WILLING TO ACCEPT THAT BURDEN THEN DON'T FUCK REPLY YOU DICK

I will accept the burden when you meet yours first.

Rememver, the input is based on the decider, so the decider must
exist first.

fucking idk why i need to explain this to retards who've been
shitposting on usenet longer than i've even been alive...

seriously what a fucking EfniEfiA

It seems you are the one that is stuck and ruining your life.


And perhaps if you took the time to understand what you are talking
about, and the netiquette of asking about things, you might get
better results.

--
a burnt out swe investigating into why our tooling doesn't involve
basic semantic proofs like halting analysis

please excuse my pseudo-pyscript,

~ nick
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 1/2/26 12:31 AM, dart200 wrote:

On 1/1/26 8:38 PM, Richard Damon wrote:

On 1/1/26 11:17 PM, dart200 wrote:

On 1/1/26 7:34 PM, Richard Damon wrote:

On 1/1/26 10:11 PM, dart200 wrote:

On 1/1/26 4:20 PM, Richard Damon wrote:

On 1/1/26 7:06 PM, dart200 wrote:

On 1/1/26 11:38 AM, Richard Damon wrote:

On 1/1/26 2:23 PM, dart200 wrote:

On 1/1/26 11:19 AM, Richard Damon wrote:

On 1/1/26 1:58 PM, dart200 wrote:

On 1/1/26 9:23 AM, Richard Damon wrote:

On 1/1/26 4:14 AM, dart200 wrote:

On 12/31/25 11:09 AM, Richard Damon wrote:

On 12/31/25 12:52 PM, dart200 wrote:

On 12/31/25 9:01 AM, Richard Damon wrote:

On 12/31/25 11:32 AM, dart200 wrote:

On 12/31/25 4:38 AM, Richard Damon wrote:

On 12/31/25 3:28 AM, dart200 wrote:

previously i wrote about a classifier variation i >>>>>>>>>>>>>>>>>>> called the ghost detector with 3 return values: >>>>>>>>>>>>>>>>>>> HALTS/ LOOPS/ UNRELIABLE

this unfortunately got stumped by a paradox that >>>>>>>>>>>>>>>>>>> invalidated a total ghost detector by doing an >>>>>>>>>>>>>>>>>>> unbounded search via the reduction techniques used to >>>>>>>>>>>>>>>>>>> compute the machine that is functionally equivalent >>>>>>>>>>>>>>>>>>> to the "paradoxical" machine.

and so i propose a truly radical 4th return value for >>>>>>>>>>>>>>>>>>> this ghost detector: UNCOMPUTABLE

now a certain massive dick festering around in these >>>>>>>>>>>>>>>>>>> parts Efn< is going to claim this is just kicking the >>>>>>>>>>>>>>>>>>> can down the road. but that's not actually true. many >>>>>>>>>>>>>>>>>>> machines are directly computable. many not directly >>>>>>>>>>>>>>>>>>> computable, are *still* REDUCIBLE by computation >>>>>>>>>>>>>>>>>>> (those that only contradict a finite amount of >>>>>>>>>>>>>>>>>>> detector calls in the chain of functionally >>>>>>>>>>>>>>>>>>> equivalent machines found by injection/ reduction), >>>>>>>>>>>>>>>>>>> while only a final (but still identifiable) class of >>>>>>>>>>>>>>>>>>> machines paradoxes *all* functionally equivalent >>>>>>>>>>>>>>>>>>> machines found by value injection, and are therefore >>>>>>>>>>>>>>>>>>> not reducible in a computable fashion.

that doesn't mean we cannot know what the >>>>>>>>>>>>>>>>>>> uncomputable machine will do, just that we just can't >>>>>>>>>>>>>>>>>>> determine them generally via computable algo because >>>>>>>>>>>>>>>>>>> UNCOMPUTABLE machines will defeat that aglo. >>>>>>>>>>>>>>>>>>>
so a halting ghost detector now has the form: >>>>>>>>>>>>>>>>>>

Which just assumes that you can compute something that >>>>>>>>>>>>>>>>>> is uncomputable, namely that something is uncomputable. >>>>>>>>>>>>>>>>>>
Yes, if you assume someone can give you the answer, >>>>>>>>>>>>>>>>>> any problem becomes computable, but you system blows >>>>>>>>>>>>>>>>>> up in a contradiction, as such an "oracle" doesn't >>>>>>>>>>>>>>>>>> exist, and can't exist in the system.

richard u tard, actually read it. UNCOMPUTABLE machines >>>>>>>>>>>>>>>>> have a specific, identifiable semantic structure. >>>>>>>>>>>>>>>>

NO they don't, but I guess you are too tard to >>>>>>>>>>>>>>>> understand that.

DU is NOT UNCOMPUTABLE, it is only wrongly decided by >>>>>>>>>>>>>>>> the specific set of functions it is based on. Remember, >>>>>>>>>>>>>>>> it is only actually a machine if > it includes ALL the >>>>>>>>>>>>>>>> code it uses, incuding that "decider" you are
talking about.

yes i'm aware. that's actually a plus. since the decider >>>>>>>>>>>>>>> code needs to be entirely in the input to the decider, it >>>>>>>>>>>>>>> certainly can identify itself. identical/self-equivalent >>>>>>>>>>>>>>> (and code- isomorphic machines) are fairly trivial to >>>>>>>>>>>>>>> identify.

No, the problem is the input only needs the functional >>>>>>>>>>>>>> equivalent of the decider, and thus that fact can be >>>>>>>>>>>>>> undetectable.

HEY DICK, WHEN ARE WE GOING TO STOP BEGGING THE FUCKING >>>>>>>>>>>>> QUESTION???

the proof against turing equivalence deciders is *also* a >>>>>>>>>>>>> semantic paradox, just like the halting problem. this >>>>>>>>>>>>> detector form is ultimately going to be generalized to all >>>>>>>>>>>>> semantic problems.

No, it isn't. Your problem is you keep on assuming you can >>>>>>>>>>>> do infinite work which you can't.

where is infinite work required???

You keep on assuming you can determine things that are
uncompuational.

you haven't shown that dick

I don't need to. You need to prove that it is a reasonable
assumption.

by showing how a decider/detector can co-exist with paradoxical >>>>>>> input???

THAT'S THE POINT OF THE ATTEMPT, KEEP BEGGING THE DAMN QUESTION DICK >>>>>>

But the point is that the "paradoxical input" shows that the
decider is just incorrect / fails to meet its requirements.

AND??? THE POINT OF THE MACHINE IS UNCOMPUTABLE BY A GENERAL ALGO
*ARE* IDENTIFIABLE,

How? Since you can't make a machine that does something that isn't
computable, you are just tring to define something that doesn't exst.

Note, the "Contrary" machine is NOT "uncompuable", just that it
makes the one machine it was defined to make wrong give the wrong
answer.

You seem to be mixing up two very different concept.

WHICH IS SOMETHING U CLAIM TO NOT BE COMPUTABLE

Detecting the "Ghosts" is uncomputable.

Detecting that that two machies are functionally equivalent is
uncomputable.

WHEN ARE WE GOING TO STOP BEGGING THE DAMN QUESTION, DICK???

BOTH OF THOSE ARE SEMANTIC QUESTIONS, BOTH PROOFS AGAINST THEM
INVOLVE SEMANTIC PARADOXES, AND THE GHOST DETECTOR IS MEANT TO
FACILITATE WHEN WE CAN AND CANNOT ANSWER THE SEMANTIC QUESTIONS THUR
A GENERAL INTERFACE

But you confuse the two.

The "Ghost" machine isn't based on the decider, as it is undecidable
to every machine, not just this one.

until you actually post code for this "ghost" that confounds the
interface i gave ...

But the machine that confounds the interface isn't the ghost.
YOUR OWN input confounds it.

You seem to ignore my point that the last two answers can't be correctly given.

Since the input is based on a SPECIFIC version of your machine (as that
is how it is defined) it isn't "Contradictory" to anything but has
definite behavior. The copy of the decider that we are asking about it
COULD have given a different answer if we change it, but the input will
ot change (since it was built on a FIXED version of that machine). Thus Contradictory is never the right answer.

And, your "uncomputable" answer can't actually be computed, so at best
you are admitting to being just a partial decider, which is
uninteresting if you can't define the cases it doesn't decide.

you can keep up the good work in repeating urself ad nausium EfaiEfaiEfai

The Contrary machine, uses a functional copy of the decider, and makes
that one machine wrong. It is not undeciable unless that decider is
itself an undeciable machine,

Sincd the contrary machine given to the decider it was built to
contradict has a definite behavior, it saying it is incoherent is
just wrong, as there IS a correct answer.

Trying to detect all possible contrary machines is not computable,
so it can't give a "Contray" answer to all such machines, and that
answer is actually just wrong.

For instance, how can you get a "reducible" value, as either the
machine halt or it doesn't based on the answer the particular
implmentation of your decider that it is based on answers.

UR ASKING QUESTIONS THAT WOULD BE ANSWERED BY THE SPECIFIC EXAMPLES >>>>> U NEVER READ, DICK

So, give me the code of your claimed decider. That is the pre-
requesit for making the contrary machine.

WHAT IN THE FUCK ARE YOU SMOKING DICK???

SINCE WHEN IS PRODUCING THE CODE FOR A DECIDER NECESSARY TO BUILD THE
CONTRADICTION??? ALL THAT'S EVER BEEN CONTRADICTED IS THE INTERFACE,
WHICH I ALREADY GAVE.

Since it was ever defined. Read the paper.

no paper gave code for a decider they then claim to then contradict u
moron, as the contradiction means it then doesn't exist.

Right, because the proof was based on a generic decider, and showed how
to algorithmically buid an input off of that decider.

what in the fuck are you talking about chard?

How actual logic works.

Since even WITH the code of your example you can't actually create a
full decider that gets the right answer, how do you expect to handle a callenger that knows how you work.

The Contray program STARTS with a COPY of the decider (not its
interface) and that is then modified.

You can't build a "program" based on another "programs" interface,
since the definition of a "program" in the theory requires it to
include ALL of the detalied algorithm it uses, and NOT just a
reference to something else.

Sometimes it is simplifed to be shown as a call, but to actually
implement the code needs to be copied in to form the actual "program"

Or agree, that you machine isn't allowed to try to detect the
posible undetectable copy of it.

Remeber, the input doesn't "call" some nebuolus machine to be
deterimined, but a particular implementation that it is to make
wrong.

And, how can your decider return UNCOMPUTABLE, since the only
machines whose result can't be computed would be a LOOPING
machines, as ANY machine that HALTS can be computed to halt by a
simple UTM, which would be an always right recognizer for halting.

BECAUSE THE INFINITE REDUCTION PARADOX IS IDENTIFIABLE

How?

That is just your claim.

You might be able to detect some cases of it, but that is insufficent. >>>>

I can rely on the existing proof that say they are.

YOU need to disprove them, or admit you are outside the theory >>>>>>>> of computaition, and thus nothing you say actually applies to it. >>>>>>>>
And then, you have the burden to actually FULLY define what you >>>>>>>> are doing.

so u have no burden but to continually throw out gish gallop???

I have no burden to prove what is already proven in the literature. >>>>>

I DON'T KNOW WHY THE FUCK UR POSTING, TBH

IF YOU WANT TO HAVE A DISCUSSION THEN SOME BURDEN IS ON YOU TO
UNDERSTAND WHAT I'M SAYING IN ORDER TO MAKE COHERENT REPLIES.

But I can only do that if you are being coherent, and that means
stop just claiming you can do things that you can't.

IF UR NOT WILLING TO ACCEPT THAT BURDEN THEN DON'T FUCK REPLY YOU DICK >>>>

I will accept the burden when you meet yours first.

Rememver, the input is based on the decider, so the decider must
exist first.

fucking idk why i need to explain this to retards who've been
shitposting on usenet longer than i've even been alive...

seriously what a fucking EfniEfiA

It seems you are the one that is stuck and ruining your life.


And perhaps if you took the time to understand what you are talking
about, and the netiquette of asking about things, you might get
better results.

--- Synchronet 3.21a-Linux NewsLink 1.2