On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a smarter TM
diagonal across the circle-free computable numbers that defeats
all variants of anti_fixed_H,
Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version of that
diagonal, one that includes some circular numbers as well. for
this i will introduce a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free machines,
then the enumeration of the "computable numbers" it generates isn't >>>>> valid, as the array of values has holes in it.
it's not an enumeration of computable numbers, it's a superset of
said enumeration that includes some "circular" machines, but should
include all computable numbers
No, it is a decider that enumerates machines that is supposed to
generate that, but then a machine that tries to use it to enumerate
all enumerable numbers will hang and not generate the enumeration.
Again, what good is this "incorrect" enumeration for getting you to
the goal of showing how to compute an enumeration of all computable
numbers.
Note, because the set of "computable numbers" are (as you have
pointed out) NOT the same machines that compute them, Your "super
set" as described isn't a set of one sort of thing, and is actually
(as I just described) a set of MACHINES that compute computable
numbers + some machines that are circular.
The presence of the circular machines in the set means you can't use
that set to compute the computable numbers, as you process will hang
on circular machines in the set.
This is, i think. part of the reason that Turing switch to the
enumeration of non-circular machines, as they are easier to talk
about processing, as they are finite things, while the elements of
the computable numbers are not, and if you try to talk about using
ONE machine that generates it, you have the problem of selecting that
one machine from the infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on the
"diagonal" a spot where the kth machine in the list doesn't
generate k digits of output, because it was one of those non-
circle-free machines accepted that got stuck too early.
we can avoid that using a stepping simulation while dovetailing:
Nope.
your step_deect_loop might not return anything for all machines, as
not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow over
time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to find
the first even number that can't be found as the sum of two prime,
will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation,
kth digit of M: if the Kth digit of M is reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time >>>> if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case >>>> output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation,
kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>> }
loop detection happens in two cases:
1) if a circular machine is detected when a configuration is
reached twice
2) if a circular recursion is detected when a simulated machine >>>>>> tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular condition
when simulating a machine, but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if circular machines
end up on the list
And why can't that same program be used to compute the sloppy-anti-
diagonal (where you still test the M with DN(sloppy_H) not changing
that, and then reverse the output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- program does
EXACTLY the same steps it will also create an anti-diagonal, which
could not have been from a machine in the listing, thus showing your
enumation doesn't include ALL machines for ALL the computable numbers.
i guess at this point there's little point to even try to filter out
any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output
}
every time step is called it advances the machine's runtime,
recording any output alone the way. after the step is complete, if
the Kth output has been recorded already it will output that.
however if the Kth output has not already been output by the machine
then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case >>>> output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to anti_sloppier_H
when sloppier_H starts dovetailing it. i'm kinda guessing at the
moment that the K within sloppier_H grows faster than the K within
anti_sloppier_H and therefore sloppier_H will just never actually
output a digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of
sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect anything,
it still existed as the code for the machine with its number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly run
behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra steps
for each cycle K ... mean sloppier_H's K _must_ grow faster than
anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H.
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a smarter TM
diagonal across the circle-free computable numbers that defeats >>>>>>> all variants of anti_fixed_H,
Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version of that >>>>>>> diagonal, one that includes some circular numbers as well. for
this i will introduce a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free machines, >>>>>> then the enumeration of the "computable numbers" it generates
isn't valid, as the array of values has holes in it.
it's not an enumeration of computable numbers, it's a superset of
said enumeration that includes some "circular" machines, but should >>>>> include all computable numbers
No, it is a decider that enumerates machines that is supposed to
generate that, but then a machine that tries to use it to enumerate
all enumerable numbers will hang and not generate the enumeration.
Again, what good is this "incorrect" enumeration for getting you to
the goal of showing how to compute an enumeration of all computable
numbers.
Note, because the set of "computable numbers" are (as you have
pointed out) NOT the same machines that compute them, Your "super
set" as described isn't a set of one sort of thing, and is actually
(as I just described) a set of MACHINES that compute computable
numbers + some machines that are circular.
The presence of the circular machines in the set means you can't use
that set to compute the computable numbers, as you process will hang
on circular machines in the set.
This is, i think. part of the reason that Turing switch to the
enumeration of non-circular machines, as they are easier to talk
about processing, as they are finite things, while the elements of
the computable numbers are not, and if you try to talk about using
ONE machine that generates it, you have the problem of selecting
that one machine from the infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on the
"diagonal" a spot where the kth machine in the list doesn't
generate k digits of output, because it was one of those non-
circle-free machines accepted that got stuck too early.
we can avoid that using a stepping simulation while dovetailing:
Nope.
your step_deect_loop might not return anything for all machines, as
not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow over
time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to find
the first even number that can't be found as the sum of two prime,
will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation,
kth digit of M: if the Kth digit of M is reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time >>>>> if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case >>>>> output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>> }
loop detection happens in two cases:
1) if a circular machine is detected when a configuration is >>>>>>> reached twice
2) if a circular recursion is detected when a simulated machine >>>>>>> tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular condition
when simulating a machine, but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if circular machines
end up on the list
And why can't that same program be used to compute the sloppy-anti-
diagonal (where you still test the M with DN(sloppy_H) not changing
that, and then reverse the output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- program does
EXACTLY the same steps it will also create an anti-diagonal, which
could not have been from a machine in the listing, thus showing your
enumation doesn't include ALL machines for ALL the computable numbers. >>>>
i guess at this point there's little point to even try to filter
out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output
}
every time step is called it advances the machine's runtime,
recording any output alone the way. after the step is complete, if
the Kth output has been recorded already it will output that.
however if the Kth output has not already been output by the
machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case >>>>> output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to anti_sloppier_H >>>>> when sloppier_H starts dovetailing it. i'm kinda guessing at the
moment that the K within sloppier_H grows faster than the K within
anti_sloppier_H and therefore sloppier_H will just never actually
output a digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of
sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect
anything, it still existed as the code for the machine with its number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly run
behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra
steps for each cycle K ... mean sloppier_H's K _must_ grow faster
than anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H because it needs to check the output of after each step of sloppier_H, to see if an output was found, and then advance K if so.
this is done for every step of sloppier_H, so therefore run head to
head, anti_sloppier_H will output slower than sloppier_H.
in fact, anti_sloppier_H cannot output a digit for a particular K
until /after/ sloppier_H outputs a digit for that particular K...
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at least a
K+1 digit,
meaning sloppier_H will never put anti_sloppier_H on the diagonal
it is therefore _not_ possible to effectively enumerate _all machines_ ,
in direct contradiction to the obviously effective enumerability used to create sloppier_H in the first place
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a smarter TM >>>>>>>> diagonal across the circle-free computable numbers that defeats >>>>>>>> all variants of anti_fixed_H,
Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version of that >>>>>>>> diagonal, one that includes some circular numbers as well. for >>>>>>>> this i will introduce a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free machines, >>>>>>> then the enumeration of the "computable numbers" it generates
isn't valid, as the array of values has holes in it.
it's not an enumeration of computable numbers, it's a superset of >>>>>> said enumeration that includes some "circular" machines, but
should include all computable numbers
No, it is a decider that enumerates machines that is supposed to
generate that, but then a machine that tries to use it to enumerate >>>>> all enumerable numbers will hang and not generate the enumeration.
Again, what good is this "incorrect" enumeration for getting you to >>>>> the goal of showing how to compute an enumeration of all computable >>>>> numbers.
Note, because the set of "computable numbers" are (as you have
pointed out) NOT the same machines that compute them, Your "super
set" as described isn't a set of one sort of thing, and is actually >>>>> (as I just described) a set of MACHINES that compute computable
numbers + some machines that are circular.
The presence of the circular machines in the set means you can't
use that set to compute the computable numbers, as you process will >>>>> hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to the
enumeration of non-circular machines, as they are easier to talk
about processing, as they are finite things, while the elements of
the computable numbers are not, and if you try to talk about using
ONE machine that generates it, you have the problem of selecting
that one machine from the infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on the >>>>>>> "diagonal" a spot where the kth machine in the list doesn't
generate k digits of output, because it was one of those non-
circle-free machines accepted that got stuck too early.
we can avoid that using a stepping simulation while dovetailing:
Nope.
your step_deect_loop might not return anything for all machines, as >>>>> not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow over
time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to find >>>>> the first even number that can't be found as the sum of two prime,
will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation,
kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>> }
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time >>>>>> if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>>> }
loop detection happens in two cases:
1) if a circular machine is detected when a configuration is >>>>>>>> reached twice
2) if a circular recursion is detected when a simulated
machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular condition >>>>>>> when simulating a machine, but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if circular machines >>>>>> end up on the list
And why can't that same program be used to compute the sloppy-anti- >>>>> diagonal (where you still test the M with DN(sloppy_H) not changing >>>>> that, and then reverse the output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- program
does EXACTLY the same steps it will also create an anti-diagonal,
which could not have been from a machine in the listing, thus
showing your enumation doesn't include ALL machines for ALL the
computable numbers.
i guess at this point there's little point to even try to filter
out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output
}
every time step is called it advances the machine's runtime,
recording any output alone the way. after the step is complete, if >>>>>> the Kth output has been recorded already it will output that.
however if the Kth output has not already been output by the
machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm kinda
guessing at the moment that the K within sloppier_H grows faster
than the K within anti_sloppier_H and therefore sloppier_H will
just never actually output a digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of
sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect
anything, it still existed as the code for the machine with its number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly run
behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra
steps for each cycle K ... mean sloppier_H's K _must_ grow faster
than anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H because
it needs to check the output of after each step of sloppier_H, to see
if an output was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to anti-sloppier_H
this is done for every step of sloppier_H, so therefore run head to
head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular K
until /after/ sloppier_H outputs a digit for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY follow the
behavior of sloppier_H (even though at a slower rate) and will EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at least a
K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the diagonal
Right.
But since anti-sloppier_H WILL fully output a computable number, at
least as long as your sloppier_H outputs a computable number as the diagonal, it needed to in order for the diagonal to be of a complete enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches the anti-diagonal computed by anti-slippier-H, and thus the computable
number it computes can't be in the enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective
enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be
complete, and thus isn't a effetive enumeration of a super-set of
machine the of at least one machine the computes every computable number.
You seem to have forgotten your own requirement that the enumeration was
to include at least one machine that computes every computable number.
Yes, there are many computably enumerated SUB-sets of the computable numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means to be correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing code
that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
I have shown a way to build a computable number that you enumeration
doesn't include, and thus it can't be a complete enumeration, as you
claim it is supposedly by some "magic" assumptions.
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a smarter TM >>>>>>>>> diagonal across the circle-free computable numbers that defeats >>>>>>>>> all variants of anti_fixed_H,
Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version of that >>>>>>>>> diagonal, one that includes some circular numbers as well. for >>>>>>>>> this i will introduce a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free
machines, then the enumeration of the "computable numbers" it >>>>>>>> generates isn't valid, as the array of values has holes in it.
it's not an enumeration of computable numbers, it's a superset of >>>>>>> said enumeration that includes some "circular" machines, but
should include all computable numbers
No, it is a decider that enumerates machines that is supposed to
generate that, but then a machine that tries to use it to
enumerate all enumerable numbers will hang and not generate the
enumeration.
Again, what good is this "incorrect" enumeration for getting you
to the goal of showing how to compute an enumeration of all
computable numbers.
Note, because the set of "computable numbers" are (as you have
pointed out) NOT the same machines that compute them, Your "super >>>>>> set" as described isn't a set of one sort of thing, and is
actually (as I just described) a set of MACHINES that compute
computable numbers + some machines that are circular.
The presence of the circular machines in the set means you can't
use that set to compute the computable numbers, as you process
will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to the
enumeration of non-circular machines, as they are easier to talk
about processing, as they are finite things, while the elements of >>>>>> the computable numbers are not, and if you try to talk about using >>>>>> ONE machine that generates it, you have the problem of selecting
that one machine from the infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on the >>>>>>>> "diagonal" a spot where the kth machine in the list doesn't
generate k digits of output, because it was one of those non- >>>>>>>> circle-free machines accepted that got stuck too early.
we can avoid that using a stepping simulation while dovetailing:
Nope.
your step_deect_loop might not return anything for all machines,
as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow over >>>>>> time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to
find the first even number that can't be found as the sum of two
prime, will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>> }
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time >>>>>>> if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>>>> }
loop detection happens in two cases:
1) if a circular machine is detected when a configuration is >>>>>>>>> reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular condition >>>>>>>> when simulating a machine, but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if circular machines >>>>>>> end up on the list
And why can't that same program be used to compute the sloppy-
anti- diagonal (where you still test the M with DN(sloppy_H) not
changing that, and then reverse the output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- program
does EXACTLY the same steps it will also create an anti-diagonal, >>>>>> which could not have been from a machine in the listing, thus
showing your enumation doesn't include ALL machines for ALL the
computable numbers.
i guess at this point there's little point to even try to filter >>>>>>> out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output
}
every time step is called it advances the machine's runtime,
recording any output alone the way. after the step is complete, >>>>>>> if the Kth output has been recorded already it will output that. >>>>>>> however if the Kth output has not already been output by the
machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm kinda >>>>>>> guessing at the moment that the K within sloppier_H grows faster >>>>>>> than the K within anti_sloppier_H and therefore sloppier_H will >>>>>>> just never actually output a digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of
sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect
anything, it still existed as the code for the machine with its number. >>>>
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly run >>>>> behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra
steps for each cycle K ... mean sloppier_H's K _must_ grow faster
than anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H because
it needs to check the output of after each step of sloppier_H, to see
if an output was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to anti-sloppier_H
this is done for every step of sloppier_H, so therefore run head to
head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular K
until /after/ sloppier_H outputs a digit for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY follow the
behavior of sloppier_H (even though at a slower rate) and will EXAXTLY
output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at least
a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the diagonal
Right.
yup
But since anti-sloppier_H WILL fully output a computable number, at
least as long as your sloppier_H outputs a computable number as the
diagonal, it needed to in order for the diagonal to be of a complete
enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches the
anti-diagonal computed by anti-slippier-H, and thus the computable
number it computes can't be in the enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective
enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be
complete, and thus isn't a effetive enumeration of a super-set of
machine the of at least one machine the computes every computable number.
You seem to have forgotten your own requirement that the enumeration
was to include at least one machine that computes every computable
number.
Yes, there are many computably enumerated SUB-sets of the computable
numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means to be
correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing code
that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
i'm not selecting for anything in particular, i'm just running any
whatever machine that we come across, and trying to put it on a diagonal
I have shown a way to build a computable number that you enumeration
doesn't include, and thus it can't be a complete enumeration, as you
claim it is supposedly by some "magic" assumptions.
u don't really seem aware of where we've ended up:
disproving an ability to enumerate _not_ just computable numbers, but actually _all machines_
which is a contradiction to the premise used to construct the machine in
the first place
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:it's not an enumeration of computable numbers, it's a superset >>>>>>>> of said enumeration that includes some "circular" machines, but >>>>>>>> should include all computable numbers
after getting a lil stuck on trying to construct a smarter TM >>>>>>>>>> diagonal across the circle-free computable numbers that
defeats all variants of anti_fixed_H,
Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version of that >>>>>>>>>> diagonal, one that includes some circular numbers as well. for >>>>>>>>>> this i will introduce a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free
machines, then the enumeration of the "computable numbers" it >>>>>>>>> generates isn't valid, as the array of values has holes in it. >>>>>>>>
No, it is a decider that enumerates machines that is supposed to >>>>>>> generate that, but then a machine that tries to use it to
enumerate all enumerable numbers will hang and not generate the >>>>>>> enumeration.
Again, what good is this "incorrect" enumeration for getting you >>>>>>> to the goal of showing how to compute an enumeration of all
computable numbers.
Note, because the set of "computable numbers" are (as you have >>>>>>> pointed out) NOT the same machines that compute them, Your "super >>>>>>> set" as described isn't a set of one sort of thing, and is
actually (as I just described) a set of MACHINES that compute
computable numbers + some machines that are circular.
The presence of the circular machines in the set means you can't >>>>>>> use that set to compute the computable numbers, as you process
will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to the
enumeration of non-circular machines, as they are easier to talk >>>>>>> about processing, as they are finite things, while the elements >>>>>>> of the computable numbers are not, and if you try to talk about >>>>>>> using ONE machine that generates it, you have the problem of
selecting that one machine from the infinite set that generates it. >>>>>>>
Nope.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on >>>>>>>>> the "diagonal" a spot where the kth machine in the list doesn't >>>>>>>>> generate k digits of output, because it was one of those non- >>>>>>>>> circle-free machines accepted that got stuck too early.
we can avoid that using a stepping simulation while dovetailing: >>>>>>>
your step_deect_loop might not return anything for all machines, >>>>>>> as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow over >>>>>>> time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to
find the first even number that can't be found as the sum of two >>>>>>> prime, will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>>> }
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time
if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>>>>> }
loop detection happens in two cases:
1) if a circular machine is detected when a configuration is >>>>>>>>>> reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular condition >>>>>>>>> when simulating a machine, but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if circular
machines end up on the list
And why can't that same program be used to compute the sloppy-
anti- diagonal (where you still test the M with DN(sloppy_H) not >>>>>>> changing that, and then reverse the output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- program >>>>>>> does EXACTLY the same steps it will also create an anti-diagonal, >>>>>>> which could not have been from a machine in the listing, thus
showing your enumation doesn't include ALL machines for ALL the >>>>>>> computable numbers.
i guess at this point there's little point to even try to filter >>>>>>>> out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>> }
every time step is called it advances the machine's runtime,
recording any output alone the way. after the step is complete, >>>>>>>> if the Kth output has been recorded already it will output that. >>>>>>>> however if the Kth output has not already been output by the
machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm kinda >>>>>>>> guessing at the moment that the K within sloppier_H grows faster >>>>>>>> than the K within anti_sloppier_H and therefore sloppier_H will >>>>>>>> just never actually output a digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of
sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect
anything, it still existed as the code for the machine with its
number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly
run behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra
steps for each cycle K ... mean sloppier_H's K _must_ grow faster >>>>>> than anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H because
it needs to check the output of after each step of sloppier_H, to
see if an output was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to anti-sloppier_H
this is done for every step of sloppier_H, so therefore run head to
head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular K
until /after/ sloppier_H outputs a digit for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY follow the
behavior of sloppier_H (even though at a slower rate) and will
EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at least
a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't include the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be correct.
But since anti-sloppier_H WILL fully output a computable number, at
least as long as your sloppier_H outputs a computable number as the
diagonal, it needed to in order for the diagonal to be of a complete
enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches the
anti-diagonal computed by anti-slippier-H, and thus the computable
number it computes can't be in the enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective
enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be
complete, and thus isn't a effetive enumeration of a super-set of
machine the of at least one machine the computes every computable
number.
You seem to have forgotten your own requirement that the enumeration
was to include at least one machine that computes every computable
number.
Yes, there are many computably enumerated SUB-sets of the computable
numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means to be
correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing
code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
But that was the problem you were trying to solve.
i'm not selecting for anything in particular, i'm just running any
whatever machine that we come across, and trying to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to play in
your garbage.
Did you forget, that you started by saying, lets allow D to not select
EVERY non-circular machine, just it needs to select at least one for
each computable number.
The computable number of the anti-diagonal isn't in the set of numbers
your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem, because
you attention span is apparently to short to take it to a finish line.
I have shown a way to build a computable number that you enumeration
doesn't include, and thus it can't be a complete enumeration, as you
claim it is supposedly by some "magic" assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem you are working on because you are just fundamentally ignorant of what you are talking about.
disproving an ability to enumerate _not_ just computable numbers, but
actually _all machines_
But "All Machines" are enumerable.
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:anti_sloppier_H takes more steps for each step of sloppier_H
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:it's not an enumeration of computable numbers, it's a superset >>>>>>>>> of said enumeration that includes some "circular" machines, but >>>>>>>>> should include all computable numbers
after getting a lil stuck on trying to construct a smarter TM >>>>>>>>>>> diagonal across the circle-free computable numbers that >>>>>>>>>>> defeats all variants of anti_fixed_H,
Because you can't, since it isn't computable.
And what good is such a enumeration?
i’d like to try playing around with a sloppier version of >>>>>>>>>>> that diagonal, one that includes some circular numbers as >>>>>>>>>>> well. for this i will introduce a new simulation machine: >>>>>>>>>>
Note, if your enumeration includes some non-circle-free
machines, then the enumeration of the "computable numbers" it >>>>>>>>>> generates isn't valid, as the array of values has holes in it. >>>>>>>>>
No, it is a decider that enumerates machines that is supposed to >>>>>>>> generate that, but then a machine that tries to use it to
enumerate all enumerable numbers will hang and not generate the >>>>>>>> enumeration.
Again, what good is this "incorrect" enumeration for getting you >>>>>>>> to the goal of showing how to compute an enumeration of all
computable numbers.
Note, because the set of "computable numbers" are (as you have >>>>>>>> pointed out) NOT the same machines that compute them, Your
"super set" as described isn't a set of one sort of thing, and >>>>>>>> is actually (as I just described) a set of MACHINES that compute >>>>>>>> computable numbers + some machines that are circular.
The presence of the circular machines in the set means you can't >>>>>>>> use that set to compute the computable numbers, as you process >>>>>>>> will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to the >>>>>>>> enumeration of non-circular machines, as they are easier to talk >>>>>>>> about processing, as they are finite things, while the elements >>>>>>>> of the computable numbers are not, and if you try to talk about >>>>>>>> using ONE machine that generates it, you have the problem of
selecting that one machine from the infinite set that generates it. >>>>>>>>
Nope.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on >>>>>>>>>> the "diagonal" a spot where the kth machine in the list
doesn't generate k digits of output, because it was one of >>>>>>>>>> those non- circle-free machines accepted that got stuck too >>>>>>>>>> early.
we can avoid that using a stepping simulation while dovetailing: >>>>>>>>
your step_deect_loop might not return anything for all machines, >>>>>>>> as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow
over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to >>>>>>>> find the first even number that can't be found as the sum of two >>>>>>>> prime, will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>>>> }
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time
if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this
machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks
stepping
list.push(m)
}
M += 1
}
}
this is the sloppy diagonal, it doesn't care if circular
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>> before a loop is detected, >>>>>>>>>>> }
loop detection happens in two cases:
1) if a circular machine is detected when a configuration >>>>>>>>>>> is reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular
condition when simulating a machine, but it hasn't halted yet. >>>>>>>>>
machines end up on the list
And why can't that same program be used to compute the sloppy- >>>>>>>> anti- diagonal (where you still test the M with DN(sloppy_H) not >>>>>>>> changing that, and then reverse the output of the two outputs. >>>>>>>>
If your sloppy_H produces a diagonal, because the anti- program >>>>>>>> does EXACTLY the same steps it will also create an anti-
diagonal, which could not have been from a machine in the
listing, thus showing your enumation doesn't include ALL
machines for ALL the computable numbers.
i guess at this point there's little point to even try to
filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>> }
every time step is called it advances the machine's runtime, >>>>>>>>> recording any output alone the way. after the step is complete, >>>>>>>>> if the Kth output has been recorded already it will output
that. however if the Kth output has not already been output by >>>>>>>>> the machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm
kinda guessing at the moment that the K within sloppier_H grows >>>>>>>>> faster than the K within anti_sloppier_H and therefore
sloppier_H will just never actually output a digit from
anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of
sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect
anything, it still existed as the code for the machine with its
number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly >>>>>>> run behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra >>>>>>> steps for each cycle K ... mean sloppier_H's K _must_ grow faster >>>>>>> than anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H. >>>>>
because it needs to check the output of after each step of
sloppier_H, to see if an output was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to anti-sloppier_H >>>>
this is done for every step of sloppier_H, so therefore run head to >>>>> head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular K
until /after/ sloppier_H outputs a digit for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY follow the
behavior of sloppier_H (even though at a slower rate) and will
EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at
least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't include the
required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be correct.
But since anti-sloppier_H WILL fully output a computable number, at
least as long as your sloppier_H outputs a computable number as the
diagonal, it needed to in order for the diagonal to be of a complete
enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches the
anti-diagonal computed by anti-slippier-H, and thus the computable
number it computes can't be in the enumeration that it is working from. >>>>
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective
enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be
complete, and thus isn't a effetive enumeration of a super-set of
machine the of at least one machine the computes every computable
number.
You seem to have forgotten your own requirement that the enumeration
was to include at least one machine that computes every computable
number.
Yes, there are many computably enumerated SUB-sets of the computable
numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means to
be correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing
code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
i'm not selecting for anything in particular, i'm just running any
whatever machine that we come across, and trying to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to play
in your garbage.
Did you forget, that you started by saying, lets allow D to not select
EVERY non-circular machine, just it needs to select at least one for
each computable number.
The computable number of the anti-diagonal isn't in the set of numbers
your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem,
because you attention span is apparently to short to take it to a
finish line.
the process of innovation is inherently serendipitous, rick
I have shown a way to build a computable number that you enumeration
doesn't include, and thus it can't be a complete enumeration, as you
claim it is supposedly by some "magic" assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem you
are working on because you are just fundamentally ignorant of what you
are talking about.
sloppier_H is not selecting for or even attempting to select for
"computable sequences"
disproving an ability to enumerate _not_ just computable numbers, but
actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of some form...
yet we're stuck with machines that cannot be put on the diagonal,
therefor _all machines_ is not effectively enumerable
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:So?
On 3/28/26 8:37 PM, dart200 wrote:anti_sloppier_H takes more steps for each step of sloppier_H
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:it's not an enumeration of computable numbers, it's a superset >>>>>>>>>> of said enumeration that includes some "circular" machines, >>>>>>>>>> but should include all computable numbers
after getting a lil stuck on trying to construct a smarter >>>>>>>>>>>> TM diagonal across the circle-free computable numbers that >>>>>>>>>>>> defeats all variants of anti_fixed_H,
Because you can't, since it isn't computable.
And what good is such a enumeration?
i’d like to try playing around with a sloppier version of >>>>>>>>>>>> that diagonal, one that includes some circular numbers as >>>>>>>>>>>> well. for this i will introduce a new simulation machine: >>>>>>>>>>>
Note, if your enumeration includes some non-circle-free >>>>>>>>>>> machines, then the enumeration of the "computable numbers" it >>>>>>>>>>> generates isn't valid, as the array of values has holes in it. >>>>>>>>>>
No, it is a decider that enumerates machines that is supposed >>>>>>>>> to generate that, but then a machine that tries to use it to >>>>>>>>> enumerate all enumerable numbers will hang and not generate the >>>>>>>>> enumeration.
Again, what good is this "incorrect" enumeration for getting >>>>>>>>> you to the goal of showing how to compute an enumeration of all >>>>>>>>> computable numbers.
Note, because the set of "computable numbers" are (as you have >>>>>>>>> pointed out) NOT the same machines that compute them, Your
"super set" as described isn't a set of one sort of thing, and >>>>>>>>> is actually (as I just described) a set of MACHINES that
compute computable numbers + some machines that are circular. >>>>>>>>>
The presence of the circular machines in the set means you
can't use that set to compute the computable numbers, as you >>>>>>>>> process will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to the >>>>>>>>> enumeration of non-circular machines, as they are easier to >>>>>>>>> talk about processing, as they are finite things, while the >>>>>>>>> elements of the computable numbers are not, and if you try to >>>>>>>>> talk about using ONE machine that generates it, you have the >>>>>>>>> problem of selecting that one machine from the infinite set >>>>>>>>> that generates it.
Nope.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on >>>>>>>>>>> the "diagonal" a spot where the kth machine in the list >>>>>>>>>>> doesn't generate k digits of output, because it was one of >>>>>>>>>>> those non- circle-free machines accepted that got stuck too >>>>>>>>>>> early.
we can avoid that using a stepping simulation while dovetailing: >>>>>>>>>
your step_deect_loop might not return anything for all
machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow >>>>>>>>> over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to >>>>>>>>> find the first even number that can't be found as the sum of >>>>>>>>> two prime, will run forever but never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>>>> kth digit of M: if the Kth digit of M is reached
before a loop is detected, >>>>>>>>>> }
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time
if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this
machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks
stepping
list.push(m)
}
M += 1
}
}
this is the sloppy diagonal, it doesn't care if circular
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a configuration >>>>>>>>>>>> is reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular
condition when simulating a machine, but it hasn't halted yet. >>>>>>>>>>
machines end up on the list
And why can't that same program be used to compute the sloppy- >>>>>>>>> anti- diagonal (where you still test the M with DN(sloppy_H) >>>>>>>>> not changing that, and then reverse the output of the two outputs. >>>>>>>>>
If your sloppy_H produces a diagonal, because the anti- program >>>>>>>>> does EXACTLY the same steps it will also create an anti-
diagonal, which could not have been from a machine in the
listing, thus showing your enumation doesn't include ALL
machines for ALL the computable numbers.
i guess at this point there's little point to even try to >>>>>>>>>> filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>> }
every time step is called it advances the machine's runtime, >>>>>>>>>> recording any output alone the way. after the step is
complete, if the Kth output has been recorded already it will >>>>>>>>>> output that. however if the Kth output has not already been >>>>>>>>>> output by the machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm >>>>>>>>>> kinda guessing at the moment that the K within sloppier_H >>>>>>>>>> grows faster than the K within anti_sloppier_H and therefore >>>>>>>>>> sloppier_H will just never actually output a digit from
anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of >>>>>>>> sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect
anything, it still existed as the code for the machine with its >>>>>>> number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly >>>>>>>> run behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with extra >>>>>>>> steps for each cycle K ... mean sloppier_H's K _must_ grow
faster than anti_sloppier_H even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps of sloppier_H. >>>>>>
because it needs to check the output of after each step of
sloppier_H, to see if an output was found, and then advance K if so. >>>>>
That doesn't affect the answer that sloppier_H gives to anti-
sloppier_H
this is done for every step of sloppier_H, so therefore run head
to head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular K >>>>>> until /after/ sloppier_H outputs a digit for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY follow the >>>>> behavior of sloppier_H (even though at a slower rate) and will
EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at
least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't include the
required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be correct.
But since anti-sloppier_H WILL fully output a computable number, at >>>>> least as long as your sloppier_H outputs a computable number as the >>>>> diagonal, it needed to in order for the diagonal to be of a
complete enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches the >>>>> anti-diagonal computed by anti-slippier-H, and thus the computable
number it computes can't be in the enumeration that it is working
from.
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective
enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be
complete, and thus isn't a effetive enumeration of a super-set of
machine the of at least one machine the computes every computable
number.
You seem to have forgotten your own requirement that the
enumeration was to include at least one machine that computes every >>>>> computable number.
Yes, there are many computably enumerated SUB-sets of the
computable numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means to
be correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing
code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't
compute the diagonal of an enumeration that includes all computable
numbers? (which is at least close to what Turing was talking about).
Computing the diagonal of a comuptable enumeration that is admittedly containing only a subset of the computable numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow yourself to just wonder off into uninteresting problems with no attempt to justify why
they might be interesting because you are doing them better that how
they have been done before, you are just wasting everyone's time.
i'm not selecting for anything in particular, i'm just running any
whatever machine that we come across, and trying to put it on a
diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to play
in your garbage.
Did you forget, that you started by saying, lets allow D to not
select EVERY non-circular machine, just it needs to select at least
one for each computable number.
The computable number of the anti-diagonal isn't in the set of
numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem,
because you attention span is apparently to short to take it to a
finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative areas,
you can waste a LOT of time.
Again, it seems you don't care if you work can actually be useful, as
you seem to accept that it is ok to spend a lot of time in mundane
problems with known solutions, while also adding in booby-traps (like accepting circular machines into your enumeration) that makes
quantifying what you are doing nearly impossible.
I have shown a way to build a computable number that you
enumeration doesn't include, and thus it can't be a complete
enumeration, as you claim it is supposedly by some "magic"
assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem you
are working on because you are just fundamentally ignorant of what
you are talking about.
sloppier_H is not selecting for or even attempting to select for
"computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you description of what the based decider is doing by trying to filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable numbers,
but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of some
form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the diagonal,
therefor _all machines_ is not effectively enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, doesn't mean
we can "compute the diagonal" of the output of all machines, as some
machines don't have there output reach the diagonal, since "all
machines" include circular machines that only output a finite number of digits, so "the diagonal" doesn't exist.
And we can't even say, extending the circular machine output with some symbol, as THAT operation is the equivalent of the halting problem and
is uncomputable.
Your logic seems to be based on "gut feelings" and you have a poorly
tuned gut. You like to talk about what "should" be able to be done, yet can't actually justify why you should be, it all comes out of your
ignorance and inability to actually reason about what you are talking
about.
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:So?
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a smarter >>>>>>>>>>>>> TM diagonal across the circle-free computable numbers that >>>>>>>>>>>>> defeats all variants of anti_fixed_H,
Because you can't, since it isn't computable.
And what good is such a enumeration?
i’d like to try playing around with a sloppier version of >>>>>>>>>>>>> that diagonal, one that includes some circular numbers as >>>>>>>>>>>>> well. for this i will introduce a new simulation machine: >>>>>>>>>>>>
Note, if your enumeration includes some non-circle-free >>>>>>>>>>>> machines, then the enumeration of the "computable numbers" >>>>>>>>>>>> it generates isn't valid, as the array of values has holes >>>>>>>>>>>> in it.
it's not an enumeration of computable numbers, it's a
superset of said enumeration that includes some "circular" >>>>>>>>>>> machines, but should include all computable numbers
No, it is a decider that enumerates machines that is supposed >>>>>>>>>> to generate that, but then a machine that tries to use it to >>>>>>>>>> enumerate all enumerable numbers will hang and not generate >>>>>>>>>> the enumeration.
Again, what good is this "incorrect" enumeration for getting >>>>>>>>>> you to the goal of showing how to compute an enumeration of >>>>>>>>>> all computable numbers.
Note, because the set of "computable numbers" are (as you >>>>>>>>>> have pointed out) NOT the same machines that compute them, >>>>>>>>>> Your "super set" as described isn't a set of one sort of
thing, and is actually (as I just described) a set of MACHINES >>>>>>>>>> that compute computable numbers + some machines that are
circular.
The presence of the circular machines in the set means you >>>>>>>>>> can't use that set to compute the computable numbers, as you >>>>>>>>>> process will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to the >>>>>>>>>> enumeration of non-circular machines, as they are easier to >>>>>>>>>> talk about processing, as they are finite things, while the >>>>>>>>>> elements of the computable numbers are not, and if you try to >>>>>>>>>> talk about using ONE machine that generates it, you have the >>>>>>>>>> problem of selecting that one machine from the infinite set >>>>>>>>>> that generates it.
Nope.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere on >>>>>>>>>>>> the "diagonal" a spot where the kth machine in the list >>>>>>>>>>>> doesn't generate k digits of output, because it was one of >>>>>>>>>>>> those non- circle-free machines accepted that got stuck too >>>>>>>>>>>> early.
we can avoid that using a stepping simulation while dovetailing: >>>>>>>>>>
your step_deect_loop might not return anything for all
machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow >>>>>>>>>> over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program to >>>>>>>>>> find the first even number that can't be found as the sum of >>>>>>>>>> two prime, will run forever but never hit a repeated state. >>>>>>>>>>
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>> before a loop is detected, >>>>>>>>>>> }
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time
if (res == STEP) {
continue
} // outputs other than STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this
machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks
stepping
list.push(m)
}
M += 1
}
}
this is the sloppy diagonal, it doesn't care if circular >>>>>>>>>>> machines end up on the list
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a configuration >>>>>>>>>>>>> is reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>> condition when simulating a machine, but it hasn't halted yet. >>>>>>>>>>>
And why can't that same program be used to compute the sloppy- >>>>>>>>>> anti- diagonal (where you still test the M with DN(sloppy_H) >>>>>>>>>> not changing that, and then reverse the output of the two >>>>>>>>>> outputs.
If your sloppy_H produces a diagonal, because the anti-
program does EXACTLY the same steps it will also create an >>>>>>>>>> anti- diagonal, which could not have been from a machine in >>>>>>>>>> the listing, thus showing your enumation doesn't include ALL >>>>>>>>>> machines for ALL the computable numbers.
i guess at this point there's little point to even try to >>>>>>>>>>> filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>>> }
every time step is called it advances the machine's runtime, >>>>>>>>>>> recording any output alone the way. after the step is
complete, if the Kth output has been recorded already it will >>>>>>>>>>> output that. however if the Kth output has not already been >>>>>>>>>>> output by the machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm >>>>>>>>>>> kinda guessing at the moment that the K within sloppier_H >>>>>>>>>>> grows faster than the K within anti_sloppier_H and therefore >>>>>>>>>>> sloppier_H will just never actually output a digit from >>>>>>>>>>> anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of >>>>>>>>> sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect >>>>>>>> anything, it still existed as the code for the machine with its >>>>>>>> number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will constantly >>>>>>>>> run behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with
extra steps for each cycle K ... mean sloppier_H's K _must_ >>>>>>>>> grow faster than anti_sloppier_H even when run directly in
parallel
No, it is supposed to be EXACTLY simulating the steps of
sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H
because it needs to check the output of after each step of
sloppier_H, to see if an output was found, and then advance K if so. >>>>>>
That doesn't affect the answer that sloppier_H gives to anti-
sloppier_H
this is done for every step of sloppier_H, so therefore run head >>>>>>> to head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular K >>>>>>> until /after/ sloppier_H outputs a digit for that particular K... >>>>>>Right. and the execution of anti-sloppier_H will EXACTLY follow
the behavior of sloppier_H (even though at a slower rate) and will >>>>>> EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some
particular K until after sloppier_H has started looking for at
least a K+1 digit,
So?
Right.
meaning sloppier_H will never put anti_sloppier_H on the diagonal >>>>>>
yup
And thus, your diagonal that you claim to compute doesn't include
the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be correct.
But since anti-sloppier_H WILL fully output a computable number,
at least as long as your sloppier_H outputs a computable number as >>>>>> the diagonal, it needed to in order for the diagonal to be of a
complete enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches
the anti-diagonal computed by anti-slippier-H, and thus the
computable number it computes can't be in the enumeration that it >>>>>> is working from.
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective
enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be
complete, and thus isn't a effetive enumeration of a super-set of >>>>>> machine the of at least one machine the computes every computable >>>>>> number.
You seem to have forgotten your own requirement that the
enumeration was to include at least one machine that computes
every computable number.
Yes, there are many computably enumerated SUB-sets of the
computable numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means to >>>>>> be correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing >>>>>> code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't
compute the diagonal of an enumeration that includes all computable
numbers? (which is at least close to what Turing was talking about).
Computing the diagonal of a comuptable enumeration that is admittedly
containing only a subset of the computable numbers is just not
interesting.
Again, as I pointed out a long time ago, if you allow yourself to just
wonder off into uninteresting problems with no attempt to justify why
they might be interesting because you are doing them better that how
they have been done before, you are just wasting everyone's time.
i'm not selecting for anything in particular, i'm just running any
whatever machine that we come across, and trying to put it on a
diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to play
in your garbage.
Did you forget, that you started by saying, lets allow D to not
select EVERY non-circular machine, just it needs to select at least
one for each computable number.
The computable number of the anti-diagonal isn't in the set of
numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem,
because you attention span is apparently to short to take it to a
finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative areas,
you can waste a LOT of time.
god only knows what u think ur doing
Again, it seems you don't care if you work can actually be useful, as
you seem to accept that it is ok to spend a lot of time in mundane
problems with known solutions, while also adding in booby-traps (like
accepting circular machines into your enumeration) that makes
quantifying what you are doing nearly impossible.
I have shown a way to build a computable number that you
enumeration doesn't include, and thus it can't be a complete
enumeration, as you claim it is supposedly by some "magic"
assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem you
are working on because you are just fundamentally ignorant of what
you are talking about.
sloppier_H is not selecting for or even attempting to select for
"computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you description
of what the based decider is doing by trying to filter out inputs that
hit repeat state.
disproving an ability to enumerate _not_ just computable numbers,
but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of
some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the diagonal,
therefor _all machines_ is not effectively enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, doesn't
mean we can "compute the diagonal" of the output of all machines, as some
if i mean if machine enumerability _does not imply_ being able to
compute a diagonal across the machines being enumerated,
ei: if enumerability of a set of machines is independent from being able
to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove a lack
of enumerability, and u've lost turing's proof against the enumerability
of computable numbers
machines don't have there output reach the diagonal, since "all
machines" include circular machines that only output a finite number
of digits, so "the diagonal" doesn't exist.
And we can't even say, extending the circular machine output with some
symbol, as THAT operation is the equivalent of the halting problem and
is uncomputable.
clearly if we're not specifically selecting for computable numbers, just simulating every machine independently ...
certainly we should be able to create a diagonal from that
Your logic seems to be based on "gut feelings" and you have a poorly
tuned gut. You like to talk about what "should" be able to be done,
yet can't actually justify why you should be, it all comes out of your
ignorance and inability to actually reason about what you are talking
about.
u too rick
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a smarter >>>>>>>>>>>>>> TM diagonal across the circle-free computable numbers that >>>>>>>>>>>>>> defeats all variants of anti_fixed_H,
Because you can't, since it isn't computable.
And what good is such a enumeration?
i’d like to try playing around with a sloppier version of >>>>>>>>>>>>>> that diagonal, one that includes some circular numbers as >>>>>>>>>>>>>> well. for this i will introduce a new simulation machine: >>>>>>>>>>>>>
Note, if your enumeration includes some non-circle-free >>>>>>>>>>>>> machines, then the enumeration of the "computable numbers" >>>>>>>>>>>>> it generates isn't valid, as the array of values has holes >>>>>>>>>>>>> in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>> superset of said enumeration that includes some "circular" >>>>>>>>>>>> machines, but should include all computable numbers
No, it is a decider that enumerates machines that is supposed >>>>>>>>>>> to generate that, but then a machine that tries to use it to >>>>>>>>>>> enumerate all enumerable numbers will hang and not generate >>>>>>>>>>> the enumeration.
Again, what good is this "incorrect" enumeration for getting >>>>>>>>>>> you to the goal of showing how to compute an enumeration of >>>>>>>>>>> all computable numbers.
Note, because the set of "computable numbers" are (as you >>>>>>>>>>> have pointed out) NOT the same machines that compute them, >>>>>>>>>>> Your "super set" as described isn't a set of one sort of >>>>>>>>>>> thing, and is actually (as I just described) a set of
MACHINES that compute computable numbers + some machines that >>>>>>>>>>> are circular.
The presence of the circular machines in the set means you >>>>>>>>>>> can't use that set to compute the computable numbers, as you >>>>>>>>>>> process will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to >>>>>>>>>>> the enumeration of non-circular machines, as they are easier >>>>>>>>>>> to talk about processing, as they are finite things, while >>>>>>>>>>> the elements of the computable numbers are not, and if you >>>>>>>>>>> try to talk about using ONE machine that generates it, you >>>>>>>>>>> have the problem of selecting that one machine from the >>>>>>>>>>> infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere >>>>>>>>>>>>> on the "diagonal" a spot where the kth machine in the list >>>>>>>>>>>>> doesn't generate k digits of output, because it was one of >>>>>>>>>>>>> those non- circle-free machines accepted that got stuck too >>>>>>>>>>>>> early.
we can avoid that using a stepping simulation while
dovetailing:
Nope.
your step_deect_loop might not return anything for all
machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow >>>>>>>>>>> over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program >>>>>>>>>>> to find the first even number that can't be found as the sum >>>>>>>>>>> of two prime, will run forever but never hit a repeated state. >>>>>>>>>>>
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a time
if (res == STEP) {
continue
} // outputs other than
STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this
machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks
stepping
list.push(m)
}
M += 1
}
}
this is the sloppy diagonal, it doesn't care if circular >>>>>>>>>>>> machines end up on the list
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a
configuration is reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>> condition when simulating a machine, but it hasn't halted yet. >>>>>>>>>>>>
And why can't that same program be used to compute the
sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the output >>>>>>>>>>> of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>> program does EXACTLY the same steps it will also create an >>>>>>>>>>> anti- diagonal, which could not have been from a machine in >>>>>>>>>>> the listing, thus showing your enumation doesn't include ALL >>>>>>>>>>> machines for ALL the computable numbers.
i guess at this point there's little point to even try to >>>>>>>>>>>> filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>>>> }
every time step is called it advances the machine's runtime, >>>>>>>>>>>> recording any output alone the way. after the step is >>>>>>>>>>>> complete, if the Kth output has been recorded already it >>>>>>>>>>>> will output that. however if the Kth output has not already >>>>>>>>>>>> been output by the machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to
anti_sloppier_H when sloppier_H starts dovetailing it. i'm >>>>>>>>>>>> kinda guessing at the moment that the K within sloppier_H >>>>>>>>>>>> grows faster than the K within anti_sloppier_H and therefore >>>>>>>>>>>> sloppier_H will just never actually output a digit from >>>>>>>>>>>> anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of >>>>>>>>>> sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect >>>>>>>>> anything, it still existed as the code for the machine with its >>>>>>>>> number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will
constantly run behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with >>>>>>>>>> extra steps for each cycle K ... mean sloppier_H's K _must_ >>>>>>>>>> grow faster than anti_sloppier_H even when run directly in >>>>>>>>>> parallel
No, it is supposed to be EXACTLY simulating the steps of
sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H
because it needs to check the output of after each step of
sloppier_H, to see if an output was found, and then advance K if >>>>>>>> so.
So?
That doesn't affect the answer that sloppier_H gives to anti-
sloppier_H
this is done for every step of sloppier_H, so therefore run head >>>>>>>> to head, anti_sloppier_H will output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular >>>>>>>> K until /after/ sloppier_H outputs a digit for that particular K... >>>>>>>Right. and the execution of anti-sloppier_H will EXACTLY follow >>>>>>> the behavior of sloppier_H (even though at a slower rate) and
will EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some >>>>>>>> particular K until after sloppier_H has started looking for at >>>>>>>> least a K+1 digit,
So?
Right.
meaning sloppier_H will never put anti_sloppier_H on the diagonal >>>>>>>
yup
And thus, your diagonal that you claim to compute doesn't include
the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be correct. >>>>>
But since anti-sloppier_H WILL fully output a computable number, >>>>>>> at least as long as your sloppier_H outputs a computable number >>>>>>> as the diagonal, it needed to in order for the diagonal to be of >>>>>>> a complete enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches >>>>>>> the anti-diagonal computed by anti-slippier-H, and thus the
computable number it computes can't be in the enumeration that it >>>>>>> is working from.
it is therefore _not_ possible to effectively enumerate _all
machines_ , in direct contradiction to the obviously effective >>>>>>>> enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be >>>>>>> complete, and thus isn't a effetive enumeration of a super-set of >>>>>>> machine the of at least one machine the computes every computable >>>>>>> number.
You seem to have forgotten your own requirement that the
enumeration was to include at least one machine that computes
every computable number.
Yes, there are many computably enumerated SUB-sets of the
computable numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means >>>>>>> to be correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people releasing >>>>>>> code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't
compute the diagonal of an enumeration that includes all computable
numbers? (which is at least close to what Turing was talking about).
Computing the diagonal of a comuptable enumeration that is admittedly
containing only a subset of the computable numbers is just not
interesting.
Again, as I pointed out a long time ago, if you allow yourself to
just wonder off into uninteresting problems with no attempt to
justify why they might be interesting because you are doing them
better that how they have been done before, you are just wasting
everyone's time.
i'm not selecting for anything in particular, i'm just running any >>>>>> whatever machine that we come across, and trying to put it on a
diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to
play in your garbage.
Did you forget, that you started by saying, lets allow D to not
select EVERY non-circular machine, just it needs to select at least >>>>> one for each computable number.
The computable number of the anti-diagonal isn't in the set of
numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem,
because you attention span is apparently to short to take it to a
finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative
areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem.
Again, it seems you don't care if you work can actually be useful, as
you seem to accept that it is ok to spend a lot of time in mundane
problems with known solutions, while also adding in booby-traps (like
accepting circular machines into your enumeration) that makes
quantifying what you are doing nearly impossible.
I have shown a way to build a computable number that you
enumeration doesn't include, and thus it can't be a complete
enumeration, as you claim it is supposedly by some "magic"
assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem you >>>>> are working on because you are just fundamentally ignorant of what
you are talking about.
sloppier_H is not selecting for or even attempting to select for
"computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you description
of what the based decider is doing by trying to filter out inputs
that hit repeat state.
disproving an ability to enumerate _not_ just computable numbers, >>>>>> but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of
some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the diagonal,
therefor _all machines_ is not effectively enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, doesn't
mean we can "compute the diagonal" of the output of all machines, as
some
if i mean if machine enumerability _does not imply_ being able to
compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not REACH the diagonal. Hard to compute a diagonal with "holes" in it (since "hole"
isn't a valid symbol)
ei: if enumerability of a set of machines is independent from being
able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove a
lack of enumerability, and u've lost turing's proof against the
enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines.
The point is that the proof used the fact that the ability to compute an enumeration of computable numbers implies by the construction of
Turing's H that we must be able to compute the diagonal.
But, that machine created a paradox for the enumerator, meaning it
couldn't create the enumeration.
But, of course, understand how proofs work seems to be beyond your
ability to reason since you like to assume you can do the impossible.
machines don't have there output reach the diagonal, since "all
machines" include circular machines that only output a finite number
of digits, so "the diagonal" doesn't exist.
And we can't even say, extending the circular machine output with
some symbol, as THAT operation is the equivalent of the halting
problem and is uncomputable.
clearly if we're not specifically selecting for computable numbers,
just simulating every machine independently ...
certainly we should be able to create a diagonal from that
Sure, but a diagonal that doesn't mean anything.
You don't see to understand that being able to compute a problem that
only has passing simulatity to the uncomutable problems, but missing key aspects, doesn't actually mean anything. THere are lots of computable problems, so making another worthless one isn't worth anything.
Your logic seems to be based on "gut feelings" and you have a poorly
tuned gut. You like to talk about what "should" be able to be done,
yet can't actually justify why you should be, it all comes out of
your ignorance and inability to actually reason about what you are
talking about.
u too rick
Nope, but of course, you can't see the difference, since you don't seem
to understand logic.
Good Luck and finding anyone who want to support your work. Maybe you
are going to need to learn how to dig ditches or sling burgers to make a living.
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>> smarter TM diagonal across the circle-free computable >>>>>>>>>>>>>>> numbers that defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>Because you can't, since it isn't computable.
And what good is such a enumeration?
i’d like to try playing around with a sloppier version of >>>>>>>>>>>>>>> that diagonal, one that includes some circular numbers as >>>>>>>>>>>>>>> well. for this i will introduce a new simulation machine: >>>>>>>>>>>>>>
Note, if your enumeration includes some non-circle-free >>>>>>>>>>>>>> machines, then the enumeration of the "computable numbers" >>>>>>>>>>>>>> it generates isn't valid, as the array of values has holes >>>>>>>>>>>>>> in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>> superset of said enumeration that includes some "circular" >>>>>>>>>>>>> machines, but should include all computable numbers
No, it is a decider that enumerates machines that is
supposed to generate that, but then a machine that tries to >>>>>>>>>>>> use it to enumerate all enumerable numbers will hang and not >>>>>>>>>>>> generate the enumeration.
Again, what good is this "incorrect" enumeration for getting >>>>>>>>>>>> you to the goal of showing how to compute an enumeration of >>>>>>>>>>>> all computable numbers.
Note, because the set of "computable numbers" are (as you >>>>>>>>>>>> have pointed out) NOT the same machines that compute them, >>>>>>>>>>>> Your "super set" as described isn't a set of one sort of >>>>>>>>>>>> thing, and is actually (as I just described) a set of >>>>>>>>>>>> MACHINES that compute computable numbers + some machines >>>>>>>>>>>> that are circular.
The presence of the circular machines in the set means you >>>>>>>>>>>> can't use that set to compute the computable numbers, as you >>>>>>>>>>>> process will hang on circular machines in the set.
This is, i think. part of the reason that Turing switch to >>>>>>>>>>>> the enumeration of non-circular machines, as they are easier >>>>>>>>>>>> to talk about processing, as they are finite things, while >>>>>>>>>>>> the elements of the computable numbers are not, and if you >>>>>>>>>>>> try to talk about using ONE machine that generates it, you >>>>>>>>>>>> have the problem of selecting that one machine from the >>>>>>>>>>>> infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere >>>>>>>>>>>>>> on the "diagonal" a spot where the kth machine in the list >>>>>>>>>>>>>> doesn't generate k digits of output, because it was one of >>>>>>>>>>>>>> those non- circle-free machines accepted that got stuck >>>>>>>>>>>>>> too early.
we can avoid that using a stepping simulation while >>>>>>>>>>>>> dovetailing:
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>> machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly grow >>>>>>>>>>>> over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program >>>>>>>>>>>> to find the first even number that can't be found as the sum >>>>>>>>>>>> of two prime, will run forever but never hit a repeated state. >>>>>>>>>>>>
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a
time
if (res == STEP) {
continue
} // outputs other than
STEP
if (res != LOOP) { // indicate we're done
output res // dovetailing this
machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks
stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a >>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a simulated >>>>>>>>>>>>>>> machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>>> condition when simulating a machine, but it hasn't halted >>>>>>>>>>>>>> yet.
this is the sloppy diagonal, it doesn't care if circular >>>>>>>>>>>>> machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the output >>>>>>>>>>>> of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>>> program does EXACTLY the same steps it will also create an >>>>>>>>>>>> anti- diagonal, which could not have been from a machine in >>>>>>>>>>>> the listing, thus showing your enumation doesn't include ALL >>>>>>>>>>>> machines for ALL the computable numbers.
i guess at this point there's little point to even try to >>>>>>>>>>>>> filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>>>>> }
every time step is called it advances the machine's >>>>>>>>>>>>> runtime, recording any output alone the way. after the step >>>>>>>>>>>>> is complete, if the Kth output has been recorded already it >>>>>>>>>>>>> will output that. however if the Kth output has not already >>>>>>>>>>>>> been output by the machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a
time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing it. i'm >>>>>>>>>>>>> kinda guessing at the moment that the K within sloppier_H >>>>>>>>>>>>> grows faster than the K within anti_sloppier_H and
therefore sloppier_H will just never actually output a >>>>>>>>>>>>> digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety of >>>>>>>>>>> sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H affect >>>>>>>>>> anything, it still existed as the code for the machine with >>>>>>>>>> its number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will
constantly run behind sloppier's K for several reasons:
1) anti_sloppier_H is simulating sloppier_H's runtime with >>>>>>>>>>> extra steps for each cycle K ... mean sloppier_H's K _must_ >>>>>>>>>>> grow faster than anti_sloppier_H even when run directly in >>>>>>>>>>> parallel
No, it is supposed to be EXACTLY simulating the steps of
sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H >>>>>>>>> because it needs to check the output of after each step of
sloppier_H, to see if an output was found, and then advance K >>>>>>>>> if so.
So?
That doesn't affect the answer that sloppier_H gives to anti- >>>>>>>> sloppier_H
this is done for every step of sloppier_H, so therefore run >>>>>>>>> head to head, anti_sloppier_H will output slower than sloppier_H. >>>>>>>>>
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a particular >>>>>>>>> K until /after/ sloppier_H outputs a digit for that particular >>>>>>>>> K...
Right. and the execution of anti-sloppier_H will EXACTLY follow >>>>>>>> the behavior of sloppier_H (even though at a slower rate) and >>>>>>>> will EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some >>>>>>>>> particular K until after sloppier_H has started looking for at >>>>>>>>> least a K+1 digit,
So?
Right.
meaning sloppier_H will never put anti_sloppier_H on the diagonal >>>>>>>>
yup
And thus, your diagonal that you claim to compute doesn't include >>>>>> the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be correct. >>>>>>
But since anti-sloppier_H WILL fully output a computable number, >>>>>>>> at least as long as your sloppier_H outputs a computable number >>>>>>>> as the diagonal, it needed to in order for the diagonal to be of >>>>>>>> a complete enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that matches >>>>>>>> the anti-diagonal computed by anti-slippier-H, and thus the
computable number it computes can't be in the enumeration that >>>>>>>> it is working from.
it is therefore _not_ possible to effectively enumerate _all >>>>>>>>> machines_ , in direct contradiction to the obviously effective >>>>>>>>> enumerability used to create sloppier_H in the first place
But the effective enumeration used to create sloppier_H can't be >>>>>>>> complete, and thus isn't a effetive enumeration of a super-set >>>>>>>> of machine the of at least one machine the computes every
computable number.
You seem to have forgotten your own requirement that the
enumeration was to include at least one machine that computes >>>>>>>> every computable number.
Yes, there are many computably enumerated SUB-sets of the
computable numbers, just not one for a complete set of them.
All you are doing is showing you don't understand what it means >>>>>>>> to be correct.
Maybe you should test your machines to see if they meet your
requirements, after all, you complaint was about people
releasing code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't
compute the diagonal of an enumeration that includes all computable
numbers? (which is at least close to what Turing was talking about).
Computing the diagonal of a comuptable enumeration that is
admittedly containing only a subset of the computable numbers is
just not interesting.
Again, as I pointed out a long time ago, if you allow yourself to
just wonder off into uninteresting problems with no attempt to
justify why they might be interesting because you are doing them
better that how they have been done before, you are just wasting
everyone's time.
i'm not selecting for anything in particular, i'm just running
any whatever machine that we come across, and trying to put it on >>>>>>> a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to
play in your garbage.
Did you forget, that you started by saying, lets allow D to not
select EVERY non-circular machine, just it needs to select at
least one for each computable number.
The computable number of the anti-diagonal isn't in the set of
numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem,
because you attention span is apparently to short to take it to a >>>>>> finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative
areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem.
Again, it seems you don't care if you work can actually be useful,
as you seem to accept that it is ok to spend a lot of time in
mundane problems with known solutions, while also adding in booby-
traps (like accepting circular machines into your enumeration) that
makes quantifying what you are doing nearly impossible.
I have shown a way to build a computable number that you
enumeration doesn't include, and thus it can't be a complete
enumeration, as you claim it is supposedly by some "magic"
assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem
you are working on because you are just fundamentally ignorant of >>>>>> what you are talking about.
sloppier_H is not selecting for or even attempting to select for
"computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you
description of what the based decider is doing by trying to filter
out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable numbers, >>>>>>> but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of
some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the diagonal,
therefor _all machines_ is not effectively enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, doesn't
mean we can "compute the diagonal" of the output of all machines, as
some
if i mean if machine enumerability _does not imply_ being able to
compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not REACH
the diagonal. Hard to compute a diagonal with "holes" in it (since
"hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from being
able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove a
lack of enumerability, and u've lost turing's proof against the
enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines.
enumerating a set of machines is enumerating a set of machines eh????
why does failing to produce a diagonal for one set (computable numbers) imply it's not effectively enumerability,
but failing to produce a diagonal for the other (all machines) does not impact it's effective enumerability???
seems like special pleading to me
but the class of machines that are being analized don't HAVE a halt
The point is that the proof used the fact that the ability to compute
an enumeration of computable numbers implies by the construction of
Turing's H that we must be able to compute the diagonal.
for sloppier_H it seems we can classify machines into a few categories:
- machines that halt slow enough to have a digit put the diagonal
- machine that halt too quickly and end up as a 0 on the diagonal
- circular machines that produce digits fast enough to be put on the diagonal
- circular machines that produce too slow to be put on the diagonal (includes ones that stop producing digits but keep running)
- circle-free machines that output digits fast enough to be put on the diagonal
- circle-free machines that output digit too slowly to be put on the diagonal
did i miss any?
But, that machine created a paradox for the enumerator, meaning it
couldn't create the enumeration.
But, of course, understand how proofs work seems to be beyond your
ability to reason since you like to assume you can do the impossible.
machines don't have there output reach the diagonal, since "all
machines" include circular machines that only output a finite number
of digits, so "the diagonal" doesn't exist.
And we can't even say, extending the circular machine output with
some symbol, as THAT operation is the equivalent of the halting
problem and is uncomputable.
clearly if we're not specifically selecting for computable numbers,
just simulating every machine independently ...
certainly we should be able to create a diagonal from that
Sure, but a diagonal that doesn't mean anything.
sure??? _but we cannot_ produce that diagonal, as i just have shown
You don't see to understand that being able to compute a problem that
only has passing simulatity to the uncomutable problems, but missing
key aspects, doesn't actually mean anything. THere are lots of
computable problems, so making another worthless one isn't worth
anything.
Your logic seems to be based on "gut feelings" and you have a poorly
tuned gut. You like to talk about what "should" be able to be done,
yet can't actually justify why you should be, it all comes out of
your ignorance and inability to actually reason about what you are
talking about.
u too rick
Nope, but of course, you can't see the difference, since you don't
seem to understand logic.
Good Luck and finding anyone who want to support your work. Maybe you
are going to need to learn how to dig ditches or sling burgers to make
a living.
no idea why ur so butthurt but this is obviously a pain point of some kind
i don't agree a robust theory should have such pain points
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:No, it is a decider that enumerates machines that is >>>>>>>>>>>>> supposed to generate that, but then a machine that tries to >>>>>>>>>>>>> use it to enumerate all enumerable numbers will hang and >>>>>>>>>>>>> not generate the enumeration.
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free computable >>>>>>>>>>>>>>>> numbers that defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>>Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version >>>>>>>>>>>>>>>> of that diagonal, one that includes some circular >>>>>>>>>>>>>>>> numbers as well. for this i will introduce a new >>>>>>>>>>>>>>>> simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free >>>>>>>>>>>>>>> machines, then the enumeration of the "computable >>>>>>>>>>>>>>> numbers" it generates isn't valid, as the array of values >>>>>>>>>>>>>>> has holes in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>>> superset of said enumeration that includes some "circular" >>>>>>>>>>>>>> machines, but should include all computable numbers >>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are (as you >>>>>>>>>>>>> have pointed out) NOT the same machines that compute them, >>>>>>>>>>>>> Your "super set" as described isn't a set of one sort of >>>>>>>>>>>>> thing, and is actually (as I just described) a set of >>>>>>>>>>>>> MACHINES that compute computable numbers + some machines >>>>>>>>>>>>> that are circular.
The presence of the circular machines in the set means you >>>>>>>>>>>>> can't use that set to compute the computable numbers, as >>>>>>>>>>>>> you process will hang on circular machines in the set. >>>>>>>>>>>>>
This is, i think. part of the reason that Turing switch to >>>>>>>>>>>>> the enumeration of non-circular machines, as they are >>>>>>>>>>>>> easier to talk about processing, as they are finite things, >>>>>>>>>>>>> while the elements of the computable numbers are not, and >>>>>>>>>>>>> if you try to talk about using ONE machine that generates >>>>>>>>>>>>> it, you have the problem of selecting that one machine from >>>>>>>>>>>>> the infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely somewhere >>>>>>>>>>>>>>> on the "diagonal" a spot where the kth machine in the >>>>>>>>>>>>>>> list doesn't generate k digits of output, because it was >>>>>>>>>>>>>>> one of those non- circle-free machines accepted that got >>>>>>>>>>>>>>> stuck too early.
we can avoid that using a stepping simulation while >>>>>>>>>>>>>> dovetailing:
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>>> machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly >>>>>>>>>>>>> grow over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a program >>>>>>>>>>>>> to find the first even number that can't be found as the >>>>>>>>>>>>> sum of two prime, will run forever but never hit a repeated >>>>>>>>>>>>> state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation, >>>>>>>>>>>>>> kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as a
time
if (res == STEP) {
continue
} // outputs other
than STEP
if (res != LOOP) { // indicate we're
done
output res // dovetailing
this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally tracks
stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a >>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>> simulated machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>>>> condition when simulating a machine, but it hasn't halted >>>>>>>>>>>>>>> yet.
this is the sloppy diagonal, it doesn't care if circular >>>>>>>>>>>>>> machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the output >>>>>>>>>>>>> of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>>>> program does EXACTLY the same steps it will also create an >>>>>>>>>>>>> anti- diagonal, which could not have been from a machine in >>>>>>>>>>>>> the listing, thus showing your enumation doesn't include >>>>>>>>>>>>> ALL machines for ALL the computable numbers.
i guess at this point there's little point to even try to >>>>>>>>>>>>>> filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>>>>>> }
every time step is called it advances the machine's >>>>>>>>>>>>>> runtime, recording any output alone the way. after the >>>>>>>>>>>>>> step is complete, if the Kth output has been recorded >>>>>>>>>>>>>> already it will output that. however if the Kth output has >>>>>>>>>>>>>> not already been output by the machine then STEP it output >>>>>>>>>>>>>>
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as a
time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing it. i'm >>>>>>>>>>>>>> kinda guessing at the moment that the K within sloppier_H >>>>>>>>>>>>>> grows faster than the K within anti_sloppier_H and >>>>>>>>>>>>>> therefore sloppier_H will just never actually output a >>>>>>>>>>>>>> digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety >>>>>>>>>>>> of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>> affect anything, it still existed as the code for the machine >>>>>>>>>>> with its number.
i suppose we can adjust it with a steppable runtime:
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will
constantly run behind sloppier's K for several reasons: >>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime with >>>>>>>>>>>> extra steps for each cycle K ... mean sloppier_H's K _must_ >>>>>>>>>>>> grow faster than anti_sloppier_H even when run directly in >>>>>>>>>>>> parallel
No, it is supposed to be EXACTLY simulating the steps of >>>>>>>>>>> sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H >>>>>>>>>> because it needs to check the output of after each step of >>>>>>>>>> sloppier_H, to see if an output was found, and then advance K >>>>>>>>>> if so.
So?
That doesn't affect the answer that sloppier_H gives to anti- >>>>>>>>> sloppier_H
this is done for every step of sloppier_H, so therefore run >>>>>>>>>> head to head, anti_sloppier_H will output slower than sloppier_H. >>>>>>>>>>
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a
particular K until /after/ sloppier_H outputs a digit for that >>>>>>>>>> particular K...
Right. and the execution of anti-sloppier_H will EXACTLY follow >>>>>>>>> the behavior of sloppier_H (even though at a slower rate) and >>>>>>>>> will EXAXTLY output the opposite that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output for some >>>>>>>>>> particular K until after sloppier_H has started looking for at >>>>>>>>>> least a K+1 digit,
So?
Right.
meaning sloppier_H will never put anti_sloppier_H on the diagonal >>>>>>>>>
yup
And thus, your diagonal that you claim to compute doesn't include >>>>>>> the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be
correct.
But that was the problem you were trying to solve.
But since anti-sloppier_H WILL fully output a computable
number, at least as long as your sloppier_H outputs a
computable number as the diagonal, it needed to in order for >>>>>>>>> the diagonal to be of a complete enumeration of computable
numbers.
Sloppier H can NEVER output a digiton its diagonal that matches >>>>>>>>> the anti-diagonal computed by anti-slippier-H, and thus the >>>>>>>>> computable number it computes can't be in the enumeration that >>>>>>>>> it is working from.
it is therefore _not_ possible to effectively enumerate _all >>>>>>>>>> machines_ , in direct contradiction to the obviously effective >>>>>>>>>> enumerability used to create sloppier_H in the first place >>>>>>>>>>
But the effective enumeration used to create sloppier_H can't >>>>>>>>> be complete, and thus isn't a effetive enumeration of a super- >>>>>>>>> set of machine the of at least one machine the computes every >>>>>>>>> computable number.
You seem to have forgotten your own requirement that the
enumeration was to include at least one machine that computes >>>>>>>>> every computable number.
Yes, there are many computably enumerated SUB-sets of the
computable numbers, just not one for a complete set of them. >>>>>>>>>
All you are doing is showing you don't understand what it means >>>>>>>>> to be correct.
Maybe you should test your machines to see if they meet your >>>>>>>>> requirements, after all, you complaint was about people
releasing code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick >>>>>>>
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't
compute the diagonal of an enumeration that includes all computable >>>>> numbers? (which is at least close to what Turing was talking about). >>>>>
Computing the diagonal of a comuptable enumeration that is
admittedly containing only a subset of the computable numbers is
just not interesting.
Again, as I pointed out a long time ago, if you allow yourself to
just wonder off into uninteresting problems with no attempt to
justify why they might be interesting because you are doing them
better that how they have been done before, you are just wasting
everyone's time.
i'm not selecting for anything in particular, i'm just running >>>>>>>> any whatever machine that we come across, and trying to put it >>>>>>>> on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to >>>>>>> play in your garbage.
Did you forget, that you started by saying, lets allow D to not >>>>>>> select EVERY non-circular machine, just it needs to select at
least one for each computable number.
The computable number of the anti-diagonal isn't in the set of
numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem, >>>>>>> because you attention span is apparently to short to take it to a >>>>>>> finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative
areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem.
Again, it seems you don't care if you work can actually be useful,
as you seem to accept that it is ok to spend a lot of time in
mundane problems with known solutions, while also adding in booby-
traps (like accepting circular machines into your enumeration) that >>>>> makes quantifying what you are doing nearly impossible.
I have shown a way to build a computable number that you
enumeration doesn't include, and thus it can't be a complete >>>>>>>>> enumeration, as you claim it is supposedly by some "magic"
assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem >>>>>>> you are working on because you are just fundamentally ignorant of >>>>>>> what you are talking about.
sloppier_H is not selecting for or even attempting to select for
"computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you
description of what the based decider is doing by trying to filter
out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable
numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of >>>>>> some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the diagonal, >>>>>> therefor _all machines_ is not effectively enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, doesn't >>>>> mean we can "compute the diagonal" of the output of all machines,
as some
if i mean if machine enumerability _does not imply_ being able to
compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not REACH
the diagonal. Hard to compute a diagonal with "holes" in it (since
"hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from being
able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove a
lack of enumerability, and u've lost turing's proof against the
enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines.
enumerating a set of machines is enumerating a set of machines eh????
why does failing to produce a diagonal for one set (computable
numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we could
build the diagonal (or anti-diagonal) computation from the algorithm of
the effective enumeration.
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free computable >>>>>>>>>>>>>>>>> numbers that defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>>>Because you can't, since it isn't computable.
i’d like to try playing around with a sloppier version >>>>>>>>>>>>>>>>> of that diagonal, one that includes some circular >>>>>>>>>>>>>>>>> numbers as well. for this i will introduce a new >>>>>>>>>>>>>>>>> simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free >>>>>>>>>>>>>>>> machines, then the enumeration of the "computable >>>>>>>>>>>>>>>> numbers" it generates isn't valid, as the array of >>>>>>>>>>>>>>>> values has holes in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>>>> superset of said enumeration that includes some >>>>>>>>>>>>>>> "circular" machines, but should include all computable >>>>>>>>>>>>>>> numbers
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>> supposed to generate that, but then a machine that tries >>>>>>>>>>>>>> to use it to enumerate all enumerable numbers will hang >>>>>>>>>>>>>> and not generate the enumeration.
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are (as you >>>>>>>>>>>>>> have pointed out) NOT the same machines that compute them, >>>>>>>>>>>>>> Your "super set" as described isn't a set of one sort of >>>>>>>>>>>>>> thing, and is actually (as I just described) a set of >>>>>>>>>>>>>> MACHINES that compute computable numbers + some machines >>>>>>>>>>>>>> that are circular.
The presence of the circular machines in the set means you >>>>>>>>>>>>>> can't use that set to compute the computable numbers, as >>>>>>>>>>>>>> you process will hang on circular machines in the set. >>>>>>>>>>>>>>
This is, i think. part of the reason that Turing switch to >>>>>>>>>>>>>> the enumeration of non-circular machines, as they are >>>>>>>>>>>>>> easier to talk about processing, as they are finite >>>>>>>>>>>>>> things, while the elements of the computable numbers are >>>>>>>>>>>>>> not, and if you try to talk about using ONE machine that >>>>>>>>>>>>>> generates it, you have the problem of selecting that one >>>>>>>>>>>>>> machine from the infinite set that generates it.
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth machine >>>>>>>>>>>>>>>> in the list doesn't generate k digits of output, because >>>>>>>>>>>>>>>> it was one of those non- circle-free machines accepted >>>>>>>>>>>>>>>> that got stuck too early.
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>> dovetailing:
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>>>> machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly >>>>>>>>>>>>>> grow over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>> program to find the first even number that can't be found >>>>>>>>>>>>>> as the sum of two prime, will run forever but never hit a >>>>>>>>>>>>>> repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as
a time
if (res == STEP) {
continue
} // outputs other
than STEP
if (res != LOOP) { // indicate we're
done
output res // dovetailing
this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref
case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>> simulated machine tries to simulates itself
How can you tell this?
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>>>>> condition when simulating a machine, but it hasn't >>>>>>>>>>>>>>>> halted yet.
this is the sloppy diagonal, it doesn't care if circular >>>>>>>>>>>>>>> machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the >>>>>>>>>>>>>> output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>>>>> program does EXACTLY the same steps it will also create an >>>>>>>>>>>>>> anti- diagonal, which could not have been from a machine >>>>>>>>>>>>>> in the listing, thus showing your enumation doesn't >>>>>>>>>>>>>> include ALL machines for ALL the computable numbers. >>>>>>>>>>>>>>
i guess at this point there's little point to even try to >>>>>>>>>>>>>>> filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>>>>>>> }
every time step is called it advances the machine's >>>>>>>>>>>>>>> runtime, recording any output alone the way. after the >>>>>>>>>>>>>>> step is complete, if the Kth output has been recorded >>>>>>>>>>>>>>> already it will output that. however if the Kth output >>>>>>>>>>>>>>> has not already been output by the machine then STEP it >>>>>>>>>>>>>>> output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as
a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref
case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing it. >>>>>>>>>>>>>>> i'm kinda guessing at the moment that the K within >>>>>>>>>>>>>>> sloppier_H grows faster than the K within anti_sloppier_H >>>>>>>>>>>>>>> and therefore sloppier_H will just never actually output >>>>>>>>>>>>>>> a digit from anti_sloppier_H ...
Why won't it be able to simulate it?
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety >>>>>>>>>>>>> of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>>> affect anything, it still existed as the code for the >>>>>>>>>>>> machine with its number.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime with >>>>>>>>>>>>> extra steps for each cycle K ... mean sloppier_H's K _must_ >>>>>>>>>>>>> grow faster than anti_sloppier_H even when run directly in >>>>>>>>>>>>> parallel
No, it is supposed to be EXACTLY simulating the steps of >>>>>>>>>>>> sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H >>>>>>>>>>> because it needs to check the output of after each step of >>>>>>>>>>> sloppier_H, to see if an output was found, and then advance K >>>>>>>>>>> if so.
So?
That doesn't affect the answer that sloppier_H gives to anti- >>>>>>>>>> sloppier_H
this is done for every step of sloppier_H, so therefore run >>>>>>>>>>> head to head, anti_sloppier_H will output slower than
sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a
particular K until /after/ sloppier_H outputs a digit for >>>>>>>>>>> that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY
follow the behavior of sloppier_H (even though at a slower >>>>>>>>>> rate) and will EXAXTLY output the opposite that sloppier_H >>>>>>>>>> outputs.
so there is no way for anti_sloppier_H to ever output for >>>>>>>>>>> some particular K until after sloppier_H has started looking >>>>>>>>>>> for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the >>>>>>>>>>> diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't
include the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be
correct.
But that was the problem you were trying to solve.
But since anti-sloppier_H WILL fully output a computable
number, at least as long as your sloppier_H outputs a
computable number as the diagonal, it needed to in order for >>>>>>>>>> the diagonal to be of a complete enumeration of computable >>>>>>>>>> numbers.
Sloppier H can NEVER output a digiton its diagonal that
matches the anti-diagonal computed by anti-slippier-H, and >>>>>>>>>> thus the computable number it computes can't be in the
enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate _all >>>>>>>>>>> machines_ , in direct contradiction to the obviously
effective enumerability used to create sloppier_H in the >>>>>>>>>>> first place
But the effective enumeration used to create sloppier_H can't >>>>>>>>>> be complete, and thus isn't a effetive enumeration of a super- >>>>>>>>>> set of machine the of at least one machine the computes every >>>>>>>>>> computable number.
You seem to have forgotten your own requirement that the
enumeration was to include at least one machine that computes >>>>>>>>>> every computable number.
Yes, there are many computably enumerated SUB-sets of the >>>>>>>>>> computable numbers, just not one for a complete set of them. >>>>>>>>>>
All you are doing is showing you don't understand what it >>>>>>>>>> means to be correct.
Maybe you should test your machines to see if they meet your >>>>>>>>>> requirements, after all, you complaint was about people
releasing code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick >>>>>>>>
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't >>>>>> compute the diagonal of an enumeration that includes all
computable numbers? (which is at least close to what Turing was
talking about).
Computing the diagonal of a comuptable enumeration that is
admittedly containing only a subset of the computable numbers is
just not interesting.
Again, as I pointed out a long time ago, if you allow yourself to >>>>>> just wonder off into uninteresting problems with no attempt to
justify why they might be interesting because you are doing them
better that how they have been done before, you are just wasting
everyone's time.
i'm not selecting for anything in particular, i'm just running >>>>>>>>> any whatever machine that we come across, and trying to put it >>>>>>>>> on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to >>>>>>>> play in your garbage.
Did you forget, that you started by saying, lets allow D to not >>>>>>>> select EVERY non-circular machine, just it needs to select at >>>>>>>> least one for each computable number.
The computable number of the anti-diagonal isn't in the set of >>>>>>>> numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem, >>>>>>>> because you attention span is apparently to short to take it to >>>>>>>> a finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative
areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem.
Again, it seems you don't care if you work can actually be useful, >>>>>> as you seem to accept that it is ok to spend a lot of time in
mundane problems with known solutions, while also adding in booby- >>>>>> traps (like accepting circular machines into your enumeration)
that makes quantifying what you are doing nearly impossible.
I have shown a way to build a computable number that you
enumeration doesn't include, and thus it can't be a complete >>>>>>>>>> enumeration, as you claim it is supposedly by some "magic" >>>>>>>>>> assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem >>>>>>>> you are working on because you are just fundamentally ignorant >>>>>>>> of what you are talking about.
sloppier_H is not selecting for or even attempting to select for >>>>>>> "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you
description of what the based decider is doing by trying to filter >>>>>> out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable
numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them of >>>>>>> some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the diagonal, >>>>>>> therefor _all machines_ is not effectively enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines,
doesn't mean we can "compute the diagonal" of the output of all
machines, as some
if i mean if machine enumerability _does not imply_ being able to
compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not REACH
the diagonal. Hard to compute a diagonal with "holes" in it (since
"hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from being >>>>> able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove a >>>>> lack of enumerability, and u've lost turing's proof against the
enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines.
enumerating a set of machines is enumerating a set of machines eh????
why does failing to produce a diagonal for one set (computable
numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we could
build the diagonal (or anti-diagonal) computation from the algorithm
of the effective enumeration.
clearly building a diagonal is not required for a set of machines to be effectively enumerable ..
and stop insulting me to make up for ur lack of consistency in principles
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free computable >>>>>>>>>>>>>>>>>> numbers that defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier version >>>>>>>>>>>>>>>>>> of that diagonal, one that includes some circular >>>>>>>>>>>>>>>>>> numbers as well. for this i will introduce a new >>>>>>>>>>>>>>>>>> simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle-free >>>>>>>>>>>>>>>>> machines, then the enumeration of the "computable >>>>>>>>>>>>>>>>> numbers" it generates isn't valid, as the array of >>>>>>>>>>>>>>>>> values has holes in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>>>>> superset of said enumeration that includes some >>>>>>>>>>>>>>>> "circular" machines, but should include all computable >>>>>>>>>>>>>>>> numbers
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>>> supposed to generate that, but then a machine that tries >>>>>>>>>>>>>>> to use it to enumerate all enumerable numbers will hang >>>>>>>>>>>>>>> and not generate the enumeration.
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are (as >>>>>>>>>>>>>>> you have pointed out) NOT the same machines that compute >>>>>>>>>>>>>>> them, Your "super set" as described isn't a set of one >>>>>>>>>>>>>>> sort of thing, and is actually (as I just described) a >>>>>>>>>>>>>>> set of MACHINES that compute computable numbers + some >>>>>>>>>>>>>>> machines that are circular.
The presence of the circular machines in the set means >>>>>>>>>>>>>>> you can't use that set to compute the computable numbers, >>>>>>>>>>>>>>> as you process will hang on circular machines in the set. >>>>>>>>>>>>>>>
This is, i think. part of the reason that Turing switch >>>>>>>>>>>>>>> to the enumeration of non-circular machines, as they are >>>>>>>>>>>>>>> easier to talk about processing, as they are finite >>>>>>>>>>>>>>> things, while the elements of the computable numbers are >>>>>>>>>>>>>>> not, and if you try to talk about using ONE machine that >>>>>>>>>>>>>>> generates it, you have the problem of selecting that one >>>>>>>>>>>>>>> machine from the infinite set that generates it. >>>>>>>>>>>>>>>
In other words, your world is just broken.
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>> output, because it was one of those non- circle-free >>>>>>>>>>>>>>>>> machines accepted that got stuck too early.
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>>> dovetailing:
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>>>>> machines, as not all circularity is detectable.
As I pointed out, some machines just continue to slowly >>>>>>>>>>>>>>> grow over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>> program to find the first even number that can't be found >>>>>>>>>>>>>>> as the sum of two prime, will run forever but never hit a >>>>>>>>>>>>>>> repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step as
a time
if (res == STEP) {
continue
} // outputs other
than STEP
if (res != LOOP) { // indicate
we're done
output res // dovetailing
this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref
case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>>>>>> condition when simulating a machine, but it hasn't >>>>>>>>>>>>>>>>> halted yet.
this is the sloppy diagonal, it doesn't care if circular >>>>>>>>>>>>>>>> machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the >>>>>>>>>>>>>>> output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>>>>>> program does EXACTLY the same steps it will also create >>>>>>>>>>>>>>> an anti- diagonal, which could not have been from a >>>>>>>>>>>>>>> machine in the listing, thus showing your enumation >>>>>>>>>>>>>>> doesn't include ALL machines for ALL the computable numbers. >>>>>>>>>>>>>>>
Why won't it be able to simulate it?
i guess at this point there's little point to even try >>>>>>>>>>>>>>>> to filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output >>>>>>>>>>>>>>>> }
every time step is called it advances the machine's >>>>>>>>>>>>>>>> runtime, recording any output alone the way. after the >>>>>>>>>>>>>>>> step is complete, if the Kth output has been recorded >>>>>>>>>>>>>>>> already it will output that. however if the Kth output >>>>>>>>>>>>>>>> has not already been output by the machine then STEP it >>>>>>>>>>>>>>>> output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step as
a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-ref
case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing it. >>>>>>>>>>>>>>>> i'm kinda guessing at the moment that the K within >>>>>>>>>>>>>>>> sloppier_H grows faster than the K within
anti_sloppier_H and therefore sloppier_H will just never >>>>>>>>>>>>>>>> actually output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the entirety >>>>>>>>>>>>>> of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>>>> affect anything, it still existed as the code for the >>>>>>>>>>>>> machine with its number.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime with >>>>>>>>>>>>>> extra steps for each cycle K ... mean sloppier_H's K >>>>>>>>>>>>>> _must_ grow faster than anti_sloppier_H even when run >>>>>>>>>>>>>> directly in parallel
No, it is supposed to be EXACTLY simulating the steps of >>>>>>>>>>>>> sloppier_H.
anti_sloppier_H takes more steps for each step of sloppier_H >>>>>>>>>>>> because it needs to check the output of after each step of >>>>>>>>>>>> sloppier_H, to see if an output was found, and then advance >>>>>>>>>>>> K if so.
So?
That doesn't affect the answer that sloppier_H gives to anti- >>>>>>>>>>> sloppier_H
this is done for every step of sloppier_H, so therefore run >>>>>>>>>>>> head to head, anti_sloppier_H will output slower than >>>>>>>>>>>> sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a
particular K until /after/ sloppier_H outputs a digit for >>>>>>>>>>>> that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY >>>>>>>>>>> follow the behavior of sloppier_H (even though at a slower >>>>>>>>>>> rate) and will EXAXTLY output the opposite that sloppier_H >>>>>>>>>>> outputs.
so there is no way for anti_sloppier_H to ever output for >>>>>>>>>>>> some particular K until after sloppier_H has started looking >>>>>>>>>>>> for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the >>>>>>>>>>>> diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't
include the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be >>>>>>>>> correct.
But that was the problem you were trying to solve.
But since anti-sloppier_H WILL fully output a computable >>>>>>>>>>> number, at least as long as your sloppier_H outputs a
computable number as the diagonal, it needed to in order for >>>>>>>>>>> the diagonal to be of a complete enumeration of computable >>>>>>>>>>> numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, and >>>>>>>>>>> thus the computable number it computes can't be in the
enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate _all >>>>>>>>>>>> machines_ , in direct contradiction to the obviously
effective enumerability used to create sloppier_H in the >>>>>>>>>>>> first place
But the effective enumeration used to create sloppier_H can't >>>>>>>>>>> be complete, and thus isn't a effetive enumeration of a >>>>>>>>>>> super- set of machine the of at least one machine the
computes every computable number.
You seem to have forgotten your own requirement that the >>>>>>>>>>> enumeration was to include at least one machine that computes >>>>>>>>>>> every computable number.
Yes, there are many computably enumerated SUB-sets of the >>>>>>>>>>> computable numbers, just not one for a complete set of them. >>>>>>>>>>>
All you are doing is showing you don't understand what it >>>>>>>>>>> means to be correct.
Maybe you should test your machines to see if they meet your >>>>>>>>>>> requirements, after all, you complaint was about people >>>>>>>>>>> releasing code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick >>>>>>>>>
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you can't >>>>>>> compute the diagonal of an enumeration that includes all
computable numbers? (which is at least close to what Turing was >>>>>>> talking about).
Computing the diagonal of a comuptable enumeration that is
admittedly containing only a subset of the computable numbers is >>>>>>> just not interesting.
Again, as I pointed out a long time ago, if you allow yourself to >>>>>>> just wonder off into uninteresting problems with no attempt to
justify why they might be interesting because you are doing them >>>>>>> better that how they have been done before, you are just wasting >>>>>>> everyone's time.
i'm not selecting for anything in particular, i'm just running >>>>>>>>>> any whatever machine that we come across, and trying to put it >>>>>>>>>> on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started to >>>>>>>>> play in your garbage.
Did you forget, that you started by saying, lets allow D to not >>>>>>>>> select EVERY non-circular machine, just it needs to select at >>>>>>>>> least one for each computable number.
The computable number of the anti-diagonal isn't in the set of >>>>>>>>> numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the problem, >>>>>>>>> because you attention span is apparently to short to take it to >>>>>>>>> a finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative >>>>>>> areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem.
Again, it seems you don't care if you work can actually be
useful, as you seem to accept that it is ok to spend a lot of
time in mundane problems with known solutions, while also adding >>>>>>> in booby- traps (like accepting circular machines into your
enumeration) that makes quantifying what you are doing nearly
impossible.
I have shown a way to build a computable number that you >>>>>>>>>>> enumeration doesn't include, and thus it can't be a complete >>>>>>>>>>> enumeration, as you claim it is supposedly by some "magic" >>>>>>>>>>> assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what problem >>>>>>>>> you are working on because you are just fundamentally ignorant >>>>>>>>> of what you are talking about.
sloppier_H is not selecting for or even attempting to select for >>>>>>>> "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you
description of what the based decider is doing by trying to
filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable
numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them >>>>>>>> of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the
diagonal, therefor _all machines_ is not effectively enumerable >>>>>>>>
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines,
doesn't mean we can "compute the diagonal" of the output of all >>>>>>> machines, as some
if i mean if machine enumerability _does not imply_ being able to >>>>>> compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not REACH >>>>> the diagonal. Hard to compute a diagonal with "holes" in it (since
"hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from
being able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove >>>>>> a lack of enumerability, and u've lost turing's proof against the >>>>>> enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines.
enumerating a set of machines is enumerating a set of machines eh????
why does failing to produce a diagonal for one set (computable
numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we could
build the diagonal (or anti-diagonal) computation from the algorithm
of the effective enumeration.
clearly building a diagonal is not required for a set of machines to
be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a full
matrix of results, as a diagonal exists.
Of course if there isn't a diagonal, because not every machine reaches
it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in principles
What inconsistency?
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your modus operandi.
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free computable >>>>>>>>>>>>>>>>>>> numbers that defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes some >>>>>>>>>>>>>>>>>>> circular numbers as well. for this i will introduce a >>>>>>>>>>>>>>>>>>> new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle- >>>>>>>>>>>>>>>>>> free machines, then the enumeration of the "computable >>>>>>>>>>>>>>>>>> numbers" it generates isn't valid, as the array of >>>>>>>>>>>>>>>>>> values has holes in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>>>>>> superset of said enumeration that includes some >>>>>>>>>>>>>>>>> "circular" machines, but should include all computable >>>>>>>>>>>>>>>>> numbers
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>>>> supposed to generate that, but then a machine that tries >>>>>>>>>>>>>>>> to use it to enumerate all enumerable numbers will hang >>>>>>>>>>>>>>>> and not generate the enumeration.
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are (as >>>>>>>>>>>>>>>> you have pointed out) NOT the same machines that compute >>>>>>>>>>>>>>>> them, Your "super set" as described isn't a set of one >>>>>>>>>>>>>>>> sort of thing, and is actually (as I just described) a >>>>>>>>>>>>>>>> set of MACHINES that compute computable numbers + some >>>>>>>>>>>>>>>> machines that are circular.
The presence of the circular machines in the set means >>>>>>>>>>>>>>>> you can't use that set to compute the computable >>>>>>>>>>>>>>>> numbers, as you process will hang on circular machines >>>>>>>>>>>>>>>> in the set.
This is, i think. part of the reason that Turing switch >>>>>>>>>>>>>>>> to the enumeration of non-circular machines, as they are >>>>>>>>>>>>>>>> easier to talk about processing, as they are finite >>>>>>>>>>>>>>>> things, while the elements of the computable numbers are >>>>>>>>>>>>>>>> not, and if you try to talk about using ONE machine that >>>>>>>>>>>>>>>> generates it, you have the problem of selecting that one >>>>>>>>>>>>>>>> machine from the infinite set that generates it. >>>>>>>>>>>>>>>>
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>>>> dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>> output, because it was one of those non- circle-free >>>>>>>>>>>>>>>>>> machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>>>>>> machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to slowly >>>>>>>>>>>>>>>> grow over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>>> program to find the first even number that can't be >>>>>>>>>>>>>>>> found as the sum of two prime, will run forever but >>>>>>>>>>>>>>>> never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step
as a time
if (res == STEP) {
continue
} // outputs other
than STEP
if (res != LOOP) { // indicate
we're done
output res // dovetailing
this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-
ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>>>>>>> condition when simulating a machine, but it hasn't >>>>>>>>>>>>>>>>>> halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>> circular machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the >>>>>>>>>>>>>>>> output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>>>>>>> program does EXACTLY the same steps it will also create >>>>>>>>>>>>>>>> an anti- diagonal, which could not have been from a >>>>>>>>>>>>>>>> machine in the listing, thus showing your enumation >>>>>>>>>>>>>>>> doesn't include ALL machines for ALL the computable >>>>>>>>>>>>>>>> numbers.
Why won't it be able to simulate it?
i guess at this point there's little point to even try >>>>>>>>>>>>>>>>> to filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been output
}
every time step is called it advances the machine's >>>>>>>>>>>>>>>>> runtime, recording any output alone the way. after the >>>>>>>>>>>>>>>>> step is complete, if the Kth output has been recorded >>>>>>>>>>>>>>>>> already it will output that. however if the Kth output >>>>>>>>>>>>>>>>> has not already been output by the machine then STEP it >>>>>>>>>>>>>>>>> output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step
as a time
if (res == STEP) continue
output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-
ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing it. >>>>>>>>>>>>>>>>> i'm kinda guessing at the moment that the K within >>>>>>>>>>>>>>>>> sloppier_H grows faster than the K within
anti_sloppier_H and therefore sloppier_H will just >>>>>>>>>>>>>>>>> never actually output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>>>>> affect anything, it still existed as the code for the >>>>>>>>>>>>>> machine with its number.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime >>>>>>>>>>>>>>> with extra steps for each cycle K ... mean sloppier_H's K >>>>>>>>>>>>>>> _must_ grow faster than anti_sloppier_H even when run >>>>>>>>>>>>>>> directly in parallel
No, it is supposed to be EXACTLY simulating the steps of >>>>>>>>>>>>>> sloppier_H.
anti_sloppier_H takes more steps for each step of
sloppier_H because it needs to check the output of after >>>>>>>>>>>>> each step of sloppier_H, to see if an output was found, and >>>>>>>>>>>>> then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to >>>>>>>>>>>> anti- sloppier_H
this is done for every step of sloppier_H, so therefore run >>>>>>>>>>>>> head to head, anti_sloppier_H will output slower than >>>>>>>>>>>>> sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit for >>>>>>>>>>>>> that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY >>>>>>>>>>>> follow the behavior of sloppier_H (even though at a slower >>>>>>>>>>>> rate) and will EXAXTLY output the opposite that sloppier_H >>>>>>>>>>>> outputs.
so there is no way for anti_sloppier_H to ever output for >>>>>>>>>>>>> some particular K until after sloppier_H has started >>>>>>>>>>>>> looking for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the >>>>>>>>>>>>> diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't >>>>>>>>>> include the required COMPLETE set of computable numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be >>>>>>>>>> correct.
But that was the problem you were trying to solve.
But since anti-sloppier_H WILL fully output a computable >>>>>>>>>>>> number, at least as long as your sloppier_H outputs a >>>>>>>>>>>> computable number as the diagonal, it needed to in order for >>>>>>>>>>>> the diagonal to be of a complete enumeration of computable >>>>>>>>>>>> numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, and >>>>>>>>>>>> thus the computable number it computes can't be in the >>>>>>>>>>>> enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate >>>>>>>>>>>>> _all machines_ , in direct contradiction to the obviously >>>>>>>>>>>>> effective enumerability used to create sloppier_H in the >>>>>>>>>>>>> first place
But the effective enumeration used to create sloppier_H >>>>>>>>>>>> can't be complete, and thus isn't a effetive enumeration of >>>>>>>>>>>> a super- set of machine the of at least one machine the >>>>>>>>>>>> computes every computable number.
You seem to have forgotten your own requirement that the >>>>>>>>>>>> enumeration was to include at least one machine that
computes every computable number.
Yes, there are many computably enumerated SUB-sets of the >>>>>>>>>>>> computable numbers, just not one for a complete set of them. >>>>>>>>>>>>
All you are doing is showing you don't understand what it >>>>>>>>>>>> means to be correct.
Maybe you should test your machines to see if they meet your >>>>>>>>>>>> requirements, after all, you complaint was about people >>>>>>>>>>>> releasing code that wasn't proven to be correct.
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, rick >>>>>>>>>>
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you
can't compute the diagonal of an enumeration that includes all >>>>>>>> computable numbers? (which is at least close to what Turing was >>>>>>>> talking about).
Computing the diagonal of a comuptable enumeration that is
admittedly containing only a subset of the computable numbers is >>>>>>>> just not interesting.
Again, as I pointed out a long time ago, if you allow yourself >>>>>>>> to just wonder off into uninteresting problems with no attempt >>>>>>>> to justify why they might be interesting because you are doing >>>>>>>> them better that how they have been done before, you are just >>>>>>>> wasting everyone's time.
i'm not selecting for anything in particular, i'm just
running any whatever machine that we come across, and trying >>>>>>>>>>> to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started >>>>>>>>>> to play in your garbage.
Did you forget, that you started by saying, lets allow D to >>>>>>>>>> not select EVERY non-circular machine, just it needs to select >>>>>>>>>> at least one for each computable number.
The computable number of the anti-diagonal isn't in the set of >>>>>>>>>> numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the
problem, because you attention span is apparently to short to >>>>>>>>>> take it to a finish line.
the process of innovation is inherently serendipitous, rick
And when you let yourself wonder into mundane and non-inovative >>>>>>>> areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem.
Again, it seems you don't care if you work can actually be
useful, as you seem to accept that it is ok to spend a lot of >>>>>>>> time in mundane problems with known solutions, while also adding >>>>>>>> in booby- traps (like accepting circular machines into your
enumeration) that makes quantifying what you are doing nearly >>>>>>>> impossible.
I have shown a way to build a computable number that you >>>>>>>>>>>> enumeration doesn't include, and thus it can't be a complete >>>>>>>>>>>> enumeration, as you claim it is supposedly by some "magic" >>>>>>>>>>>> assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what
problem you are working on because you are just fundamentally >>>>>>>>>> ignorant of what you are talking about.
sloppier_H is not selecting for or even attempting to select >>>>>>>>> for "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you
description of what the based decider is doing by trying to
filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable >>>>>>>>>>> numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them >>>>>>>>> of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the
diagonal, therefor _all machines_ is not effectively enumerable >>>>>>>>>
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines,
doesn't mean we can "compute the diagonal" of the output of all >>>>>>>> machines, as some
if i mean if machine enumerability _does not imply_ being able to >>>>>>> compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not
REACH the diagonal. Hard to compute a diagonal with "holes" in it >>>>>> (since "hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from
being able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to prove >>>>>>> a lack of enumerability, and u've lost turing's proof against the >>>>>>> enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines.
enumerating a set of machines is enumerating a set of machines eh???? >>>>>
why does failing to produce a diagonal for one set (computable
numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we
could build the diagonal (or anti-diagonal) computation from the
algorithm of the effective enumeration.
clearly building a diagonal is not required for a set of machines to
be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a full
matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any
diagonal because it's based off the output of the diagonal computation itself...
like what i did with the set of _all_ machines
Of course if there isn't a diagonal, because not every machine reaches
it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in
principles
What inconsistency?
can't compute diagonal across computable numbers => proof against
effective enumerability
can't compute diagonal across all executable machines => not proof
against effective enumerability
totally inconsistent rick, and idk how to make that more clear tbh
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your modus
operandi.
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:enumerating a set of machines is enumerating a set of machines eh???? >>>>>>
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote:
On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free >>>>>>>>>>>>>>>>>>>> computable numbers that defeats all variants of >>>>>>>>>>>>>>>>>>>> anti_fixed_H,
Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes some >>>>>>>>>>>>>>>>>>>> circular numbers as well. for this i will introduce >>>>>>>>>>>>>>>>>>>> a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle- >>>>>>>>>>>>>>>>>>> free machines, then the enumeration of the >>>>>>>>>>>>>>>>>>> "computable numbers" it generates isn't valid, as the >>>>>>>>>>>>>>>>>>> array of values has holes in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>>>>>>> superset of said enumeration that includes some >>>>>>>>>>>>>>>>>> "circular" machines, but should include all computable >>>>>>>>>>>>>>>>>> numbers
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>>>>> supposed to generate that, but then a machine that >>>>>>>>>>>>>>>>> tries to use it to enumerate all enumerable numbers >>>>>>>>>>>>>>>>> will hang and not generate the enumeration.
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are (as >>>>>>>>>>>>>>>>> you have pointed out) NOT the same machines that >>>>>>>>>>>>>>>>> compute them, Your "super set" as described isn't a set >>>>>>>>>>>>>>>>> of one sort of thing, and is actually (as I just >>>>>>>>>>>>>>>>> described) a set of MACHINES that compute computable >>>>>>>>>>>>>>>>> numbers + some machines that are circular.
The presence of the circular machines in the set means >>>>>>>>>>>>>>>>> you can't use that set to compute the computable >>>>>>>>>>>>>>>>> numbers, as you process will hang on circular machines >>>>>>>>>>>>>>>>> in the set.
This is, i think. part of the reason that Turing switch >>>>>>>>>>>>>>>>> to the enumeration of non-circular machines, as they >>>>>>>>>>>>>>>>> are easier to talk about processing, as they are finite >>>>>>>>>>>>>>>>> things, while the elements of the computable numbers >>>>>>>>>>>>>>>>> are not, and if you try to talk about using ONE machine >>>>>>>>>>>>>>>>> that generates it, you have the problem of selecting >>>>>>>>>>>>>>>>> that one machine from the infinite set that generates it. >>>>>>>>>>>>>>>>>
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>>>>> dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>>> output, because it was one of those non- circle-free >>>>>>>>>>>>>>>>>>> machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>>>>>>> machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to slowly >>>>>>>>>>>>>>>>> grow over time and never repeat a state.
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>>>> program to find the first even number that can't be >>>>>>>>>>>>>>>>> found as the sum of two prime, will run forever but >>>>>>>>>>>>>>>>> never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step
as a time
if (res == STEP) {
continue
} // outputs other
than STEP
if (res != LOOP) { // indicate
we're done
output res // dovetailing
this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-
ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases:
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"?
How do you detect that you won't find such a circular >>>>>>>>>>>>>>>>>>> condition when simulating a machine, but it hasn't >>>>>>>>>>>>>>>>>>> halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>> circular machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M with >>>>>>>>>>>>>>>>> DN(sloppy_H) not changing that, and then reverse the >>>>>>>>>>>>>>>>> output of the two outputs.
If your sloppy_H produces a diagonal, because the anti- >>>>>>>>>>>>>>>>> program does EXACTLY the same steps it will also create >>>>>>>>>>>>>>>>> an anti- diagonal, which could not have been from a >>>>>>>>>>>>>>>>> machine in the listing, thus showing your enumation >>>>>>>>>>>>>>>>> doesn't include ALL machines for ALL the computable >>>>>>>>>>>>>>>>> numbers.
Why won't it be able to simulate it?
i guess at this point there's little point to even try >>>>>>>>>>>>>>>>>> to filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been >>>>>>>>>>>>>>>>>> output
}
every time step is called it advances the machine's >>>>>>>>>>>>>>>>>> runtime, recording any output alone the way. after the >>>>>>>>>>>>>>>>>> step is complete, if the Kth output has been recorded >>>>>>>>>>>>>>>>>> already it will output that. however if the Kth output >>>>>>>>>>>>>>>>>> has not already been output by the machine then STEP >>>>>>>>>>>>>>>>>> it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step
as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-
ref case
output 0
K += 1
} else {
m = steppable_runtime(M)
list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing it. >>>>>>>>>>>>>>>>>> i'm kinda guessing at the moment that the K within >>>>>>>>>>>>>>>>>> sloppier_H grows faster than the K within >>>>>>>>>>>>>>>>>> anti_sloppier_H and therefore sloppier_H will just >>>>>>>>>>>>>>>>>> never actually output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>>>>>> affect anything, it still existed as the code for the >>>>>>>>>>>>>>> machine with its number.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime >>>>>>>>>>>>>>>> with extra steps for each cycle K ... mean sloppier_H's >>>>>>>>>>>>>>>> K _must_ grow faster than anti_sloppier_H even when run >>>>>>>>>>>>>>>> directly in parallel
No, it is supposed to be EXACTLY simulating the steps of >>>>>>>>>>>>>>> sloppier_H.
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>> sloppier_H because it needs to check the output of after >>>>>>>>>>>>>> each step of sloppier_H, to see if an output was found, >>>>>>>>>>>>>> and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to >>>>>>>>>>>>> anti- sloppier_H
this is done for every step of sloppier_H, so therefore >>>>>>>>>>>>>> run head to head, anti_sloppier_H will output slower than >>>>>>>>>>>>>> sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit for >>>>>>>>>>>>>> that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY >>>>>>>>>>>>> follow the behavior of sloppier_H (even though at a slower >>>>>>>>>>>>> rate) and will EXAXTLY output the opposite that sloppier_H >>>>>>>>>>>>> outputs.
so there is no way for anti_sloppier_H to ever output for >>>>>>>>>>>>>> some particular K until after sloppier_H has started >>>>>>>>>>>>>> looking for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the >>>>>>>>>>>>>> diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't >>>>>>>>>>> include the required COMPLETE set of computable numbers. >>>>>>>>>>>
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be >>>>>>>>>>> correct.
But since anti-sloppier_H WILL fully output a computable >>>>>>>>>>>>> number, at least as long as your sloppier_H outputs a >>>>>>>>>>>>> computable number as the diagonal, it needed to in order >>>>>>>>>>>>> for the diagonal to be of a complete enumeration of >>>>>>>>>>>>> computable numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, and >>>>>>>>>>>>> thus the computable number it computes can't be in the >>>>>>>>>>>>> enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate >>>>>>>>>>>>>> _all machines_ , in direct contradiction to the obviously >>>>>>>>>>>>>> effective enumerability used to create sloppier_H in the >>>>>>>>>>>>>> first place
But the effective enumeration used to create sloppier_H >>>>>>>>>>>>> can't be complete, and thus isn't a effetive enumeration of >>>>>>>>>>>>> a super- set of machine the of at least one machine the >>>>>>>>>>>>> computes every computable number.
You seem to have forgotten your own requirement that the >>>>>>>>>>>>> enumeration was to include at least one machine that >>>>>>>>>>>>> computes every computable number.
Yes, there are many computably enumerated SUB-sets of the >>>>>>>>>>>>> computable numbers, just not one for a complete set of them. >>>>>>>>>>>>>
All you are doing is showing you don't understand what it >>>>>>>>>>>>> means to be correct.
Maybe you should test your machines to see if they meet >>>>>>>>>>>>> your requirements, after all, you complaint was about >>>>>>>>>>>>> people releasing code that wasn't proven to be correct. >>>>>>>>>>>>>
And you keep on releasing things provably INCORRECT.
i'm not selecting for "computable numbers" with sloppier_H, >>>>>>>>>>>> rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you >>>>>>>>> can't compute the diagonal of an enumeration that includes all >>>>>>>>> computable numbers? (which is at least close to what Turing was >>>>>>>>> talking about).
Computing the diagonal of a comuptable enumeration that is
admittedly containing only a subset of the computable numbers >>>>>>>>> is just not interesting.
Again, as I pointed out a long time ago, if you allow yourself >>>>>>>>> to just wonder off into uninteresting problems with no attempt >>>>>>>>> to justify why they might be interesting because you are doing >>>>>>>>> them better that how they have been done before, you are just >>>>>>>>> wasting everyone's time.
And when you let yourself wonder into mundane and non-inovative >>>>>>>>> areas, you can waste a LOT of time.
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>> running any whatever machine that we come across, and trying >>>>>>>>>>>> to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started >>>>>>>>>>> to play in your garbage.
Did you forget, that you started by saying, lets allow D to >>>>>>>>>>> not select EVERY non-circular machine, just it needs to >>>>>>>>>>> select at least one for each computable number.
The computable number of the anti-diagonal isn't in the set >>>>>>>>>>> of numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the
problem, because you attention span is apparently to short to >>>>>>>>>>> take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem. >>>>>>>
Again, it seems you don't care if you work can actually be
useful, as you seem to accept that it is ok to spend a lot of >>>>>>>>> time in mundane problems with known solutions, while also
adding in booby- traps (like accepting circular machines into >>>>>>>>> your enumeration) that makes quantifying what you are doing >>>>>>>>> nearly impossible.
I have shown a way to build a computable number that you >>>>>>>>>>>>> enumeration doesn't include, and thus it can't be a >>>>>>>>>>>>> complete enumeration, as you claim it is supposedly by some >>>>>>>>>>>>> "magic" assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what >>>>>>>>>>> problem you are working on because you are just fundamentally >>>>>>>>>>> ignorant of what you are talking about.
sloppier_H is not selecting for or even attempting to select >>>>>>>>>> for "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you
description of what the based decider is doing by trying to >>>>>>>>> filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable >>>>>>>>>>>> numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across them >>>>>>>>>> of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the
diagonal, therefor _all machines_ is not effectively enumerable >>>>>>>>>>
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, >>>>>>>>> doesn't mean we can "compute the diagonal" of the output of all >>>>>>>>> machines, as some
if i mean if machine enumerability _does not imply_ being able >>>>>>>> to compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not
REACH the diagonal. Hard to compute a diagonal with "holes" in it >>>>>>> (since "hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from >>>>>>>> being able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to
prove a lack of enumerability, and u've lost turing's proof
against the enumerability of computable numbers
Which showds you don't understand the difference between just
enumerating any ol machine, and enumerating circle-free machines. >>>>>>
why does failing to produce a diagonal for one set (computable
numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we
could build the diagonal (or anti-diagonal) computation from the
algorithm of the effective enumeration.
clearly building a diagonal is not required for a set of machines to
be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a full
matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any
diagonal because it's based off the output of the diagonal computation
itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as all the machines generate enough data to reach it, you can compute the diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of machine
that all reach the diagonal with a machine in that which doesn't reach
the diagonal.
Of course if there isn't a diagonal, because not every machine
reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in
principles
What inconsistency?
can't compute diagonal across computable numbers => proof against
effective enumerability
can't compute diagonal across all executable machines => not proof
against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be the
reason you can't compute it.
totally inconsistent rick, and idk how to make that more clear tbh
Just like your K < K claim, since that diagonal computation apparently reached the diagonal in one view to create it, but also can't reach it
to compute it.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist (like
the diagonal of an enumeration that includes circular machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than 2
doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your modus
operandi.
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:enumerating a set of machines is enumerating a set of machines
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free >>>>>>>>>>>>>>>>>>>>> computable numbers that defeats all variants of >>>>>>>>>>>>>>>>>>>>> anti_fixed_H,
Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes some >>>>>>>>>>>>>>>>>>>>> circular numbers as well. for this i will introduce >>>>>>>>>>>>>>>>>>>>> a new simulation machine:
And what good is such a enumeration?
Note, if your enumeration includes some non-circle- >>>>>>>>>>>>>>>>>>>> free machines, then the enumeration of the >>>>>>>>>>>>>>>>>>>> "computable numbers" it generates isn't valid, as >>>>>>>>>>>>>>>>>>>> the array of values has holes in it.
it's not an enumeration of computable numbers, it's a >>>>>>>>>>>>>>>>>>> superset of said enumeration that includes some >>>>>>>>>>>>>>>>>>> "circular" machines, but should include all >>>>>>>>>>>>>>>>>>> computable numbers
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>>>>>> supposed to generate that, but then a machine that >>>>>>>>>>>>>>>>>> tries to use it to enumerate all enumerable numbers >>>>>>>>>>>>>>>>>> will hang and not generate the enumeration. >>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are (as >>>>>>>>>>>>>>>>>> you have pointed out) NOT the same machines that >>>>>>>>>>>>>>>>>> compute them, Your "super set" as described isn't a >>>>>>>>>>>>>>>>>> set of one sort of thing, and is actually (as I just >>>>>>>>>>>>>>>>>> described) a set of MACHINES that compute computable >>>>>>>>>>>>>>>>>> numbers + some machines that are circular. >>>>>>>>>>>>>>>>>>
The presence of the circular machines in the set means >>>>>>>>>>>>>>>>>> you can't use that set to compute the computable >>>>>>>>>>>>>>>>>> numbers, as you process will hang on circular machines >>>>>>>>>>>>>>>>>> in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular machines, as >>>>>>>>>>>>>>>>>> they are easier to talk about processing, as they are >>>>>>>>>>>>>>>>>> finite things, while the elements of the computable >>>>>>>>>>>>>>>>>> numbers are not, and if you try to talk about using >>>>>>>>>>>>>>>>>> ONE machine that generates it, you have the problem of >>>>>>>>>>>>>>>>>> selecting that one machine from the infinite set that >>>>>>>>>>>>>>>>>> generates it.
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>>>>>> dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>>>> output, because it was one of those non- circle-free >>>>>>>>>>>>>>>>>>>> machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for all >>>>>>>>>>>>>>>>>> machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>>>>> program to find the first even number that can't be >>>>>>>>>>>>>>>>>> found as the sum of two prime, will run forever but >>>>>>>>>>>>>>>>>> never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one step
as a time
if (res == STEP) {
continue
} // outputs
other than STEP
if (res != LOOP) { // indicate
we're done
output res //
dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-
ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> {
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>>>>> before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"?
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, but it >>>>>>>>>>>>>>>>>>>> hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>> circular machines end up on the list
And why can't that same program be used to compute the >>>>>>>>>>>>>>>>>> sloppy- anti- diagonal (where you still test the M >>>>>>>>>>>>>>>>>> with DN(sloppy_H) not changing that, and then reverse >>>>>>>>>>>>>>>>>> the output of the two outputs.
If your sloppy_H produces a diagonal, because the >>>>>>>>>>>>>>>>>> anti- program does EXACTLY the same steps it will also >>>>>>>>>>>>>>>>>> create an anti- diagonal, which could not have been >>>>>>>>>>>>>>>>>> from a machine in the listing, thus showing your >>>>>>>>>>>>>>>>>> enumation doesn't include ALL machines for ALL the >>>>>>>>>>>>>>>>>> computable numbers.
Why won't it be able to simulate it?
i guess at this point there's little point to even >>>>>>>>>>>>>>>>>>> try to filter out any circular machines
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been >>>>>>>>>>>>>>>>>>> output
}
every time step is called it advances the machine's >>>>>>>>>>>>>>>>>>> runtime, recording any output alone the way. after >>>>>>>>>>>>>>>>>>> the step is complete, if the Kth output has been >>>>>>>>>>>>>>>>>>> recorded already it will output that. however if the >>>>>>>>>>>>>>>>>>> Kth output has not already been output by the machine >>>>>>>>>>>>>>>>>>> then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one step
as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle self-
ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>> list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K)
K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing >>>>>>>>>>>>>>>>>>> it. i'm kinda guessing at the moment that the K >>>>>>>>>>>>>>>>>>> within sloppier_H grows faster than the K within >>>>>>>>>>>>>>>>>>> anti_sloppier_H and therefore sloppier_H will just >>>>>>>>>>>>>>>>>>> never actually output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>>>>>>> affect anything, it still existed as the code for the >>>>>>>>>>>>>>>> machine with its number.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H)
do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime >>>>>>>>>>>>>>>>> with extra steps for each cycle K ... mean sloppier_H's >>>>>>>>>>>>>>>>> K _must_ grow faster than anti_sloppier_H even when run >>>>>>>>>>>>>>>>> directly in parallel
No, it is supposed to be EXACTLY simulating the steps of >>>>>>>>>>>>>>>> sloppier_H.
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>> sloppier_H because it needs to check the output of after >>>>>>>>>>>>>>> each step of sloppier_H, to see if an output was found, >>>>>>>>>>>>>>> and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to >>>>>>>>>>>>>> anti- sloppier_H
this is done for every step of sloppier_H, so therefore >>>>>>>>>>>>>>> run head to head, anti_sloppier_H will output slower than >>>>>>>>>>>>>>> sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit for >>>>>>>>>>>>>>> that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY >>>>>>>>>>>>>> follow the behavior of sloppier_H (even though at a slower >>>>>>>>>>>>>> rate) and will EXAXTLY output the opposite that sloppier_H >>>>>>>>>>>>>> outputs.
so there is no way for anti_sloppier_H to ever output for >>>>>>>>>>>>>>> some particular K until after sloppier_H has started >>>>>>>>>>>>>>> looking for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the >>>>>>>>>>>>>>> diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't >>>>>>>>>>>> include the required COMPLETE set of computable numbers. >>>>>>>>>>>>
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to be >>>>>>>>>>>> correct.
i'm not selecting for "computable numbers" with sloppier_H, >>>>>>>>>>>>> rick
But since anti-sloppier_H WILL fully output a computable >>>>>>>>>>>>>> number, at least as long as your sloppier_H outputs a >>>>>>>>>>>>>> computable number as the diagonal, it needed to in order >>>>>>>>>>>>>> for the diagonal to be of a complete enumeration of >>>>>>>>>>>>>> computable numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, and >>>>>>>>>>>>>> thus the computable number it computes can't be in the >>>>>>>>>>>>>> enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate >>>>>>>>>>>>>>> _all machines_ , in direct contradiction to the obviously >>>>>>>>>>>>>>> effective enumerability used to create sloppier_H in the >>>>>>>>>>>>>>> first place
But the effective enumeration used to create sloppier_H >>>>>>>>>>>>>> can't be complete, and thus isn't a effetive enumeration >>>>>>>>>>>>>> of a super- set of machine the of at least one machine the >>>>>>>>>>>>>> computes every computable number.
You seem to have forgotten your own requirement that the >>>>>>>>>>>>>> enumeration was to include at least one machine that >>>>>>>>>>>>>> computes every computable number.
Yes, there are many computably enumerated SUB-sets of the >>>>>>>>>>>>>> computable numbers, just not one for a complete set of them. >>>>>>>>>>>>>>
All you are doing is showing you don't understand what it >>>>>>>>>>>>>> means to be correct.
Maybe you should test your machines to see if they meet >>>>>>>>>>>>>> your requirements, after all, you complaint was about >>>>>>>>>>>>>> people releasing code that wasn't proven to be correct. >>>>>>>>>>>>>>
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you >>>>>>>>>> can't compute the diagonal of an enumeration that includes all >>>>>>>>>> computable numbers? (which is at least close to what Turing >>>>>>>>>> was talking about).
Computing the diagonal of a comuptable enumeration that is >>>>>>>>>> admittedly containing only a subset of the computable numbers >>>>>>>>>> is just not interesting.
Again, as I pointed out a long time ago, if you allow yourself >>>>>>>>>> to just wonder off into uninteresting problems with no attempt >>>>>>>>>> to justify why they might be interesting because you are doing >>>>>>>>>> them better that how they have been done before, you are just >>>>>>>>>> wasting everyone's time.
And when you let yourself wonder into mundane and non-
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>>> running any whatever machine that we come across, and >>>>>>>>>>>>> trying to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just started >>>>>>>>>>>> to play in your garbage.
Did you forget, that you started by saying, lets allow D to >>>>>>>>>>>> not select EVERY non-circular machine, just it needs to >>>>>>>>>>>> select at least one for each computable number.
The computable number of the anti-diagonal isn't in the set >>>>>>>>>>>> of numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the >>>>>>>>>>>> problem, because you attention span is apparently to short >>>>>>>>>>>> to take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>>
inovative areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem. >>>>>>>>
Again, it seems you don't care if you work can actually be >>>>>>>>>> useful, as you seem to accept that it is ok to spend a lot of >>>>>>>>>> time in mundane problems with known solutions, while also >>>>>>>>>> adding in booby- traps (like accepting circular machines into >>>>>>>>>> your enumeration) that makes quantifying what you are doing >>>>>>>>>> nearly impossible.
I have shown a way to build a computable number that you >>>>>>>>>>>>>> enumeration doesn't include, and thus it can't be a >>>>>>>>>>>>>> complete enumeration, as you claim it is supposedly by >>>>>>>>>>>>>> some "magic" assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what >>>>>>>>>>>> problem you are working on because you are just
fundamentally ignorant of what you are talking about.
sloppier_H is not selecting for or even attempting to select >>>>>>>>>>> for "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you >>>>>>>>>> description of what the based decider is doing by trying to >>>>>>>>>> filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable >>>>>>>>>>>>> numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across >>>>>>>>>>> them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>> diagonal, therefor _all machines_ is not effectively enumerable >>>>>>>>>>>
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, >>>>>>>>>> doesn't mean we can "compute the diagonal" of the output of >>>>>>>>>> all machines, as some
if i mean if machine enumerability _does not imply_ being able >>>>>>>>> to compute a diagonal across the machines being enumerated,
WHy should it. Many machines are circular, and thus might not >>>>>>>> REACH the diagonal. Hard to compute a diagonal with "holes" in >>>>>>>> it (since "hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent from >>>>>>>>> being able to compute a diagonal across the set of machine,
then one _cannot_ use an inability to compute a diagonal to >>>>>>>>> prove a lack of enumerability, and u've lost turing's proof >>>>>>>>> against the enumerability of computable numbers
Which showds you don't understand the difference between just >>>>>>>> enumerating any ol machine, and enumerating circle-free machines. >>>>>>>
eh????
why does failing to produce a diagonal for one set (computable
numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we
could build the diagonal (or anti-diagonal) computation from the
algorithm of the effective enumeration.
clearly building a diagonal is not required for a set of machines
to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a
full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any
diagonal because it's based off the output of the diagonal
computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the diagonal
doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as all
the machines generate enough data to reach it, you can compute the
diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of machine
that all reach the diagonal with a machine in that which doesn't reach
the diagonal.
Of course if there isn't a diagonal, because not every machine
reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in
principles
What inconsistency?
can't compute diagonal across computable numbers => proof against
effective enumerability
can't compute diagonal across all executable machines => not proof
against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be the
reason you can't compute it.
totally inconsistent rick, and idk how to make that more clear tbh
Just like your K < K claim, since that diagonal computation apparently
reached the diagonal in one view to create it, but also can't reach it
to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist (like
the diagonal of an enumeration that includes circular machines) so
there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than 2
doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your modus
operandi.
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:enumerating a set of machines is enumerating a set of machines >>>>>>>> eh????
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote:
On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote:
after getting a lil stuck on trying to construct a >>>>>>>>>>>>>>>>>>>>>> smarter TM diagonal across the circle-free >>>>>>>>>>>>>>>>>>>>>> computable numbers that defeats all variants of >>>>>>>>>>>>>>>>>>>>>> anti_fixed_H,
Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes some >>>>>>>>>>>>>>>>>>>>>> circular numbers as well. for this i will >>>>>>>>>>>>>>>>>>>>>> introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non-circle- >>>>>>>>>>>>>>>>>>>>> free machines, then the enumeration of the >>>>>>>>>>>>>>>>>>>>> "computable numbers" it generates isn't valid, as >>>>>>>>>>>>>>>>>>>>> the array of values has holes in it.
it's not an enumeration of computable numbers, it's >>>>>>>>>>>>>>>>>>>> a superset of said enumeration that includes some >>>>>>>>>>>>>>>>>>>> "circular" machines, but should include all >>>>>>>>>>>>>>>>>>>> computable numbers
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>>>>>>> supposed to generate that, but then a machine that >>>>>>>>>>>>>>>>>>> tries to use it to enumerate all enumerable numbers >>>>>>>>>>>>>>>>>>> will hang and not generate the enumeration. >>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>>>>>>> enumeration of all computable numbers.
Note, because the set of "computable numbers" are >>>>>>>>>>>>>>>>>>> (as you have pointed out) NOT the same machines that >>>>>>>>>>>>>>>>>>> compute them, Your "super set" as described isn't a >>>>>>>>>>>>>>>>>>> set of one sort of thing, and is actually (as I just >>>>>>>>>>>>>>>>>>> described) a set of MACHINES that compute computable >>>>>>>>>>>>>>>>>>> numbers + some machines that are circular. >>>>>>>>>>>>>>>>>>>
The presence of the circular machines in the set >>>>>>>>>>>>>>>>>>> means you can't use that set to compute the >>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>> circular machines in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular machines, >>>>>>>>>>>>>>>>>>> as they are easier to talk about processing, as they >>>>>>>>>>>>>>>>>>> are finite things, while the elements of the >>>>>>>>>>>>>>>>>>> computable numbers are not, and if you try to talk >>>>>>>>>>>>>>>>>>> about using ONE machine that generates it, you have >>>>>>>>>>>>>>>>>>> the problem of selecting that one machine from the >>>>>>>>>>>>>>>>>>> infinite set that generates it.
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>>>>>>> dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>>>>> output, because it was one of those non- circle- >>>>>>>>>>>>>>>>>>>>> free machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for >>>>>>>>>>>>>>>>>>> all machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>>>>>> program to find the first even number that can't be >>>>>>>>>>>>>>>>>>> found as the sum of two prime, will run forever but >>>>>>>>>>>>>>>>>>> never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one >>>>>>>>>>>>>>>>>>>> step as a time
if (res == STEP) {
continue
} // outputs
other than STEP
if (res != LOOP) { // indicate
we're done
output res // dovetailing
this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, but >>>>>>>>>>>>>>>>>>>>> it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>>> circular machines end up on the list
And why can't that same program be used to compute >>>>>>>>>>>>>>>>>>> the sloppy- anti- diagonal (where you still test the >>>>>>>>>>>>>>>>>>> M with DN(sloppy_H) not changing that, and then >>>>>>>>>>>>>>>>>>> reverse the output of the two outputs.
If your sloppy_H produces a diagonal, because the >>>>>>>>>>>>>>>>>>> anti- program does EXACTLY the same steps it will >>>>>>>>>>>>>>>>>>> also create an anti- diagonal, which could not have >>>>>>>>>>>>>>>>>>> been from a machine in the listing, thus showing your >>>>>>>>>>>>>>>>>>> enumation doesn't include ALL machines for ALL the >>>>>>>>>>>>>>>>>>> computable numbers.
Why won't it be able to simulate it?
i guess at this point there's little point to even >>>>>>>>>>>>>>>>>>>> try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been >>>>>>>>>>>>>>>>>>>> output
}
every time step is called it advances the machine's >>>>>>>>>>>>>>>>>>>> runtime, recording any output alone the way. after >>>>>>>>>>>>>>>>>>>> the step is complete, if the Kth output has been >>>>>>>>>>>>>>>>>>>> recorded already it will output that. however if the >>>>>>>>>>>>>>>>>>>> Kth output has not already been output by the >>>>>>>>>>>>>>>>>>>> machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one
step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>> list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing >>>>>>>>>>>>>>>>>>>> it. i'm kinda guessing at the moment that the K >>>>>>>>>>>>>>>>>>>> within sloppier_H grows faster than the K within >>>>>>>>>>>>>>>>>>>> anti_sloppier_H and therefore sloppier_H will just >>>>>>>>>>>>>>>>>>>> never actually output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,
And how does the writing out the program nti-sloppier_H >>>>>>>>>>>>>>>>> affect anything, it still existed as the code for the >>>>>>>>>>>>>>>>> machine with its number.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime >>>>>>>>>>>>>>>>>> with extra steps for each cycle K ... mean >>>>>>>>>>>>>>>>>> sloppier_H's K _must_ grow faster than anti_sloppier_H >>>>>>>>>>>>>>>>>> even when run directly in parallel
No, it is supposed to be EXACTLY simulating the steps >>>>>>>>>>>>>>>>> of sloppier_H.
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of after >>>>>>>>>>>>>>>> each step of sloppier_H, to see if an output was found, >>>>>>>>>>>>>>>> and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to >>>>>>>>>>>>>>> anti- sloppier_H
this is done for every step of sloppier_H, so therefore >>>>>>>>>>>>>>>> run head to head, anti_sloppier_H will output slower >>>>>>>>>>>>>>>> than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit >>>>>>>>>>>>>>>> for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY >>>>>>>>>>>>>>> follow the behavior of sloppier_H (even though at a >>>>>>>>>>>>>>> slower rate) and will EXAXTLY output the opposite that >>>>>>>>>>>>>>> sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output >>>>>>>>>>>>>>>> for some particular K until after sloppier_H has started >>>>>>>>>>>>>>>> looking for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on the >>>>>>>>>>>>>>>> diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't >>>>>>>>>>>>> include the required COMPLETE set of computable numbers. >>>>>>>>>>>>>
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to >>>>>>>>>>>>> be correct.
i'm not selecting for "computable numbers" with
But since anti-sloppier_H WILL fully output a computable >>>>>>>>>>>>>>> number, at least as long as your sloppier_H outputs a >>>>>>>>>>>>>>> computable number as the diagonal, it needed to in order >>>>>>>>>>>>>>> for the diagonal to be of a complete enumeration of >>>>>>>>>>>>>>> computable numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, >>>>>>>>>>>>>>> and thus the computable number it computes can't be in >>>>>>>>>>>>>>> the enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate >>>>>>>>>>>>>>>> _all machines_ , in direct contradiction to the >>>>>>>>>>>>>>>> obviously effective enumerability used to create >>>>>>>>>>>>>>>> sloppier_H in the first place
But the effective enumeration used to create sloppier_H >>>>>>>>>>>>>>> can't be complete, and thus isn't a effetive enumeration >>>>>>>>>>>>>>> of a super- set of machine the of at least one machine >>>>>>>>>>>>>>> the computes every computable number.
You seem to have forgotten your own requirement that the >>>>>>>>>>>>>>> enumeration was to include at least one machine that >>>>>>>>>>>>>>> computes every computable number.
Yes, there are many computably enumerated SUB-sets of the >>>>>>>>>>>>>>> computable numbers, just not one for a complete set of them. >>>>>>>>>>>>>>>
All you are doing is showing you don't understand what it >>>>>>>>>>>>>>> means to be correct.
Maybe you should test your machines to see if they meet >>>>>>>>>>>>>>> your requirements, after all, you complaint was about >>>>>>>>>>>>>>> people releasing code that wasn't proven to be correct. >>>>>>>>>>>>>>>
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>
sloppier_H, rick
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you >>>>>>>>>>> can't compute the diagonal of an enumeration that includes >>>>>>>>>>> all computable numbers? (which is at least close to what >>>>>>>>>>> Turing was talking about).
Computing the diagonal of a comuptable enumeration that is >>>>>>>>>>> admittedly containing only a subset of the computable numbers >>>>>>>>>>> is just not interesting.
Again, as I pointed out a long time ago, if you allow
yourself to just wonder off into uninteresting problems with >>>>>>>>>>> no attempt to justify why they might be interesting because >>>>>>>>>>> you are doing them better that how they have been done
before, you are just wasting everyone's time.
And when you let yourself wonder into mundane and non-
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>>>> running any whatever machine that we come across, and >>>>>>>>>>>>>> trying to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just >>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets allow D to >>>>>>>>>>>>> not select EVERY non-circular machine, just it needs to >>>>>>>>>>>>> select at least one for each computable number.
The computable number of the anti-diagonal isn't in the set >>>>>>>>>>>>> of numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the >>>>>>>>>>>>> problem, because you attention span is apparently to short >>>>>>>>>>>>> to take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>>>
inovative areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem. >>>>>>>>>
WHy should it. Many machines are circular, and thus might not >>>>>>>>> REACH the diagonal. Hard to compute a diagonal with "holes" in >>>>>>>>> it (since "hole" isn't a valid symbol)
Again, it seems you don't care if you work can actually be >>>>>>>>>>> useful, as you seem to accept that it is ok to spend a lot of >>>>>>>>>>> time in mundane problems with known solutions, while also >>>>>>>>>>> adding in booby- traps (like accepting circular machines into >>>>>>>>>>> your enumeration) that makes quantifying what you are doing >>>>>>>>>>> nearly impossible.
sloppier_H is not selecting for or even attempting to select >>>>>>>>>>>> for "computable sequences"
I have shown a way to build a computable number that you >>>>>>>>>>>>>>> enumeration doesn't include, and thus it can't be a >>>>>>>>>>>>>>> complete enumeration, as you claim it is supposedly by >>>>>>>>>>>>>>> some "magic" assumptions.
u don't really seem aware of where we've ended up:
Yep, that is your problem, as you don't understand what >>>>>>>>>>>>> problem you are working on because you are just
fundamentally ignorant of what you are talking about. >>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you >>>>>>>>>>> description of what the based decider is doing by trying to >>>>>>>>>>> filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable >>>>>>>>>>>>>> numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across >>>>>>>>>>>> them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>>> diagonal, therefor _all machines_ is not effectively enumerable >>>>>>>>>>>>
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, >>>>>>>>>>> doesn't mean we can "compute the diagonal" of the output of >>>>>>>>>>> all machines, as some
if i mean if machine enumerability _does not imply_ being able >>>>>>>>>> to compute a diagonal across the machines being enumerated, >>>>>>>>>
ei: if enumerability of a set of machines is independent from >>>>>>>>>> being able to compute a diagonal across the set of machine, >>>>>>>>>>
then one _cannot_ use an inability to compute a diagonal to >>>>>>>>>> prove a lack of enumerability, and u've lost turing's proof >>>>>>>>>> against the enumerability of computable numbers
Which showds you don't understand the difference between just >>>>>>>>> enumerating any ol machine, and enumerating circle-free machines. >>>>>>>>
why does failing to produce a diagonal for one set (computable >>>>>>>> numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we >>>>>>> could build the diagonal (or anti-diagonal) computation from the >>>>>>> algorithm of the effective enumeration.
clearly building a diagonal is not required for a set of machines >>>>>> to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a
full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any
diagonal because it's based off the output of the diagonal
computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the diagonal
doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as all
the machines generate enough data to reach it, you can compute the
diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of
machine that all reach the diagonal with a machine in that which
doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every machine
reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in
principles
What inconsistency?
can't compute diagonal across computable numbers => proof against
effective enumerability
can't compute diagonal across all executable machines => not proof
against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be the
reason you can't compute it.
totally inconsistent rick, and idk how to make that more clear tbh
Just like your K < K claim, since that diagonal computation
apparently reached the diagonal in one view to create it, but also
can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration that sloppier_H is incomplete, it is uninteresting.
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't a VALUE output, but the id number of the row being output, and the digit on that
row being outputed.
Your just implied that every row makes it to the diagonal, as sloppier_H
can generate the diagonal, which means that anti_sloppier_H can't be in
that enumeration, and thus anti_sloppier_H can't get "stuck" on it
trying to get there.
For sloppier_H to work, the Kth row need to compute at least K digits,
and thus any machine like turing's original H that looks to see what it
does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special
number, but anti_sloppier_H won't do that, so sloppier_H will never put
it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference" number
as sloppier_H, NOT its own, and thus it WILL get the anti-diagonal that
is the opposite of sloppier_H, and won't get hung up on itself, since neither did sloppier_H get hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do
accurate work because "correct" isn't a word you understand.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist
(like the diagonal of an enumeration that includes circular machines)
so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than 2
doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your
modus operandi.
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:enumerating a set of machines is enumerating a set of machines >>>>>>>>> eh????
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:
On 3/29/26 1:25 PM, dart200 wrote:
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to construct >>>>>>>>>>>>>>>>>>>>>>> a smarter TM diagonal across the circle-free >>>>>>>>>>>>>>>>>>>>>>> computable numbers that defeats all variants of >>>>>>>>>>>>>>>>>>>>>>> anti_fixed_H,
it's not an enumeration of computable numbers, it's >>>>>>>>>>>>>>>>>>>>> a superset of said enumeration that includes some >>>>>>>>>>>>>>>>>>>>> "circular" machines, but should include all >>>>>>>>>>>>>>>>>>>>> computable numbers
Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes some >>>>>>>>>>>>>>>>>>>>>>> circular numbers as well. for this i will >>>>>>>>>>>>>>>>>>>>>>> introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration of the >>>>>>>>>>>>>>>>>>>>>> "computable numbers" it generates isn't valid, as >>>>>>>>>>>>>>>>>>>>>> the array of values has holes in it. >>>>>>>>>>>>>>>>>>>>>
No, it is a decider that enumerates machines that is >>>>>>>>>>>>>>>>>>>> supposed to generate that, but then a machine that >>>>>>>>>>>>>>>>>>>> tries to use it to enumerate all enumerable numbers >>>>>>>>>>>>>>>>>>>> will hang and not generate the enumeration. >>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration for >>>>>>>>>>>>>>>>>>>> getting you to the goal of showing how to compute an >>>>>>>>>>>>>>>>>>>> enumeration of all computable numbers. >>>>>>>>>>>>>>>>>>>>
Note, because the set of "computable numbers" are >>>>>>>>>>>>>>>>>>>> (as you have pointed out) NOT the same machines that >>>>>>>>>>>>>>>>>>>> compute them, Your "super set" as described isn't a >>>>>>>>>>>>>>>>>>>> set of one sort of thing, and is actually (as I just >>>>>>>>>>>>>>>>>>>> described) a set of MACHINES that compute computable >>>>>>>>>>>>>>>>>>>> numbers + some machines that are circular. >>>>>>>>>>>>>>>>>>>>
The presence of the circular machines in the set >>>>>>>>>>>>>>>>>>>> means you can't use that set to compute the >>>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>>> circular machines in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular machines, >>>>>>>>>>>>>>>>>>>> as they are easier to talk about processing, as they >>>>>>>>>>>>>>>>>>>> are finite things, while the elements of the >>>>>>>>>>>>>>>>>>>> computable numbers are not, and if you try to talk >>>>>>>>>>>>>>>>>>>> about using ONE machine that generates it, you have >>>>>>>>>>>>>>>>>>>> the problem of selecting that one machine from the >>>>>>>>>>>>>>>>>>>> infinite set that generates it.
we can avoid that using a stepping simulation while >>>>>>>>>>>>>>>>>>>>> dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>>>>>> output, because it was one of those non- circle- >>>>>>>>>>>>>>>>>>>>>> free machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for >>>>>>>>>>>>>>>>>>>> all machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>>>>>>> program to find the first even number that can't be >>>>>>>>>>>>>>>>>>>> found as the sum of two prime, will run forever but >>>>>>>>>>>>>>>>>>>> never hit a repeated state.
step_detect_loop = (M, K) -> {
STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached >>>>>>>>>>>>>>>>>>>>> before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one >>>>>>>>>>>>>>>>>>>>> step as a time
if (res == STEP) {
continue
} // outputs
other than STEP
if (res != LOOP) { // indicate
we're done
output res //
dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // internally
tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>>>> configuration is reached twice
2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, but >>>>>>>>>>>>>>>>>>>>>> it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>>>> circular machines end up on the list
And why can't that same program be used to compute >>>>>>>>>>>>>>>>>>>> the sloppy- anti- diagonal (where you still test the >>>>>>>>>>>>>>>>>>>> M with DN(sloppy_H) not changing that, and then >>>>>>>>>>>>>>>>>>>> reverse the output of the two outputs. >>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because the >>>>>>>>>>>>>>>>>>>> anti- program does EXACTLY the same steps it will >>>>>>>>>>>>>>>>>>>> also create an anti- diagonal, which could not have >>>>>>>>>>>>>>>>>>>> been from a machine in the listing, thus showing >>>>>>>>>>>>>>>>>>>> your enumation doesn't include ALL machines for ALL >>>>>>>>>>>>>>>>>>>> the computable numbers.
Why won't it be able to simulate it?
i guess at this point there's little point to even >>>>>>>>>>>>>>>>>>>>> try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has been >>>>>>>>>>>>>>>>>>>>> output
}
every time step is called it advances the machine's >>>>>>>>>>>>>>>>>>>>> runtime, recording any output alone the way. after >>>>>>>>>>>>>>>>>>>>> the step is complete, if the Kth output has been >>>>>>>>>>>>>>>>>>>>> recorded already it will output that. however if >>>>>>>>>>>>>>>>>>>>> the Kth output has not already been output by the >>>>>>>>>>>>>>>>>>>>> machine then STEP it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one
step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>> list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what happens to >>>>>>>>>>>>>>>>>>>>> anti_sloppier_H when sloppier_H starts dovetailing >>>>>>>>>>>>>>>>>>>>> it. i'm kinda guessing at the moment that the K >>>>>>>>>>>>>>>>>>>>> within sloppier_H grows faster than the K within >>>>>>>>>>>>>>>>>>>>> anti_sloppier_H and therefore sloppier_H will just >>>>>>>>>>>>>>>>>>>>> never actually output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,
And how does the writing out the program nti- >>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as the >>>>>>>>>>>>>>>>>> code for the machine with its number.
No, it is supposed to be EXACTLY simulating the steps >>>>>>>>>>>>>>>>>> of sloppier_H.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's runtime >>>>>>>>>>>>>>>>>>> with extra steps for each cycle K ... mean >>>>>>>>>>>>>>>>>>> sloppier_H's K _must_ grow faster than
anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of >>>>>>>>>>>>>>>>> after each step of sloppier_H, to see if an output was >>>>>>>>>>>>>>>>> found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to >>>>>>>>>>>>>>>> anti- sloppier_H
this is done for every step of sloppier_H, so therefore >>>>>>>>>>>>>>>>> run head to head, anti_sloppier_H will output slower >>>>>>>>>>>>>>>>> than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit >>>>>>>>>>>>>>>>> for that particular K...
Right. and the execution of anti-sloppier_H will EXACTLY >>>>>>>>>>>>>>>> follow the behavior of sloppier_H (even though at a >>>>>>>>>>>>>>>> slower rate) and will EXAXTLY output the opposite that >>>>>>>>>>>>>>>> sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output >>>>>>>>>>>>>>>>> for some particular K until after sloppier_H has >>>>>>>>>>>>>>>>> started looking for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on >>>>>>>>>>>>>>>>> the diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't >>>>>>>>>>>>>> include the required COMPLETE set of computable numbers. >>>>>>>>>>>>>>
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to >>>>>>>>>>>>>> be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a computable >>>>>>>>>>>>>>>> number, at least as long as your sloppier_H outputs a >>>>>>>>>>>>>>>> computable number as the diagonal, it needed to in order >>>>>>>>>>>>>>>> for the diagonal to be of a complete enumeration of >>>>>>>>>>>>>>>> computable numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, >>>>>>>>>>>>>>>> and thus the computable number it computes can't be in >>>>>>>>>>>>>>>> the enumeration that it is working from.
it is therefore _not_ possible to effectively enumerate >>>>>>>>>>>>>>>>> _all machines_ , in direct contradiction to the >>>>>>>>>>>>>>>>> obviously effective enumerability used to create >>>>>>>>>>>>>>>>> sloppier_H in the first place
But the effective enumeration used to create sloppier_H >>>>>>>>>>>>>>>> can't be complete, and thus isn't a effetive enumeration >>>>>>>>>>>>>>>> of a super- set of machine the of at least one machine >>>>>>>>>>>>>>>> the computes every computable number.
You seem to have forgotten your own requirement that the >>>>>>>>>>>>>>>> enumeration was to include at least one machine that >>>>>>>>>>>>>>>> computes every computable number.
Yes, there are many computably enumerated SUB-sets of >>>>>>>>>>>>>>>> the computable numbers, just not one for a complete set >>>>>>>>>>>>>>>> of them.
All you are doing is showing you don't understand what >>>>>>>>>>>>>>>> it means to be correct.
Maybe you should test your machines to see if they meet >>>>>>>>>>>>>>>> your requirements, after all, you complaint was about >>>>>>>>>>>>>>>> people releasing code that wasn't proven to be correct. >>>>>>>>>>>>>>>>
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>
But that was the problem you were trying to solve.
that was...
but it's not what we are dealing with in sloppier_H
So, what use is that problem, if you are admitting that you >>>>>>>>>>>> can't compute the diagonal of an enumeration that includes >>>>>>>>>>>> all computable numbers? (which is at least close to what >>>>>>>>>>>> Turing was talking about).
Computing the diagonal of a comuptable enumeration that is >>>>>>>>>>>> admittedly containing only a subset of the computable >>>>>>>>>>>> numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>> yourself to just wonder off into uninteresting problems with >>>>>>>>>>>> no attempt to justify why they might be interesting because >>>>>>>>>>>> you are doing them better that how they have been done >>>>>>>>>>>> before, you are just wasting everyone's time.
And when you let yourself wonder into mundane and non- >>>>>>>>>>>> inovative areas, you can waste a LOT of time.
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>>>>> running any whatever machine that we come across, and >>>>>>>>>>>>>>> trying to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just >>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets allow D >>>>>>>>>>>>>> to not select EVERY non-circular machine, just it needs to >>>>>>>>>>>>>> select at least one for each computable number.
The computable number of the anti-diagonal isn't in the >>>>>>>>>>>>>> set of numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the >>>>>>>>>>>>>> problem, because you attention span is apparently to short >>>>>>>>>>>>>> to take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>>>>
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem. >>>>>>>>>>
WHy should it. Many machines are circular, and thus might not >>>>>>>>>> REACH the diagonal. Hard to compute a diagonal with "holes" in >>>>>>>>>> it (since "hole" isn't a valid symbol)
Again, it seems you don't care if you work can actually be >>>>>>>>>>>> useful, as you seem to accept that it is ok to spend a lot >>>>>>>>>>>> of time in mundane problems with known solutions, while also >>>>>>>>>>>> adding in booby- traps (like accepting circular machines >>>>>>>>>>>> into your enumeration) that makes quantifying what you are >>>>>>>>>>>> doing nearly impossible.
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand what >>>>>>>>>>>>>> problem you are working on because you are just
I have shown a way to build a computable number that you >>>>>>>>>>>>>>>> enumeration doesn't include, and thus it can't be a >>>>>>>>>>>>>>>> complete enumeration, as you claim it is supposedly by >>>>>>>>>>>>>>>> some "magic" assumptions.
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>
fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you >>>>>>>>>>>> description of what the based decider is doing by trying to >>>>>>>>>>>> filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable >>>>>>>>>>>>>>> numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across >>>>>>>>>>>>> them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>>>> diagonal, therefor _all machines_ is not effectively >>>>>>>>>>>>> enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, >>>>>>>>>>>> doesn't mean we can "compute the diagonal" of the output of >>>>>>>>>>>> all machines, as some
if i mean if machine enumerability _does not imply_ being >>>>>>>>>>> able to compute a diagonal across the machines being enumerated, >>>>>>>>>>
ei: if enumerability of a set of machines is independent from >>>>>>>>>>> being able to compute a diagonal across the set of machine, >>>>>>>>>>>
then one _cannot_ use an inability to compute a diagonal to >>>>>>>>>>> prove a lack of enumerability, and u've lost turing's proof >>>>>>>>>>> against the enumerability of computable numbers
Which showds you don't understand the difference between just >>>>>>>>>> enumerating any ol machine, and enumerating circle-free machines. >>>>>>>>>
why does failing to produce a diagonal for one set (computable >>>>>>>>> numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we >>>>>>>> could build the diagonal (or anti-diagonal) computation from the >>>>>>>> algorithm of the effective enumeration.
clearly building a diagonal is not required for a set of machines >>>>>>> to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a
full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any
diagonal because it's based off the output of the diagonal
computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the
diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as all
the machines generate enough data to reach it, you can compute the
diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of
machine that all reach the diagonal with a machine in that which
doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every machine
reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in
principles
What inconsistency?
can't compute diagonal across computable numbers => proof against
effective enumerability
can't compute diagonal across all executable machines => not proof
against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be the
reason you can't compute it.
totally inconsistent rick, and idk how to make that more clear tbh
Just like your K < K claim, since that diagonal computation
apparently reached the diagonal in one view to create it, but also
can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration that
sloppier_H is incomplete, it is uninteresting.
i think it's _very_ interesting that despite have a method to enumerate _all_ machines, which includes _all_ computable numbers, it's still not possible to put all the computable numbers within that set on a diagonal:
clearly being able to enumerate a set of machines, does _not_ then imply
one can certainly construct a diagonal across the computable numbers
within that set
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't a
VALUE output, but the id number of the row being output, and the digit
on that row being outputed.
Your just implied that every row makes it to the diagonal, as
sloppier_H can generate the diagonal, which means that anti_sloppier_H
can't be in that enumeration, and thus anti_sloppier_H can't get
"stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K digits,
and thus any machine like turing's original H that looks to see what
it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special
number, but anti_sloppier_H won't do that, so sloppier_H will never
put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference"
number as sloppier_H, NOT its own, and thus it WILL get the anti-
diagonal that is the opposite of sloppier_H, and won't get hung up on
itself, since neither did sloppier_H get hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do
accurate work because "correct" isn't a word you understand.
y do u think i disagree with any of that?
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist
(like the diagonal of an enumeration that includes circular
machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than 2
doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your
modus operandi.
On 4/1/26 12:06 PM, dart200 wrote:
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:So, what use is that problem, if you are admitting that you >>>>>>>>>>>>> can't compute the diagonal of an enumeration that includes >>>>>>>>>>>>> all computable numbers? (which is at least close to what >>>>>>>>>>>>> Turing was talking about).
On 3/29/26 1:25 PM, dart200 wrote:that was...
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote:
On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote:
On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to construct >>>>>>>>>>>>>>>>>>>>>>>> a smarter TM diagonal across the circle-free >>>>>>>>>>>>>>>>>>>>>>>> computable numbers that defeats all variants of >>>>>>>>>>>>>>>>>>>>>>>> anti_fixed_H,
it's not an enumeration of computable numbers, >>>>>>>>>>>>>>>>>>>>>> it's a superset of said enumeration that includes >>>>>>>>>>>>>>>>>>>>>> some "circular" machines, but should include all >>>>>>>>>>>>>>>>>>>>>> computable numbers
Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes some >>>>>>>>>>>>>>>>>>>>>>>> circular numbers as well. for this i will >>>>>>>>>>>>>>>>>>>>>>>> introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration of >>>>>>>>>>>>>>>>>>>>>>> the "computable numbers" it generates isn't >>>>>>>>>>>>>>>>>>>>>>> valid, as the array of values has holes in it. >>>>>>>>>>>>>>>>>>>>>>
No, it is a decider that enumerates machines that >>>>>>>>>>>>>>>>>>>>> is supposed to generate that, but then a machine >>>>>>>>>>>>>>>>>>>>> that tries to use it to enumerate all enumerable >>>>>>>>>>>>>>>>>>>>> numbers will hang and not generate the enumeration. >>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration >>>>>>>>>>>>>>>>>>>>> for getting you to the goal of showing how to >>>>>>>>>>>>>>>>>>>>> compute an enumeration of all computable numbers. >>>>>>>>>>>>>>>>>>>>>
Note, because the set of "computable numbers" are >>>>>>>>>>>>>>>>>>>>> (as you have pointed out) NOT the same machines >>>>>>>>>>>>>>>>>>>>> that compute them, Your "super set" as described >>>>>>>>>>>>>>>>>>>>> isn't a set of one sort of thing, and is actually >>>>>>>>>>>>>>>>>>>>> (as I just described) a set of MACHINES that >>>>>>>>>>>>>>>>>>>>> compute computable numbers + some machines that are >>>>>>>>>>>>>>>>>>>>> circular.
The presence of the circular machines in the set >>>>>>>>>>>>>>>>>>>>> means you can't use that set to compute the >>>>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>>>> circular machines in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular machines, >>>>>>>>>>>>>>>>>>>>> as they are easier to talk about processing, as >>>>>>>>>>>>>>>>>>>>> they are finite things, while the elements of the >>>>>>>>>>>>>>>>>>>>> computable numbers are not, and if you try to talk >>>>>>>>>>>>>>>>>>>>> about using ONE machine that generates it, you have >>>>>>>>>>>>>>>>>>>>> the problem of selecting that one machine from the >>>>>>>>>>>>>>>>>>>>> infinite set that generates it.
we can avoid that using a stepping simulation >>>>>>>>>>>>>>>>>>>>>> while dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>>>>>>> output, because it was one of those non- circle- >>>>>>>>>>>>>>>>>>>>>>> free machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for >>>>>>>>>>>>>>>>>>>>> all machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is true, a >>>>>>>>>>>>>>>>>>>>> program to find the first even number that can't be >>>>>>>>>>>>>>>>>>>>> found as the sum of two prime, will run forever but >>>>>>>>>>>>>>>>>>>>> never hit a repeated state.
And why can't that same program be used to compute >>>>>>>>>>>>>>>>>>>>> the sloppy- anti- diagonal (where you still test >>>>>>>>>>>>>>>>>>>>> the M with DN(sloppy_H) not changing that, and then >>>>>>>>>>>>>>>>>>>>> reverse the output of the two outputs. >>>>>>>>>>>>>>>>>>>>>
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>> STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step_detect_loop(m, K) // sim one
step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>> continue
} // outputs
other than STEP
if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // >>>>>>>>>>>>>>>>>>>>>> internally tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>>>>> configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, but >>>>>>>>>>>>>>>>>>>>>>> it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>>>>> circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because the >>>>>>>>>>>>>>>>>>>>> anti- program does EXACTLY the same steps it will >>>>>>>>>>>>>>>>>>>>> also create an anti- diagonal, which could not have >>>>>>>>>>>>>>>>>>>>> been from a machine in the listing, thus showing >>>>>>>>>>>>>>>>>>>>> your enumation doesn't include ALL machines for ALL >>>>>>>>>>>>>>>>>>>>> the computable numbers.
i guess at this point there's little point to even >>>>>>>>>>>>>>>>>>>>>> try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has >>>>>>>>>>>>>>>>>>>>>> been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output alone the >>>>>>>>>>>>>>>>>>>>>> way. after the step is complete, if the Kth output >>>>>>>>>>>>>>>>>>>>>> has been recorded already it will output that. >>>>>>>>>>>>>>>>>>>>>> however if the Kth output has not already been >>>>>>>>>>>>>>>>>>>>>> output by the machine then STEP it output >>>>>>>>>>>>>>>>>>>>>>
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) {
res = step(m, K) // sim one
step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>> list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what happens >>>>>>>>>>>>>>>>>>>>>> to anti_sloppier_H when sloppier_H starts >>>>>>>>>>>>>>>>>>>>>> dovetailing it. i'm kinda guessing at the moment >>>>>>>>>>>>>>>>>>>>>> that the K within sloppier_H grows faster than the >>>>>>>>>>>>>>>>>>>>>> K within anti_sloppier_H and therefore sloppier_H >>>>>>>>>>>>>>>>>>>>>> will just never actually output a digit from >>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H ...
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently.
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,
And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as the >>>>>>>>>>>>>>>>>>> code for the machine with its number.
No, it is supposed to be EXACTLY simulating the steps >>>>>>>>>>>>>>>>>>> of sloppier_H.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it will >>>>>>>>>>>>>>>>>>>> constantly run behind sloppier's K for several reasons: >>>>>>>>>>>>>>>>>>>
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... mean >>>>>>>>>>>>>>>>>>>> sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of >>>>>>>>>>>>>>>>>> after each step of sloppier_H, to see if an output was >>>>>>>>>>>>>>>>>> found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives to >>>>>>>>>>>>>>>>> anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>> output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit >>>>>>>>>>>>>>>>>> for that particular K...
Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even though >>>>>>>>>>>>>>>>> at a slower rate) and will EXAXTLY output the opposite >>>>>>>>>>>>>>>>> that sloppier_H outputs.
so there is no way for anti_sloppier_H to ever output >>>>>>>>>>>>>>>>>> for some particular K until after sloppier_H has >>>>>>>>>>>>>>>>>> started looking for at least a K+1 digit,
So?
meaning sloppier_H will never put anti_sloppier_H on >>>>>>>>>>>>>>>>>> the diagonal
Right.
yup
And thus, your diagonal that you claim to compute doesn't >>>>>>>>>>>>>>> include the required COMPLETE set of computable numbers. >>>>>>>>>>>>>>>
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs to >>>>>>>>>>>>>>> be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>> computable number, at least as long as your sloppier_H >>>>>>>>>>>>>>>>> outputs a computable number as the diagonal, it needed >>>>>>>>>>>>>>>>> to in order for the diagonal to be of a complete >>>>>>>>>>>>>>>>> enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal that >>>>>>>>>>>>>>>>> matches the anti-diagonal computed by anti-slippier-H, >>>>>>>>>>>>>>>>> and thus the computable number it computes can't be in >>>>>>>>>>>>>>>>> the enumeration that it is working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct contradiction to >>>>>>>>>>>>>>>>>> the obviously effective enumerability used to create >>>>>>>>>>>>>>>>>> sloppier_H in the first place
But the effective enumeration used to create sloppier_H >>>>>>>>>>>>>>>>> can't be complete, and thus isn't a effetive >>>>>>>>>>>>>>>>> enumeration of a super- set of machine the of at least >>>>>>>>>>>>>>>>> one machine the computes every computable number. >>>>>>>>>>>>>>>>>
You seem to have forgotten your own requirement that >>>>>>>>>>>>>>>>> the enumeration was to include at least one machine >>>>>>>>>>>>>>>>> that computes every computable number.
Yes, there are many computably enumerated SUB-sets of >>>>>>>>>>>>>>>>> the computable numbers, just not one for a complete set >>>>>>>>>>>>>>>>> of them.
All you are doing is showing you don't understand what >>>>>>>>>>>>>>>>> it means to be correct.
Maybe you should test your machines to see if they meet >>>>>>>>>>>>>>>>> your requirements, after all, you complaint was about >>>>>>>>>>>>>>>>> people releasing code that wasn't proven to be correct. >>>>>>>>>>>>>>>>>
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration that is >>>>>>>>>>>>> admittedly containing only a subset of the computable >>>>>>>>>>>>> numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>> yourself to just wonder off into uninteresting problems >>>>>>>>>>>>> with no attempt to justify why they might be interesting >>>>>>>>>>>>> because you are doing them better that how they have been >>>>>>>>>>>>> done before, you are just wasting everyone's time.
And when you let yourself wonder into mundane and non- >>>>>>>>>>>>> inovative areas, you can waste a LOT of time.
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>>>>>> running any whatever machine that we come across, and >>>>>>>>>>>>>>>> trying to put it on a diagonal
In other words, you are just computing garbage.
You forgot the problem you were working on, and just >>>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets allow D >>>>>>>>>>>>>>> to not select EVERY non-circular machine, just it needs >>>>>>>>>>>>>>> to select at least one for each computable number. >>>>>>>>>>>>>>>
The computable number of the anti-diagonal isn't in the >>>>>>>>>>>>>>> set of numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the >>>>>>>>>>>>>>> problem, because you attention span is apparently to >>>>>>>>>>>>>>> short to take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>>>>>
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your problem. >>>>>>>>>>>
Again, it seems you don't care if you work can actually be >>>>>>>>>>>>> useful, as you seem to accept that it is ok to spend a lot >>>>>>>>>>>>> of time in mundane problems with known solutions, while >>>>>>>>>>>>> also adding in booby- traps (like accepting circular >>>>>>>>>>>>> machines into your enumeration) that makes quantifying what >>>>>>>>>>>>> you are doing nearly impossible.
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand what >>>>>>>>>>>>>>> problem you are working on because you are just >>>>>>>>>>>>>>> fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>>
I have shown a way to build a computable number that >>>>>>>>>>>>>>>>> you enumeration doesn't include, and thus it can't be a >>>>>>>>>>>>>>>>> complete enumeration, as you claim it is supposedly by >>>>>>>>>>>>>>>>> some "magic" assumptions.
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you >>>>>>>>>>>>> description of what the based decider is doing by trying to >>>>>>>>>>>>> filter out inputs that hit repeat state.
disproving an ability to enumerate _not_ just computable >>>>>>>>>>>>>>>> numbers, but actually _all machines_
But "All Machines" are enumerable.
therefore i should be able to construct a diagonal across >>>>>>>>>>>>>> them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>>>>> diagonal, therefor _all machines_ is not effectively >>>>>>>>>>>>>> enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all machines, >>>>>>>>>>>>> doesn't mean we can "compute the diagonal" of the output of >>>>>>>>>>>>> all machines, as some
if i mean if machine enumerability _does not imply_ being >>>>>>>>>>>> able to compute a diagonal across the machines being
enumerated,
WHy should it. Many machines are circular, and thus might not >>>>>>>>>>> REACH the diagonal. Hard to compute a diagonal with "holes" >>>>>>>>>>> in it (since "hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent >>>>>>>>>>>> from being able to compute a diagonal across the set of >>>>>>>>>>>> machine,
then one _cannot_ use an inability to compute a diagonal to >>>>>>>>>>>> prove a lack of enumerability, and u've lost turing's proof >>>>>>>>>>>> against the enumerability of computable numbers
Which showds you don't understand the difference between just >>>>>>>>>>> enumerating any ol machine, and enumerating circle-free >>>>>>>>>>> machines.
enumerating a set of machines is enumerating a set of machines >>>>>>>>>> eh????
why does failing to produce a diagonal for one set (computable >>>>>>>>>> numbers) imply it's not effectively enumerability,
Because if it WAS effectively enumerable, you could, because we >>>>>>>>> could build the diagonal (or anti-diagonal) computation from >>>>>>>>> the algorithm of the effective enumeration.
clearly building a diagonal is not required for a set of
machines to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a >>>>>>> full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any >>>>>> diagonal because it's based off the output of the diagonal
computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the
diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as all >>>>> the machines generate enough data to reach it, you can compute the
diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of
machine that all reach the diagonal with a machine in that which
doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every machine
reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in >>>>>>>> principles
What inconsistency?
can't compute diagonal across computable numbers => proof against >>>>>> effective enumerability
can't compute diagonal across all executable machines => not proof >>>>>> against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be
the reason you can't compute it.
totally inconsistent rick, and idk how to make that more clear tbh
Just like your K < K claim, since that diagonal computation
apparently reached the diagonal in one view to create it, but also
can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration
that sloppier_H is incomplete, it is uninteresting.
i think it's _very_ interesting that despite have a method to
enumerate _all_ machines, which includes _all_ computable numbers,
it's still not possible to put all the computable numbers within that
set on a diagonal:
Right, because you can't create the "diagonal" for all machines, as it
doesn't exist, as if you try to generate the grid of running all
machines as enumerated doesh't always reach the diagonal.
It seems you have a fundamental problem about thinking through the requirements, as "requirements" are just optional ideas to you.
clearly being able to enumerate a set of machines, does _not_ then
imply one can certainly construct a diagonal across the computable
numbers within that set
Because the determination that a given machine create a computable
number is an uncomputable operation.
What is so hard about that?
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't a
VALUE output, but the id number of the row being output, and the
digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as
sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K
digits, and thus any machine like turing's original H that looks to
see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special
number, but anti_sloppier_H won't do that, so sloppier_H will never
put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference"
number as sloppier_H, NOT its own, and thus it WILL get the anti-
diagonal that is the opposite of sloppier_H, and won't get hung up on
itself, since neither did sloppier_H get hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do
accurate work because "correct" isn't a word you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to follow
instructions because you are mentally unable to do accurate work becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't understand
what that impies.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist
(like the diagonal of an enumeration that includes circular
machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than 2
doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your
modus operandi.
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:Because if it WAS effectively enumerable, you could, because >>>>>>>>>> we could build the diagonal (or anti-diagonal) computation >>>>>>>>>> from the algorithm of the effective enumeration.
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:So, what use is that problem, if you are admitting that >>>>>>>>>>>>>> you can't compute the diagonal of an enumeration that >>>>>>>>>>>>>> includes all computable numbers? (which is at least close >>>>>>>>>>>>>> to what Turing was talking about).
On 3/29/26 1:25 PM, dart200 wrote:that was...
On 3/29/26 10:07 AM, Richard Damon wrote:
On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across the >>>>>>>>>>>>>>>>>>>>>>>>> circle-free computable numbers that defeats all >>>>>>>>>>>>>>>>>>>>>>>>> variants of anti_fixed_H,
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,it's not an enumeration of computable numbers, >>>>>>>>>>>>>>>>>>>>>>> it's a superset of said enumeration that includes >>>>>>>>>>>>>>>>>>>>>>> some "circular" machines, but should include all >>>>>>>>>>>>>>>>>>>>>>> computable numbers
Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes >>>>>>>>>>>>>>>>>>>>>>>>> some circular numbers as well. for this i will >>>>>>>>>>>>>>>>>>>>>>>>> introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration of >>>>>>>>>>>>>>>>>>>>>>>> the "computable numbers" it generates isn't >>>>>>>>>>>>>>>>>>>>>>>> valid, as the array of values has holes in it. >>>>>>>>>>>>>>>>>>>>>>>
No, it is a decider that enumerates machines that >>>>>>>>>>>>>>>>>>>>>> is supposed to generate that, but then a machine >>>>>>>>>>>>>>>>>>>>>> that tries to use it to enumerate all enumerable >>>>>>>>>>>>>>>>>>>>>> numbers will hang and not generate the enumeration. >>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration >>>>>>>>>>>>>>>>>>>>>> for getting you to the goal of showing how to >>>>>>>>>>>>>>>>>>>>>> compute an enumeration of all computable numbers. >>>>>>>>>>>>>>>>>>>>>>
Note, because the set of "computable numbers" are >>>>>>>>>>>>>>>>>>>>>> (as you have pointed out) NOT the same machines >>>>>>>>>>>>>>>>>>>>>> that compute them, Your "super set" as described >>>>>>>>>>>>>>>>>>>>>> isn't a set of one sort of thing, and is actually >>>>>>>>>>>>>>>>>>>>>> (as I just described) a set of MACHINES that >>>>>>>>>>>>>>>>>>>>>> compute computable numbers + some machines that >>>>>>>>>>>>>>>>>>>>>> are circular.
The presence of the circular machines in the set >>>>>>>>>>>>>>>>>>>>>> means you can't use that set to compute the >>>>>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>>>>> circular machines in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular >>>>>>>>>>>>>>>>>>>>>> machines, as they are easier to talk about >>>>>>>>>>>>>>>>>>>>>> processing, as they are finite things, while the >>>>>>>>>>>>>>>>>>>>>> elements of the computable numbers are not, and if >>>>>>>>>>>>>>>>>>>>>> you try to talk about using ONE machine that >>>>>>>>>>>>>>>>>>>>>> generates it, you have the problem of selecting >>>>>>>>>>>>>>>>>>>>>> that one machine from the infinite set that >>>>>>>>>>>>>>>>>>>>>> generates it.
we can avoid that using a stepping simulation >>>>>>>>>>>>>>>>>>>>>>> while dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the kth >>>>>>>>>>>>>>>>>>>>>>>> machine in the list doesn't generate k digits of >>>>>>>>>>>>>>>>>>>>>>>> output, because it was one of those non- circle- >>>>>>>>>>>>>>>>>>>>>>>> free machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything for >>>>>>>>>>>>>>>>>>>>>> all machines, as not all circularity is detectable. >>>>>>>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is true, >>>>>>>>>>>>>>>>>>>>>> a program to find the first even number that can't >>>>>>>>>>>>>>>>>>>>>> be found as the sum of two prime, will run forever >>>>>>>>>>>>>>>>>>>>>> but never hit a repeated state.
And why can't that same program be used to compute >>>>>>>>>>>>>>>>>>>>>> the sloppy- anti- diagonal (where you still test >>>>>>>>>>>>>>>>>>>>>> the M with DN(sloppy_H) not changing that, and >>>>>>>>>>>>>>>>>>>>>> then reverse the output of the two outputs. >>>>>>>>>>>>>>>>>>>>>>
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>> STEP: step completed,
LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // sim one
step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>> continue
} // outputs
other than STEP
if (res != LOOP) { // indicate
we're done
output res //
dovetailing this machine
K += 1
}
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // >>>>>>>>>>>>>>>>>>>>>>> internally tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>>>>>> configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected when a >>>>>>>>>>>>>>>>>>>>>>>>> simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, >>>>>>>>>>>>>>>>>>>>>>>> but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>>>>>> circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because the >>>>>>>>>>>>>>>>>>>>>> anti- program does EXACTLY the same steps it will >>>>>>>>>>>>>>>>>>>>>> also create an anti- diagonal, which could not >>>>>>>>>>>>>>>>>>>>>> have been from a machine in the listing, thus >>>>>>>>>>>>>>>>>>>>>> showing your enumation doesn't include ALL >>>>>>>>>>>>>>>>>>>>>> machines for ALL the computable numbers. >>>>>>>>>>>>>>>>>>>>>>
i guess at this point there's little point to >>>>>>>>>>>>>>>>>>>>>>> even try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed,
kth digit of M: if the Kth digit of M has >>>>>>>>>>>>>>>>>>>>>>> been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output alone the >>>>>>>>>>>>>>>>>>>>>>> way. after the step is complete, if the Kth >>>>>>>>>>>>>>>>>>>>>>> output has been recorded already it will output >>>>>>>>>>>>>>>>>>>>>>> that. however if the Kth output has not already >>>>>>>>>>>>>>>>>>>>>>> been output by the machine then STEP it output >>>>>>>>>>>>>>>>>>>>>>>
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) // sim one
step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m)
}
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>> list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> {
K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what happens >>>>>>>>>>>>>>>>>>>>>>> to anti_sloppier_H when sloppier_H starts >>>>>>>>>>>>>>>>>>>>>>> dovetailing it. i'm kinda guessing at the moment >>>>>>>>>>>>>>>>>>>>>>> that the K within sloppier_H grows faster than >>>>>>>>>>>>>>>>>>>>>>> the K within anti_sloppier_H and therefore >>>>>>>>>>>>>>>>>>>>>>> sloppier_H will just never actually output a >>>>>>>>>>>>>>>>>>>>>>> digit from anti_sloppier_H ...
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>
And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as the >>>>>>>>>>>>>>>>>>>> code for the machine with its number.
No, it is supposed to be EXACTLY simulating the >>>>>>>>>>>>>>>>>>>> steps of sloppier_H.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it >>>>>>>>>>>>>>>>>>>>> will constantly run behind sloppier's K for several >>>>>>>>>>>>>>>>>>>>> reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... mean >>>>>>>>>>>>>>>>>>>>> sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of >>>>>>>>>>>>>>>>>>> after each step of sloppier_H, to see if an output >>>>>>>>>>>>>>>>>>> was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives >>>>>>>>>>>>>>>>>> to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>>> output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a digit >>>>>>>>>>>>>>>>>>> for that particular K...
Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even though >>>>>>>>>>>>>>>>>> at a slower rate) and will EXAXTLY output the opposite >>>>>>>>>>>>>>>>>> that sloppier_H outputs.
So?
so there is no way for anti_sloppier_H to ever output >>>>>>>>>>>>>>>>>>> for some particular K until after sloppier_H has >>>>>>>>>>>>>>>>>>> started looking for at least a K+1 digit, >>>>>>>>>>>>>>>>>>
meaning sloppier_H will never put anti_sloppier_H on >>>>>>>>>>>>>>>>>>> the diagonal
Right.
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of computable >>>>>>>>>>>>>>>> numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs >>>>>>>>>>>>>>>> to be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>> computable number, at least as long as your sloppier_H >>>>>>>>>>>>>>>>>> outputs a computable number as the diagonal, it needed >>>>>>>>>>>>>>>>>> to in order for the diagonal to be of a complete >>>>>>>>>>>>>>>>>> enumeration of computable numbers.
Sloppier H can NEVER output a digiton its diagonal >>>>>>>>>>>>>>>>>> that matches the anti-diagonal computed by anti- >>>>>>>>>>>>>>>>>> slippier-H, and thus the computable number it computes >>>>>>>>>>>>>>>>>> can't be in the enumeration that it is working from. >>>>>>>>>>>>>>>>>>
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct contradiction to >>>>>>>>>>>>>>>>>>> the obviously effective enumerability used to create >>>>>>>>>>>>>>>>>>> sloppier_H in the first place
But the effective enumeration used to create >>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine the of >>>>>>>>>>>>>>>>>> at least one machine the computes every computable >>>>>>>>>>>>>>>>>> number.
You seem to have forgotten your own requirement that >>>>>>>>>>>>>>>>>> the enumeration was to include at least one machine >>>>>>>>>>>>>>>>>> that computes every computable number.
Yes, there are many computably enumerated SUB-sets of >>>>>>>>>>>>>>>>>> the computable numbers, just not one for a complete >>>>>>>>>>>>>>>>>> set of them.
All you are doing is showing you don't understand what >>>>>>>>>>>>>>>>>> it means to be correct.
Maybe you should test your machines to see if they >>>>>>>>>>>>>>>>>> meet your requirements, after all, you complaint was >>>>>>>>>>>>>>>>>> about people releasing code that wasn't proven to be >>>>>>>>>>>>>>>>>> correct.
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration that is >>>>>>>>>>>>>> admittedly containing only a subset of the computable >>>>>>>>>>>>>> numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>>> yourself to just wonder off into uninteresting problems >>>>>>>>>>>>>> with no attempt to justify why they might be interesting >>>>>>>>>>>>>> because you are doing them better that how they have been >>>>>>>>>>>>>> done before, you are just wasting everyone's time. >>>>>>>>>>>>>>
And when you let yourself wonder into mundane and non- >>>>>>>>>>>>>> inovative areas, you can waste a LOT of time.
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>>>>>>> running any whatever machine that we come across, and >>>>>>>>>>>>>>>>> trying to put it on a diagonal
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>
You forgot the problem you were working on, and just >>>>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets allow D >>>>>>>>>>>>>>>> to not select EVERY non-circular machine, just it needs >>>>>>>>>>>>>>>> to select at least one for each computable number. >>>>>>>>>>>>>>>>
The computable number of the anti-diagonal isn't in the >>>>>>>>>>>>>>>> set of numbers your D accepts a machine for.
And thus you failed at your goal, and forgot about the >>>>>>>>>>>>>>>> problem, because you attention span is apparently to >>>>>>>>>>>>>>>> short to take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>>>>>>
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your >>>>>>>>>>>> problem.
Again, it seems you don't care if you work can actually be >>>>>>>>>>>>>> useful, as you seem to accept that it is ok to spend a lot >>>>>>>>>>>>>> of time in mundane problems with known solutions, while >>>>>>>>>>>>>> also adding in booby- traps (like accepting circular >>>>>>>>>>>>>> machines into your enumeration) that makes quantifying >>>>>>>>>>>>>> what you are doing nearly impossible.
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand what >>>>>>>>>>>>>>>> problem you are working on because you are just >>>>>>>>>>>>>>>> fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>>>
I have shown a way to build a computable number that >>>>>>>>>>>>>>>>>> you enumeration doesn't include, and thus it can't be >>>>>>>>>>>>>>>>>> a complete enumeration, as you claim it is supposedly >>>>>>>>>>>>>>>>>> by some "magic" assumptions.
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you >>>>>>>>>>>>>> description of what the based decider is doing by trying >>>>>>>>>>>>>> to filter out inputs that hit repeat state.
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal across >>>>>>>>>>>>>>> them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>>>>>> diagonal, therefor _all machines_ is not effectively >>>>>>>>>>>>>>> enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all >>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" of >>>>>>>>>>>>>> the output of all machines, as some
if i mean if machine enumerability _does not imply_ being >>>>>>>>>>>>> able to compute a diagonal across the machines being >>>>>>>>>>>>> enumerated,
WHy should it. Many machines are circular, and thus might >>>>>>>>>>>> not REACH the diagonal. Hard to compute a diagonal with >>>>>>>>>>>> "holes" in it (since "hole" isn't a valid symbol)
ei: if enumerability of a set of machines is independent >>>>>>>>>>>>> from being able to compute a diagonal across the set of >>>>>>>>>>>>> machine,
then one _cannot_ use an inability to compute a diagonal to >>>>>>>>>>>>> prove a lack of enumerability, and u've lost turing's proof >>>>>>>>>>>>> against the enumerability of computable numbers
Which showds you don't understand the difference between >>>>>>>>>>>> just enumerating any ol machine, and enumerating circle-free >>>>>>>>>>>> machines.
enumerating a set of machines is enumerating a set of
machines eh????
why does failing to produce a diagonal for one set
(computable numbers) imply it's not effectively enumerability, >>>>>>>>>>
clearly building a diagonal is not required for a set of
machines to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates a >>>>>>>> full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on any >>>>>>> diagonal because it's based off the output of the diagonal
computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the
diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as
all the machines generate enough data to reach it, you can compute >>>>>> the diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of
machine that all reach the diagonal with a machine in that which
doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every machine >>>>>>>> reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in >>>>>>>>> principles
What inconsistency?
can't compute diagonal across computable numbers => proof against >>>>>>> effective enumerability
can't compute diagonal across all executable machines => not
proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be
the reason you can't compute it.
Just like your K < K claim, since that diagonal computation
totally inconsistent rick, and idk how to make that more clear tbh >>>>>>
apparently reached the diagonal in one view to create it, but also >>>>>> can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration
that sloppier_H is incomplete, it is uninteresting.
i think it's _very_ interesting that despite have a method to
enumerate _all_ machines, which includes _all_ computable numbers,
it's still not possible to put all the computable numbers within that
set on a diagonal:
Right, because you can't create the "diagonal" for all machines, as it
you _can_ enumerate them...
doesn't exist, as if you try to generate the grid of running all
machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
but all the computable numbers _should_ reach the diagonal, because they _all_ produce an infinite sequence...
so they _should_ end up on the attempted diagonal computation, given
we're simulating all of them in parallel, but that can't happen
It seems you have a fundamental problem about thinking through the
requirements, as "requirements" are just optional ideas to you.
clearly being able to enumerate a set of machines, does _not_ then
imply one can certainly construct a diagonal across the computable
numbers within that set
Because the determination that a given machine create a computable
number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't a
VALUE output, but the id number of the row being output, and the
digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as
sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K
digits, and thus any machine like turing's original H that looks to
see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special
number, but anti_sloppier_H won't do that, so sloppier_H will never
put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference"
number as sloppier_H, NOT its own, and thus it WILL get the anti-
diagonal that is the opposite of sloppier_H, and won't get hung up
on itself, since neither did sloppier_H get hung up on anti_sloppier_H. >>>>
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do
accurate work because "correct" isn't a word you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to follow
instructions because you are mentally unable to do accurate work
becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't understand
what that impies.
lol, talk about bad faith discussion dick
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist
(like the diagonal of an enumeration that includes circular
machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than 2 >>>>>> doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real
inconsistance, but just throw out a strawman, and that is your >>>>>>>> modus operandi.
On 4/1/26 7:06 PM, dart200 wrote:
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:Because if it WAS effectively enumerable, you could, because >>>>>>>>>>> we could build the diagonal (or anti-diagonal) computation >>>>>>>>>>> from the algorithm of the effective enumeration.
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:So, what use is that problem, if you are admitting that >>>>>>>>>>>>>>> you can't compute the diagonal of an enumeration that >>>>>>>>>>>>>>> includes all computable numbers? (which is at least close >>>>>>>>>>>>>>> to what Turing was talking about).
On 3/29/26 1:25 PM, dart200 wrote:that was...
On 3/29/26 10:07 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote:
On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across the >>>>>>>>>>>>>>>>>>>>>>>>>> circle-free computable numbers that defeats >>>>>>>>>>>>>>>>>>>>>>>>>> all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>>>>>>>>
before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K,Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>>it's not an enumeration of computable numbers, >>>>>>>>>>>>>>>>>>>>>>>> it's a superset of said enumeration that >>>>>>>>>>>>>>>>>>>>>>>> includes some "circular" machines, but should >>>>>>>>>>>>>>>>>>>>>>>> include all computable numbers
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a sloppier >>>>>>>>>>>>>>>>>>>>>>>>>> version of that diagonal, one that includes >>>>>>>>>>>>>>>>>>>>>>>>>> some circular numbers as well. for this i will >>>>>>>>>>>>>>>>>>>>>>>>>> introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration of >>>>>>>>>>>>>>>>>>>>>>>>> the "computable numbers" it generates isn't >>>>>>>>>>>>>>>>>>>>>>>>> valid, as the array of values has holes in it. >>>>>>>>>>>>>>>>>>>>>>>>
No, it is a decider that enumerates machines that >>>>>>>>>>>>>>>>>>>>>>> is supposed to generate that, but then a machine >>>>>>>>>>>>>>>>>>>>>>> that tries to use it to enumerate all enumerable >>>>>>>>>>>>>>>>>>>>>>> numbers will hang and not generate the enumeration. >>>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration >>>>>>>>>>>>>>>>>>>>>>> for getting you to the goal of showing how to >>>>>>>>>>>>>>>>>>>>>>> compute an enumeration of all computable numbers. >>>>>>>>>>>>>>>>>>>>>>>
Note, because the set of "computable numbers" >>>>>>>>>>>>>>>>>>>>>>> are (as you have pointed out) NOT the same >>>>>>>>>>>>>>>>>>>>>>> machines that compute them, Your "super set" as >>>>>>>>>>>>>>>>>>>>>>> described isn't a set of one sort of thing, and >>>>>>>>>>>>>>>>>>>>>>> is actually (as I just described) a set of >>>>>>>>>>>>>>>>>>>>>>> MACHINES that compute computable numbers + some >>>>>>>>>>>>>>>>>>>>>>> machines that are circular.
The presence of the circular machines in the set >>>>>>>>>>>>>>>>>>>>>>> means you can't use that set to compute the >>>>>>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>>>>>> circular machines in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular >>>>>>>>>>>>>>>>>>>>>>> machines, as they are easier to talk about >>>>>>>>>>>>>>>>>>>>>>> processing, as they are finite things, while the >>>>>>>>>>>>>>>>>>>>>>> elements of the computable numbers are not, and >>>>>>>>>>>>>>>>>>>>>>> if you try to talk about using ONE machine that >>>>>>>>>>>>>>>>>>>>>>> generates it, you have the problem of selecting >>>>>>>>>>>>>>>>>>>>>>> that one machine from the infinite set that >>>>>>>>>>>>>>>>>>>>>>> generates it.
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is likely >>>>>>>>>>>>>>>>>>>>>>>>> somewhere on the "diagonal" a spot where the >>>>>>>>>>>>>>>>>>>>>>>>> kth machine in the list doesn't generate k >>>>>>>>>>>>>>>>>>>>>>>>> digits of output, because it was one of those >>>>>>>>>>>>>>>>>>>>>>>>> non- circle- free machines accepted that got >>>>>>>>>>>>>>>>>>>>>>>>> stuck too early.
we can avoid that using a stepping simulation >>>>>>>>>>>>>>>>>>>>>>>> while dovetailing:
Nope.
your step_deect_loop might not return anything >>>>>>>>>>>>>>>>>>>>>>> for all machines, as not all circularity is >>>>>>>>>>>>>>>>>>>>>>> detectable.
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is true, >>>>>>>>>>>>>>>>>>>>>>> a program to find the first even number that >>>>>>>>>>>>>>>>>>>>>>> can't be found as the sum of two prime, will run >>>>>>>>>>>>>>>>>>>>>>> forever but never hit a repeated state. >>>>>>>>>>>>>>>>>>>>>>>
And why can't that same program be used to >>>>>>>>>>>>>>>>>>>>>>> compute the sloppy- anti- diagonal (where you >>>>>>>>>>>>>>>>>>>>>>> still test the M with DN(sloppy_H) not changing >>>>>>>>>>>>>>>>>>>>>>> that, and then reverse the output of the two >>>>>>>>>>>>>>>>>>>>>>> outputs.
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected during >>>>>>>>>>>>>>>>>>>>>>>> simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // sim one
step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>>> continue
} // outputs
other than STEP
if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine
K += 1
}
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // >>>>>>>>>>>>>>>>>>>>>>>> internally tracks stepping
list.push(m)
}
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>>>>>>> configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected when >>>>>>>>>>>>>>>>>>>>>>>>>> a simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, >>>>>>>>>>>>>>>>>>>>>>>>> but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>>>>>>> circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because the >>>>>>>>>>>>>>>>>>>>>>> anti- program does EXACTLY the same steps it will >>>>>>>>>>>>>>>>>>>>>>> also create an anti- diagonal, which could not >>>>>>>>>>>>>>>>>>>>>>> have been from a machine in the listing, thus >>>>>>>>>>>>>>>>>>>>>>> showing your enumation doesn't include ALL >>>>>>>>>>>>>>>>>>>>>>> machines for ALL the computable numbers. >>>>>>>>>>>>>>>>>>>>>>>
i guess at this point there's little point to >>>>>>>>>>>>>>>>>>>>>>>> even try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M has >>>>>>>>>>>>>>>>>>>>>>>> been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output alone >>>>>>>>>>>>>>>>>>>>>>>> the way. after the step is complete, if the Kth >>>>>>>>>>>>>>>>>>>>>>>> output has been recorded already it will output >>>>>>>>>>>>>>>>>>>>>>>> that. however if the Kth output has not already >>>>>>>>>>>>>>>>>>>>>>>> been output by the machine then STEP it output >>>>>>>>>>>>>>>>>>>>>>>>
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) // sim one
step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>>> list.push(m)
}
M += 1
}
}
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>> K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what happens >>>>>>>>>>>>>>>>>>>>>>>> to anti_sloppier_H when sloppier_H starts >>>>>>>>>>>>>>>>>>>>>>>> dovetailing it. i'm kinda guessing at the moment >>>>>>>>>>>>>>>>>>>>>>>> that the K within sloppier_H grows faster than >>>>>>>>>>>>>>>>>>>>>>>> the K within anti_sloppier_H and therefore >>>>>>>>>>>>>>>>>>>>>>>> sloppier_H will just never actually output a >>>>>>>>>>>>>>>>>>>>>>>> digit from anti_sloppier_H ...
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>>
And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as the >>>>>>>>>>>>>>>>>>>>> code for the machine with its number. >>>>>>>>>>>>>>>>>>>>>
No, it is supposed to be EXACTLY simulating the >>>>>>>>>>>>>>>>>>>>> steps of sloppier_H.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it >>>>>>>>>>>>>>>>>>>>>> will constantly run behind sloppier's K for >>>>>>>>>>>>>>>>>>>>>> several reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... mean >>>>>>>>>>>>>>>>>>>>>> sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of >>>>>>>>>>>>>>>>>>>> after each step of sloppier_H, to see if an output >>>>>>>>>>>>>>>>>>>> was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives >>>>>>>>>>>>>>>>>>> to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>>>> output slower than sloppier_H.
So, that doesn't affect the value of K.
in fact, anti_sloppier_H cannot output a digit for a >>>>>>>>>>>>>>>>>>>> particular K until /after/ sloppier_H outputs a >>>>>>>>>>>>>>>>>>>> digit for that particular K...
Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even >>>>>>>>>>>>>>>>>>> though at a slower rate) and will EXAXTLY output the >>>>>>>>>>>>>>>>>>> opposite that sloppier_H outputs.
So?
so there is no way for anti_sloppier_H to ever >>>>>>>>>>>>>>>>>>>> output for some particular K until after sloppier_H >>>>>>>>>>>>>>>>>>>> has started looking for at least a K+1 digit, >>>>>>>>>>>>>>>>>>>
meaning sloppier_H will never put anti_sloppier_H on >>>>>>>>>>>>>>>>>>>> the diagonal
Right.
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of computable >>>>>>>>>>>>>>>>> numbers.
It seems you beleive errors are acceptable.
So, why do you complain of people not proving programs >>>>>>>>>>>>>>>>> to be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>>> computable number, at least as long as your >>>>>>>>>>>>>>>>>>> sloppier_H outputs a computable number as the >>>>>>>>>>>>>>>>>>> diagonal, it needed to in order for the diagonal to >>>>>>>>>>>>>>>>>>> be of a complete enumeration of computable numbers. >>>>>>>>>>>>>>>>>>>
Sloppier H can NEVER output a digiton its diagonal >>>>>>>>>>>>>>>>>>> that matches the anti-diagonal computed by anti- >>>>>>>>>>>>>>>>>>> slippier-H, and thus the computable number it >>>>>>>>>>>>>>>>>>> computes can't be in the enumeration that it is >>>>>>>>>>>>>>>>>>> working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct contradiction >>>>>>>>>>>>>>>>>>>> to the obviously effective enumerability used to >>>>>>>>>>>>>>>>>>>> create sloppier_H in the first place
But the effective enumeration used to create >>>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine the >>>>>>>>>>>>>>>>>>> of at least one machine the computes every computable >>>>>>>>>>>>>>>>>>> number.
You seem to have forgotten your own requirement that >>>>>>>>>>>>>>>>>>> the enumeration was to include at least one machine >>>>>>>>>>>>>>>>>>> that computes every computable number.
Yes, there are many computably enumerated SUB-sets of >>>>>>>>>>>>>>>>>>> the computable numbers, just not one for a complete >>>>>>>>>>>>>>>>>>> set of them.
All you are doing is showing you don't understand >>>>>>>>>>>>>>>>>>> what it means to be correct.
Maybe you should test your machines to see if they >>>>>>>>>>>>>>>>>>> meet your requirements, after all, you complaint was >>>>>>>>>>>>>>>>>>> about people releasing code that wasn't proven to be >>>>>>>>>>>>>>>>>>> correct.
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration that >>>>>>>>>>>>>>> is admittedly containing only a subset of the computable >>>>>>>>>>>>>>> numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>>>> yourself to just wonder off into uninteresting problems >>>>>>>>>>>>>>> with no attempt to justify why they might be interesting >>>>>>>>>>>>>>> because you are doing them better that how they have been >>>>>>>>>>>>>>> done before, you are just wasting everyone's time. >>>>>>>>>>>>>>>
And when you let yourself wonder into mundane and non- >>>>>>>>>>>>>>> inovative areas, you can waste a LOT of time.
i'm not selecting for anything in particular, i'm just >>>>>>>>>>>>>>>>>> running any whatever machine that we come across, and >>>>>>>>>>>>>>>>>> trying to put it on a diagonal
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>>
You forgot the problem you were working on, and just >>>>>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets allow >>>>>>>>>>>>>>>>> D to not select EVERY non-circular machine, just it >>>>>>>>>>>>>>>>> needs to select at least one for each computable number. >>>>>>>>>>>>>>>>>
The computable number of the anti-diagonal isn't in the >>>>>>>>>>>>>>>>> set of numbers your D accepts a machine for. >>>>>>>>>>>>>>>>>
And thus you failed at your goal, and forgot about the >>>>>>>>>>>>>>>>> problem, because you attention span is apparently to >>>>>>>>>>>>>>>>> short to take it to a finish line.
the process of innovation is inherently serendipitous, rick >>>>>>>>>>>>>>>
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your >>>>>>>>>>>>> problem.
Again, it seems you don't care if you work can actually >>>>>>>>>>>>>>> be useful, as you seem to accept that it is ok to spend a >>>>>>>>>>>>>>> lot of time in mundane problems with known solutions, >>>>>>>>>>>>>>> while also adding in booby- traps (like accepting >>>>>>>>>>>>>>> circular machines into your enumeration) that makes >>>>>>>>>>>>>>> quantifying what you are doing nearly impossible. >>>>>>>>>>>>>>>
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand what >>>>>>>>>>>>>>>>> problem you are working on because you are just >>>>>>>>>>>>>>>>> fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>>>>
I have shown a way to build a computable number that >>>>>>>>>>>>>>>>>>> you enumeration doesn't include, and thus it can't be >>>>>>>>>>>>>>>>>>> a complete enumeration, as you claim it is supposedly >>>>>>>>>>>>>>>>>>> by some "magic" assumptions.
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in you >>>>>>>>>>>>>>> description of what the based decider is doing by trying >>>>>>>>>>>>>>> to filter out inputs that hit repeat state.
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal >>>>>>>>>>>>>>>> across them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>>>>>>> diagonal, therefor _all machines_ is not effectively >>>>>>>>>>>>>>>> enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all >>>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" of >>>>>>>>>>>>>>> the output of all machines, as some
if i mean if machine enumerability _does not imply_ being >>>>>>>>>>>>>> able to compute a diagonal across the machines being >>>>>>>>>>>>>> enumerated,
WHy should it. Many machines are circular, and thus might >>>>>>>>>>>>> not REACH the diagonal. Hard to compute a diagonal with >>>>>>>>>>>>> "holes" in it (since "hole" isn't a valid symbol)
Which showds you don't understand the difference between >>>>>>>>>>>>> just enumerating any ol machine, and enumerating circle- >>>>>>>>>>>>> free machines.
ei: if enumerability of a set of machines is independent >>>>>>>>>>>>>> from being able to compute a diagonal across the set of >>>>>>>>>>>>>> machine,
then one _cannot_ use an inability to compute a diagonal >>>>>>>>>>>>>> to prove a lack of enumerability, and u've lost turing's >>>>>>>>>>>>>> proof against the enumerability of computable numbers >>>>>>>>>>>>>
enumerating a set of machines is enumerating a set of >>>>>>>>>>>> machines eh????
why does failing to produce a diagonal for one set
(computable numbers) imply it's not effectively enumerability, >>>>>>>>>>>
clearly building a diagonal is not required for a set of
machines to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates >>>>>>>>> a full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on >>>>>>>> any diagonal because it's based off the output of the diagonal >>>>>>>> computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the
diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as >>>>>>> all the machines generate enough data to reach it, you can
compute the diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of
machine that all reach the diagonal with a machine in that which >>>>>>> doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every machine >>>>>>>>> reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency in >>>>>>>>>> principles
What inconsistency?
can't compute diagonal across computable numbers => proof
against effective enumerability
can't compute diagonal across all executable machines => not
proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be >>>>>>> the reason you can't compute it.
Just like your K < K claim, since that diagonal computation
totally inconsistent rick, and idk how to make that more clear tbh >>>>>>>
apparently reached the diagonal in one view to create it, but
also can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H? >>>>>>
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration
that sloppier_H is incomplete, it is uninteresting.
i think it's _very_ interesting that despite have a method to
enumerate _all_ machines, which includes _all_ computable numbers,
it's still not possible to put all the computable numbers within
that set on a diagonal:
Right, because you can't create the "diagonal" for all machines, as it
you _can_ enumerate them...
Yes, but that enumeration doesn't create a "diagonal".
There isn't a kth digit output by the kth machine for all machines in
that enumeration.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all
machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal, because
they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit.
Thus, if sloppier_H continues to run and produce output, so does anti_sloppier_H
so they _should_ end up on the attempted diagonal computation, given
we're simulating all of them in parallel, but that can't happen
Right, but it misses some, like anti_sloppier_H.
And without all the numbers, it isn't COMPLETE, and thus uninteresting.
It seems you have a fundamental problem about thinking through the
requirements, as "requirements" are just optional ideas to you.
clearly being able to enumerate a set of machines, does _not_ then
imply one can certainly construct a diagonal across the computable
numbers within that set
Because the determination that a given machine create a computable
number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing off
when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the diagonal, anti_sloppier_H doesn't need to figure out what its diagonal digit is.
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't a
VALUE output, but the id number of the row being output, and the
digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as
sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K
digits, and thus any machine like turing's original H that looks to >>>>> see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special
number, but anti_sloppier_H won't do that, so sloppier_H will never >>>>> put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference"
number as sloppier_H, NOT its own, and thus it WILL get the anti-
diagonal that is the opposite of sloppier_H, and won't get hung up
on itself, since neither did sloppier_H get hung up on
anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do
accurate work because "correct" isn't a word you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to follow
instructions because you are mentally unable to do accurate work
becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't understand
what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
After all, you ARE proving you don't understand what a requirement is.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist >>>>>>> (like the diagonal of an enumeration that includes circular
machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than >>>>>>> 2 doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\
My guess is you are not going to actually answer with a real >>>>>>>>> inconsistance, but just throw out a strawman, and that is your >>>>>>>>> modus operandi.
On 4/1/26 6:36 PM, Richard Damon wrote:
On 4/1/26 7:06 PM, dart200 wrote:
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:you _can_ enumerate them...
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:Because if it WAS effectively enumerable, you could, because >>>>>>>>>>>> we could build the diagonal (or anti-diagonal) computation >>>>>>>>>>>> from the algorithm of the effective enumeration.
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:
On 3/29/26 1:37 PM, Richard Damon wrote:So, what use is that problem, if you are admitting that >>>>>>>>>>>>>>>> you can't compute the diagonal of an enumeration that >>>>>>>>>>>>>>>> includes all computable numbers? (which is at least >>>>>>>>>>>>>>>> close to what Turing was talking about).
On 3/29/26 1:25 PM, dart200 wrote:that was...
On 3/29/26 10:07 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/26 12:19 PM, dart200 wrote:
On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across the >>>>>>>>>>>>>>>>>>>>>>>>>>> circle-free computable numbers that defeats >>>>>>>>>>>>>>>>>>>>>>>>>>> all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>>>>>>>>>
And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as >>>>>>>>>>>>>>>>>>>>>> the code for the machine with its number. >>>>>>>>>>>>>>>>>>>>>>before for every K, anti_sloppier_H simulates the >>>>>>>>>>>>>>>>>>>>>>> entirety of sloppier_H from 1..K, >>>>>>>>>>>>>>>>>>>>>>No, it is a decider that enumerates machines >>>>>>>>>>>>>>>>>>>>>>>> that is supposed to generate that, but then a >>>>>>>>>>>>>>>>>>>>>>>> machine that tries to use it to enumerate all >>>>>>>>>>>>>>>>>>>>>>>> enumerable numbers will hang and not generate >>>>>>>>>>>>>>>>>>>>>>>> the enumeration.Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>>>it's not an enumeration of computable numbers, >>>>>>>>>>>>>>>>>>>>>>>>> it's a superset of said enumeration that >>>>>>>>>>>>>>>>>>>>>>>>> includes some "circular" machines, but should >>>>>>>>>>>>>>>>>>>>>>>>> include all computable numbers >>>>>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a >>>>>>>>>>>>>>>>>>>>>>>>>>> sloppier version of that diagonal, one that >>>>>>>>>>>>>>>>>>>>>>>>>>> includes some circular numbers as well. for >>>>>>>>>>>>>>>>>>>>>>>>>>> this i will introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration of >>>>>>>>>>>>>>>>>>>>>>>>>> the "computable numbers" it generates isn't >>>>>>>>>>>>>>>>>>>>>>>>>> valid, as the array of values has holes in it. >>>>>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" enumeration >>>>>>>>>>>>>>>>>>>>>>>> for getting you to the goal of showing how to >>>>>>>>>>>>>>>>>>>>>>>> compute an enumeration of all computable numbers. >>>>>>>>>>>>>>>>>>>>>>>>
Note, because the set of "computable numbers" >>>>>>>>>>>>>>>>>>>>>>>> are (as you have pointed out) NOT the same >>>>>>>>>>>>>>>>>>>>>>>> machines that compute them, Your "super set" as >>>>>>>>>>>>>>>>>>>>>>>> described isn't a set of one sort of thing, and >>>>>>>>>>>>>>>>>>>>>>>> is actually (as I just described) a set of >>>>>>>>>>>>>>>>>>>>>>>> MACHINES that compute computable numbers + some >>>>>>>>>>>>>>>>>>>>>>>> machines that are circular.
The presence of the circular machines in the set >>>>>>>>>>>>>>>>>>>>>>>> means you can't use that set to compute the >>>>>>>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>>>>>>> circular machines in the set.
This is, i think. part of the reason that Turing >>>>>>>>>>>>>>>>>>>>>>>> switch to the enumeration of non-circular >>>>>>>>>>>>>>>>>>>>>>>> machines, as they are easier to talk about >>>>>>>>>>>>>>>>>>>>>>>> processing, as they are finite things, while the >>>>>>>>>>>>>>>>>>>>>>>> elements of the computable numbers are not, and >>>>>>>>>>>>>>>>>>>>>>>> if you try to talk about using ONE machine that >>>>>>>>>>>>>>>>>>>>>>>> generates it, you have the problem of selecting >>>>>>>>>>>>>>>>>>>>>>>> that one machine from the infinite set that >>>>>>>>>>>>>>>>>>>>>>>> generates it.
we can avoid that using a stepping simulation >>>>>>>>>>>>>>>>>>>>>>>>> while dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is >>>>>>>>>>>>>>>>>>>>>>>>>> likely somewhere on the "diagonal" a spot >>>>>>>>>>>>>>>>>>>>>>>>>> where the kth machine in the list doesn't >>>>>>>>>>>>>>>>>>>>>>>>>> generate k digits of output, because it was >>>>>>>>>>>>>>>>>>>>>>>>>> one of those non- circle- free machines >>>>>>>>>>>>>>>>>>>>>>>>>> accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything >>>>>>>>>>>>>>>>>>>>>>>> for all machines, as not all circularity is >>>>>>>>>>>>>>>>>>>>>>>> detectable.
As I pointed out, some machines just continue to >>>>>>>>>>>>>>>>>>>>>>>> slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is >>>>>>>>>>>>>>>>>>>>>>>> true, a program to find the first even number >>>>>>>>>>>>>>>>>>>>>>>> that can't be found as the sum of two prime, >>>>>>>>>>>>>>>>>>>>>>>> will run forever but never hit a repeated state. >>>>>>>>>>>>>>>>>>>>>>>>
And why can't that same program be used to >>>>>>>>>>>>>>>>>>>>>>>> compute the sloppy- anti- diagonal (where you >>>>>>>>>>>>>>>>>>>>>>>> still test the M with DN(sloppy_H) not changing >>>>>>>>>>>>>>>>>>>>>>>> that, and then reverse the output of the two >>>>>>>>>>>>>>>>>>>>>>>> outputs.
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // sim >>>>>>>>>>>>>>>>>>>>>>>>> one step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>>>> continue >>>>>>>>>>>>>>>>>>>>>>>>> } //
outputs other than STEP
if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine
K += 1
}
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) // >>>>>>>>>>>>>>>>>>>>>>>>> internally tracks stepping
list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
How can you tell this?
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when a >>>>>>>>>>>>>>>>>>>>>>>>>>> configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected when >>>>>>>>>>>>>>>>>>>>>>>>>>> a simulated machine tries to simulates itself >>>>>>>>>>>>>>>>>>>>>>>>>>
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, >>>>>>>>>>>>>>>>>>>>>>>>>> but it hasn't halted yet.
this is the sloppy diagonal, it doesn't care if >>>>>>>>>>>>>>>>>>>>>>>>> circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because >>>>>>>>>>>>>>>>>>>>>>>> the anti- program does EXACTLY the same steps it >>>>>>>>>>>>>>>>>>>>>>>> will also create an anti- diagonal, which could >>>>>>>>>>>>>>>>>>>>>>>> not have been from a machine in the listing, >>>>>>>>>>>>>>>>>>>>>>>> thus showing your enumation doesn't include ALL >>>>>>>>>>>>>>>>>>>>>>>> machines for ALL the computable numbers. >>>>>>>>>>>>>>>>>>>>>>>>
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>>>
i guess at this point there's little point to >>>>>>>>>>>>>>>>>>>>>>>>> even try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M has >>>>>>>>>>>>>>>>>>>>>>>>> been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output alone >>>>>>>>>>>>>>>>>>>>>>>>> the way. after the step is complete, if the Kth >>>>>>>>>>>>>>>>>>>>>>>>> output has been recorded already it will output >>>>>>>>>>>>>>>>>>>>>>>>> that. however if the Kth output has not already >>>>>>>>>>>>>>>>>>>>>>>>> been output by the machine then STEP it output >>>>>>>>>>>>>>>>>>>>>>>>>
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) // sim
one step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>>>> output res
K += 1
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { // handle
self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>> K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what >>>>>>>>>>>>>>>>>>>>>>>>> happens to anti_sloppier_H when sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>> starts dovetailing it. i'm kinda guessing at >>>>>>>>>>>>>>>>>>>>>>>>> the moment that the K within sloppier_H grows >>>>>>>>>>>>>>>>>>>>>>>>> faster than the K within anti_sloppier_H and >>>>>>>>>>>>>>>>>>>>>>>>> therefore sloppier_H will just never actually >>>>>>>>>>>>>>>>>>>>>>>>> output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>>>
No, it is supposed to be EXACTLY simulating the >>>>>>>>>>>>>>>>>>>>>> steps of sloppier_H.
i suppose we can adjust it with a steppable runtime: >>>>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H = () -> {
K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) {
output res
K += 1
}
}
}
but i don't think this will change anything. it >>>>>>>>>>>>>>>>>>>>>>> will constantly run behind sloppier's K for >>>>>>>>>>>>>>>>>>>>>>> several reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... >>>>>>>>>>>>>>>>>>>>>>> mean sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of >>>>>>>>>>>>>>>>>>>>> after each step of sloppier_H, to see if an output >>>>>>>>>>>>>>>>>>>>> was found, and then advance K if so.
So?
That doesn't affect the answer that sloppier_H gives >>>>>>>>>>>>>>>>>>>> to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>>>>> output slower than sloppier_H.
So, that doesn't affect the value of K. >>>>>>>>>>>>>>>>>>>>
in fact, anti_sloppier_H cannot output a digit for >>>>>>>>>>>>>>>>>>>>> a particular K until /after/ sloppier_H outputs a >>>>>>>>>>>>>>>>>>>>> digit for that particular K...
Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even >>>>>>>>>>>>>>>>>>>> though at a slower rate) and will EXAXTLY output the >>>>>>>>>>>>>>>>>>>> opposite that sloppier_H outputs.
So?
so there is no way for anti_sloppier_H to ever >>>>>>>>>>>>>>>>>>>>> output for some particular K until after sloppier_H >>>>>>>>>>>>>>>>>>>>> has started looking for at least a K+1 digit, >>>>>>>>>>>>>>>>>>>>
meaning sloppier_H will never put anti_sloppier_H >>>>>>>>>>>>>>>>>>>>> on the diagonal
Right.
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of >>>>>>>>>>>>>>>>>> computable numbers.
It seems you beleive errors are acceptable. >>>>>>>>>>>>>>>>>>
So, why do you complain of people not proving programs >>>>>>>>>>>>>>>>>> to be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>>>> computable number, at least as long as your >>>>>>>>>>>>>>>>>>>> sloppier_H outputs a computable number as the >>>>>>>>>>>>>>>>>>>> diagonal, it needed to in order for the diagonal to >>>>>>>>>>>>>>>>>>>> be of a complete enumeration of computable numbers. >>>>>>>>>>>>>>>>>>>>
Sloppier H can NEVER output a digiton its diagonal >>>>>>>>>>>>>>>>>>>> that matches the anti-diagonal computed by anti- >>>>>>>>>>>>>>>>>>>> slippier-H, and thus the computable number it >>>>>>>>>>>>>>>>>>>> computes can't be in the enumeration that it is >>>>>>>>>>>>>>>>>>>> working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct contradiction >>>>>>>>>>>>>>>>>>>>> to the obviously effective enumerability used to >>>>>>>>>>>>>>>>>>>>> create sloppier_H in the first place >>>>>>>>>>>>>>>>>>>>>
But the effective enumeration used to create >>>>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine the >>>>>>>>>>>>>>>>>>>> of at least one machine the computes every >>>>>>>>>>>>>>>>>>>> computable number.
You seem to have forgotten your own requirement that >>>>>>>>>>>>>>>>>>>> the enumeration was to include at least one machine >>>>>>>>>>>>>>>>>>>> that computes every computable number. >>>>>>>>>>>>>>>>>>>>
Yes, there are many computably enumerated SUB-sets >>>>>>>>>>>>>>>>>>>> of the computable numbers, just not one for a >>>>>>>>>>>>>>>>>>>> complete set of them.
All you are doing is showing you don't understand >>>>>>>>>>>>>>>>>>>> what it means to be correct.
Maybe you should test your machines to see if they >>>>>>>>>>>>>>>>>>>> meet your requirements, after all, you complaint was >>>>>>>>>>>>>>>>>>>> about people releasing code that wasn't proven to be >>>>>>>>>>>>>>>>>>>> correct.
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration that >>>>>>>>>>>>>>>> is admittedly containing only a subset of the computable >>>>>>>>>>>>>>>> numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>>>>> yourself to just wonder off into uninteresting problems >>>>>>>>>>>>>>>> with no attempt to justify why they might be interesting >>>>>>>>>>>>>>>> because you are doing them better that how they have >>>>>>>>>>>>>>>> been done before, you are just wasting everyone's time. >>>>>>>>>>>>>>>>
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>>>
i'm not selecting for anything in particular, i'm >>>>>>>>>>>>>>>>>>> just running any whatever machine that we come >>>>>>>>>>>>>>>>>>> across, and trying to put it on a diagonal >>>>>>>>>>>>>>>>>>
You forgot the problem you were working on, and just >>>>>>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets allow >>>>>>>>>>>>>>>>>> D to not select EVERY non-circular machine, just it >>>>>>>>>>>>>>>>>> needs to select at least one for each computable number. >>>>>>>>>>>>>>>>>>
The computable number of the anti-diagonal isn't in >>>>>>>>>>>>>>>>>> the set of numbers your D accepts a machine for. >>>>>>>>>>>>>>>>>>
And thus you failed at your goal, and forgot about the >>>>>>>>>>>>>>>>>> problem, because you attention span is apparently to >>>>>>>>>>>>>>>>>> short to take it to a finish line.
the process of innovation is inherently serendipitous, >>>>>>>>>>>>>>>>> rick
And when you let yourself wonder into mundane and non- >>>>>>>>>>>>>>>> inovative areas, you can waste a LOT of time.
god only knows what u think ur doing
Yes, he knows, and the fact you can't see it shows your >>>>>>>>>>>>>> problem.
Again, it seems you don't care if you work can actually >>>>>>>>>>>>>>>> be useful, as you seem to accept that it is ok to spend >>>>>>>>>>>>>>>> a lot of time in mundane problems with known solutions, >>>>>>>>>>>>>>>> while also adding in booby- traps (like accepting >>>>>>>>>>>>>>>> circular machines into your enumeration) that makes >>>>>>>>>>>>>>>> quantifying what you are doing nearly impossible. >>>>>>>>>>>>>>>>
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand >>>>>>>>>>>>>>>>>> what problem you are working on because you are just >>>>>>>>>>>>>>>>>> fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>>>>>
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>>>
I have shown a way to build a computable number that >>>>>>>>>>>>>>>>>>>> you enumeration doesn't include, and thus it can't >>>>>>>>>>>>>>>>>>>> be a complete enumeration, as you claim it is >>>>>>>>>>>>>>>>>>>> supposedly by some "magic" assumptions. >>>>>>>>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in >>>>>>>>>>>>>>>> you description of what the based decider is doing by >>>>>>>>>>>>>>>> trying to filter out inputs that hit repeat state. >>>>>>>>>>>>>>>>
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal >>>>>>>>>>>>>>>>> across them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on the >>>>>>>>>>>>>>>>> diagonal, therefor _all machines_ is not effectively >>>>>>>>>>>>>>>>> enumerable
No, THIS METHOD can't enumerate all machines.
Also note, that just because we can enumerate all >>>>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" of >>>>>>>>>>>>>>>> the output of all machines, as some
if i mean if machine enumerability _does not imply_ being >>>>>>>>>>>>>>> able to compute a diagonal across the machines being >>>>>>>>>>>>>>> enumerated,
WHy should it. Many machines are circular, and thus might >>>>>>>>>>>>>> not REACH the diagonal. Hard to compute a diagonal with >>>>>>>>>>>>>> "holes" in it (since "hole" isn't a valid symbol)
Which showds you don't understand the difference between >>>>>>>>>>>>>> just enumerating any ol machine, and enumerating circle- >>>>>>>>>>>>>> free machines.
ei: if enumerability of a set of machines is independent >>>>>>>>>>>>>>> from being able to compute a diagonal across the set of >>>>>>>>>>>>>>> machine,
then one _cannot_ use an inability to compute a diagonal >>>>>>>>>>>>>>> to prove a lack of enumerability, and u've lost turing's >>>>>>>>>>>>>>> proof against the enumerability of computable numbers >>>>>>>>>>>>>>
enumerating a set of machines is enumerating a set of >>>>>>>>>>>>> machines eh????
why does failing to produce a diagonal for one set
(computable numbers) imply it's not effectively enumerability, >>>>>>>>>>>>
clearly building a diagonal is not required for a set of >>>>>>>>>>> machines to be effectively enumerable ..
But automatically becomes possible, if the enumeration creates >>>>>>>>>> a full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on >>>>>>>>> any diagonal because it's based off the output of the diagonal >>>>>>>>> computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the
diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as >>>>>>>> all the machines generate enough data to reach it, you can
compute the diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of >>>>>>>> machine that all reach the diagonal with a machine in that which >>>>>>>> doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every machine >>>>>>>>>> reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency >>>>>>>>>>> in principles
What inconsistency?
can't compute diagonal across computable numbers => proof
against effective enumerability
can't compute diagonal across all executable machines => not >>>>>>>>> proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can be >>>>>>>> the reason you can't compute it.
Just like your K < K claim, since that diagonal computation
totally inconsistent rick, and idk how to make that more clear tbh >>>>>>>>
apparently reached the diagonal in one view to create it, but >>>>>>>> also can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H? >>>>>>>
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration >>>>>> that sloppier_H is incomplete, it is uninteresting.
i think it's _very_ interesting that despite have a method to
enumerate _all_ machines, which includes _all_ computable numbers,
it's still not possible to put all the computable numbers within
that set on a diagonal:
Right, because you can't create the "diagonal" for all machines, as it >>>
Yes, but that enumeration doesn't create a "diagonal".
There isn't a kth digit output by the kth machine for all machines in
that enumeration.
which is fine, it skips machines that don't have output to put on the diagonal ...
but computable numbers should all have outputs to put on the diagonal,
yet we cannot compute that,
this doesn't require specifically selection for them, they should have outputs regardless of whether we select for them, and that should be the outcome of simulating them
therefore, regardless of whether we can enumerate a set of computable numbers or not, they cannot all be computably put on a diagonal
if i were talking to someone capable of doing more than upholding a bandwagon this would be an interesting fact
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all
machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal, because
they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly
built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit.
Thus, if sloppier_H continues to run and produce output, so does
anti_sloppier_H
so they _should_ end up on the attempted diagonal computation, given
we're simulating all of them in parallel, but that can't happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of the enumeration
And without all the numbers, it isn't COMPLETE, and thus uninteresting.
not all machines even produce output, so ofc trying to compute a
diagonal across all machines can include all machines ...
but all computable numbers do have outputs for all K, so they should be includable in attempting to compute a diagonal across all machines
It seems you have a fundamental problem about thinking through the
requirements, as "requirements" are just optional ideas to you.
clearly being able to enumerate a set of machines, does _not_ then
imply one can certainly construct a diagonal across the computable
numbers within that set
Because the determination that a given machine create a computable
number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing off
when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its diagonal
digit is.
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't a >>>>>> VALUE output, but the id number of the row being output, and the
digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as
sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K
digits, and thus any machine like turing's original H that looks
to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special >>>>>> number, but anti_sloppier_H won't do that, so sloppier_H will
never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference"
number as sloppier_H, NOT its own, and thus it WILL get the anti- >>>>>> diagonal that is the opposite of sloppier_H, and won't get hung up >>>>>> on itself, since neither did sloppier_H get hung up on
anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do >>>>>> accurate work because "correct" isn't a word you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to follow
instructions because you are mentally unable to do accurate work
becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱
After all, you ARE proving you don't understand what a requirement is.
this is exploring the bounds of theory mate, not engineering a system
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't exist >>>>>>>> (like the diagonal of an enumeration that includes circular
machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater than >>>>>>>> 2 doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>
My guess is you are not going to actually answer with a real >>>>>>>>>> inconsistance, but just throw out a strawman, and that is your >>>>>>>>>> modus operandi.
On 4/2/26 12:21 AM, dart200 wrote:
On 4/1/26 6:36 PM, Richard Damon wrote:
On 4/1/26 7:06 PM, dart200 wrote:
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:you _can_ enumerate them...
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:clearly building a diagonal is not required for a set of >>>>>>>>>>>> machines to be effectively enumerable ..
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:god only knows what u think ur doing
On 3/29/26 1:37 PM, Richard Damon wrote:So, what use is that problem, if you are admitting that >>>>>>>>>>>>>>>>> you can't compute the diagonal of an enumeration that >>>>>>>>>>>>>>>>> includes all computable numbers? (which is at least >>>>>>>>>>>>>>>>> close to what Turing was talking about).
On 3/29/26 1:25 PM, dart200 wrote:that was...
On 3/29/26 10:07 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 3/29/26 12:19 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across the >>>>>>>>>>>>>>>>>>>>>>>>>>>> circle-free computable numbers that defeats >>>>>>>>>>>>>>>>>>>>>>>>>>>> all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>>>>>>>>>>
So?And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as >>>>>>>>>>>>>>>>>>>>>>> the code for the machine with its number. >>>>>>>>>>>>>>>>>>>>>>>before for every K, anti_sloppier_H simulates >>>>>>>>>>>>>>>>>>>>>>>> the entirety of sloppier_H from 1..K, >>>>>>>>>>>>>>>>>>>>>>>No, it is a decider that enumerates machines >>>>>>>>>>>>>>>>>>>>>>>>> that is supposed to generate that, but then a >>>>>>>>>>>>>>>>>>>>>>>>> machine that tries to use it to enumerate all >>>>>>>>>>>>>>>>>>>>>>>>> enumerable numbers will hang and not generate >>>>>>>>>>>>>>>>>>>>>>>>> the enumeration.Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a >>>>>>>>>>>>>>>>>>>>>>>>>>>> sloppier version of that diagonal, one that >>>>>>>>>>>>>>>>>>>>>>>>>>>> includes some circular numbers as well. for >>>>>>>>>>>>>>>>>>>>>>>>>>>> this i will introduce a new simulation machine: >>>>>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration >>>>>>>>>>>>>>>>>>>>>>>>>>> of the "computable numbers" it generates >>>>>>>>>>>>>>>>>>>>>>>>>>> isn't valid, as the array of values has holes >>>>>>>>>>>>>>>>>>>>>>>>>>> in it.
it's not an enumeration of computable numbers, >>>>>>>>>>>>>>>>>>>>>>>>>> it's a superset of said enumeration that >>>>>>>>>>>>>>>>>>>>>>>>>> includes some "circular" machines, but should >>>>>>>>>>>>>>>>>>>>>>>>>> include all computable numbers >>>>>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" >>>>>>>>>>>>>>>>>>>>>>>>> enumeration for getting you to the goal of >>>>>>>>>>>>>>>>>>>>>>>>> showing how to compute an enumeration of all >>>>>>>>>>>>>>>>>>>>>>>>> computable numbers.
Note, because the set of "computable numbers" >>>>>>>>>>>>>>>>>>>>>>>>> are (as you have pointed out) NOT the same >>>>>>>>>>>>>>>>>>>>>>>>> machines that compute them, Your "super set" as >>>>>>>>>>>>>>>>>>>>>>>>> described isn't a set of one sort of thing, and >>>>>>>>>>>>>>>>>>>>>>>>> is actually (as I just described) a set of >>>>>>>>>>>>>>>>>>>>>>>>> MACHINES that compute computable numbers + some >>>>>>>>>>>>>>>>>>>>>>>>> machines that are circular.
The presence of the circular machines in the >>>>>>>>>>>>>>>>>>>>>>>>> set means you can't use that set to compute the >>>>>>>>>>>>>>>>>>>>>>>>> computable numbers, as you process will hang on >>>>>>>>>>>>>>>>>>>>>>>>> circular machines in the set. >>>>>>>>>>>>>>>>>>>>>>>>>
This is, i think. part of the reason that >>>>>>>>>>>>>>>>>>>>>>>>> Turing switch to the enumeration of non- >>>>>>>>>>>>>>>>>>>>>>>>> circular machines, as they are easier to talk >>>>>>>>>>>>>>>>>>>>>>>>> about processing, as they are finite things, >>>>>>>>>>>>>>>>>>>>>>>>> while the elements of the computable numbers >>>>>>>>>>>>>>>>>>>>>>>>> are not, and if you try to talk about using ONE >>>>>>>>>>>>>>>>>>>>>>>>> machine that generates it, you have the problem >>>>>>>>>>>>>>>>>>>>>>>>> of selecting that one machine from the infinite >>>>>>>>>>>>>>>>>>>>>>>>> set that generates it.
we can avoid that using a stepping simulation >>>>>>>>>>>>>>>>>>>>>>>>>> while dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is >>>>>>>>>>>>>>>>>>>>>>>>>>> likely somewhere on the "diagonal" a spot >>>>>>>>>>>>>>>>>>>>>>>>>>> where the kth machine in the list doesn't >>>>>>>>>>>>>>>>>>>>>>>>>>> generate k digits of output, because it was >>>>>>>>>>>>>>>>>>>>>>>>>>> one of those non- circle- free machines >>>>>>>>>>>>>>>>>>>>>>>>>>> accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything >>>>>>>>>>>>>>>>>>>>>>>>> for all machines, as not all circularity is >>>>>>>>>>>>>>>>>>>>>>>>> detectable.
As I pointed out, some machines just continue >>>>>>>>>>>>>>>>>>>>>>>>> to slowly grow over time and never repeat a state. >>>>>>>>>>>>>>>>>>>>>>>>>
For instance, if the Goldbach conjecture is >>>>>>>>>>>>>>>>>>>>>>>>> true, a program to find the first even number >>>>>>>>>>>>>>>>>>>>>>>>> that can't be found as the sum of two prime, >>>>>>>>>>>>>>>>>>>>>>>>> will run forever but never hit a repeated state. >>>>>>>>>>>>>>>>>>>>>>>>>
And why can't that same program be used to >>>>>>>>>>>>>>>>>>>>>>>>> compute the sloppy- anti- diagonal (where you >>>>>>>>>>>>>>>>>>>>>>>>> still test the M with DN(sloppy_H) not changing >>>>>>>>>>>>>>>>>>>>>>>>> that, and then reverse the output of the two >>>>>>>>>>>>>>>>>>>>>>>>> outputs.
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // sim
one step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>>>>> continue >>>>>>>>>>>>>>>>>>>>>>>>>> } //
outputs other than STEP
if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine
K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>> }
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) //
internally tracks stepping >>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
this is the sloppy diagonal, it doesn't care >>>>>>>>>>>>>>>>>>>>>>>>>> if circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>>>>
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>> is reached
before a loop is detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when >>>>>>>>>>>>>>>>>>>>>>>>>>>> a configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>> when a simulated machine tries to simulates >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself
How can you tell this?
What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a machine, >>>>>>>>>>>>>>>>>>>>>>>>>>> but it hasn't halted yet. >>>>>>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because >>>>>>>>>>>>>>>>>>>>>>>>> the anti- program does EXACTLY the same steps >>>>>>>>>>>>>>>>>>>>>>>>> it will also create an anti- diagonal, which >>>>>>>>>>>>>>>>>>>>>>>>> could not have been from a machine in the >>>>>>>>>>>>>>>>>>>>>>>>> listing, thus showing your enumation doesn't >>>>>>>>>>>>>>>>>>>>>>>>> include ALL machines for ALL the computable >>>>>>>>>>>>>>>>>>>>>>>>> numbers.
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>>>>
i guess at this point there's little point to >>>>>>>>>>>>>>>>>>>>>>>>>> even try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M has >>>>>>>>>>>>>>>>>>>>>>>>>> been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output alone >>>>>>>>>>>>>>>>>>>>>>>>>> the way. after the step is complete, if the >>>>>>>>>>>>>>>>>>>>>>>>>> Kth output has been recorded already it will >>>>>>>>>>>>>>>>>>>>>>>>>> output that. however if the Kth output has not >>>>>>>>>>>>>>>>>>>>>>>>>> already been output by the machine then STEP >>>>>>>>>>>>>>>>>>>>>>>>>> it output
sloppier_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) // sim
one step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>>>>> output res >>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case
output 0
K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>> K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what >>>>>>>>>>>>>>>>>>>>>>>>>> happens to anti_sloppier_H when sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>> starts dovetailing it. i'm kinda guessing at >>>>>>>>>>>>>>>>>>>>>>>>>> the moment that the K within sloppier_H grows >>>>>>>>>>>>>>>>>>>>>>>>>> faster than the K within anti_sloppier_H and >>>>>>>>>>>>>>>>>>>>>>>>>> therefore sloppier_H will just never actually >>>>>>>>>>>>>>>>>>>>>>>>>> output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>>>>
No, it is supposed to be EXACTLY simulating the >>>>>>>>>>>>>>>>>>>>>>> steps of sloppier_H.
i suppose we can adjust it with a steppable >>>>>>>>>>>>>>>>>>>>>>>> runtime:
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>> K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K)
if (res != STEP) { >>>>>>>>>>>>>>>>>>>>>>>> output res
K += 1
}
}
}
but i don't think this will change anything. it >>>>>>>>>>>>>>>>>>>>>>>> will constantly run behind sloppier's K for >>>>>>>>>>>>>>>>>>>>>>>> several reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... >>>>>>>>>>>>>>>>>>>>>>>> mean sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output of >>>>>>>>>>>>>>>>>>>>>> after each step of sloppier_H, to see if an output >>>>>>>>>>>>>>>>>>>>>> was found, and then advance K if so. >>>>>>>>>>>>>>>>>>>>>
That doesn't affect the answer that sloppier_H >>>>>>>>>>>>>>>>>>>>> gives to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>>>>>> output slower than sloppier_H.
So, that doesn't affect the value of K. >>>>>>>>>>>>>>>>>>>>>
in fact, anti_sloppier_H cannot output a digit for >>>>>>>>>>>>>>>>>>>>>> a particular K until /after/ sloppier_H outputs a >>>>>>>>>>>>>>>>>>>>>> digit for that particular K...
Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even >>>>>>>>>>>>>>>>>>>>> though at a slower rate) and will EXAXTLY output >>>>>>>>>>>>>>>>>>>>> the opposite that sloppier_H outputs. >>>>>>>>>>>>>>>>>>>>>
so there is no way for anti_sloppier_H to ever >>>>>>>>>>>>>>>>>>>>>> output for some particular K until after >>>>>>>>>>>>>>>>>>>>>> sloppier_H has started looking for at least a K+1 >>>>>>>>>>>>>>>>>>>>>> digit,
So?
meaning sloppier_H will never put anti_sloppier_H >>>>>>>>>>>>>>>>>>>>>> on the diagonal
Right.
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of >>>>>>>>>>>>>>>>>>> computable numbers.
It seems you beleive errors are acceptable. >>>>>>>>>>>>>>>>>>>
So, why do you complain of people not proving >>>>>>>>>>>>>>>>>>> programs to be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>>>>> computable number, at least as long as your >>>>>>>>>>>>>>>>>>>>> sloppier_H outputs a computable number as the >>>>>>>>>>>>>>>>>>>>> diagonal, it needed to in order for the diagonal to >>>>>>>>>>>>>>>>>>>>> be of a complete enumeration of computable numbers. >>>>>>>>>>>>>>>>>>>>>
Sloppier H can NEVER output a digiton its diagonal >>>>>>>>>>>>>>>>>>>>> that matches the anti-diagonal computed by anti- >>>>>>>>>>>>>>>>>>>>> slippier-H, and thus the computable number it >>>>>>>>>>>>>>>>>>>>> computes can't be in the enumeration that it is >>>>>>>>>>>>>>>>>>>>> working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct contradiction >>>>>>>>>>>>>>>>>>>>>> to the obviously effective enumerability used to >>>>>>>>>>>>>>>>>>>>>> create sloppier_H in the first place >>>>>>>>>>>>>>>>>>>>>>
But the effective enumeration used to create >>>>>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine the >>>>>>>>>>>>>>>>>>>>> of at least one machine the computes every >>>>>>>>>>>>>>>>>>>>> computable number.
You seem to have forgotten your own requirement >>>>>>>>>>>>>>>>>>>>> that the enumeration was to include at least one >>>>>>>>>>>>>>>>>>>>> machine that computes every computable number. >>>>>>>>>>>>>>>>>>>>>
Yes, there are many computably enumerated SUB-sets >>>>>>>>>>>>>>>>>>>>> of the computable numbers, just not one for a >>>>>>>>>>>>>>>>>>>>> complete set of them.
All you are doing is showing you don't understand >>>>>>>>>>>>>>>>>>>>> what it means to be correct.
Maybe you should test your machines to see if they >>>>>>>>>>>>>>>>>>>>> meet your requirements, after all, you complaint >>>>>>>>>>>>>>>>>>>>> was about people releasing code that wasn't proven >>>>>>>>>>>>>>>>>>>>> to be correct.
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration that >>>>>>>>>>>>>>>>> is admittedly containing only a subset of the >>>>>>>>>>>>>>>>> computable numbers is just not interesting.
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>>>>>> yourself to just wonder off into uninteresting problems >>>>>>>>>>>>>>>>> with no attempt to justify why they might be >>>>>>>>>>>>>>>>> interesting because you are doing them better that how >>>>>>>>>>>>>>>>> they have been done before, you are just wasting >>>>>>>>>>>>>>>>> everyone's time.
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>>>>
i'm not selecting for anything in particular, i'm >>>>>>>>>>>>>>>>>>>> just running any whatever machine that we come >>>>>>>>>>>>>>>>>>>> across, and trying to put it on a diagonal >>>>>>>>>>>>>>>>>>>
You forgot the problem you were working on, and just >>>>>>>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets >>>>>>>>>>>>>>>>>>> allow D to not select EVERY non-circular machine, >>>>>>>>>>>>>>>>>>> just it needs to select at least one for each >>>>>>>>>>>>>>>>>>> computable number.
The computable number of the anti-diagonal isn't in >>>>>>>>>>>>>>>>>>> the set of numbers your D accepts a machine for. >>>>>>>>>>>>>>>>>>>
And thus you failed at your goal, and forgot about >>>>>>>>>>>>>>>>>>> the problem, because you attention span is apparently >>>>>>>>>>>>>>>>>>> to short to take it to a finish line.
the process of innovation is inherently serendipitous, >>>>>>>>>>>>>>>>>> rick
And when you let yourself wonder into mundane and non- >>>>>>>>>>>>>>>>> inovative areas, you can waste a LOT of time. >>>>>>>>>>>>>>>>
Yes, he knows, and the fact you can't see it shows your >>>>>>>>>>>>>>> problem.
Again, it seems you don't care if you work can actually >>>>>>>>>>>>>>>>> be useful, as you seem to accept that it is ok to spend >>>>>>>>>>>>>>>>> a lot of time in mundane problems with known solutions, >>>>>>>>>>>>>>>>> while also adding in booby- traps (like accepting >>>>>>>>>>>>>>>>> circular machines into your enumeration) that makes >>>>>>>>>>>>>>>>> quantifying what you are doing nearly impossible. >>>>>>>>>>>>>>>>>
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand >>>>>>>>>>>>>>>>>>> what problem you are working on because you are just >>>>>>>>>>>>>>>>>>> fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>>>>>>
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>>>>
I have shown a way to build a computable number >>>>>>>>>>>>>>>>>>>>> that you enumeration doesn't include, and thus it >>>>>>>>>>>>>>>>>>>>> can't be a complete enumeration, as you claim it is >>>>>>>>>>>>>>>>>>>>> supposedly by some "magic" assumptions. >>>>>>>>>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in >>>>>>>>>>>>>>>>> you description of what the based decider is doing by >>>>>>>>>>>>>>>>> trying to filter out inputs that hit repeat state. >>>>>>>>>>>>>>>>>
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal >>>>>>>>>>>>>>>>>> across them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on >>>>>>>>>>>>>>>>>> the diagonal, therefor _all machines_ is not >>>>>>>>>>>>>>>>>> effectively enumerable
No, THIS METHOD can't enumerate all machines. >>>>>>>>>>>>>>>>>
Also note, that just because we can enumerate all >>>>>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" of >>>>>>>>>>>>>>>>> the output of all machines, as some
if i mean if machine enumerability _does not imply_ >>>>>>>>>>>>>>>> being able to compute a diagonal across the machines >>>>>>>>>>>>>>>> being enumerated,
WHy should it. Many machines are circular, and thus might >>>>>>>>>>>>>>> not REACH the diagonal. Hard to compute a diagonal with >>>>>>>>>>>>>>> "holes" in it (since "hole" isn't a valid symbol) >>>>>>>>>>>>>>>
Which showds you don't understand the difference between >>>>>>>>>>>>>>> just enumerating any ol machine, and enumerating circle- >>>>>>>>>>>>>>> free machines.
ei: if enumerability of a set of machines is independent >>>>>>>>>>>>>>>> from being able to compute a diagonal across the set of >>>>>>>>>>>>>>>> machine,
then one _cannot_ use an inability to compute a diagonal >>>>>>>>>>>>>>>> to prove a lack of enumerability, and u've lost turing's >>>>>>>>>>>>>>>> proof against the enumerability of computable numbers >>>>>>>>>>>>>>>
enumerating a set of machines is enumerating a set of >>>>>>>>>>>>>> machines eh????
why does failing to produce a diagonal for one set >>>>>>>>>>>>>> (computable numbers) imply it's not effectively
enumerability,
Because if it WAS effectively enumerable, you could, >>>>>>>>>>>>> because we could build the diagonal (or anti-diagonal) >>>>>>>>>>>>> computation from the algorithm of the effective enumeration. >>>>>>>>>>>>
But automatically becomes possible, if the enumeration
creates a full matrix of results, as a diagonal exists.
even if u can enumerate the set of machines,
it's still possible to define a machines that can't be put on >>>>>>>>>> any diagonal because it's based off the output of the diagonal >>>>>>>>>> computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the >>>>>>>>> diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, as >>>>>>>>> all the machines generate enough data to reach it, you can
compute the diagonal.
Of course you can't compute a diagonal that doesn't exist.
It seems you are riding your Unicorn again of a enumeration of >>>>>>>>> machine that all reach the diagonal with a machine in that
which doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every
machine reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency >>>>>>>>>>>> in principles
What inconsistency?
can't compute diagonal across computable numbers => proof >>>>>>>>>> against effective enumerability
can't compute diagonal across all executable machines => not >>>>>>>>>> proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can >>>>>>>>> be the reason you can't compute it.
totally inconsistent rick, and idk how to make that more clear >>>>>>>>>> tbh
Just like your K < K claim, since that diagonal computation >>>>>>>>> apparently reached the diagonal in one view to create it, but >>>>>>>>> also can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H? >>>>>>>>
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your enumaration >>>>>>> that sloppier_H is incomplete, it is uninteresting.
i think it's _very_ interesting that despite have a method to
enumerate _all_ machines, which includes _all_ computable numbers, >>>>>> it's still not possible to put all the computable numbers within
that set on a diagonal:
Right, because you can't create the "diagonal" for all machines, as it >>>>
Yes, but that enumeration doesn't create a "diagonal".
There isn't a kth digit output by the kth machine for all machines in
that enumeration.
which is fine, it skips machines that don't have output to put on the
diagonal ...
But, it turns out, this means that its enumerations isn't complete
but computable numbers should all have outputs to put on the diagonal,
yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
this doesn't require specifically selection for them, they should have
outputs regardless of whether we select for them, and that should be
the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off anti- sloppier-H, which while actually computable, beomes to "slow" to reach
the top of the list.
therefore, regardless of whether we can enumerate a set of computable
numbers or not, they cannot all be computably put on a diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth digits
in a finite number of steps if sloppier-H outputs its Kth digit in a
finite number of steps, so both are generating computable numbers or not together, but anti-sloppier-H isn't in your enumeration.
if i were talking to someone capable of doing more than upholding a
bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that apply to finite sets apply to infinite sets.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all
machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal, because
they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly
built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit.
Thus, if sloppier_H continues to run and produce output, so does
anti_sloppier_H
so they _should_ end up on the attempted diagonal computation, given
we're simulating all of them in parallel, but that can't happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of the
enumeration
But, then the enumeration CAN'T BE COMPLETE.
The problem is that the progress that sloppier-H makes gets slower and slower as the infinite number of circular machines get added to the set
of machines being simulated to find the one that makes the next digit,
and thus the number of steps that sloppier-H needs to perform grows, and that sum becomes a divergent sum that doesn't converge, and thus it
never actually gets to anti-sloppier-H.
And without all the numbers, it isn't COMPLETE, and thus uninteresting.
not all machines even produce output, so ofc trying to compute a
diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines but
not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they should
be includable in attempting to compute a diagonal across all machines
The problem is that you are NOT making an enumeration of ALL machines,
but only machines that reach the diagonal when sorted by your criteria.
Where we sort the machines this way, we create a super-set of the
machines, and thus get to an uncountable infinity, so we can't enumerate
it.
Of course, uncountable infinities doen't follow the logic that you want
to try to think with.
While the sum of the number of steps needed to get to the Kth output of anti-sloppier-H is finite, when you multiply each element by the number
of machines included by sloppier-H to compute that, the sum doesn't converge, thus your "enumeration" puts anti-sloppier-H at an uncountable value in the enumeration even though the machine itself is circle-free.
It seems you have a fundamental problem about thinking through the
requirements, as "requirements" are just optional ideas to you.
clearly being able to enumerate a set of machines, does _not_ then >>>>>> imply one can certainly construct a diagonal across the computable >>>>>> numbers within that set
Because the determination that a given machine create a computable
number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing off
when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its
diagonal digit is.
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't >>>>>>> a VALUE output, but the id number of the row being output, and
the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as
sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K
digits, and thus any machine like turing's original H that looks >>>>>>> to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a special >>>>>>> number, but anti_sloppier_H won't do that, so sloppier_H will
never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference" >>>>>>> number as sloppier_H, NOT its own, and thus it WILL get the anti- >>>>>>> diagonal that is the opposite of sloppier_H, and won't get hung >>>>>>> up on itself, since neither did sloppier_H get hung up on
anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow
instructions, possible because you are just mentally unable to do >>>>>>> accurate work because "correct" isn't a word you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to follow
instructions because you are mentally unable to do accurate work
becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱
It seems that is just all you can do, since you don't understand how to
do actual logic, but just want to use fallacies.
After all, you ARE proving you don't understand what a requirement is.
this is exploring the bounds of theory mate, not engineering a system
But, you forget that you need to actually PROVE what you claim.
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix, you can
not show that you compute "fast" enough to get to any particuar machine,
as there are an infinite number of machines that can get to their kth
output before this one, (even if they eventually become circular and
stop outputing).
Ultimately, the problem is that the sorting that your "enumeration" is
based on creates a super-set of the Natural Numbers, which is
uncountable, so you can't get to all the elements of that set.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't
exist (like the diagonal of an enumeration that includes
circular machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater >>>>>>>>> than 2 doesn't affect our ability to compute other primes.
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>
My guess is you are not going to actually answer with a real >>>>>>>>>>> inconsistance, but just throw out a strawman, and that is >>>>>>>>>>> your modus operandi.
On 4/2/26 4:18 AM, Richard Damon wrote:
On 4/2/26 12:21 AM, dart200 wrote:
On 4/1/26 6:36 PM, Richard Damon wrote:
On 4/1/26 7:06 PM, dart200 wrote:
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:i think it's _very_ interesting that despite have a method to
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:even if u can enumerate the set of machines,
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:clearly building a diagonal is not required for a set of >>>>>>>>>>>>> machines to be effectively enumerable ..
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:god only knows what u think ur doing
On 3/29/26 1:37 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/26 1:25 PM, dart200 wrote:So, what use is that problem, if you are admitting >>>>>>>>>>>>>>>>>> that you can't compute the diagonal of an enumeration >>>>>>>>>>>>>>>>>> that includes all computable numbers? (which is at >>>>>>>>>>>>>>>>>> least close to what Turing was talking about). >>>>>>>>>>>>>>>>>>
that was...On 3/29/26 10:07 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/29/26 12:19 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> circle-free computable numbers that defeats >>>>>>>>>>>>>>>>>>>>>>>>>>>>> all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>>>>>>>>>>>
So?And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as >>>>>>>>>>>>>>>>>>>>>>>> the code for the machine with its number. >>>>>>>>>>>>>>>>>>>>>>>>before for every K, anti_sloppier_H simulates >>>>>>>>>>>>>>>>>>>>>>>>> the entirety of sloppier_H from 1..K, >>>>>>>>>>>>>>>>>>>>>>>>No, it is a decider that enumerates machines >>>>>>>>>>>>>>>>>>>>>>>>>> that is supposed to generate that, but then a >>>>>>>>>>>>>>>>>>>>>>>>>> machine that tries to use it to enumerate all >>>>>>>>>>>>>>>>>>>>>>>>>> enumerable numbers will hang and not generate >>>>>>>>>>>>>>>>>>>>>>>>>> the enumeration.Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> sloppier version of that diagonal, one that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> includes some circular numbers as well. for >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this i will introduce a new simulation >>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine:
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some non- >>>>>>>>>>>>>>>>>>>>>>>>>>>> circle- free machines, then the enumeration >>>>>>>>>>>>>>>>>>>>>>>>>>>> of the "computable numbers" it generates >>>>>>>>>>>>>>>>>>>>>>>>>>>> isn't valid, as the array of values has >>>>>>>>>>>>>>>>>>>>>>>>>>>> holes in it.
it's not an enumeration of computable >>>>>>>>>>>>>>>>>>>>>>>>>>> numbers, it's a superset of said enumeration >>>>>>>>>>>>>>>>>>>>>>>>>>> that includes some "circular" machines, but >>>>>>>>>>>>>>>>>>>>>>>>>>> should include all computable numbers >>>>>>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" >>>>>>>>>>>>>>>>>>>>>>>>>> enumeration for getting you to the goal of >>>>>>>>>>>>>>>>>>>>>>>>>> showing how to compute an enumeration of all >>>>>>>>>>>>>>>>>>>>>>>>>> computable numbers.
Note, because the set of "computable numbers" >>>>>>>>>>>>>>>>>>>>>>>>>> are (as you have pointed out) NOT the same >>>>>>>>>>>>>>>>>>>>>>>>>> machines that compute them, Your "super set" >>>>>>>>>>>>>>>>>>>>>>>>>> as described isn't a set of one sort of thing, >>>>>>>>>>>>>>>>>>>>>>>>>> and is actually (as I just described) a set of >>>>>>>>>>>>>>>>>>>>>>>>>> MACHINES that compute computable numbers + >>>>>>>>>>>>>>>>>>>>>>>>>> some machines that are circular. >>>>>>>>>>>>>>>>>>>>>>>>>>
The presence of the circular machines in the >>>>>>>>>>>>>>>>>>>>>>>>>> set means you can't use that set to compute >>>>>>>>>>>>>>>>>>>>>>>>>> the computable numbers, as you process will >>>>>>>>>>>>>>>>>>>>>>>>>> hang on circular machines in the set. >>>>>>>>>>>>>>>>>>>>>>>>>>
This is, i think. part of the reason that >>>>>>>>>>>>>>>>>>>>>>>>>> Turing switch to the enumeration of non- >>>>>>>>>>>>>>>>>>>>>>>>>> circular machines, as they are easier to talk >>>>>>>>>>>>>>>>>>>>>>>>>> about processing, as they are finite things, >>>>>>>>>>>>>>>>>>>>>>>>>> while the elements of the computable numbers >>>>>>>>>>>>>>>>>>>>>>>>>> are not, and if you try to talk about using >>>>>>>>>>>>>>>>>>>>>>>>>> ONE machine that generates it, you have the >>>>>>>>>>>>>>>>>>>>>>>>>> problem of selecting that one machine from the >>>>>>>>>>>>>>>>>>>>>>>>>> infinite set that generates it. >>>>>>>>>>>>>>>>>>>>>>>>>>
we can avoid that using a stepping simulation >>>>>>>>>>>>>>>>>>>>>>>>>>> while dovetailing:
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is >>>>>>>>>>>>>>>>>>>>>>>>>>>> likely somewhere on the "diagonal" a spot >>>>>>>>>>>>>>>>>>>>>>>>>>>> where the kth machine in the list doesn't >>>>>>>>>>>>>>>>>>>>>>>>>>>> generate k digits of output, because it was >>>>>>>>>>>>>>>>>>>>>>>>>>>> one of those non- circle- free machines >>>>>>>>>>>>>>>>>>>>>>>>>>>> accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>>>>>>
Nope.
your step_deect_loop might not return anything >>>>>>>>>>>>>>>>>>>>>>>>>> for all machines, as not all circularity is >>>>>>>>>>>>>>>>>>>>>>>>>> detectable.
As I pointed out, some machines just continue >>>>>>>>>>>>>>>>>>>>>>>>>> to slowly grow over time and never repeat a >>>>>>>>>>>>>>>>>>>>>>>>>> state.
For instance, if the Goldbach conjecture is >>>>>>>>>>>>>>>>>>>>>>>>>> true, a program to find the first even number >>>>>>>>>>>>>>>>>>>>>>>>>> that can't be found as the sum of two prime, >>>>>>>>>>>>>>>>>>>>>>>>>> will run forever but never hit a repeated state. >>>>>>>>>>>>>>>>>>>>>>>>>>
And why can't that same program be used to >>>>>>>>>>>>>>>>>>>>>>>>>> compute the sloppy- anti- diagonal (where you >>>>>>>>>>>>>>>>>>>>>>>>>> still test the M with DN(sloppy_H) not >>>>>>>>>>>>>>>>>>>>>>>>>> changing that, and then reverse the output of >>>>>>>>>>>>>>>>>>>>>>>>>> the two outputs.
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M is >>>>>>>>>>>>>>>>>>>>>>>>>>> reached
before a loop is detected,
}
sloppy_H = () -> {
M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // sim
one step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>>>>>> continue >>>>>>>>>>>>>>>>>>>>>>>>>>> } //
outputs other than STEP
if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine >>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>> }
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case
output 0 >>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
} else {
m = steppable_runtime(M) //
internally tracks stepping >>>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
this is the sloppy diagonal, it doesn't care >>>>>>>>>>>>>>>>>>>>>>>>>>> if circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>>>>>
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is reached
before a loop is
detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected when >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>> when a simulated machine tries to simulates >>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself
How can you tell this? >>>>>>>>>>>>>>>>>>>>>>>>>>>> What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such a >>>>>>>>>>>>>>>>>>>>>>>>>>>> circular condition when simulating a >>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, but it hasn't halted yet. >>>>>>>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because >>>>>>>>>>>>>>>>>>>>>>>>>> the anti- program does EXACTLY the same steps >>>>>>>>>>>>>>>>>>>>>>>>>> it will also create an anti- diagonal, which >>>>>>>>>>>>>>>>>>>>>>>>>> could not have been from a machine in the >>>>>>>>>>>>>>>>>>>>>>>>>> listing, thus showing your enumation doesn't >>>>>>>>>>>>>>>>>>>>>>>>>> include ALL machines for ALL the computable >>>>>>>>>>>>>>>>>>>>>>>>>> numbers.
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>>>>>
i guess at this point there's little point to >>>>>>>>>>>>>>>>>>>>>>>>>>> even try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> {
STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>> has been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output alone >>>>>>>>>>>>>>>>>>>>>>>>>>> the way. after the step is complete, if the >>>>>>>>>>>>>>>>>>>>>>>>>>> Kth output has been recorded already it will >>>>>>>>>>>>>>>>>>>>>>>>>>> output that. however if the Kth output has >>>>>>>>>>>>>>>>>>>>>>>>>>> not already been output by the machine then >>>>>>>>>>>>>>>>>>>>>>>>>>> STEP it output
sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>> M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) // sim
one step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>>>>>> output res >>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case
output 0 >>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
} else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>> K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what >>>>>>>>>>>>>>>>>>>>>>>>>>> happens to anti_sloppier_H when sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>> starts dovetailing it. i'm kinda guessing at >>>>>>>>>>>>>>>>>>>>>>>>>>> the moment that the K within sloppier_H grows >>>>>>>>>>>>>>>>>>>>>>>>>>> faster than the K within anti_sloppier_H and >>>>>>>>>>>>>>>>>>>>>>>>>>> therefore sloppier_H will just never actually >>>>>>>>>>>>>>>>>>>>>>>>>>> output a digit from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>>>>>
No, it is supposed to be EXACTLY simulating the >>>>>>>>>>>>>>>>>>>>>>>> steps of sloppier_H.
i suppose we can adjust it with a steppable >>>>>>>>>>>>>>>>>>>>>>>>> runtime:
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>> K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K) >>>>>>>>>>>>>>>>>>>>>>>>> if (res != STEP) { >>>>>>>>>>>>>>>>>>>>>>>>> output res
K += 1
}
}
}
but i don't think this will change anything. it >>>>>>>>>>>>>>>>>>>>>>>>> will constantly run behind sloppier's K for >>>>>>>>>>>>>>>>>>>>>>>>> several reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... >>>>>>>>>>>>>>>>>>>>>>>>> mean sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in parallel >>>>>>>>>>>>>>>>>>>>>>>>
anti_sloppier_H takes more steps for each step of >>>>>>>>>>>>>>>>>>>>>>> sloppier_H because it needs to check the output >>>>>>>>>>>>>>>>>>>>>>> of after each step of sloppier_H, to see if an >>>>>>>>>>>>>>>>>>>>>>> output was found, and then advance K if so. >>>>>>>>>>>>>>>>>>>>>>
That doesn't affect the answer that sloppier_H >>>>>>>>>>>>>>>>>>>>>> gives to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>>>>>>> output slower than sloppier_H.
So, that doesn't affect the value of K. >>>>>>>>>>>>>>>>>>>>>>
in fact, anti_sloppier_H cannot output a digit >>>>>>>>>>>>>>>>>>>>>>> for a particular K until /after/ sloppier_H >>>>>>>>>>>>>>>>>>>>>>> outputs a digit for that particular K... >>>>>>>>>>>>>>>>>>>>>>Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even >>>>>>>>>>>>>>>>>>>>>> though at a slower rate) and will EXAXTLY output >>>>>>>>>>>>>>>>>>>>>> the opposite that sloppier_H outputs. >>>>>>>>>>>>>>>>>>>>>>
so there is no way for anti_sloppier_H to ever >>>>>>>>>>>>>>>>>>>>>>> output for some particular K until after >>>>>>>>>>>>>>>>>>>>>>> sloppier_H has started looking for at least a K+1 >>>>>>>>>>>>>>>>>>>>>>> digit,
So?
meaning sloppier_H will never put anti_sloppier_H >>>>>>>>>>>>>>>>>>>>>>> on the diagonal
Right.
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of >>>>>>>>>>>>>>>>>>>> computable numbers.
It seems you beleive errors are acceptable. >>>>>>>>>>>>>>>>>>>>
So, why do you complain of people not proving >>>>>>>>>>>>>>>>>>>> programs to be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>>>>>> computable number, at least as long as your >>>>>>>>>>>>>>>>>>>>>> sloppier_H outputs a computable number as the >>>>>>>>>>>>>>>>>>>>>> diagonal, it needed to in order for the diagonal >>>>>>>>>>>>>>>>>>>>>> to be of a complete enumeration of computable >>>>>>>>>>>>>>>>>>>>>> numbers.
Sloppier H can NEVER output a digiton its diagonal >>>>>>>>>>>>>>>>>>>>>> that matches the anti-diagonal computed by anti- >>>>>>>>>>>>>>>>>>>>>> slippier-H, and thus the computable number it >>>>>>>>>>>>>>>>>>>>>> computes can't be in the enumeration that it is >>>>>>>>>>>>>>>>>>>>>> working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct >>>>>>>>>>>>>>>>>>>>>>> contradiction to the obviously effective >>>>>>>>>>>>>>>>>>>>>>> enumerability used to create sloppier_H in the >>>>>>>>>>>>>>>>>>>>>>> first place
But the effective enumeration used to create >>>>>>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine >>>>>>>>>>>>>>>>>>>>>> the of at least one machine the computes every >>>>>>>>>>>>>>>>>>>>>> computable number.
You seem to have forgotten your own requirement >>>>>>>>>>>>>>>>>>>>>> that the enumeration was to include at least one >>>>>>>>>>>>>>>>>>>>>> machine that computes every computable number. >>>>>>>>>>>>>>>>>>>>>>
Yes, there are many computably enumerated SUB-sets >>>>>>>>>>>>>>>>>>>>>> of the computable numbers, just not one for a >>>>>>>>>>>>>>>>>>>>>> complete set of them.
All you are doing is showing you don't understand >>>>>>>>>>>>>>>>>>>>>> what it means to be correct.
Maybe you should test your machines to see if they >>>>>>>>>>>>>>>>>>>>>> meet your requirements, after all, you complaint >>>>>>>>>>>>>>>>>>>>>> was about people releasing code that wasn't proven >>>>>>>>>>>>>>>>>>>>>> to be correct.
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration >>>>>>>>>>>>>>>>>> that is admittedly containing only a subset of the >>>>>>>>>>>>>>>>>> computable numbers is just not interesting. >>>>>>>>>>>>>>>>>>
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>>>>>>> yourself to just wonder off into uninteresting >>>>>>>>>>>>>>>>>> problems with no attempt to justify why they might be >>>>>>>>>>>>>>>>>> interesting because you are doing them better that how >>>>>>>>>>>>>>>>>> they have been done before, you are just wasting >>>>>>>>>>>>>>>>>> everyone's time.
the process of innovation is inherently >>>>>>>>>>>>>>>>>>> serendipitous, rick
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>>>>>
i'm not selecting for anything in particular, i'm >>>>>>>>>>>>>>>>>>>>> just running any whatever machine that we come >>>>>>>>>>>>>>>>>>>>> across, and trying to put it on a diagonal >>>>>>>>>>>>>>>>>>>>
You forgot the problem you were working on, and just >>>>>>>>>>>>>>>>>>>> started to play in your garbage.
Did you forget, that you started by saying, lets >>>>>>>>>>>>>>>>>>>> allow D to not select EVERY non-circular machine, >>>>>>>>>>>>>>>>>>>> just it needs to select at least one for each >>>>>>>>>>>>>>>>>>>> computable number.
The computable number of the anti-diagonal isn't in >>>>>>>>>>>>>>>>>>>> the set of numbers your D accepts a machine for. >>>>>>>>>>>>>>>>>>>>
And thus you failed at your goal, and forgot about >>>>>>>>>>>>>>>>>>>> the problem, because you attention span is >>>>>>>>>>>>>>>>>>>> apparently to short to take it to a finish line. >>>>>>>>>>>>>>>>>>>
And when you let yourself wonder into mundane and non- >>>>>>>>>>>>>>>>>> inovative areas, you can waste a LOT of time. >>>>>>>>>>>>>>>>>
Yes, he knows, and the fact you can't see it shows your >>>>>>>>>>>>>>>> problem.
Again, it seems you don't care if you work can >>>>>>>>>>>>>>>>>> actually be useful, as you seem to accept that it is >>>>>>>>>>>>>>>>>> ok to spend a lot of time in mundane problems with >>>>>>>>>>>>>>>>>> known solutions, while also adding in booby- traps >>>>>>>>>>>>>>>>>> (like accepting circular machines into your >>>>>>>>>>>>>>>>>> enumeration) that makes quantifying what you are doing >>>>>>>>>>>>>>>>>> nearly impossible.
sloppier_H is not selecting for or even attempting to >>>>>>>>>>>>>>>>>>> select for "computable sequences"
Yep, that is your problem, as you don't understand >>>>>>>>>>>>>>>>>>>> what problem you are working on because you are just >>>>>>>>>>>>>>>>>>>> fundamentally ignorant of what you are talking about. >>>>>>>>>>>>>>>>>>>
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>>>>>
I have shown a way to build a computable number >>>>>>>>>>>>>>>>>>>>>> that you enumeration doesn't include, and thus it >>>>>>>>>>>>>>>>>>>>>> can't be a complete enumeration, as you claim it >>>>>>>>>>>>>>>>>>>>>> is supposedly by some "magic" assumptions. >>>>>>>>>>>>>>>>>>>>>
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in >>>>>>>>>>>>>>>>>> you description of what the based decider is doing by >>>>>>>>>>>>>>>>>> trying to filter out inputs that hit repeat state. >>>>>>>>>>>>>>>>>>
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal >>>>>>>>>>>>>>>>>>> across them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on >>>>>>>>>>>>>>>>>>> the diagonal, therefor _all machines_ is not >>>>>>>>>>>>>>>>>>> effectively enumerable
No, THIS METHOD can't enumerate all machines. >>>>>>>>>>>>>>>>>>
Also note, that just because we can enumerate all >>>>>>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" >>>>>>>>>>>>>>>>>> of the output of all machines, as some
if i mean if machine enumerability _does not imply_ >>>>>>>>>>>>>>>>> being able to compute a diagonal across the machines >>>>>>>>>>>>>>>>> being enumerated,
WHy should it. Many machines are circular, and thus >>>>>>>>>>>>>>>> might not REACH the diagonal. Hard to compute a diagonal >>>>>>>>>>>>>>>> with "holes" in it (since "hole" isn't a valid symbol) >>>>>>>>>>>>>>>>
ei: if enumerability of a set of machines is >>>>>>>>>>>>>>>>> independent from being able to compute a diagonal >>>>>>>>>>>>>>>>> across the set of machine,
then one _cannot_ use an inability to compute a >>>>>>>>>>>>>>>>> diagonal to prove a lack of enumerability, and u've >>>>>>>>>>>>>>>>> lost turing's proof against the enumerability of >>>>>>>>>>>>>>>>> computable numbers
Which showds you don't understand the difference between >>>>>>>>>>>>>>>> just enumerating any ol machine, and enumerating circle- >>>>>>>>>>>>>>>> free machines.
enumerating a set of machines is enumerating a set of >>>>>>>>>>>>>>> machines eh????
why does failing to produce a diagonal for one set >>>>>>>>>>>>>>> (computable numbers) imply it's not effectively >>>>>>>>>>>>>>> enumerability,
Because if it WAS effectively enumerable, you could, >>>>>>>>>>>>>> because we could build the diagonal (or anti-diagonal) >>>>>>>>>>>>>> computation from the algorithm of the effective enumeration. >>>>>>>>>>>>>
But automatically becomes possible, if the enumeration >>>>>>>>>>>> creates a full matrix of results, as a diagonal exists. >>>>>>>>>>>
it's still possible to define a machines that can't be put on >>>>>>>>>>> any diagonal because it's based off the output of the
diagonal computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the >>>>>>>>>> diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, >>>>>>>>>> as all the machines generate enough data to reach it, you can >>>>>>>>>> compute the diagonal.
Of course you can't compute a diagonal that doesn't exist. >>>>>>>>>>
It seems you are riding your Unicorn again of a enumeration of >>>>>>>>>> machine that all reach the diagonal with a machine in that >>>>>>>>>> which doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every >>>>>>>>>>>> machine reaches it, you can't compute it.
But then, that is just your imagining unicorns again.
and stop insulting me to make up for ur lack of consistency >>>>>>>>>>>>> in principles
What inconsistency?
can't compute diagonal across computable numbers => proof >>>>>>>>>>> against effective enumerability
can't compute diagonal across all executable machines => not >>>>>>>>>>> proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can >>>>>>>>>> be the reason you can't compute it.
totally inconsistent rick, and idk how to make that more >>>>>>>>>>> clear tbh
Just like your K < K claim, since that diagonal computation >>>>>>>>>> apparently reached the diagonal in one view to create it, but >>>>>>>>>> also can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within sloppier_H? >>>>>>>>>
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your
enumaration that sloppier_H is incomplete, it is uninteresting. >>>>>>>
enumerate _all_ machines, which includes _all_ computable
numbers, it's still not possible to put all the computable
numbers within that set on a diagonal:
Right, because you can't create the "diagonal" for all machines,
as it
you _can_ enumerate them...
Yes, but that enumeration doesn't create a "diagonal".
There isn't a kth digit output by the kth machine for all machines
in that enumeration.
which is fine, it skips machines that don't have output to put on the
diagonal ...
But, it turns out, this means that its enumerations isn't complete
but it's produced entirely just by simulating what _is_ a complete enumeration of _all_ machines ...
why didn't all the computable numbers, which have an output for _all_ K therefore allowing them to reach any diagonal of the output total number matrix make it onto the computed diagonal???
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
this doesn't require specifically selection for them, they should
have outputs regardless of whether we select for them, and that
should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off anti-
sloppier-H, which while actually computable, beomes to "slow" to reach
the top of the list.
at least u understand the problem here
therefore, regardless of whether we can enumerate a set of computable
numbers or not, they cannot all be computably put on a diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth
digits in a finite number of steps if sloppier-H outputs its Kth digit
in a finite number of steps, so both are generating computable numbers
or not together, but anti-sloppier-H isn't in your enumeration.
the question is: are u able to admit this is a problem? or just
continually accept the paradoxical as valid because ur already so used
to promoting the current consensus as valid?
if i were talking to someone capable of doing more than upholding a
bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that apply
to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being uncountable
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all
machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal, because >>>>> they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly
built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit.
Thus, if sloppier_H continues to run and produce output, so does
anti_sloppier_H
Right, but it misses some, like anti_sloppier_H.
so they _should_ end up on the attempted diagonal computation,
given we're simulating all of them in parallel, but that can't happen >>>>
which means the fact some are missed is an independent facet of the
enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
The problem is that the progress that sloppier-H makes gets slower and
slower as the infinite number of circular machines get added to the
set of machines being simulated to find the one that makes the next
digit, and thus the number of steps that sloppier-H needs to perform
grows, and that sum becomes a divergent sum that doesn't converge, and
thus it never actually gets to anti-sloppier-H.
i'm aware of the problem that given an enumeration which certainly
includes _all_ computable sequences, we cannot seem to actually form a diagonal with that which includes _all_ computable sequences
therefor even if given an enumeration which includes _only_ _all_
computable numbers, we should not expect to be able to use that to
produce a diagonal which includes _all_ computable sequences...
no?
not all machines even produce output, so ofc trying to compute a
And without all the numbers, it isn't COMPLETE, and thus uninteresting. >>>
diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines but
not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they should
be includable in attempting to compute a diagonal across all machines
The problem is that you are NOT making an enumeration of ALL machines,
but only machines that reach the diagonal when sorted by your criteria.
Where we sort the machines this way, we create a super-set of the
superset??? to create this we enumerated out and simulate _all_ machine, there is _no_ superset of that (which consists of only machines)...
machines, and thus get to an uncountable infinity, so we can't enumerate
BRO, what are you talking about???
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is a _contradiction_
it.
Of course, uncountable infinities doen't follow the logic that you
want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which are bijectable with natural nubmers, form _uncountable infinities_ ...
that's a _contradiction_ dude!
my god, this fucking group???
what the fuck are you all smoking???
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that we _cannot_ be able to prove machines produce an uncountable infinity ...
While the sum of the number of steps needed to get to the Kth output
of anti-sloppier-H is finite, when you multiply each element by the
number of machines included by sloppier-H to compute that, the sum
doesn't converge, thus your "enumeration" puts anti-sloppier-H at an
uncountable value in the enumeration even though the machine itself is
circle-free.
It seems you have a fundamental problem about thinking through the >>>>>> requirements, as "requirements" are just optional ideas to you.
clearly being able to enumerate a set of machines, does _not_
then imply one can certainly construct a diagonal across the
computable numbers within that set
Because the determination that a given machine create a computable >>>>>> number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing
off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its
diagonal digit is.
y do u think i disagree with any of that?
And, it seems you don't understand what I was talking about.
Apparently you can't even understand the arguement, as "K" isn't >>>>>>>> a VALUE output, but the id number of the row being output, and >>>>>>>> the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as >>>>>>>> sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there.
For sloppier_H to work, the Kth row need to compute at least K >>>>>>>> digits, and thus any machine like turing's original H that looks >>>>>>>> to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a
special number, but anti_sloppier_H won't do that, so sloppier_H >>>>>>>> will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-reference" >>>>>>>> number as sloppier_H, NOT its own, and thus it WILL get the
anti- diagonal that is the opposite of sloppier_H, and won't get >>>>>>>> hung up on itself, since neither did sloppier_H get hung up on >>>>>>>> anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow >>>>>>>> instructions, possible because you are just mentally unable to >>>>>>>> do accurate work because "correct" isn't a word you understand. >>>>>>>
So, you agree with the statement that you just refuse to follow
instructions because you are mentally unable to do accurate work
becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱
It seems that is just all you can do, since you don't understand how
to do actual logic, but just want to use fallacies.
i'm sorry u fallacy wot now?
After all, you ARE proving you don't understand what a requirement is.
this is exploring the bounds of theory mate, not engineering a system
But, you forget that you need to actually PROVE what you claim.
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix, you
can not show that you compute "fast" enough to get to any particuar
machine, as there are an infinite number of machines that can get to
their kth output before this one, (even if they eventually become
circular and stop outputing).
Ultimately, the problem is that the sorting that your "enumeration" is
based on creates a super-set of the Natural Numbers, which is
uncountable, so you can't get to all the elements of that set.
oh my god bro ... see you've gone down a fucking road bro. machines
_cannot_ produce an uncountable infinity. avoiding that was _why_ turing pursued proving the H paradox in the first place!
yet here you are trying to shut my down by casually claiming actually machines form uncountable infinities now???
_that was what turing was trying to avoiding in the first place_ !!!
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't >>>>>>>>>> exist (like the diagonal of an enumeration that includes
circular machines) so there isn't a diagonal to compute.
That is like the inability to compute an even prime greater >>>>>>>>>> than 2 doesn't affect our ability to compute other primes. >>>>>>>>>>
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>>
My guess is you are not going to actually answer with a real >>>>>>>>>>>> inconsistance, but just throw out a strawman, and that is >>>>>>>>>>>> your modus operandi.
On 4/2/26 12:52 PM, dart200 wrote:
On 4/2/26 4:18 AM, Richard Damon wrote:
On 4/2/26 12:21 AM, dart200 wrote:
On 4/1/26 6:36 PM, Richard Damon wrote:
On 4/1/26 7:06 PM, dart200 wrote:
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:i think it's _very_ interesting that despite have a method to >>>>>>>> enumerate _all_ machines, which includes _all_ computable
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:even if u can enumerate the set of machines,
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:clearly building a diagonal is not required for a set of >>>>>>>>>>>>>> machines to be effectively enumerable ..
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote:
On 3/29/26 5:05 PM, dart200 wrote:god only knows what u think ur doing
On 3/29/26 1:37 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 3/29/26 1:25 PM, dart200 wrote:So, what use is that problem, if you are admitting >>>>>>>>>>>>>>>>>>> that you can't compute the diagonal of an enumeration >>>>>>>>>>>>>>>>>>> that includes all computable numbers? (which is at >>>>>>>>>>>>>>>>>>> least close to what Turing was talking about). >>>>>>>>>>>>>>>>>>>
that was...On 3/29/26 10:07 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/26 12:19 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> circle-free computable numbers that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
So?And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed as >>>>>>>>>>>>>>>>>>>>>>>>> the code for the machine with its number. >>>>>>>>>>>>>>>>>>>>>>>>>before for every K, anti_sloppier_H simulates >>>>>>>>>>>>>>>>>>>>>>>>>> the entirety of sloppier_H from 1..K, >>>>>>>>>>>>>>>>>>>>>>>>>No, it is a decider that enumerates machines >>>>>>>>>>>>>>>>>>>>>>>>>>> that is supposed to generate that, but then a >>>>>>>>>>>>>>>>>>>>>>>>>>> machine that tries to use it to enumerate all >>>>>>>>>>>>>>>>>>>>>>>>>>> enumerable numbers will hang and not generate >>>>>>>>>>>>>>>>>>>>>>>>>>> the enumeration.Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>it's not an enumeration of computable >>>>>>>>>>>>>>>>>>>>>>>>>>>> numbers, it's a superset of said enumeration >>>>>>>>>>>>>>>>>>>>>>>>>>>> that includes some "circular" machines, but >>>>>>>>>>>>>>>>>>>>>>>>>>>> should include all computable numbers >>>>>>>>>>>>>>>>>>>>>>>>>>>
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sloppier version of that diagonal, one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that includes some circular numbers as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> well. for this i will introduce a new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation machine: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some >>>>>>>>>>>>>>>>>>>>>>>>>>>>> non- circle- free machines, then the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> enumeration of the "computable numbers" it >>>>>>>>>>>>>>>>>>>>>>>>>>>>> generates isn't valid, as the array of >>>>>>>>>>>>>>>>>>>>>>>>>>>>> values has holes in it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" >>>>>>>>>>>>>>>>>>>>>>>>>>> enumeration for getting you to the goal of >>>>>>>>>>>>>>>>>>>>>>>>>>> showing how to compute an enumeration of all >>>>>>>>>>>>>>>>>>>>>>>>>>> computable numbers.
Note, because the set of "computable >>>>>>>>>>>>>>>>>>>>>>>>>>> numbers" are (as you have pointed out) NOT >>>>>>>>>>>>>>>>>>>>>>>>>>> the same machines that compute them, Your >>>>>>>>>>>>>>>>>>>>>>>>>>> "super set" as described isn't a set of one >>>>>>>>>>>>>>>>>>>>>>>>>>> sort of thing, and is actually (as I just >>>>>>>>>>>>>>>>>>>>>>>>>>> described) a set of MACHINES that compute >>>>>>>>>>>>>>>>>>>>>>>>>>> computable numbers + some machines that are >>>>>>>>>>>>>>>>>>>>>>>>>>> circular.
The presence of the circular machines in the >>>>>>>>>>>>>>>>>>>>>>>>>>> set means you can't use that set to compute >>>>>>>>>>>>>>>>>>>>>>>>>>> the computable numbers, as you process will >>>>>>>>>>>>>>>>>>>>>>>>>>> hang on circular machines in the set. >>>>>>>>>>>>>>>>>>>>>>>>>>>
This is, i think. part of the reason that >>>>>>>>>>>>>>>>>>>>>>>>>>> Turing switch to the enumeration of non- >>>>>>>>>>>>>>>>>>>>>>>>>>> circular machines, as they are easier to talk >>>>>>>>>>>>>>>>>>>>>>>>>>> about processing, as they are finite things, >>>>>>>>>>>>>>>>>>>>>>>>>>> while the elements of the computable numbers >>>>>>>>>>>>>>>>>>>>>>>>>>> are not, and if you try to talk about using >>>>>>>>>>>>>>>>>>>>>>>>>>> ONE machine that generates it, you have the >>>>>>>>>>>>>>>>>>>>>>>>>>> problem of selecting that one machine from >>>>>>>>>>>>>>>>>>>>>>>>>>> the infinite set that generates it. >>>>>>>>>>>>>>>>>>>>>>>>>>>
Nope.
we can avoid that using a stepping >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation while dovetailing: >>>>>>>>>>>>>>>>>>>>>>>>>>>
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is >>>>>>>>>>>>>>>>>>>>>>>>>>>>> likely somewhere on the "diagonal" a spot >>>>>>>>>>>>>>>>>>>>>>>>>>>>> where the kth machine in the list doesn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate k digits of output, because it was >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one of those non- circle- free machines >>>>>>>>>>>>>>>>>>>>>>>>>>>>> accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
your step_deect_loop might not return >>>>>>>>>>>>>>>>>>>>>>>>>>> anything for all machines, as not all >>>>>>>>>>>>>>>>>>>>>>>>>>> circularity is detectable. >>>>>>>>>>>>>>>>>>>>>>>>>>>
As I pointed out, some machines just continue >>>>>>>>>>>>>>>>>>>>>>>>>>> to slowly grow over time and never repeat a >>>>>>>>>>>>>>>>>>>>>>>>>>> state.
For instance, if the Goldbach conjecture is >>>>>>>>>>>>>>>>>>>>>>>>>>> true, a program to find the first even number >>>>>>>>>>>>>>>>>>>>>>>>>>> that can't be found as the sum of two prime, >>>>>>>>>>>>>>>>>>>>>>>>>>> will run forever but never hit a repeated state. >>>>>>>>>>>>>>>>>>>>>>>>>>>
And why can't that same program be used to >>>>>>>>>>>>>>>>>>>>>>>>>>> compute the sloppy- anti- diagonal (where you >>>>>>>>>>>>>>>>>>>>>>>>>>> still test the M with DN(sloppy_H) not >>>>>>>>>>>>>>>>>>>>>>>>>>> changing that, and then reverse the output of >>>>>>>>>>>>>>>>>>>>>>>>>>> the two outputs.
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>> is reached
before a loop is detected,
}
sloppy_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>> M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // sim
one step as a time
if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>>>>>>> continue >>>>>>>>>>>>>>>>>>>>>>>>>>>> } //
outputs other than STEP >>>>>>>>>>>>>>>>>>>>>>>>>>>> if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine >>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case
output 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> } else {
m = steppable_runtime(M) //
internally tracks stepping >>>>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
this is the sloppy diagonal, it doesn't care >>>>>>>>>>>>>>>>>>>>>>>>>>>> if circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>>>>>>
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is reached
before a loop is
detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when a configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when a simulated machine tries to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates itself
How can you tell this? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a circular condition when simulating a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, but it hasn't halted yet. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, because >>>>>>>>>>>>>>>>>>>>>>>>>>> the anti- program does EXACTLY the same steps >>>>>>>>>>>>>>>>>>>>>>>>>>> it will also create an anti- diagonal, which >>>>>>>>>>>>>>>>>>>>>>>>>>> could not have been from a machine in the >>>>>>>>>>>>>>>>>>>>>>>>>>> listing, thus showing your enumation doesn't >>>>>>>>>>>>>>>>>>>>>>>>>>> include ALL machines for ALL the computable >>>>>>>>>>>>>>>>>>>>>>>>>>> numbers.
i guess at this point there's little point >>>>>>>>>>>>>>>>>>>>>>>>>>>> to even try to filter out any circular machines >>>>>>>>>>>>>>>>>>>>>>>>>>>>
step = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>> has been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output >>>>>>>>>>>>>>>>>>>>>>>>>>>> alone the way. after the step is complete, >>>>>>>>>>>>>>>>>>>>>>>>>>>> if the Kth output has been recorded already >>>>>>>>>>>>>>>>>>>>>>>>>>>> it will output that. however if the Kth >>>>>>>>>>>>>>>>>>>>>>>>>>>> output has not already been output by the >>>>>>>>>>>>>>>>>>>>>>>>>>>> machine then STEP it output >>>>>>>>>>>>>>>>>>>>>>>>>>>>
sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>> M = 0
K = 1
m_list = []
do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) // sim
one step as a time
if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>>>>>>> output res >>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case
output 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> } else {
m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>> K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what >>>>>>>>>>>>>>>>>>>>>>>>>>>> happens to anti_sloppier_H when sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>>> starts dovetailing it. i'm kinda guessing at >>>>>>>>>>>>>>>>>>>>>>>>>>>> the moment that the K within sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>>> grows faster than the K within >>>>>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H and therefore sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>>> will just never actually output a digit from >>>>>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H ...
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>>>>>>
i suppose we can adjust it with a steppable >>>>>>>>>>>>>>>>>>>>>>>>>> runtime:
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>> K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K) >>>>>>>>>>>>>>>>>>>>>>>>>> if (res != STEP) { >>>>>>>>>>>>>>>>>>>>>>>>>> output res >>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
}
but i don't think this will change anything. >>>>>>>>>>>>>>>>>>>>>>>>>> it will constantly run behind sloppier's K for >>>>>>>>>>>>>>>>>>>>>>>>>> several reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... >>>>>>>>>>>>>>>>>>>>>>>>>> mean sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in >>>>>>>>>>>>>>>>>>>>>>>>>> parallel
No, it is supposed to be EXACTLY simulating the >>>>>>>>>>>>>>>>>>>>>>>>> steps of sloppier_H.
anti_sloppier_H takes more steps for each step >>>>>>>>>>>>>>>>>>>>>>>> of sloppier_H because it needs to check the >>>>>>>>>>>>>>>>>>>>>>>> output of after each step of sloppier_H, to see >>>>>>>>>>>>>>>>>>>>>>>> if an output was found, and then advance K if so. >>>>>>>>>>>>>>>>>>>>>>>
That doesn't affect the answer that sloppier_H >>>>>>>>>>>>>>>>>>>>>>> gives to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H will >>>>>>>>>>>>>>>>>>>>>>>> output slower than sloppier_H. >>>>>>>>>>>>>>>>>>>>>>>>
So, that doesn't affect the value of K. >>>>>>>>>>>>>>>>>>>>>>>
in fact, anti_sloppier_H cannot output a digit >>>>>>>>>>>>>>>>>>>>>>>> for a particular K until /after/ sloppier_H >>>>>>>>>>>>>>>>>>>>>>>> outputs a digit for that particular K... >>>>>>>>>>>>>>>>>>>>>>>Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even >>>>>>>>>>>>>>>>>>>>>>> though at a slower rate) and will EXAXTLY output >>>>>>>>>>>>>>>>>>>>>>> the opposite that sloppier_H outputs. >>>>>>>>>>>>>>>>>>>>>>>
so there is no way for anti_sloppier_H to ever >>>>>>>>>>>>>>>>>>>>>>>> output for some particular K until after >>>>>>>>>>>>>>>>>>>>>>>> sloppier_H has started looking for at least a >>>>>>>>>>>>>>>>>>>>>>>> K+1 digit,
So?
Right.
meaning sloppier_H will never put >>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H on the diagonal >>>>>>>>>>>>>>>>>>>>>>>
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of >>>>>>>>>>>>>>>>>>>>> computable numbers.
It seems you beleive errors are acceptable. >>>>>>>>>>>>>>>>>>>>>
So, why do you complain of people not proving >>>>>>>>>>>>>>>>>>>>> programs to be correct.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>>>>>>> sloppier_H, rick
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>>>>>>> computable number, at least as long as your >>>>>>>>>>>>>>>>>>>>>>> sloppier_H outputs a computable number as the >>>>>>>>>>>>>>>>>>>>>>> diagonal, it needed to in order for the diagonal >>>>>>>>>>>>>>>>>>>>>>> to be of a complete enumeration of computable >>>>>>>>>>>>>>>>>>>>>>> numbers.
Sloppier H can NEVER output a digiton its >>>>>>>>>>>>>>>>>>>>>>> diagonal that matches the anti-diagonal computed >>>>>>>>>>>>>>>>>>>>>>> by anti- slippier-H, and thus the computable >>>>>>>>>>>>>>>>>>>>>>> number it computes can't be in the enumeration >>>>>>>>>>>>>>>>>>>>>>> that it is working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct >>>>>>>>>>>>>>>>>>>>>>>> contradiction to the obviously effective >>>>>>>>>>>>>>>>>>>>>>>> enumerability used to create sloppier_H in the >>>>>>>>>>>>>>>>>>>>>>>> first place
But the effective enumeration used to create >>>>>>>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine >>>>>>>>>>>>>>>>>>>>>>> the of at least one machine the computes every >>>>>>>>>>>>>>>>>>>>>>> computable number.
You seem to have forgotten your own requirement >>>>>>>>>>>>>>>>>>>>>>> that the enumeration was to include at least one >>>>>>>>>>>>>>>>>>>>>>> machine that computes every computable number. >>>>>>>>>>>>>>>>>>>>>>>
Yes, there are many computably enumerated SUB- >>>>>>>>>>>>>>>>>>>>>>> sets of the computable numbers, just not one for >>>>>>>>>>>>>>>>>>>>>>> a complete set of them.
All you are doing is showing you don't understand >>>>>>>>>>>>>>>>>>>>>>> what it means to be correct.
Maybe you should test your machines to see if >>>>>>>>>>>>>>>>>>>>>>> they meet your requirements, after all, you >>>>>>>>>>>>>>>>>>>>>>> complaint was about people releasing code that >>>>>>>>>>>>>>>>>>>>>>> wasn't proven to be correct.
And you keep on releasing things provably INCORRECT. >>>>>>>>>>>>>>>>>>>>>>
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration >>>>>>>>>>>>>>>>>>> that is admittedly containing only a subset of the >>>>>>>>>>>>>>>>>>> computable numbers is just not interesting. >>>>>>>>>>>>>>>>>>>
Again, as I pointed out a long time ago, if you allow >>>>>>>>>>>>>>>>>>> yourself to just wonder off into uninteresting >>>>>>>>>>>>>>>>>>> problems with no attempt to justify why they might be >>>>>>>>>>>>>>>>>>> interesting because you are doing them better that >>>>>>>>>>>>>>>>>>> how they have been done before, you are just wasting >>>>>>>>>>>>>>>>>>> everyone's time.
the process of innovation is inherently >>>>>>>>>>>>>>>>>>>> serendipitous, rick
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>>>>>>
i'm not selecting for anything in particular, i'm >>>>>>>>>>>>>>>>>>>>>> just running any whatever machine that we come >>>>>>>>>>>>>>>>>>>>>> across, and trying to put it on a diagonal >>>>>>>>>>>>>>>>>>>>>
You forgot the problem you were working on, and >>>>>>>>>>>>>>>>>>>>> just started to play in your garbage. >>>>>>>>>>>>>>>>>>>>>
Did you forget, that you started by saying, lets >>>>>>>>>>>>>>>>>>>>> allow D to not select EVERY non-circular machine, >>>>>>>>>>>>>>>>>>>>> just it needs to select at least one for each >>>>>>>>>>>>>>>>>>>>> computable number.
The computable number of the anti-diagonal isn't in >>>>>>>>>>>>>>>>>>>>> the set of numbers your D accepts a machine for. >>>>>>>>>>>>>>>>>>>>>
And thus you failed at your goal, and forgot about >>>>>>>>>>>>>>>>>>>>> the problem, because you attention span is >>>>>>>>>>>>>>>>>>>>> apparently to short to take it to a finish line. >>>>>>>>>>>>>>>>>>>>
And when you let yourself wonder into mundane and >>>>>>>>>>>>>>>>>>> non- inovative areas, you can waste a LOT of time. >>>>>>>>>>>>>>>>>>
Yes, he knows, and the fact you can't see it shows your >>>>>>>>>>>>>>>>> problem.
Again, it seems you don't care if you work can >>>>>>>>>>>>>>>>>>> actually be useful, as you seem to accept that it is >>>>>>>>>>>>>>>>>>> ok to spend a lot of time in mundane problems with >>>>>>>>>>>>>>>>>>> known solutions, while also adding in booby- traps >>>>>>>>>>>>>>>>>>> (like accepting circular machines into your >>>>>>>>>>>>>>>>>>> enumeration) that makes quantifying what you are >>>>>>>>>>>>>>>>>>> doing nearly impossible.
Yep, that is your problem, as you don't understand >>>>>>>>>>>>>>>>>>>>> what problem you are working on because you are >>>>>>>>>>>>>>>>>>>>> just fundamentally ignorant of what you are talking >>>>>>>>>>>>>>>>>>>>> about.
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>>>>>>
I have shown a way to build a computable number >>>>>>>>>>>>>>>>>>>>>>> that you enumeration doesn't include, and thus it >>>>>>>>>>>>>>>>>>>>>>> can't be a complete enumeration, as you claim it >>>>>>>>>>>>>>>>>>>>>>> is supposedly by some "magic" assumptions. >>>>>>>>>>>>>>>>>>>>>>
sloppier_H is not selecting for or even attempting >>>>>>>>>>>>>>>>>>>> to select for "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words in >>>>>>>>>>>>>>>>>>> you description of what the based decider is doing by >>>>>>>>>>>>>>>>>>> trying to filter out inputs that hit repeat state. >>>>>>>>>>>>>>>>>>>
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal >>>>>>>>>>>>>>>>>>>> across them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on >>>>>>>>>>>>>>>>>>>> the diagonal, therefor _all machines_ is not >>>>>>>>>>>>>>>>>>>> effectively enumerable
No, THIS METHOD can't enumerate all machines. >>>>>>>>>>>>>>>>>>>
Also note, that just because we can enumerate all >>>>>>>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" >>>>>>>>>>>>>>>>>>> of the output of all machines, as some
if i mean if machine enumerability _does not imply_ >>>>>>>>>>>>>>>>>> being able to compute a diagonal across the machines >>>>>>>>>>>>>>>>>> being enumerated,
WHy should it. Many machines are circular, and thus >>>>>>>>>>>>>>>>> might not REACH the diagonal. Hard to compute a >>>>>>>>>>>>>>>>> diagonal with "holes" in it (since "hole" isn't a valid >>>>>>>>>>>>>>>>> symbol)
ei: if enumerability of a set of machines is >>>>>>>>>>>>>>>>>> independent from being able to compute a diagonal >>>>>>>>>>>>>>>>>> across the set of machine,
then one _cannot_ use an inability to compute a >>>>>>>>>>>>>>>>>> diagonal to prove a lack of enumerability, and u've >>>>>>>>>>>>>>>>>> lost turing's proof against the enumerability of >>>>>>>>>>>>>>>>>> computable numbers
Which showds you don't understand the difference >>>>>>>>>>>>>>>>> between just enumerating any ol machine, and >>>>>>>>>>>>>>>>> enumerating circle- free machines.
enumerating a set of machines is enumerating a set of >>>>>>>>>>>>>>>> machines eh????
why does failing to produce a diagonal for one set >>>>>>>>>>>>>>>> (computable numbers) imply it's not effectively >>>>>>>>>>>>>>>> enumerability,
Because if it WAS effectively enumerable, you could, >>>>>>>>>>>>>>> because we could build the diagonal (or anti-diagonal) >>>>>>>>>>>>>>> computation from the algorithm of the effective enumeration. >>>>>>>>>>>>>>
But automatically becomes possible, if the enumeration >>>>>>>>>>>>> creates a full matrix of results, as a diagonal exists. >>>>>>>>>>>>
it's still possible to define a machines that can't be put >>>>>>>>>>>> on any diagonal because it's based off the output of the >>>>>>>>>>>> diagonal computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the >>>>>>>>>>> diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, >>>>>>>>>>> as all the machines generate enough data to reach it, you can >>>>>>>>>>> compute the diagonal.
Of course you can't compute a diagonal that doesn't exist. >>>>>>>>>>>
It seems you are riding your Unicorn again of a enumeration >>>>>>>>>>> of machine that all reach the diagonal with a machine in that >>>>>>>>>>> which doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every >>>>>>>>>>>>> machine reaches it, you can't compute it.
But then, that is just your imagining unicorns again. >>>>>>>>>>>>>
and stop insulting me to make up for ur lack of
consistency in principles
What inconsistency?
can't compute diagonal across computable numbers => proof >>>>>>>>>>>> against effective enumerability
can't compute diagonal across all executable machines => not >>>>>>>>>>>> proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that can >>>>>>>>>>> be the reason you can't compute it.
totally inconsistent rick, and idk how to make that more >>>>>>>>>>>> clear tbh
Just like your K < K claim, since that diagonal computation >>>>>>>>>>> apparently reached the diagonal in one view to create it, but >>>>>>>>>>> also can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within
sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your
enumaration that sloppier_H is incomplete, it is uninteresting. >>>>>>>>
numbers, it's still not possible to put all the computable
numbers within that set on a diagonal:
Right, because you can't create the "diagonal" for all machines, >>>>>>> as it
you _can_ enumerate them...
Yes, but that enumeration doesn't create a "diagonal".
There isn't a kth digit output by the kth machine for all machines
in that enumeration.
which is fine, it skips machines that don't have output to put on
the diagonal ...
But, it turns out, this means that its enumerations isn't complete
but it's produced entirely just by simulating what _is_ a complete
enumeration of _all_ machines ...
Rigth, but it simulates some circular machines, and thus wastes too much time to finish its task of simulating the non-circular machines far
enough to get the diagonal.
why didn't all the computable numbers, which have an output for _all_
K therefore allowing them to reach any diagonal of the output total
number matrix make it onto the computed diagonal???
As I said, because it spent too much time simulating circular maxhines,
which puts off the completion of the enumeration past the limits of finiteness.
It dies getting stuck in its strawmen,
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
So you AGREE that it is mising.
Since anti-sloppier-H and sloppier-H are circularity equivalent, that
means either sloppier-H misses a computational number, or it is circular
and doesn't actually compute the full diagonal.
this doesn't require specifically selection for them, they should
have outputs regardless of whether we select for them, and that
should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off
anti- sloppier-H, which while actually computable, beomes to "slow"
to reach the top of the list.
at least u understand the problem here
Yes, I do.
But apparently you don't, because you don't actually understand the requirements.
therefore, regardless of whether we can enumerate a set of
computable numbers or not, they cannot all be computably put on a
diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth
digits in a finite number of steps if sloppier-H outputs its Kth
digit in a finite number of steps, so both are generating computable
numbers or not together, but anti-sloppier-H isn't in your enumeration.
the question is: are u able to admit this is a problem? or just
continually accept the paradoxical as valid because ur already so used
to promoting the current consensus as valid?
It is a RESOLVED problem, because your enumeration just isn't complete.
IT is YOU that can't see the actual problem, because you are just
ignorant of the basics of the theory you are trying to talk about.
Your problem is you just assume you understand what you machine does, because you apparently don't understand how to handle things that can be infinite, because you like to assume they just do what you want.
if i were talking to someone capable of doing more than upholding a
bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that apply
to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being
uncountable
But since you get into the power-set (but letting your machine resort
them by length of running time) you get into the uncountable.
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
described isn't a computable number, only the diagonal of the PARTIAL enumeration of the machine that it gets to the output of is.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all >>>>>>> machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal,
because they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly
built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit. >>>>>
Thus, if sloppier_H continues to run and produce output, so does
anti_sloppier_H
Right, but it misses some, like anti_sloppier_H.
so they _should_ end up on the attempted diagonal computation,
given we're simulating all of them in parallel, but that can't happen >>>>>
which means the fact some are missed is an independent facet of the
enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
No it isn't.
The enumeratio of MACHINES that it starts from is complete.
The enumeration that the diagonal is defined to be computed of is not,
as you claim it need to get to a machine for every computable number.
The problem is that the progress that sloppier-H makes gets slower
and slower as the infinite number of circular machines get added to
the set of machines being simulated to find the one that makes the
next digit, and thus the number of steps that sloppier-H needs to
perform grows, and that sum becomes a divergent sum that doesn't
converge, and thus it never actually gets to anti-sloppier-H.
i'm aware of the problem that given an enumeration which certainly
includes _all_ computable sequences, we cannot seem to actually form a
diagonal with that which includes _all_ computable sequences
We can PRODUCE such a diagonal, but not computationally.
therefor even if given an enumeration which includes _only_ _all_
computable numbers, we should not expect to be able to use that to
produce a diagonal which includes _all_ computable sequences...
What are you considering the difference between a "Computable Number"
and a "Computable Sequence"?
Note, we can PRODUCE an enumeration of all computable numbers, under the
axiom of choice, but we can not GIVE that to a machine, as that
enumeration isn't finite or computable,
no?
And without all the numbers, it isn't COMPLETE, and thus
uninteresting.
not all machines even produce output, so ofc trying to compute a
diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines but
not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they should
be includable in attempting to compute a diagonal across all machines
The problem is that you are NOT making an enumeration of ALL
machines, but only machines that reach the diagonal when sorted by
your criteria.
Where we sort the machines this way, we create a super-set of the
superset??? to create this we enumerated out and simulate _all_
machine, there is _no_ superset of that (which consists of only
machines)...
Sure there is, as you keep on changing the ORDER of the machines as you investigate.
machines, and thus get to an uncountable infinity, so we can't enumerate
BRO, what are you talking about???
You don't understand an uncountable infinity?
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is a
_contradiction_
Right, WHEN YOU ENUMERATE THEM, and don't suffle them.
Your code keeps on updating the "set of machines" it is looking at,
which gets enough different sets to reach something of the same
cardinaltiy of the power set.
it.
Of course, uncountable infinities doen't follow the logic that you
want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which are
bijectable with natural nubmers, form _uncountable infinities_ ...
that's a _contradiction_ dude!
Right, the MACHINES are bijectable, but you don't just simply process them.
After all, the set of the mappings of the Natural Numbers to 0 or 1 is
an uncountable set.
my god, this fucking group???
what the fuck are you all smoking???
IT seems YOU are the one smoking something, as you refuse to understand
the problems you are trying to just ignore.
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that we
_cannot_ be able to prove machines produce an uncountable infinity ...
Where do you get that from?
The point is that we can not in finite steps decide if a given machine
is circular or not,
And we can not produce a machine that computationally enumerates the compuational numbers or the non-circular machines.
Where do you see him talking about anything about "countability".
While the sum of the number of steps needed to get to the Kth output
of anti-sloppier-H is finite, when you multiply each element by the
number of machines included by sloppier-H to compute that, the sum
doesn't converge, thus your "enumeration" puts anti-sloppier-H at an
uncountable value in the enumeration even though the machine itself
is circle-free.
It seems you have a fundamental problem about thinking through
the requirements, as "requirements" are just optional ideas to you. >>>>>>>
clearly being able to enumerate a set of machines, does _not_ >>>>>>>> then imply one can certainly construct a diagonal across the
computable numbers within that set
Because the determination that a given machine create a
computable number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing
off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its
diagonal digit is.
y do u think i disagree with any of that?
And, it seems you don't understand what I was talking about. >>>>>>>>>
Apparently you can't even understand the arguement, as "K"
isn't a VALUE output, but the id number of the row being
output, and the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as >>>>>>>>> sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there. >>>>>>>>>
For sloppier_H to work, the Kth row need to compute at least K >>>>>>>>> digits, and thus any machine like turing's original H that
looks to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a
special number, but anti_sloppier_H won't do that, so
sloppier_H will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-
reference" number as sloppier_H, NOT its own, and thus it WILL >>>>>>>>> get the anti- diagonal that is the opposite of sloppier_H, and >>>>>>>>> won't get hung up on itself, since neither did sloppier_H get >>>>>>>>> hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow >>>>>>>>> instructions, possible because you are just mentally unable to >>>>>>>>> do accurate work because "correct" isn't a word you understand. >>>>>>>>
So, you agree with the statement that you just refuse to follow >>>>>>> instructions because you are mentally unable to do accurate work >>>>>>> becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱
It seems that is just all you can do, since you don't understand how
to do actual logic, but just want to use fallacies.
i'm sorry u fallacy wot now?
Your logic is just based on fallacies.
Things like assuming the conclusion, or ignoring the facts.
this is exploring the bounds of theory mate, not engineering a system
After all, you ARE proving you don't understand what a requirement is. >>>>
But, you forget that you need to actually PROVE what you claim.
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix, you
can not show that you compute "fast" enough to get to any particuar
machine, as there are an infinite number of machines that can get to
their kth output before this one, (even if they eventually become
circular and stop outputing).
Ultimately, the problem is that the sorting that your "enumeration"
is based on creates a super-set of the Natural Numbers, which is
uncountable, so you can't get to all the elements of that set.
oh my god bro ... see you've gone down a fucking road bro. machines
_cannot_ produce an uncountable infinity. avoiding that was _why_
turing pursued proving the H paradox in the first place!
Right, they can not actually produce it, but if the algorith would
generate it they just will not finish.
yet here you are trying to shut my down by casually claiming actually
machines form uncountable infinities now???
SETS of machines can.
I guess your ignorance is approaching infinity.
_that was what turing was trying to avoiding in the first place_ !!!
No, he was pointing out that we can not get a result that depends on an uncountable infinity.
I can easily write a program that "when it completes" would have
produced and uncountable infinite set, it just can't ever get that far.
The fact you don't understand this is part of your problem.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't >>>>>>>>>>> exist (like the diagonal of an enumeration that includes >>>>>>>>>>> circular machines) so there isn't a diagonal to compute. >>>>>>>>>>>
That is like the inability to compute an even prime greater >>>>>>>>>>> than 2 doesn't affect our ability to compute other primes. >>>>>>>>>>>
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>>>
My guess is you are not going to actually answer with a >>>>>>>>>>>>> real inconsistance, but just throw out a strawman, and that >>>>>>>>>>>>> is your modus operandi.
On 4/2/26 4:43 PM, Richard Damon wrote:
On 4/2/26 12:52 PM, dart200 wrote:
On 4/2/26 4:18 AM, Richard Damon wrote:
On 4/2/26 12:21 AM, dart200 wrote:
On 4/1/26 6:36 PM, Richard Damon wrote:
On 4/1/26 7:06 PM, dart200 wrote:
On 4/1/26 3:37 PM, Richard Damon wrote:
On 4/1/26 12:06 PM, dart200 wrote:
On 3/31/26 6:49 PM, Richard Damon wrote:
On 3/31/26 2:19 PM, dart200 wrote:i think it's _very_ interesting that despite have a method to >>>>>>>>> enumerate _all_ machines, which includes _all_ computable
On 3/30/26 7:16 PM, Richard Damon wrote:
On 3/30/26 10:01 PM, dart200 wrote:
On 3/30/26 3:35 PM, Richard Damon wrote:
On 3/30/26 12:08 PM, dart200 wrote:even if u can enumerate the set of machines,
On 3/30/26 4:43 AM, Richard Damon wrote:
On 3/29/26 11:49 PM, dart200 wrote:
On 3/29/26 3:51 PM, Richard Damon wrote:
On 3/29/26 6:00 PM, dart200 wrote:
On 3/29/26 2:33 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/26 5:05 PM, dart200 wrote:
god only knows what u think ur doingOn 3/29/26 1:37 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/29/26 1:25 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/26 10:07 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/26 12:19 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 7:06 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 8:37 PM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 6:34 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/26 3:30 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 7:15 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/27/26 2:31 AM, dart200 wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after getting a lil stuck on trying to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> construct a smarter TM diagonal across >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the circle-free computable numbers that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defeats all variants of anti_fixed_H, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>So, what use is that problem, if you are admitting >>>>>>>>>>>>>>>>>>>> that you can't compute the diagonal of an >>>>>>>>>>>>>>>>>>>> enumeration that includes all computable numbers? >>>>>>>>>>>>>>>>>>>> (which is at least close to what Turing was talking >>>>>>>>>>>>>>>>>>>> about).
that was...So?And how does the writing out the program nti- >>>>>>>>>>>>>>>>>>>>>>>>>> sloppier_H affect anything, it still existed >>>>>>>>>>>>>>>>>>>>>>>>>> as the code for the machine with its number. >>>>>>>>>>>>>>>>>>>>>>>>>>before for every K, anti_sloppier_H simulates >>>>>>>>>>>>>>>>>>>>>>>>>>> the entirety of sloppier_H from 1..K, >>>>>>>>>>>>>>>>>>>>>>>>>>Because you can't, since it isn't computable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>it's not an enumeration of computable >>>>>>>>>>>>>>>>>>>>>>>>>>>>> numbers, it's a superset of said >>>>>>>>>>>>>>>>>>>>>>>>>>>>> enumeration that includes some "circular" >>>>>>>>>>>>>>>>>>>>>>>>>>>>> machines, but should include all computable >>>>>>>>>>>>>>>>>>>>>>>>>>>>> numbers
And what good is such a enumeration? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
i’d like to try playing around with a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sloppier version of that diagonal, one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that includes some circular numbers as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> well. for this i will introduce a new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation machine: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Note, if your enumeration includes some >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non- circle- free machines, then the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enumeration of the "computable numbers" it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generates isn't valid, as the array of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> values has holes in it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
No, it is a decider that enumerates machines >>>>>>>>>>>>>>>>>>>>>>>>>>>> that is supposed to generate that, but then >>>>>>>>>>>>>>>>>>>>>>>>>>>> a machine that tries to use it to enumerate >>>>>>>>>>>>>>>>>>>>>>>>>>>> all enumerable numbers will hang and not >>>>>>>>>>>>>>>>>>>>>>>>>>>> generate the enumeration. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Again, what good is this "incorrect" >>>>>>>>>>>>>>>>>>>>>>>>>>>> enumeration for getting you to the goal of >>>>>>>>>>>>>>>>>>>>>>>>>>>> showing how to compute an enumeration of all >>>>>>>>>>>>>>>>>>>>>>>>>>>> computable numbers.
Note, because the set of "computable >>>>>>>>>>>>>>>>>>>>>>>>>>>> numbers" are (as you have pointed out) NOT >>>>>>>>>>>>>>>>>>>>>>>>>>>> the same machines that compute them, Your >>>>>>>>>>>>>>>>>>>>>>>>>>>> "super set" as described isn't a set of one >>>>>>>>>>>>>>>>>>>>>>>>>>>> sort of thing, and is actually (as I just >>>>>>>>>>>>>>>>>>>>>>>>>>>> described) a set of MACHINES that compute >>>>>>>>>>>>>>>>>>>>>>>>>>>> computable numbers + some machines that are >>>>>>>>>>>>>>>>>>>>>>>>>>>> circular.
The presence of the circular machines in the >>>>>>>>>>>>>>>>>>>>>>>>>>>> set means you can't use that set to compute >>>>>>>>>>>>>>>>>>>>>>>>>>>> the computable numbers, as you process will >>>>>>>>>>>>>>>>>>>>>>>>>>>> hang on circular machines in the set. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
This is, i think. part of the reason that >>>>>>>>>>>>>>>>>>>>>>>>>>>> Turing switch to the enumeration of non- >>>>>>>>>>>>>>>>>>>>>>>>>>>> circular machines, as they are easier to >>>>>>>>>>>>>>>>>>>>>>>>>>>> talk about processing, as they are finite >>>>>>>>>>>>>>>>>>>>>>>>>>>> things, while the elements of the computable >>>>>>>>>>>>>>>>>>>>>>>>>>>> numbers are not, and if you try to talk >>>>>>>>>>>>>>>>>>>>>>>>>>>> about using ONE machine that generates it, >>>>>>>>>>>>>>>>>>>>>>>>>>>> you have the problem of selecting that one >>>>>>>>>>>>>>>>>>>>>>>>>>>> machine from the infinite set that generates >>>>>>>>>>>>>>>>>>>>>>>>>>>> it.
Nope.
we can avoid that using a stepping >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation while dovetailing: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
In other words, your world is just broken. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Your diagonal doesn't exist, as there is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> likely somewhere on the "diagonal" a spot >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> where the kth machine in the list doesn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate k digits of output, because it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was one of those non- circle- free >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machines accepted that got stuck too early. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
your step_deect_loop might not return >>>>>>>>>>>>>>>>>>>>>>>>>>>> anything for all machines, as not all >>>>>>>>>>>>>>>>>>>>>>>>>>>> circularity is detectable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
As I pointed out, some machines just >>>>>>>>>>>>>>>>>>>>>>>>>>>> continue to slowly grow over time and never >>>>>>>>>>>>>>>>>>>>>>>>>>>> repeat a state.
For instance, if the Goldbach conjecture is >>>>>>>>>>>>>>>>>>>>>>>>>>>> true, a program to find the first even >>>>>>>>>>>>>>>>>>>>>>>>>>>> number that can't be found as the sum of two >>>>>>>>>>>>>>>>>>>>>>>>>>>> prime, will run forever but never hit a >>>>>>>>>>>>>>>>>>>>>>>>>>>> repeated state.
And why can't that same program be used to >>>>>>>>>>>>>>>>>>>>>>>>>>>> compute the sloppy- anti- diagonal (where >>>>>>>>>>>>>>>>>>>>>>>>>>>> you still test the M with DN(sloppy_H) not >>>>>>>>>>>>>>>>>>>>>>>>>>>> changing that, and then reverse the output >>>>>>>>>>>>>>>>>>>>>>>>>>>> of the two outputs.
step_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation,
kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>>> is reached
before a loop is
detected,
}
sloppy_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> M = 0
K = 1
m_list = [] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> res = step_detect_loop(m, K) // >>>>>>>>>>>>>>>>>>>>>>>>>>>>> sim one step as a time >>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (res == STEP) { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> continue >>>>>>>>>>>>>>>>>>>>>>>>>>>>> } //
outputs other than STEP >>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (res != LOOP) { //
indicate we're done
output res //
dovetailing this machine >>>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case >>>>>>>>>>>>>>>>>>>>>>>>>>>>> output 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> m = steppable_runtime(M) //
internally tracks stepping >>>>>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
this is the sloppy diagonal, it doesn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>> care if circular machines end up on the list >>>>>>>>>>>>>>>>>>>>>>>>>>>>
sim_detect_loop = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> LOOP: if a circular loop is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during simulation, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> M is reached
before a loop is
detected,
}
loop detection happens in two cases: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1) if a circular machine is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when a configuration is reached twice >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) if a circular recursion is detected >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when a simulated machine tries to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates itself
How can you tell this? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What if it is just a "twin brother"? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
How do you detect that you won't find such >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a circular condition when simulating a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine, but it hasn't halted yet. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
If your sloppy_H produces a diagonal, >>>>>>>>>>>>>>>>>>>>>>>>>>>> because the anti- program does EXACTLY the >>>>>>>>>>>>>>>>>>>>>>>>>>>> same steps it will also create an anti- >>>>>>>>>>>>>>>>>>>>>>>>>>>> diagonal, which could not have been from a >>>>>>>>>>>>>>>>>>>>>>>>>>>> machine in the listing, thus showing your >>>>>>>>>>>>>>>>>>>>>>>>>>>> enumation doesn't include ALL machines for >>>>>>>>>>>>>>>>>>>>>>>>>>>> ALL the computable numbers. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Why won't it be able to simulate it? >>>>>>>>>>>>>>>>>>>>>>>>>>>>
i guess at this point there's little point >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to even try to filter out any circular >>>>>>>>>>>>>>>>>>>>>>>>>>>>> machines
step = (M, K) -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> STEP: step completed, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> kth digit of M: if the Kth digit of M >>>>>>>>>>>>>>>>>>>>>>>>>>>>> has been output
}
every time step is called it advances the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine's runtime, recording any output >>>>>>>>>>>>>>>>>>>>>>>>>>>>> alone the way. after the step is complete, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the Kth output has been recorded already >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it will output that. however if the Kth >>>>>>>>>>>>>>>>>>>>>>>>>>>>> output has not already been output by the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine then STEP it output >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> M = 0
K = 1
m_list = [] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> do {
for (m in m_list) { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> res = step(m, K) //
sim one step as a time >>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (res == STEP) continue >>>>>>>>>>>>>>>>>>>>>>>>>>>>> output res >>>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> list.remove(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
if (M == DN(sloppy_H)) { //
handle self- ref case >>>>>>>>>>>>>>>>>>>>>>>>>>>>> output 0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> m = steppable_runtime(M) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> list.push(m) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
M += 1
}
}
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>>>> K = 1
do {
output 1-sim(sloppier_H,K) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
i have a hard time really asserting what >>>>>>>>>>>>>>>>>>>>>>>>>>>>> happens to anti_sloppier_H when sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>>>> starts dovetailing it. i'm kinda guessing >>>>>>>>>>>>>>>>>>>>>>>>>>>>> at the moment that the K within sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>>>> grows faster than the K within >>>>>>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H and therefore sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>>>>>> will just never actually output a digit >>>>>>>>>>>>>>>>>>>>>>>>>>>>> from anti_sloppier_H ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Why should the K's grow differently. >>>>>>>>>>>>>>>>>>>>>>>>>>>
i suppose we can adjust it with a steppable >>>>>>>>>>>>>>>>>>>>>>>>>>> runtime:
anti_sloppier_H = () -> { >>>>>>>>>>>>>>>>>>>>>>>>>>> K = 0
m = steppable_runtime(sloppier_H) >>>>>>>>>>>>>>>>>>>>>>>>>>> do {
res = step(m, K) >>>>>>>>>>>>>>>>>>>>>>>>>>> if (res != STEP) { >>>>>>>>>>>>>>>>>>>>>>>>>>> output res >>>>>>>>>>>>>>>>>>>>>>>>>>> K += 1
}
}
}
but i don't think this will change anything. >>>>>>>>>>>>>>>>>>>>>>>>>>> it will constantly run behind sloppier's K >>>>>>>>>>>>>>>>>>>>>>>>>>> for several reasons:
1) anti_sloppier_H is simulating sloppier_H's >>>>>>>>>>>>>>>>>>>>>>>>>>> runtime with extra steps for each cycle K ... >>>>>>>>>>>>>>>>>>>>>>>>>>> mean sloppier_H's K _must_ grow faster than >>>>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H even when run directly in >>>>>>>>>>>>>>>>>>>>>>>>>>> parallel
No, it is supposed to be EXACTLY simulating >>>>>>>>>>>>>>>>>>>>>>>>>> the steps of sloppier_H.
anti_sloppier_H takes more steps for each step >>>>>>>>>>>>>>>>>>>>>>>>> of sloppier_H because it needs to check the >>>>>>>>>>>>>>>>>>>>>>>>> output of after each step of sloppier_H, to see >>>>>>>>>>>>>>>>>>>>>>>>> if an output was found, and then advance K if so. >>>>>>>>>>>>>>>>>>>>>>>>
That doesn't affect the answer that sloppier_H >>>>>>>>>>>>>>>>>>>>>>>> gives to anti- sloppier_H
this is done for every step of sloppier_H, so >>>>>>>>>>>>>>>>>>>>>>>>> therefore run head to head, anti_sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>> will output slower than sloppier_H. >>>>>>>>>>>>>>>>>>>>>>>>>
So, that doesn't affect the value of K. >>>>>>>>>>>>>>>>>>>>>>>>
in fact, anti_sloppier_H cannot output a digit >>>>>>>>>>>>>>>>>>>>>>>>> for a particular K until /after/ sloppier_H >>>>>>>>>>>>>>>>>>>>>>>>> outputs a digit for that particular K... >>>>>>>>>>>>>>>>>>>>>>>>Right. and the execution of anti-sloppier_H will >>>>>>>>>>>>>>>>>>>>>>>> EXACTLY follow the behavior of sloppier_H (even >>>>>>>>>>>>>>>>>>>>>>>> though at a slower rate) and will EXAXTLY output >>>>>>>>>>>>>>>>>>>>>>>> the opposite that sloppier_H outputs. >>>>>>>>>>>>>>>>>>>>>>>>
so there is no way for anti_sloppier_H to ever >>>>>>>>>>>>>>>>>>>>>>>>> output for some particular K until after >>>>>>>>>>>>>>>>>>>>>>>>> sloppier_H has started looking for at least a >>>>>>>>>>>>>>>>>>>>>>>>> K+1 digit,
So?
Right.
meaning sloppier_H will never put >>>>>>>>>>>>>>>>>>>>>>>>> anti_sloppier_H on the diagonal >>>>>>>>>>>>>>>>>>>>>>>>
yup
And thus, your diagonal that you claim to compute >>>>>>>>>>>>>>>>>>>>>> doesn't include the required COMPLETE set of >>>>>>>>>>>>>>>>>>>>>> computable numbers.
It seems you beleive errors are acceptable. >>>>>>>>>>>>>>>>>>>>>>
So, why do you complain of people not proving >>>>>>>>>>>>>>>>>>>>>> programs to be correct.
But since anti-sloppier_H WILL fully output a >>>>>>>>>>>>>>>>>>>>>>>> computable number, at least as long as your >>>>>>>>>>>>>>>>>>>>>>>> sloppier_H outputs a computable number as the >>>>>>>>>>>>>>>>>>>>>>>> diagonal, it needed to in order for the diagonal >>>>>>>>>>>>>>>>>>>>>>>> to be of a complete enumeration of computable >>>>>>>>>>>>>>>>>>>>>>>> numbers.
Sloppier H can NEVER output a digiton its >>>>>>>>>>>>>>>>>>>>>>>> diagonal that matches the anti-diagonal computed >>>>>>>>>>>>>>>>>>>>>>>> by anti- slippier-H, and thus the computable >>>>>>>>>>>>>>>>>>>>>>>> number it computes can't be in the enumeration >>>>>>>>>>>>>>>>>>>>>>>> that it is working from.
it is therefore _not_ possible to effectively >>>>>>>>>>>>>>>>>>>>>>>>> enumerate _all machines_ , in direct >>>>>>>>>>>>>>>>>>>>>>>>> contradiction to the obviously effective >>>>>>>>>>>>>>>>>>>>>>>>> enumerability used to create sloppier_H in the >>>>>>>>>>>>>>>>>>>>>>>>> first place
But the effective enumeration used to create >>>>>>>>>>>>>>>>>>>>>>>> sloppier_H can't be complete, and thus isn't a >>>>>>>>>>>>>>>>>>>>>>>> effetive enumeration of a super- set of machine >>>>>>>>>>>>>>>>>>>>>>>> the of at least one machine the computes every >>>>>>>>>>>>>>>>>>>>>>>> computable number.
You seem to have forgotten your own requirement >>>>>>>>>>>>>>>>>>>>>>>> that the enumeration was to include at least one >>>>>>>>>>>>>>>>>>>>>>>> machine that computes every computable number. >>>>>>>>>>>>>>>>>>>>>>>>
Yes, there are many computably enumerated SUB- >>>>>>>>>>>>>>>>>>>>>>>> sets of the computable numbers, just not one for >>>>>>>>>>>>>>>>>>>>>>>> a complete set of them.
All you are doing is showing you don't >>>>>>>>>>>>>>>>>>>>>>>> understand what it means to be correct. >>>>>>>>>>>>>>>>>>>>>>>>
Maybe you should test your machines to see if >>>>>>>>>>>>>>>>>>>>>>>> they meet your requirements, after all, you >>>>>>>>>>>>>>>>>>>>>>>> complaint was about people releasing code that >>>>>>>>>>>>>>>>>>>>>>>> wasn't proven to be correct.
And you keep on releasing things provably >>>>>>>>>>>>>>>>>>>>>>>> INCORRECT.
i'm not selecting for "computable numbers" with >>>>>>>>>>>>>>>>>>>>>>> sloppier_H, rick
But that was the problem you were trying to solve. >>>>>>>>>>>>>>>>>>>>>
but it's not what we are dealing with in sloppier_H >>>>>>>>>>>>>>>>>>>>
Computing the diagonal of a comuptable enumeration >>>>>>>>>>>>>>>>>>>> that is admittedly containing only a subset of the >>>>>>>>>>>>>>>>>>>> computable numbers is just not interesting. >>>>>>>>>>>>>>>>>>>>
Again, as I pointed out a long time ago, if you >>>>>>>>>>>>>>>>>>>> allow yourself to just wonder off into uninteresting >>>>>>>>>>>>>>>>>>>> problems with no attempt to justify why they might >>>>>>>>>>>>>>>>>>>> be interesting because you are doing them better >>>>>>>>>>>>>>>>>>>> that how they have been done before, you are just >>>>>>>>>>>>>>>>>>>> wasting everyone's time.
the process of innovation is inherently >>>>>>>>>>>>>>>>>>>>> serendipitous, rick
In other words, you are just computing garbage. >>>>>>>>>>>>>>>>>>>>>>
i'm not selecting for anything in particular, i'm >>>>>>>>>>>>>>>>>>>>>>> just running any whatever machine that we come >>>>>>>>>>>>>>>>>>>>>>> across, and trying to put it on a diagonal >>>>>>>>>>>>>>>>>>>>>>
You forgot the problem you were working on, and >>>>>>>>>>>>>>>>>>>>>> just started to play in your garbage. >>>>>>>>>>>>>>>>>>>>>>
Did you forget, that you started by saying, lets >>>>>>>>>>>>>>>>>>>>>> allow D to not select EVERY non-circular machine, >>>>>>>>>>>>>>>>>>>>>> just it needs to select at least one for each >>>>>>>>>>>>>>>>>>>>>> computable number.
The computable number of the anti-diagonal isn't >>>>>>>>>>>>>>>>>>>>>> in the set of numbers your D accepts a machine for. >>>>>>>>>>>>>>>>>>>>>>
And thus you failed at your goal, and forgot about >>>>>>>>>>>>>>>>>>>>>> the problem, because you attention span is >>>>>>>>>>>>>>>>>>>>>> apparently to short to take it to a finish line. >>>>>>>>>>>>>>>>>>>>>
And when you let yourself wonder into mundane and >>>>>>>>>>>>>>>>>>>> non- inovative areas, you can waste a LOT of time. >>>>>>>>>>>>>>>>>>>
Yes, he knows, and the fact you can't see it shows >>>>>>>>>>>>>>>>>> your problem.
if i mean if machine enumerability _does not imply_ >>>>>>>>>>>>>>>>>>> being able to compute a diagonal across the machines >>>>>>>>>>>>>>>>>>> being enumerated,
Again, it seems you don't care if you work can >>>>>>>>>>>>>>>>>>>> actually be useful, as you seem to accept that it is >>>>>>>>>>>>>>>>>>>> ok to spend a lot of time in mundane problems with >>>>>>>>>>>>>>>>>>>> known solutions, while also adding in booby- traps >>>>>>>>>>>>>>>>>>>> (like accepting circular machines into your >>>>>>>>>>>>>>>>>>>> enumeration) that makes quantifying what you are >>>>>>>>>>>>>>>>>>>> doing nearly impossible.
Yep, that is your problem, as you don't understand >>>>>>>>>>>>>>>>>>>>>> what problem you are working on because you are >>>>>>>>>>>>>>>>>>>>>> just fundamentally ignorant of what you are >>>>>>>>>>>>>>>>>>>>>> talking about.
u don't really seem aware of where we've ended up: >>>>>>>>>>>>>>>>>>>>>>
I have shown a way to build a computable number >>>>>>>>>>>>>>>>>>>>>>>> that you enumeration doesn't include, and thus >>>>>>>>>>>>>>>>>>>>>>>> it can't be a complete enumeration, as you claim >>>>>>>>>>>>>>>>>>>>>>>> it is supposedly by some "magic" assumptions. >>>>>>>>>>>>>>>>>>>>>>>
sloppier_H is not selecting for or even attempting >>>>>>>>>>>>>>>>>>>>> to select for "computable sequences"
Then what *IS* its definition.
It seems just to be sloopy.
After all, you still seem to use some of the words >>>>>>>>>>>>>>>>>>>> in you description of what the based decider is >>>>>>>>>>>>>>>>>>>> doing by trying to filter out inputs that hit repeat >>>>>>>>>>>>>>>>>>>> state.
But "All Machines" are enumerable.
disproving an ability to enumerate _not_ just >>>>>>>>>>>>>>>>>>>>>>> computable numbers, but actually _all machines_ >>>>>>>>>>>>>>>>>>>>>>
therefore i should be able to construct a diagonal >>>>>>>>>>>>>>>>>>>>> across them of some form...
Nope, not defined (see below)
yet we're stuck with machines that cannot be put on >>>>>>>>>>>>>>>>>>>>> the diagonal, therefor _all machines_ is not >>>>>>>>>>>>>>>>>>>>> effectively enumerable
No, THIS METHOD can't enumerate all machines. >>>>>>>>>>>>>>>>>>>>
Also note, that just because we can enumerate all >>>>>>>>>>>>>>>>>>>> machines, doesn't mean we can "compute the diagonal" >>>>>>>>>>>>>>>>>>>> of the output of all machines, as some >>>>>>>>>>>>>>>>>>>
WHy should it. Many machines are circular, and thus >>>>>>>>>>>>>>>>>> might not REACH the diagonal. Hard to compute a >>>>>>>>>>>>>>>>>> diagonal with "holes" in it (since "hole" isn't a >>>>>>>>>>>>>>>>>> valid symbol)
ei: if enumerability of a set of machines is >>>>>>>>>>>>>>>>>>> independent from being able to compute a diagonal >>>>>>>>>>>>>>>>>>> across the set of machine,
then one _cannot_ use an inability to compute a >>>>>>>>>>>>>>>>>>> diagonal to prove a lack of enumerability, and u've >>>>>>>>>>>>>>>>>>> lost turing's proof against the enumerability of >>>>>>>>>>>>>>>>>>> computable numbers
Which showds you don't understand the difference >>>>>>>>>>>>>>>>>> between just enumerating any ol machine, and >>>>>>>>>>>>>>>>>> enumerating circle- free machines.
enumerating a set of machines is enumerating a set of >>>>>>>>>>>>>>>>> machines eh????
why does failing to produce a diagonal for one set >>>>>>>>>>>>>>>>> (computable numbers) imply it's not effectively >>>>>>>>>>>>>>>>> enumerability,
Because if it WAS effectively enumerable, you could, >>>>>>>>>>>>>>>> because we could build the diagonal (or anti-diagonal) >>>>>>>>>>>>>>>> computation from the algorithm of the effective >>>>>>>>>>>>>>>> enumeration.
clearly building a diagonal is not required for a set of >>>>>>>>>>>>>>> machines to be effectively enumerable ..
But automatically becomes possible, if the enumeration >>>>>>>>>>>>>> creates a full matrix of results, as a diagonal exists. >>>>>>>>>>>>>
it's still possible to define a machines that can't be put >>>>>>>>>>>>> on any diagonal because it's based off the output of the >>>>>>>>>>>>> diagonal computation itself...
like what i did with the set of _all_ machines
Then the matrix of number doesn't reach the diagonal and the >>>>>>>>>>>> diagonal doesn't exist.
As I said, *IF* the enumeration actually creates a diagonal, >>>>>>>>>>>> as all the machines generate enough data to reach it, you >>>>>>>>>>>> can compute the diagonal.
Of course you can't compute a diagonal that doesn't exist. >>>>>>>>>>>>
It seems you are riding your Unicorn again of a enumeration >>>>>>>>>>>> of machine that all reach the diagonal with a machine in >>>>>>>>>>>> that which doesn't reach the diagonal.
Of course if there isn't a diagonal, because not every >>>>>>>>>>>>>> machine reaches it, you can't compute it.
But then, that is just your imagining unicorns again. >>>>>>>>>>>>>>
and stop insulting me to make up for ur lack of >>>>>>>>>>>>>>> consistency in principles
What inconsistency?
can't compute diagonal across computable numbers => proof >>>>>>>>>>>>> against effective enumerability
can't compute diagonal across all executable machines => >>>>>>>>>>>>> not proof against effective enumerability
Sure, because the diagonal doesn't need to exist, so that >>>>>>>>>>>> can be the reason you can't compute it.
totally inconsistent rick, and idk how to make that more >>>>>>>>>>>>> clear tbh
Just like your K < K claim, since that diagonal computation >>>>>>>>>>>> apparently reached the diagonal in one view to create it, >>>>>>>>>>>> but also can't reach it to compute it.
i'm sorry are you having trouble understanding
(a) why anti_sloppier_H will _never_ output a K within
sloppier_H?
even if (b) anti_sloppier_H _is_ a computable number?
do u disagree with either (a) or (b)???
cause if so, we should talk about that
The problem is that since you have admitted that your
enumaration that sloppier_H is incomplete, it is uninteresting. >>>>>>>>>
numbers, it's still not possible to put all the computable
numbers within that set on a diagonal:
Right, because you can't create the "diagonal" for all machines, >>>>>>>> as it
you _can_ enumerate them...
Yes, but that enumeration doesn't create a "diagonal".
There isn't a kth digit output by the kth machine for all machines >>>>>> in that enumeration.
which is fine, it skips machines that don't have output to put on
the diagonal ...
But, it turns out, this means that its enumerations isn't complete
but it's produced entirely just by simulating what _is_ a complete
enumeration of _all_ machines ...
Rigth, but it simulates some circular machines, and thus wastes too
much time to finish its task of simulating the non-circular machines
far enough to get the diagonal.
why didn't all the computable numbers, which have an output for _all_
K therefore allowing them to reach any diagonal of the output total
number matrix make it onto the computed diagonal???
As I said, because it spent too much time simulating circular maxhines,
that is _not_ what is happening here,
even if we ( _hypothetically_ ) started with a full enumeration of
_just_ computable numbers, so no time was "wasted", it still wouldn't be able to produce the diagonal via dovetailing ...
the _same_ problem would exist
(note that _particular_ problem wouldn't exist with RTMs)
which puts off the completion of the enumeration past the limits of
finiteness.
It dies getting stuck in its strawmen,
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
So you AGREE that it is mising.
Since anti-sloppier-H and sloppier-H are circularity equivalent, that
means either sloppier-H misses a computational number, or it is
circular and doesn't actually compute the full diagonal.
this doesn't require specifically selection for them, they should
have outputs regardless of whether we select for them, and that
should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off
anti- sloppier-H, which while actually computable, beomes to "slow"
to reach the top of the list.
at least u understand the problem here
Yes, I do.
But apparently you don't, because you don't actually understand the
requirements.
the question is: are u able to admit this is a problem? or just
therefore, regardless of whether we can enumerate a set of
computable numbers or not, they cannot all be computably put on a
diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth
digits in a finite number of steps if sloppier-H outputs its Kth
digit in a finite number of steps, so both are generating computable
numbers or not together, but anti-sloppier-H isn't in your enumeration. >>>
continually accept the paradoxical as valid because ur already so
used to promoting the current consensus as valid?
It is a RESOLVED problem, because your enumeration just isn't complete.
IT is YOU that can't see the actual problem, because you are just
ignorant of the basics of the theory you are trying to talk about.
Your problem is you just assume you understand what you machine does,
because you apparently don't understand how to handle things that can
be infinite, because you like to assume they just do what you want.
the answer is: not yet apparently
if i were talking to someone capable of doing more than upholding a >>>>> bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that apply
to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being
uncountable
But since you get into the power-set (but letting your machine resort
them by length of running time) you get into the uncountable.
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
*infinite not uncountable... the steps of any actual computation are necessarily countable,
and circular machine do not impede dovetailing algo, that is a bizarre response and and just forgetful of the fact circular machines also do
not impede using dovetailing to enumerate out halting machines
described isn't a computable number, only the diagonal of the PARTIAL
enumeration of the machine that it gets to the output of is.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all >>>>>>>> machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal,
because they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly >>>>>> built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit. >>>>>>
Thus, if sloppier_H continues to run and produce output, so does
anti_sloppier_H
so they _should_ end up on the attempted diagonal computation,
given we're simulating all of them in parallel, but that can't
happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of the >>>>> enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
No it isn't.
The enumeratio of MACHINES that it starts from is complete.
yes it starts with a full enumeration of all machines, including all computable numbers, and is still unable to produce a diagonal that
includes all computable numbers despite them all having enough digits to
be on the diagonal
The enumeration that the diagonal is defined to be computed of is not,
as you claim it need to get to a machine for every computable number.
The problem is that the progress that sloppier-H makes gets slower
and slower as the infinite number of circular machines get added to
the set of machines being simulated to find the one that makes the
next digit, and thus the number of steps that sloppier-H needs to
perform grows, and that sum becomes a divergent sum that doesn't
converge, and thus it never actually gets to anti-sloppier-H.
i'm aware of the problem that given an enumeration which certainly
includes _all_ computable sequences, we cannot seem to actually form
a diagonal with that which includes _all_ computable sequences
We can PRODUCE such a diagonal, but not computationally.
if u can't write me down the diagonal, i can't agree u "PRODUCED" it
therefor even if given an enumeration which includes _only_ _all_
computable numbers, we should not expect to be able to use that to
produce a diagonal which includes _all_ computable sequences...
What are you considering the difference between a "Computable Number"
and a "Computable Sequence"?
| A sequence is said to be computable if it can be computed
| by a circle-free machine. A number is computable if it
| differs by an integer from the number computed by a
| circle-free machine
Note, we can PRODUCE an enumeration of all computable numbers, under the
u can "DEFINE" it i guess, i can't agree u can actually PRODUCE it as
show me a production of it ... as u can't actually write it down without
a method to compute it
i'm pretty whatever about the axiom of choice
axiom of choice, but we can not GIVE that to a machine, as that
enumeration isn't finite or computable,
no?
And without all the numbers, it isn't COMPLETE, and thus
uninteresting.
not all machines even produce output, so ofc trying to compute a
diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines
but not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they
should be includable in attempting to compute a diagonal across all >>>>> machines
The problem is that you are NOT making an enumeration of ALL
machines, but only machines that reach the diagonal when sorted by
your criteria.
Where we sort the machines this way, we create a super-set of the
superset??? to create this we enumerated out and simulate _all_
machine, there is _no_ superset of that (which consists of only
machines)...
Sure there is, as you keep on changing the ORDER of the machines as
you investigate.
machines, and thus get to an uncountable infinity, so we can't
enumerate
BRO, what are you talking about???
You don't understand an uncountable infinity?
honestly bro u just fucking backing urself into a corner by completely misapplying basic number theory
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is a
_contradiction_
Right, WHEN YOU ENUMERATE THEM, and don't suffle them.
Your code keeps on updating the "set of machines" it is looking at,
each set of machines it looks at, for any given cycle, is _finite_, as
each cycle of the dovetailing algo is and must be _finite_ ...
you cannot create an uncountable set of sets using only finite length
sets of finite objects (like machines/natural number), richard
this is basic number theory
and _no_ just because each machine may produce an infinite set of output does not turing this into an uncountable situation... like any given computable sequence, the entire output set is equatable with the /finite length/ machine that produced it, so therefor sets of output sets will
not produce countability issues anymore than sets of the machines which produce them will
which gets enough different sets to reach something of the same
cardinaltiy of the power set.
it.
Of course, uncountable infinities doen't follow the logic that you
want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which
are bijectable with natural nubmers, form _uncountable
infinities_ ... that's a _contradiction_ dude!
Right, the MACHINES are bijectable, but you don't just simply process
them.
After all, the set of the mappings of the Natural Numbers to 0 or 1 is
an uncountable set.
the set of *all* mappings sure, but not necessarily all subsets of that, obviously...
the set of all computable mappings obviously isn't uncountable
my god, this fucking group???
what the fuck are you all smoking???
IT seems YOU are the one smoking something, as you refuse to
understand the problems you are trying to just ignore.
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that we
_cannot_ be able to prove machines produce an uncountable infinity ...
Where do you get that from?
The point is that we can not in finite steps decide if a given machine
is circular or not,
And we can not produce a machine that computationally enumerates the
compuational numbers or the non-circular machines.
Where do you see him talking about anything about "countability".
literally the first sentence of §8:
| It may be thought that arguments which prove that the
| real numbers are not enumerable would also prove that
| the computable numbers and sequences cannot be enumerable
the whole point of the H paradox was to prevent a diagonalization proof
on computable numbers that would show them to be not enumerable, more commonly now known as uncountable ...
so you casually throwing uncountability in regards to computing a
_single set_ of machines is just mindbogglingly detached from even
turing's proof, which is crazy because ur trying to defend his proof bro,
_and fucking nonsense like this is exactly why i'm pursuing this research_
the fucking tards that have been handling this thus far are incredibly lacking in their critical thinking and coherency faculties, and have now ended up attacking me with the very same ideas turing was trying to keep from being applied to computable numbers, _IN THE FIRST PLACE_
While the sum of the number of steps needed to get to the Kth output
of anti-sloppier-H is finite, when you multiply each element by the
number of machines included by sloppier-H to compute that, the sum
doesn't converge, thus your "enumeration" puts anti-sloppier-H at an
uncountable value in the enumeration even though the machine itself
is circle-free.
It seems that is just all you can do, since you don't understand how
It seems you have a fundamental problem about thinking through >>>>>>>> the requirements, as "requirements" are just optional ideas to you. >>>>>>>>
clearly being able to enumerate a set of machines, does _not_ >>>>>>>>> then imply one can certainly construct a diagonal across the >>>>>>>>> computable numbers within that set
Because the determination that a given machine create a
computable number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing >>>>>> off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its
diagonal digit is.
y do u think i disagree with any of that?
And, it seems you don't understand what I was talking about. >>>>>>>>>>
Apparently you can't even understand the arguement, as "K" >>>>>>>>>> isn't a VALUE output, but the id number of the row being
output, and the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as >>>>>>>>>> sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there. >>>>>>>>>>
For sloppier_H to work, the Kth row need to compute at least K >>>>>>>>>> digits, and thus any machine like turing's original H that >>>>>>>>>> looks to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a >>>>>>>>>> special number, but anti_sloppier_H won't do that, so
sloppier_H will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-
reference" number as sloppier_H, NOT its own, and thus it WILL >>>>>>>>>> get the anti- diagonal that is the opposite of sloppier_H, and >>>>>>>>>> won't get hung up on itself, since neither did sloppier_H get >>>>>>>>>> hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow >>>>>>>>>> instructions, possible because you are just mentally unable to >>>>>>>>>> do accurate work because "correct" isn't a word you understand. >>>>>>>>>
So, you agree with the statement that you just refuse to follow >>>>>>>> instructions because you are mentally unable to do accurate work >>>>>>>> becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱 >>>>
to do actual logic, but just want to use fallacies.
i'm sorry u fallacy wot now?
Your logic is just based on fallacies.
Things like assuming the conclusion, or ignoring the facts.
But, you forget that you need to actually PROVE what you claim.
After all, you ARE proving you don't understand what a requirement >>>>>> is.
this is exploring the bounds of theory mate, not engineering a system >>>>
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix, you
can not show that you compute "fast" enough to get to any particuar
machine, as there are an infinite number of machines that can get to
their kth output before this one, (even if they eventually become
circular and stop outputing).
Ultimately, the problem is that the sorting that your "enumeration"
is based on creates a super-set of the Natural Numbers, which is
uncountable, so you can't get to all the elements of that set.
oh my god bro ... see you've gone down a fucking road bro. machines
_cannot_ produce an uncountable infinity. avoiding that was _why_
turing pursued proving the H paradox in the first place!
Right, they can not actually produce it, but if the algorith would
generate it they just will not finish.
yet here you are trying to shut my down by casually claiming actually
machines form uncountable infinities now???
SETS of machines can.
no, an infinite set of infinite sets of machines can be uncountable,
but just an infinite set of machines cannot be uncountable, richard
the set of computable numbers is _not_ uncountable
nothing here is trying to compute an uncountable set
u bringing up uncountablity is just u ramming in a pathetic excuse for
us failing to study this further for almost a century now...
I guess your ignorance is approaching infinity.
_that was what turing was trying to avoiding in the first place_ !!!
No, he was pointing out that we can not get a result that depends on
an uncountable infinity.
I can easily write a program that "when it completes" would have
produced and uncountable infinite set, it just can't ever get that far.
The fact you don't understand this is part of your problem.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't >>>>>>>>>>>> exist (like the diagonal of an enumeration that includes >>>>>>>>>>>> circular machines) so there isn't a diagonal to compute. >>>>>>>>>>>>
That is like the inability to compute an even prime greater >>>>>>>>>>>> than 2 doesn't affect our ability to compute other primes. >>>>>>>>>>>>
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>>>>
My guess is you are not going to actually answer with a >>>>>>>>>>>>>> real inconsistance, but just throw out a strawman, and >>>>>>>>>>>>>> that is your modus operandi.
On 4/2/26 8:19 PM, dart200 wrote:
On 4/2/26 4:43 PM, Richard Damon wrote:
On 4/2/26 12:52 PM, dart200 wrote:
On 4/2/26 4:18 AM, Richard Damon wrote:
On 4/2/26 12:21 AM, dart200 wrote:
if i were talking to someone capable of doing more than upholding >>>>>> a bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that
apply to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being
uncountable
But since you get into the power-set (but letting your machine resort
them by length of running time) you get into the uncountable.
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
*infinite not uncountable... the steps of any actual computation are
necessarily countable,
and circular machine do not impede dovetailing algo, that is a bizarre
response and and just forgetful of the fact circular machines also do
not impede using dovetailing to enumerate out halting machines
admittedly halting machines cannot entirely express this paradox because halting machines cannot compute across an infinite set of machines, and
this paradox requires that facet in order to contradict _all_ possible machines...
non-halting machines can, and basically the consensus just gave up at
the recognition of this... problem 🤷🤷🤷
my opinion is that ur failure rick to really understand the true relationship of countability to machines *and therefore their output
sets* is highly related to the incomplete view of undecidability u also hold. i see that decidability problems, especially in regards to the behaviors of machine, can be limited and/or constrained /by the inherent limited countable nature of machines/ and /therefore their output sets
as well/
On 4/2/26 4:43 PM, Richard Damon wrote:
On 4/2/26 12:52 PM, dart200 wrote:
why didn't all the computable numbers, which have an output for _all_
K therefore allowing them to reach any diagonal of the output total
number matrix make it onto the computed diagonal???
As I said, because it spent too much time simulating circular maxhines,
that is _not_ what is happening here,
even if we ( _hypothetically_ ) started with a full enumeration of
_just_ computable numbers, so no time was "wasted", it still wouldn't be able to produce the diagonal via dovetailing ...
the _same_ problem would exist
(note that _particular_ problem wouldn't exist with RTMs)
which puts off the completion of the enumeration past the limits of
finiteness.
It dies getting stuck in its strawmen,
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
So you AGREE that it is mising.
Since anti-sloppier-H and sloppier-H are circularity equivalent, that
means either sloppier-H misses a computational number, or it is
circular and doesn't actually compute the full diagonal.
this doesn't require specifically selection for them, they should
have outputs regardless of whether we select for them, and that
should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off
anti- sloppier-H, which while actually computable, beomes to "slow"
to reach the top of the list.
at least u understand the problem here
Yes, I do.
But apparently you don't, because you don't actually understand the
requirements.
the question is: are u able to admit this is a problem? or just
therefore, regardless of whether we can enumerate a set of
computable numbers or not, they cannot all be computably put on a
diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth
digits in a finite number of steps if sloppier-H outputs its Kth
digit in a finite number of steps, so both are generating computable
numbers or not together, but anti-sloppier-H isn't in your enumeration. >>>
continually accept the paradoxical as valid because ur already so
used to promoting the current consensus as valid?
It is a RESOLVED problem, because your enumeration just isn't complete.
IT is YOU that can't see the actual problem, because you are just
ignorant of the basics of the theory you are trying to talk about.
Your problem is you just assume you understand what you machine does,
because you apparently don't understand how to handle things that can
be infinite, because you like to assume they just do what you want.
the answer is: not yet apparently
if i were talking to someone capable of doing more than upholding a >>>>> bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that apply
to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being
uncountable
But since you get into the power-set (but letting your machine resort
them by length of running time) you get into the uncountable.
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
*infinite not uncountable... the steps of any actual computation are necessarily countable,
and circular machine do not impede dovetailing algo, that is a bizarre response and and just forgetful of the fact circular machines also do
not impede using dovetailing to enumerate out halting machines
described isn't a computable number, only the diagonal of the PARTIAL
enumeration of the machine that it gets to the output of is.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running all >>>>>>>> machines as enumerated doesh't always reach the diagonal.
that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal,
because they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the properly >>>>>> built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H
(including the number checked) except it outputs the reversed digit. >>>>>>
Thus, if sloppier_H continues to run and produce output, so does
anti_sloppier_H
so they _should_ end up on the attempted diagonal computation,
given we're simulating all of them in parallel, but that can't
happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of the >>>>> enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
No it isn't.
The enumeratio of MACHINES that it starts from is complete.
yes it starts with a full enumeration of all machines, including all computable numbers, and is still unable to produce a diagonal that
includes all computable numbers despite them all having enough digits to
be on the diagonal
The enumeration that the diagonal is defined to be computed of is not,
as you claim it need to get to a machine for every computable number.
The problem is that the progress that sloppier-H makes gets slower
and slower as the infinite number of circular machines get added to
the set of machines being simulated to find the one that makes the
next digit, and thus the number of steps that sloppier-H needs to
perform grows, and that sum becomes a divergent sum that doesn't
converge, and thus it never actually gets to anti-sloppier-H.
i'm aware of the problem that given an enumeration which certainly
includes _all_ computable sequences, we cannot seem to actually form
a diagonal with that which includes _all_ computable sequences
We can PRODUCE such a diagonal, but not computationally.
if u can't write me down the diagonal, i can't agree u "PRODUCED" it
therefor even if given an enumeration which includes _only_ _all_
computable numbers, we should not expect to be able to use that to
produce a diagonal which includes _all_ computable sequences...
What are you considering the difference between a "Computable Number"
and a "Computable Sequence"?
| A sequence is said to be computable if it can be computed
| by a circle-free machine. A number is computable if it
| differs by an integer from the number computed by a
| circle-free machine
Note, we can PRODUCE an enumeration of all computable numbers, under the
u can "DEFINE" it i guess, i can't agree u can actually PRODUCE it as
show me a production of it ... as u can't actually write it down without
a method to compute it
i'm pretty whatever about the axiom of choice
axiom of choice, but we can not GIVE that to a machine, as that
enumeration isn't finite or computable,
no?
And without all the numbers, it isn't COMPLETE, and thus
uninteresting.
not all machines even produce output, so ofc trying to compute a
diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines
but not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they
should be includable in attempting to compute a diagonal across all >>>>> machines
The problem is that you are NOT making an enumeration of ALL
machines, but only machines that reach the diagonal when sorted by
your criteria.
Where we sort the machines this way, we create a super-set of the
superset??? to create this we enumerated out and simulate _all_
machine, there is _no_ superset of that (which consists of only
machines)...
Sure there is, as you keep on changing the ORDER of the machines as
you investigate.
machines, and thus get to an uncountable infinity, so we can't
enumerate
BRO, what are you talking about???
You don't understand an uncountable infinity?
honestly bro u just fucking backing urself into a corner by completely misapplying basic number theory
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is a
_contradiction_
Right, WHEN YOU ENUMERATE THEM, and don't suffle them.
Your code keeps on updating the "set of machines" it is looking at,
each set of machines it looks at, for any given cycle, is _finite_, as
each cycle of the dovetailing algo is and must be _finite_ ...
you cannot create an uncountable set of sets using only finite length
sets of finite objects (like machines/natural number), richard
this is basic number theory
and _no_ just because each machine may produce an infinite set of output does not turing this into an uncountable situation... like any given computable sequence, the entire output set is equatable with the /finite length/ machine that produced it, so therefor sets of output sets will
not produce countability issues anymore than sets of the machines which produce them will
which gets enough different sets to reach something of the same
cardinaltiy of the power set.
it.
Of course, uncountable infinities doen't follow the logic that you
want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which
are bijectable with natural nubmers, form _uncountable
infinities_ ... that's a _contradiction_ dude!
Right, the MACHINES are bijectable, but you don't just simply process
them.
After all, the set of the mappings of the Natural Numbers to 0 or 1 is
an uncountable set.
the set of *all* mappings sure, but not necessarily all subsets of that, obviously...
the set of all computable mappings obviously isn't uncountable
my god, this fucking group???
what the fuck are you all smoking???
IT seems YOU are the one smoking something, as you refuse to
understand the problems you are trying to just ignore.
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that we
_cannot_ be able to prove machines produce an uncountable infinity ...
Where do you get that from?
The point is that we can not in finite steps decide if a given machine
is circular or not,
And we can not produce a machine that computationally enumerates the
compuational numbers or the non-circular machines.
Where do you see him talking about anything about "countability".
literally the first sentence of §8:
| It may be thought that arguments which prove that the
| real numbers are not enumerable would also prove that
| the computable numbers and sequences cannot be enumerable
the whole point of the H paradox was to prevent a diagonalization proof
on computable numbers that would show them to be not enumerable, more commonly now known as uncountable ...
so you casually throwing uncountability in regards to computing a
_single set_ of machines is just mindbogglingly detached from even
turing's proof, which is crazy because ur trying to defend his proof bro,
_and fucking nonsense like this is exactly why i'm pursuing this research_
the fucking tards that have been handling this thus far are incredibly lacking in their critical thinking and coherency faculties, and have now ended up attacking me with the very same ideas turing was trying to keep from being applied to computable numbers, _IN THE FIRST PLACE_
While the sum of the number of steps needed to get to the Kth output
of anti-sloppier-H is finite, when you multiply each element by the
number of machines included by sloppier-H to compute that, the sum
doesn't converge, thus your "enumeration" puts anti-sloppier-H at an
uncountable value in the enumeration even though the machine itself
is circle-free.
It seems that is just all you can do, since you don't understand how
It seems you have a fundamental problem about thinking through >>>>>>>> the requirements, as "requirements" are just optional ideas to you. >>>>>>>>
clearly being able to enumerate a set of machines, does _not_ >>>>>>>>> then imply one can certainly construct a diagonal across the >>>>>>>>> computable numbers within that set
Because the determination that a given machine create a
computable number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H
computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing >>>>>> off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its
diagonal digit is.
y do u think i disagree with any of that?
And, it seems you don't understand what I was talking about. >>>>>>>>>>
Apparently you can't even understand the arguement, as "K" >>>>>>>>>> isn't a VALUE output, but the id number of the row being
output, and the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as >>>>>>>>>> sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there. >>>>>>>>>>
For sloppier_H to work, the Kth row need to compute at least K >>>>>>>>>> digits, and thus any machine like turing's original H that >>>>>>>>>> looks to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a >>>>>>>>>> special number, but anti_sloppier_H won't do that, so
sloppier_H will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-
reference" number as sloppier_H, NOT its own, and thus it WILL >>>>>>>>>> get the anti- diagonal that is the opposite of sloppier_H, and >>>>>>>>>> won't get hung up on itself, since neither did sloppier_H get >>>>>>>>>> hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to follow >>>>>>>>>> instructions, possible because you are just mentally unable to >>>>>>>>>> do accurate work because "correct" isn't a word you understand. >>>>>>>>>
So, you agree with the statement that you just refuse to follow >>>>>>>> instructions because you are mentally unable to do accurate work >>>>>>>> becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱 >>>>
to do actual logic, but just want to use fallacies.
i'm sorry u fallacy wot now?
Your logic is just based on fallacies.
Things like assuming the conclusion, or ignoring the facts.
But, you forget that you need to actually PROVE what you claim.
After all, you ARE proving you don't understand what a requirement >>>>>> is.
this is exploring the bounds of theory mate, not engineering a system >>>>
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix, you
can not show that you compute "fast" enough to get to any particuar
machine, as there are an infinite number of machines that can get to
their kth output before this one, (even if they eventually become
circular and stop outputing).
Ultimately, the problem is that the sorting that your "enumeration"
is based on creates a super-set of the Natural Numbers, which is
uncountable, so you can't get to all the elements of that set.
oh my god bro ... see you've gone down a fucking road bro. machines
_cannot_ produce an uncountable infinity. avoiding that was _why_
turing pursued proving the H paradox in the first place!
Right, they can not actually produce it, but if the algorith would
generate it they just will not finish.
yet here you are trying to shut my down by casually claiming actually
machines form uncountable infinities now???
SETS of machines can.
no, an infinite set of infinite sets of machines can be uncountable,
but just an infinite set of machines cannot be uncountable, richard
the set of computable numbers is _not_ uncountable
nothing here is trying to compute an uncountable set
u bringing up uncountablity is just u ramming in a pathetic excuse for
us failing to study this further for almost a century now...
I guess your ignorance is approaching infinity.
_that was what turing was trying to avoiding in the first place_ !!!
No, he was pointing out that we can not get a result that depends on
an uncountable infinity.
I can easily write a program that "when it completes" would have
produced and uncountable infinite set, it just can't ever get that far.
The fact you don't understand this is part of your problem.
In other words, for you 1 = 2 is just a fact of life.
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't >>>>>>>>>>>> exist (like the diagonal of an enumeration that includes >>>>>>>>>>>> circular machines) so there isn't a diagonal to compute. >>>>>>>>>>>>
That is like the inability to compute an even prime greater >>>>>>>>>>>> than 2 doesn't affect our ability to compute other primes. >>>>>>>>>>>>
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>>>>
My guess is you are not going to actually answer with a >>>>>>>>>>>>>> real inconsistance, but just throw out a strawman, and >>>>>>>>>>>>>> that is your modus operandi.
On 4/2/26 11:19 PM, dart200 wrote:
On 4/2/26 4:43 PM, Richard Damon wrote:
On 4/2/26 12:52 PM, dart200 wrote:
why didn't all the computable numbers, which have an output for
_all_ K therefore allowing them to reach any diagonal of the output
total number matrix make it onto the computed diagonal???
As I said, because it spent too much time simulating circular maxhines,
that is _not_ what is happening here,
Sure it is.
even if we ( _hypothetically_ ) started with a full enumeration of
_just_ computable numbers, so no time was "wasted", it still wouldn't
be able to produce the diagonal via dovetailing ...
But you aren't allowed to hypothisize about the impossible, except to
prove it impossible.
This is the fatal fallacy in all your logic.
Of course if you start with a broken system where 1 == 0, you can prove
all sorts of nonsense. Your world is just one that has exploded by the contradictions you assume are allowed.
the _same_ problem would exist
(note that _particular_ problem wouldn't exist with RTMs)
Sure it would, you just are trying to define RTMs so that wrong answers
can be right.
which puts off the completion of the enumeration past the limits of
finiteness.
It dies getting stuck in its strawmen,
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
So you AGREE that it is mising.
Since anti-sloppier-H and sloppier-H are circularity equivalent, that
means either sloppier-H misses a computational number, or it is
circular and doesn't actually compute the full diagonal.
this doesn't require specifically selection for them, they should >>>>>> have outputs regardless of whether we select for them, and that
should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off
anti- sloppier-H, which while actually computable, beomes to "slow" >>>>> to reach the top of the list.
at least u understand the problem here
Yes, I do.
But apparently you don't, because you don't actually understand the
requirements.
therefore, regardless of whether we can enumerate a set of
computable numbers or not, they cannot all be computably put on a >>>>>> diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth
digits in a finite number of steps if sloppier-H outputs its Kth
digit in a finite number of steps, so both are generating
computable numbers or not together, but anti-sloppier-H isn't in
your enumeration.
the question is: are u able to admit this is a problem? or just
continually accept the paradoxical as valid because ur already so
used to promoting the current consensus as valid?
It is a RESOLVED problem, because your enumeration just isn't complete.
IT is YOU that can't see the actual problem, because you are just
ignorant of the basics of the theory you are trying to talk about.
Your problem is you just assume you understand what you machine does,
because you apparently don't understand how to handle things that can
be infinite, because you like to assume they just do what you want.
the answer is: not yet apparently
And that is the problem, you don't understand the basics of logic, and
thus everything you do is just based on assuming the absurd.
if i were talking to someone capable of doing more than upholding >>>>>> a bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that
apply to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being
uncountable
But since you get into the power-set (but letting your machine resort
them by length of running time) you get into the uncountable.
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
*infinite not uncountable... the steps of any actual computation are
necessarily countable,
And NEVER reaches its stated goal, even in that contable infinite number
of steps.
and circular machine do not impede dovetailing algo, that is a bizarre
response and and just forgetful of the fact circular machines also do
not impede using dovetailing to enumerate out halting machines
Sure they do, as they push off the time needed to simulate the non- circulare machines until it never happens.
described isn't a computable number, only the diagonal of the PARTIAL
enumeration of the machine that it gets to the output of is.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running >>>>>>>>> all machines as enumerated doesh't always reach the diagonal. >>>>>>>>that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal,
because they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the
properly built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H >>>>>>> (including the number checked) except it outputs the reversed digit. >>>>>>>
Thus, if sloppier_H continues to run and produce output, so does >>>>>>> anti_sloppier_H
so they _should_ end up on the attempted diagonal computation, >>>>>>>> given we're simulating all of them in parallel, but that can't >>>>>>>> happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of
the enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
No it isn't.
The enumeratio of MACHINES that it starts from is complete.
yes it starts with a full enumeration of all machines, including all
computable numbers, and is still unable to produce a diagonal that
includes all computable numbers despite them all having enough digits
to be on the diagonal
Because determining which machines are non-circular is non-computatable,
in it spends too much time simulating machines that will never produce a result.
The problem is that if a given non-circular machine (m) takes N(k) steps
to compute its kth digit, it won't be used to simulate that digit for
output unless there are less than k machines in process that have
reached that point in the m+N(k) machines that are in the running.
There exists enough circular machines fast enough, and some non-circular machines slow enough, that the non-circular machine never gets output.
Try to prove otherwise!
After all, I have shown a machine that is in that situtation, at least
if your sloppier-H actually produces a computable number becausse it is non-circular (my anti-sloppier-H). It produces its k'th digit in exactly
the same number of steps as the sloppier-H it was modeled after, but
clearly never gets output, because it is always beaten to the line by
other machines.
The enumeration that the diagonal is defined to be computed of is
not, as you claim it need to get to a machine for every computable
number.
The problem is that the progress that sloppier-H makes gets slower
and slower as the infinite number of circular machines get added to >>>>> the set of machines being simulated to find the one that makes the
next digit, and thus the number of steps that sloppier-H needs to
perform grows, and that sum becomes a divergent sum that doesn't
converge, and thus it never actually gets to anti-sloppier-H.
i'm aware of the problem that given an enumeration which certainly
includes _all_ computable sequences, we cannot seem to actually form
a diagonal with that which includes _all_ computable sequences
We can PRODUCE such a diagonal, but not computationally.
if u can't write me down the diagonal, i can't agree u "PRODUCED" it
Then you dom't understand what the words mean and how the axiom of
choice works.
Since the diagonal in infinite in length, it can't be written down, so
to you logic, it can't exist.
therefor even if given an enumeration which includes _only_ _all_
computable numbers, we should not expect to be able to use that to
produce a diagonal which includes _all_ computable sequences...
What are you considering the difference between a "Computable Number"
and a "Computable Sequence"?
| A sequence is said to be computable if it can be computed
| by a circle-free machine. A number is computable if it
| differs by an integer from the number computed by a
| circle-free machine
Where do you get that definition of a computable number, that it DIFFERS from a number computed by a circle-free machine?
u can "DEFINE" it i guess, i can't agree u can actually PRODUCE it as
Note, we can PRODUCE an enumeration of all computable numbers, under the >>
show me a production of it ... as u can't actually write it down
without a method to compute it
Which shows the hole in your logic.
i'm pretty whatever about the axiom of choice
It seems you are pretty "whatever" abput logical thinking in general.
axiom of choice, but we can not GIVE that to a machine, as that
enumeration isn't finite or computable,
no?
And without all the numbers, it isn't COMPLETE, and thus
uninteresting.
not all machines even produce output, so ofc trying to compute a
diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines
but not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they
should be includable in attempting to compute a diagonal across
all machines
The problem is that you are NOT making an enumeration of ALL
machines, but only machines that reach the diagonal when sorted by
your criteria.
Where we sort the machines this way, we create a super-set of the
superset??? to create this we enumerated out and simulate _all_
machine, there is _no_ superset of that (which consists of only
machines)...
Sure there is, as you keep on changing the ORDER of the machines as
you investigate.
machines, and thus get to an uncountable infinity, so we can't
enumerate
BRO, what are you talking about???
You don't understand an uncountable infinity?
honestly bro u just fucking backing urself into a corner by completely
misapplying basic number theory
Try to show me wrong.
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is a
_contradiction_
Right, WHEN YOU ENUMERATE THEM, and don't suffle them.
Your code keeps on updating the "set of machines" it is looking at,
each set of machines it looks at, for any given cycle, is _finite_, as
each cycle of the dovetailing algo is and must be _finite_ ...
you cannot create an uncountable set of sets using only finite length
sets of finite objects (like machines/natural number), richard
But the set your goal is trying to compute IS, and that is why you can
never produce it.
this is basic number theory
No, you are just showing why you can't count the uncountable infinity.
That exact same arguement occurs in any attempt to enumerate an
uncountable infinity, you always only have a finite set of things under
consideration at the time, you just never get to anywhere near the end.
and _no_ just because each machine may produce an infinite set of
output does not turing this into an uncountable situation... like any
given computable sequence, the entire output set is equatable with
the /finite length/ machine that produced it, so therefor sets of
output sets will not produce countability issues anymore than sets of
the machines which produce them will
Because countable infinity can be counted.
If we have an O(1) method of finding the "next" machine in sequence, we
can compute the number of steps needed to find the Kth digit of the Nth number, and it will be finite.
Because YOUR method of computing the diagonal doesn't follow that
method, since your selecting isn't O(1), it turns out that to compute
how many steps it takes to do that same thing by our method is no longer
a bounded number and thus you haven't actually enumerated the system.
which gets enough different sets to reach something of the same
cardinaltiy of the power set.
it.
Of course, uncountable infinities doen't follow the logic that you
want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which
are bijectable with natural nubmers, form _uncountable
infinities_ ... that's a _contradiction_ dude!
Right, the MACHINES are bijectable, but you don't just simply process
them.
After all, the set of the mappings of the Natural Numbers to 0 or 1
is an uncountable set.
the set of *all* mappings sure, but not necessarily all subsets of
that, obviously...
Not ALL, but some. Your problem is you need to try to show that the one
you are working with isn't one of them, while I have shown it is by the existance of anti-sloppier-H, which is a computable number not in the
set (that is defined to need to include it) if the subset you are trying
to generate wasn't.
the set of all computable mappings obviously isn't uncountable
Right, but that isn't the set you are working with.
my god, this fucking group???
what the fuck are you all smoking???
IT seems YOU are the one smoking something, as you refuse to
understand the problems you are trying to just ignore.
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that we
_cannot_ be able to prove machines produce an uncountable infinity ...
Where do you get that from?
The point is that we can not in finite steps decide if a given
machine is circular or not,
And we can not produce a machine that computationally enumerates the
compuational numbers or the non-circular machines.
Where do you see him talking about anything about "countability".
literally the first sentence of §8:
| It may be thought that arguments which prove that the
| real numbers are not enumerable would also prove that
| the computable numbers and sequences cannot be enumerable
Which shows that he isn't using a counting arguement, because he is
showing that isn't applicable.
Note, you have to watch out on the meaning of the words, as Turing uses "enumerable" here to mean what we now call effectively enumerable, to
mean an enumeration that is computable.
By THAT definition, the computable numbers are not enumerable, even
though they can by put into a bijection with the Natural Numbers, and
are thus a countable infinity.
the whole point of the H paradox was to prevent a diagonalization
proof on computable numbers that would show them to be not enumerable,
more commonly now known as uncountable ...
Which is a wrong statement as I just explained.
There are only a countable number of machines, and just by bi-jection
they must be enumerable by your definition, but that enumeration is not
what we now call effective, so isn't what Turing was calling enumerable.
so you casually throwing uncountability in regards to computing a
_single set_ of machines is just mindbogglingly detached from even
turing's proof, which is crazy because ur trying to defend his proof bro,
Because in his language, enumerating and being countable are different things.
_and fucking nonsense like this is exactly why i'm pursuing this
research_
And the "fucking nonsense" is based on you just failing to learn what
things mean in their context.
the fucking tards that have been handling this thus far are incredibly
lacking in their critical thinking and coherency faculties, and have
now ended up attacking me with the very same ideas turing was trying
to keep from being applied to computable numbers, _IN THE FIRST PLACE_
No, YOU lack the critical thinking ability to understand what is being discussed, as you don't understand the need to understand the language
as it is being used.
The fact that your logic depends on the need to assume false statements
just shows how fucked up your brain is. Of course, you don't see the falseness of the statements, as you just don't understand what they
actually mean because you don't understand the language being used.
You blaim the great minds of being stupid because they aren't using
words the way you want them to be, but the way they were defined at the
time they wrote their papers.
While the sum of the number of steps needed to get to the Kth
output of anti-sloppier-H is finite, when you multiply each element >>>>> by the number of machines included by sloppier-H to compute that,
the sum doesn't converge, thus your "enumeration" puts anti-
sloppier-H at an uncountable value in the enumeration even though
the machine itself is circle-free.
It seems that is just all you can do, since you don't understand
It seems you have a fundamental problem about thinking through >>>>>>>>> the requirements, as "requirements" are just optional ideas to >>>>>>>>> you.
clearly being able to enumerate a set of machines, does _not_ >>>>>>>>>> then imply one can certainly construct a diagonal across the >>>>>>>>>> computable numbers within that set
Because the determination that a given machine create a
computable number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H >>>>>>>> computation that i proposed
And it never reaches ALL the numbers, because it keeps on pushing >>>>>>> off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the
diagonal, anti_sloppier_H doesn't need to figure out what its
diagonal digit is.
And, it seems you don't understand what I was talking about. >>>>>>>>>>>
Apparently you can't even understand the arguement, as "K" >>>>>>>>>>> isn't a VALUE output, but the id number of the row being >>>>>>>>>>> output, and the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, as >>>>>>>>>>> sloppier_H can generate the diagonal, which means that
anti_sloppier_H can't be in that enumeration, and thus
anti_sloppier_H can't get "stuck" on it trying to get there. >>>>>>>>>>>
For sloppier_H to work, the Kth row need to compute at least >>>>>>>>>>> K digits, and thus any machine like turing's original H that >>>>>>>>>>> looks to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a >>>>>>>>>>> special number, but anti_sloppier_H won't do that, so
sloppier_H will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self-
reference" number as sloppier_H, NOT its own, and thus it >>>>>>>>>>> WILL get the anti- diagonal that is the opposite of
sloppier_H, and won't get hung up on itself, since neither >>>>>>>>>>> did sloppier_H get hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to >>>>>>>>>>> follow instructions, possible because you are just mentally >>>>>>>>>>> unable to do accurate work because "correct" isn't a word you >>>>>>>>>>> understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to follow >>>>>>>>> instructions because you are mentally unable to do accurate >>>>>>>>> work becuae "correct" isn't a word you understand?
At least you know that you are that stupid, you just don't
understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱 >>>>>
how to do actual logic, but just want to use fallacies.
i'm sorry u fallacy wot now?
Your logic is just based on fallacies.
Things like assuming the conclusion, or ignoring the facts.
But, you forget that you need to actually PROVE what you claim.
After all, you ARE proving you don't understand what a
requirement is.
this is exploring the bounds of theory mate, not engineering a system >>>>>
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix,
you can not show that you compute "fast" enough to get to any
particuar machine, as there are an infinite number of machines that >>>>> can get to their kth output before this one, (even if they
eventually become circular and stop outputing).
Ultimately, the problem is that the sorting that your "enumeration" >>>>> is based on creates a super-set of the Natural Numbers, which is
uncountable, so you can't get to all the elements of that set.
oh my god bro ... see you've gone down a fucking road bro. machines
_cannot_ produce an uncountable infinity. avoiding that was _why_
turing pursued proving the H paradox in the first place!
Right, they can not actually produce it, but if the algorith would
generate it they just will not finish.
yet here you are trying to shut my down by casually claiming
actually machines form uncountable infinities now???
SETS of machines can.
no, an infinite set of infinite sets of machines can be uncountable,
but just an infinite set of machines cannot be uncountable, richard
Right,
the set of computable numbers is _not_ uncountable
Right.
nothing here is trying to compute an uncountable set
Right, but computable is a proper subset of countable.
When we look at the space being examined by your computation, it is
looking at VARIOUS sets of machines. And this set that is built
INTERNALLY, if expaded to its definition, would be uncountable.
Thus, the EXTERNAL set of the problem might be countable, but the
INTERNAL space being examined goes uncountable, and thus the comutation can't complete, even given countable infinite time.
u bringing up uncountablity is just u ramming in a pathetic excuse for
us failing to study this further for almost a century now...
And the problem is that if the path only generated a countable number of possibilities, you could compute it.
I guess your ignorance is approaching infinity.
_that was what turing was trying to avoiding in the first place_ !!!
No, he was pointing out that we can not get a result that depends on
an uncountable infinity.
I can easily write a program that "when it completes" would have
produced and uncountable infinite set, it just can't ever get that far.
The fact you don't understand this is part of your problem.
In other words, for you 1 = 2 is just a fact of life. >>>>>>>>>>>>>
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't >>>>>>>>>>>>> exist (like the diagonal of an enumeration that includes >>>>>>>>>>>>> circular machines) so there isn't a diagonal to compute. >>>>>>>>>>>>>
That is like the inability to compute an even prime greater >>>>>>>>>>>>> than 2 doesn't affect our ability to compute other primes. >>>>>>>>>>>>>
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>>>>>
My guess is you are not going to actually answer with a >>>>>>>>>>>>>>> real inconsistance, but just throw out a strawman, and >>>>>>>>>>>>>>> that is your modus operandi.
On 4/3/26 7:25 AM, Richard Damon wrote:
On 4/2/26 11:19 PM, dart200 wrote:
On 4/2/26 4:43 PM, Richard Damon wrote:
On 4/2/26 12:52 PM, dart200 wrote:that is _not_ what is happening here,
why didn't all the computable numbers, which have an output for
_all_ K therefore allowing them to reach any diagonal of the output >>>>> total number matrix make it onto the computed diagonal???
As I said, because it spent too much time simulating circular maxhines, >>>
Sure it is.
it's not richard
even if we ( _hypothetically_ ) started with a full enumeration of
_just_ computable numbers, so no time was "wasted", it still wouldn't
be able to produce the diagonal via dovetailing ...
But you aren't allowed to hypothisize about the impossible, except to
prove it impossible.
who's stopping me? you?? 🤣🤣🤣
This is the fatal fallacy in all your logic.
Of course if you start with a broken system where 1 == 0, you can
prove all sorts of nonsense. Your world is just one that has exploded
by the contradictions you assume are allowed.
what? richard, the _same_ problem manifests with trying to dovetail
_all_ machines as that with _just_ computable numbers ...
it has nothing to do with supposed impossibility of effectively
enumerating computable numbers, there's no connection ur just throwing arguments at the wall in total denial
the _same_ problem would exist
(note that _particular_ problem wouldn't exist with RTMs)
Sure it would, you just are trying to define RTMs so that wrong
answers can be right.
which puts off the completion of the enumeration past the limits of
finiteness.
It dies getting stuck in its strawmen,
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
So you AGREE that it is mising.
Since anti-sloppier-H and sloppier-H are circularity equivalent,
that means either sloppier-H misses a computational number, or it is
circular and doesn't actually compute the full diagonal.
this doesn't require specifically selection for them, they should >>>>>>> have outputs regardless of whether we select for them, and that >>>>>>> should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off
anti- sloppier-H, which while actually computable, beomes to
"slow" to reach the top of the list.
at least u understand the problem here
Yes, I do.
But apparently you don't, because you don't actually understand the
requirements.
therefore, regardless of whether we can enumerate a set of
computable numbers or not, they cannot all be computably put on a >>>>>>> diagonal
But, you don't haven't enumerated the complete set of computable
numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth >>>>>> digits in a finite number of steps if sloppier-H outputs its Kth
digit in a finite number of steps, so both are generating
computable numbers or not together, but anti-sloppier-H isn't in
your enumeration.
the question is: are u able to admit this is a problem? or just
continually accept the paradoxical as valid because ur already so
used to promoting the current consensus as valid?
It is a RESOLVED problem, because your enumeration just isn't complete. >>>>
IT is YOU that can't see the actual problem, because you are just
ignorant of the basics of the theory you are trying to talk about.
Your problem is you just assume you understand what you machine
does, because you apparently don't understand how to handle things
that can be infinite, because you like to assume they just do what
you want.
the answer is: not yet apparently
And that is the problem, you don't understand the basics of logic, and
thus everything you do is just based on assuming the absurd.
if i were talking to someone capable of doing more than upholding >>>>>>> a bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that
apply to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being
uncountable
But since you get into the power-set (but letting your machine
resort them by length of running time) you get into the uncountable.
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
*infinite not uncountable... the steps of any actual computation are
necessarily countable,
And NEVER reaches its stated goal, even in that contable infinite
number of steps.
bro, if u think we've diagonalized _all_ machines and demonstrated an uncountable infinite being involved ....
_that is exactly what turing was trying to prevent in §8_
and circular machine do not impede dovetailing algo, that is a
bizarre response and and just forgetful of the fact circular machines
also do not impede using dovetailing to enumerate out halting machines
Sure they do, as they push off the time needed to simulate the non-
circulare machines until it never happens.
no, anti_sloppier_H is defined to only produce an output for some K
*after* sloppier_H produces an output for that K. even if
anti_sloppier_H skipped everything but computable sequences,
anti_sloppier_H still could never produce some K *after* sloppier_H does...
described isn't a computable number, only the diagonal of the
PARTIAL enumeration of the machine that it gets to the output of is.
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running >>>>>>>>>> all machines as enumerated doesh't always reach the diagonal. >>>>>>>>>that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal, >>>>>>>>> because they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the
properly built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as sloppier_H >>>>>>>> (including the number checked) except it outputs the reversed >>>>>>>> digit.
Thus, if sloppier_H continues to run and produce output, so does >>>>>>>> anti_sloppier_H
so they _should_ end up on the attempted diagonal computation, >>>>>>>>> given we're simulating all of them in parallel, but that can't >>>>>>>>> happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of >>>>>>> the enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
No it isn't.
The enumeratio of MACHINES that it starts from is complete.
yes it starts with a full enumeration of all machines, including all
computable numbers, and is still unable to produce a diagonal that
includes all computable numbers despite them all having enough digits
to be on the diagonal
Because determining which machines are non-circular is non-
computatable, in it spends too much time simulating machines that will
never produce a result.
...this doesn't decide what machines are non-circular, as it will mix in circular machines onto the diagonal...
ur just making up wild claims rick
The problem is that if a given non-circular machine (m) takes N(k)
steps to compute its kth digit, it won't be used to simulate that
digit for output unless there are less than k machines in process that
have reached that point in the m+N(k) machines that are in the running.
There exists enough circular machines fast enough, and some non-
circular machines slow enough, that the non-circular machine never
gets output.
Try to prove otherwise!
no, anti_sloppier_H is defined to only produce an output for some K
*after* sloppier_H produces an output for that K. even if
anti_sloppier_H skipped everything but computable sequences,
anti_sloppier_H still could never produce some K *after* sloppier_H does...
After all, I have shown a machine that is in that situtation, at least
if your sloppier-H actually produces a computable number becausse it
is non-circular (my anti-sloppier-H). It produces its k'th digit in
exactly the same number of steps as the sloppier-H it was modeled
after, but
no richard, for each cycle it must simulate all of sloppier_H + extra
steps for anti_sloppier_H
clearly never gets output, because it is always beaten to the line by
other machines.
The enumeration that the diagonal is defined to be computed of is
not, as you claim it need to get to a machine for every computable
number.
i'm aware of the problem that given an enumeration which certainly
The problem is that the progress that sloppier-H makes gets slower >>>>>> and slower as the infinite number of circular machines get added
to the set of machines being simulated to find the one that makes >>>>>> the next digit, and thus the number of steps that sloppier-H needs >>>>>> to perform grows, and that sum becomes a divergent sum that
doesn't converge, and thus it never actually gets to anti-sloppier-H. >>>>>
includes _all_ computable sequences, we cannot seem to actually
form a diagonal with that which includes _all_ computable sequences
We can PRODUCE such a diagonal, but not computationally.
if u can't write me down the diagonal, i can't agree u "PRODUCED" it
Then you dom't understand what the words mean and how the axiom of
choice works.
that's fine. u keep boasting about producing something that results in
no actual product and i'll just keep staring blankly at how stupid a
claim that is
Since the diagonal in infinite in length, it can't be written down, so
to you logic, it can't exist.
you can't write down any amount of it, as u have no method to
therefor even if given an enumeration which includes _only_ _all_
computable numbers, we should not expect to be able to use that to
produce a diagonal which includes _all_ computable sequences...
What are you considering the difference between a "Computable
Number" and a "Computable Sequence"?
| A sequence is said to be computable if it can be computed
| by a circle-free machine. A number is computable if it
| differs by an integer from the number computed by a
| circle-free machine
Where do you get that definition of a computable number, that it
DIFFERS from a number computed by a circle-free machine?
the same source i always quote: /on computable numbers/ richard
Note, we can PRODUCE an enumeration of all computable numbers, under
the
u can "DEFINE" it i guess, i can't agree u can actually PRODUCE it as
show me a production of it ... as u can't actually write it down
without a method to compute it
Which shows the hole in your logic.
what hole is that?
i'm pretty whatever about the axiom of choice
It seems you are pretty "whatever" abput logical thinking in general.
axiom of choice, but we can not GIVE that to a machine, as that
enumeration isn't finite or computable,
no?
And without all the numbers, it isn't COMPLETE, and thus
uninteresting.
not all machines even produce output, so ofc trying to compute a >>>>>>> diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines >>>>>> but not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they
should be includable in attempting to compute a diagonal across >>>>>>> all machines
The problem is that you are NOT making an enumeration of ALL
machines, but only machines that reach the diagonal when sorted by >>>>>> your criteria.
Where we sort the machines this way, we create a super-set of the
superset??? to create this we enumerated out and simulate _all_
machine, there is _no_ superset of that (which consists of only
machines)...
Sure there is, as you keep on changing the ORDER of the machines as
you investigate.
machines, and thus get to an uncountable infinity, so we can't
enumerate
BRO, what are you talking about???
You don't understand an uncountable infinity?
honestly bro u just fucking backing urself into a corner by
completely misapplying basic number theory
Try to show me wrong.
oh my fucking god bro... ur gunna double down on this??? classic rick...
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is a >>>>> _contradiction_
Right, WHEN YOU ENUMERATE THEM, and don't suffle them.
Your code keeps on updating the "set of machines" it is looking at,
each set of machines it looks at, for any given cycle, is _finite_,
as each cycle of the dovetailing algo is and must be _finite_ ...
you cannot create an uncountable set of sets using only finite length
sets of finite objects (like machines/natural number), richard
But the set your goal is trying to compute IS, and that is why you can
never produce it.
this is basic number theory
No, you are just showing why you can't count the uncountable infinity.
That exact same arguement occurs in any attempt to enumerate an
uncountable infinity, you always only have a finite set of things under
are you suggesting that we've diagonalized the set of all output sets, showing it to be an uncountable infinity?
consideration at the time, you just never get to anywhere near the end.
and _no_ just because each machine may produce an infinite set of
output does not turing this into an uncountable situation... like any
given computable sequence, the entire output set is equatable with
the /finite length/ machine that produced it, so therefor sets of
output sets will not produce countability issues anymore than sets of
the machines which produce them will
Because countable infinity can be counted.
bro, are you literally contradicting urself one sentence down by
agreeing that the set of all output sets is a countable infinity???
If we have an O(1) method of finding the "next" machine in sequence, we
this has nothing to do with big O and certainly does not need to be O(1) 🤣🤣🤣
can compute the number of steps needed to find the Kth digit of the
Nth number, and it will be finite.
Because YOUR method of computing the diagonal doesn't follow that
method, since your selecting isn't O(1), it turns out that to compute
how many steps it takes to do that same thing by our method is no
longer a bounded number and thus you haven't actually enumerated the
system.
huh this brings up another question in my mind:
can we enumerate _all_ the output from _all_ the machines???
which gets enough different sets to reach something of the same
cardinaltiy of the power set.
it.
Of course, uncountable infinities doen't follow the logic that you >>>>>> want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which
are bijectable with natural nubmers, form _uncountable
infinities_ ... that's a _contradiction_ dude!
Right, the MACHINES are bijectable, but you don't just simply
process them.
After all, the set of the mappings of the Natural Numbers to 0 or 1
is an uncountable set.
the set of *all* mappings sure, but not necessarily all subsets of
that, obviously...
Not ALL, but some. Your problem is you need to try to show that the
one you are working with isn't one of them, while I have shown it is
by the existance of anti-sloppier-H, which is a computable number not
in the set (that is defined to need to include it) if the subset you
are trying to generate wasn't.
the set of all computable mappings obviously isn't uncountable
Right, but that isn't the set you are working with.
uhhh... yes it is? i'm only working with the outputs of machines, and if
it was output by a machine obviously it was a computable mapping...
my god, this fucking group???
what the fuck are you all smoking???
IT seems YOU are the one smoking something, as you refuse to
understand the problems you are trying to just ignore.
Where do you get that from?
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that we >>>>> _cannot_ be able to prove machines produce an uncountable infinity ... >>>>
The point is that we can not in finite steps decide if a given
machine is circular or not,
And we can not produce a machine that computationally enumerates the
compuational numbers or the non-circular machines.
Where do you see him talking about anything about "countability".
literally the first sentence of §8:
| It may be thought that arguments which prove that the
| real numbers are not enumerable would also prove that
| the computable numbers and sequences cannot be enumerable
Which shows that he isn't using a counting arguement, because he is
showing that isn't applicable.
Note, you have to watch out on the meaning of the words, as Turing
uses "enumerable" here to mean what we now call effectively
enumerable, to mean an enumeration that is computable.
no, it is specifically mentioning "arguments which prove that real
numbers are not enumerable" which is a reference to cantor's
diagonlization argument proving real numbers aren't enumerable/countable
vs natural numbers
By THAT definition, the computable numbers are not enumerable, even
it's not by "THAT" definition. turing refers to "THAT" as "computability":
| In a recent paper Alonzo Church has introduced an idea of
| "effective calculability", which is equivalent to my "computability",
| but is very differently defined. Church also reaches similar
| conclusions about the Entscheidungsproblem. The proof of equivalence
| between "computability" and "effective calculability" is outlined in
| an appendix to the present paper
though they can by put into a bijection with the Natural Numbers, and
are thus a countable infinity.
the whole point of the H paradox was to prevent a diagonalization
proof on computable numbers that would show them to be not
enumerable, more commonly now known as uncountable ...
Which is a wrong statement as I just explained.
There are only a countable number of machines, and just by bi-jection
they must be enumerable by your definition, but that enumeration is
not what we now call effective, so isn't what Turing was calling
enumerable.
so you casually throwing uncountability in regards to computing a
_single set_ of machines is just mindbogglingly detached from even
turing's proof, which is crazy because ur trying to defend his proof
bro,
Because in his language, enumerating and being countable are different
things.
no they aren't
_and fucking nonsense like this is exactly why i'm pursuing this
research_
And the "fucking nonsense" is based on you just failing to learn what
things mean in their context.
the fucking tards that have been handling this thus far are
incredibly lacking in their critical thinking and coherency
faculties, and have now ended up attacking me with the very same
ideas turing was trying to keep from being applied to computable
numbers, _IN THE FIRST PLACE_
No, YOU lack the critical thinking ability to understand what is being
discussed, as you don't understand the need to understand the language
as it is being used.
The fact that your logic depends on the need to assume false
statements just shows how fucked up your brain is. Of course, you
don't see the falseness of the statements, as you just don't
understand what they actually mean because you don't understand the
language being used.
You blaim the great minds of being stupid because they aren't using
words the way you want them to be, but the way they were defined at
the time they wrote their papers.
While the sum of the number of steps needed to get to the Kth
output of anti-sloppier-H is finite, when you multiply each
element by the number of machines included by sloppier-H to
compute that, the sum doesn't converge, thus your "enumeration"
puts anti- sloppier-H at an uncountable value in the enumeration
even though the machine itself is circle-free.
It seems that is just all you can do, since you don't understand
It seems you have a fundamental problem about thinking through >>>>>>>>>> the requirements, as "requirements" are just optional ideas to >>>>>>>>>> you.
clearly being able to enumerate a set of machines, does _not_ >>>>>>>>>>> then imply one can certainly construct a diagonal across the >>>>>>>>>>> computable numbers within that set
Because the determination that a given machine create a
computable number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H >>>>>>>>> computation that i proposed
And it never reaches ALL the numbers, because it keeps on
pushing off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the >>>>>>>> diagonal, anti_sloppier_H doesn't need to figure out what its >>>>>>>> diagonal digit is.
And, it seems you don't understand what I was talking about. >>>>>>>>>>>>
Apparently you can't even understand the arguement, as "K" >>>>>>>>>>>> isn't a VALUE output, but the id number of the row being >>>>>>>>>>>> output, and the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, >>>>>>>>>>>> as sloppier_H can generate the diagonal, which means that >>>>>>>>>>>> anti_sloppier_H can't be in that enumeration, and thus >>>>>>>>>>>> anti_sloppier_H can't get "stuck" on it trying to get there. >>>>>>>>>>>>
For sloppier_H to work, the Kth row need to compute at least >>>>>>>>>>>> K digits, and thus any machine like turing's original H that >>>>>>>>>>>> looks to see what it does can't be on the diagonal.
You fix the issue for sloppier_H with your reference to a >>>>>>>>>>>> special number, but anti_sloppier_H won't do that, so >>>>>>>>>>>> sloppier_H will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self- >>>>>>>>>>>> reference" number as sloppier_H, NOT its own, and thus it >>>>>>>>>>>> WILL get the anti- diagonal that is the opposite of
sloppier_H, and won't get hung up on itself, since neither >>>>>>>>>>>> did sloppier_H get hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to >>>>>>>>>>>> follow instructions, possible because you are just mentally >>>>>>>>>>>> unable to do accurate work because "correct" isn't a word >>>>>>>>>>>> you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to
follow instructions because you are mentally unable to do >>>>>>>>>> accurate work becuae "correct" isn't a word you understand? >>>>>>>>>>
At least you know that you are that stupid, you just don't >>>>>>>>>> understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱 >>>>>>
how to do actual logic, but just want to use fallacies.
i'm sorry u fallacy wot now?
Your logic is just based on fallacies.
Things like assuming the conclusion, or ignoring the facts.
After all, you ARE proving you don't understand what a
requirement is.
this is exploring the bounds of theory mate, not engineering a
system
But, you forget that you need to actually PROVE what you claim.
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix,
you can not show that you compute "fast" enough to get to any
particuar machine, as there are an infinite number of machines
that can get to their kth output before this one, (even if they
eventually become circular and stop outputing).
Ultimately, the problem is that the sorting that your
"enumeration" is based on creates a super-set of the Natural
Numbers, which is uncountable, so you can't get to all the
elements of that set.
oh my god bro ... see you've gone down a fucking road bro. machines >>>>> _cannot_ produce an uncountable infinity. avoiding that was _why_
turing pursued proving the H paradox in the first place!
Right, they can not actually produce it, but if the algorith would
generate it they just will not finish.
yet here you are trying to shut my down by casually claiming
actually machines form uncountable infinities now???
SETS of machines can.
no, an infinite set of infinite sets of machines can be uncountable,
but just an infinite set of machines cannot be uncountable, richard
Right,
the set of computable numbers is _not_ uncountable
Right.
nothing here is trying to compute an uncountable set
Right, but computable is a proper subset of countable.
When we look at the space being examined by your computation, it is
looking at VARIOUS sets of machines. And this set that is built
INTERNALLY, if expaded to its definition, would be uncountable.
Thus, the EXTERNAL set of the problem might be countable, but the
INTERNAL space being examined goes uncountable, and thus the
comutation can't complete, even given countable infinite time.
no idea what you mean by INTERNALLY uncountable and EXTERNALLY countable
in regards to the any particular set of machines or their output...
u bringing up uncountablity is just u ramming in a pathetic excuse
for us failing to study this further for almost a century now...
And the problem is that if the path only generated a countable number
of possibilities, you could compute it.
what are you talking about??? there are only a countable number of
machines that could be added to the diagonal...
are you suggesting there is a uncountable subset of machines???
I guess your ignorance is approaching infinity.
_that was what turing was trying to avoiding in the first place_ !!!
No, he was pointing out that we can not get a result that depends on
an uncountable infinity.
I can easily write a program that "when it completes" would have
produced and uncountable infinite set, it just can't ever get that far. >>>>
The fact you don't understand this is part of your problem.
In other words, for you 1 = 2 is just a fact of life. >>>>>>>>>>>>>>
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that doesn't >>>>>>>>>>>>>> exist (like the diagonal of an enumeration that includes >>>>>>>>>>>>>> circular machines) so there isn't a diagonal to compute. >>>>>>>>>>>>>>
That is like the inability to compute an even prime >>>>>>>>>>>>>> greater than 2 doesn't affect our ability to compute other >>>>>>>>>>>>>> primes.
All you are doing is showing your ignorance and stupidity.\ >>>>>>>>>>>>>>>>
My guess is you are not going to actually answer with a >>>>>>>>>>>>>>>> real inconsistance, but just throw out a strawman, and >>>>>>>>>>>>>>>> that is your modus operandi.
On 4/3/26 8:42 PM, dart200 wrote:
On 4/3/26 7:25 AM, Richard Damon wrote:
On 4/2/26 11:19 PM, dart200 wrote:
On 4/2/26 4:43 PM, Richard Damon wrote:
On 4/2/26 12:52 PM, dart200 wrote:
why didn't all the computable numbers, which have an output for
_all_ K therefore allowing them to reach any diagonal of the
output total number matrix make it onto the computed diagonal???
As I said, because it spent too much time simulating circular
maxhines,
that is _not_ what is happening here,
Sure it is.
it's not richard
even if we ( _hypothetically_ ) started with a full enumeration of
_just_ computable numbers, so no time was "wasted", it still
wouldn't be able to produce the diagonal via dovetailing ...
But you aren't allowed to hypothisize about the impossible, except to
prove it impossible.
who's stopping me? you?? 🤣🤣🤣
This is the fatal fallacy in all your logic.
Of course if you start with a broken system where 1 == 0, you can
prove all sorts of nonsense. Your world is just one that has exploded
by the contradictions you assume are allowed.
what? richard, the _same_ problem manifests with trying to dovetail
_all_ machines as that with _just_ computable numbers ...
it has nothing to do with supposed impossibility of effectively
enumerating computable numbers, there's no connection ur just throwing
arguments at the wall in total denial
the _same_ problem would exist
(note that _particular_ problem wouldn't exist with RTMs)
Sure it would, you just are trying to define RTMs so that wrong
answers can be right.
which puts off the completion of the enumeration past the limits of >>>>> finiteness.
It dies getting stuck in its strawmen,
but computable numbers should all have outputs to put on the
diagonal, yet we cannot compute that,
Yes, but apparently anti-sloppier-H isn't there.
yes, paradoxically so ...
So you AGREE that it is mising.
Since anti-sloppier-H and sloppier-H are circularity equivalent,
that means either sloppier-H misses a computational number, or it
is circular and doesn't actually compute the full diagonal.
this doesn't require specifically selection for them, they
should have outputs regardless of whether we select for them, >>>>>>>> and that should be the outcome of simulating them
But unfortunately doesn't actually work, as it keeps pushing off >>>>>>> anti- sloppier-H, which while actually computable, beomes to
"slow" to reach the top of the list.
at least u understand the problem here
Yes, I do.
But apparently you don't, because you don't actually understand the >>>>> requirements.
therefore, regardless of whether we can enumerate a set of
computable numbers or not, they cannot all be computably put on >>>>>>>> a diagonal
But, you don't haven't enumerated the complete set of computable >>>>>>> numbers, and a diagonal of it, as anti-sloppier-H outputs its Kth >>>>>>> digits in a finite number of steps if sloppier-H outputs its Kth >>>>>>> digit in a finite number of steps, so both are generating
computable numbers or not together, but anti-sloppier-H isn't in >>>>>>> your enumeration.
the question is: are u able to admit this is a problem? or just
continually accept the paradoxical as valid because ur already so >>>>>> used to promoting the current consensus as valid?
It is a RESOLVED problem, because your enumeration just isn't
complete.
IT is YOU that can't see the actual problem, because you are just
ignorant of the basics of the theory you are trying to talk about.
Your problem is you just assume you understand what you machine
does, because you apparently don't understand how to handle things
that can be infinite, because you like to assume they just do what
you want.
the answer is: not yet apparently
And that is the problem, you don't understand the basics of logic,
and thus everything you do is just based on assuming the absurd.
if i were talking to someone capable of doing more than
upholding a bandwagon this would be an interesting fact
But not a fact, as it has a flaw in that you assume rules that
apply to finite sets apply to infinite sets.
the property i'm really banking on is their countability vs being >>>>>> uncountable
But since you get into the power-set (but letting your machine
resort them by length of running time) you get into the uncountable. >>>>>
Again, your problem is you don't understand about infinity.
Sloppier_H computes enough from the circular machines to need an
uncountable number of steps to complete, and thus the diagonal as
*infinite not uncountable... the steps of any actual computation are
necessarily countable,
And NEVER reaches its stated goal, even in that contable infinite
number of steps.
bro, if u think we've diagonalized _all_ machines and demonstrated an
uncountable infinite being involved ....
_that is exactly what turing was trying to prevent in §8_
and circular machine do not impede dovetailing algo, that is a
bizarre response and and just forgetful of the fact circular
machines also do not impede using dovetailing to enumerate out
halting machines
Sure they do, as they push off the time needed to simulate the non-
circulare machines until it never happens.
no, anti_sloppier_H is defined to only produce an output for some K
*after* sloppier_H produces an output for that K. even if
anti_sloppier_H skipped everything but computable sequences,
anti_sloppier_H still could never produce some K *after* sloppier_H
does...
described isn't a computable number, only the diagonal of the
PARTIAL enumeration of the machine that it gets to the output of is. >>>>>
Thus, your diagonal is just another of your Unicorns.
doesn't exist, as if you try to generate the grid of running >>>>>>>>>>> all machines as enumerated doesh't always reach the diagonal. >>>>>>>>>>that's fine, the sloppier_H diagonal does not care...
Sure it does, because otherwise it isn't a diagonal.
but all the computable numbers _should_ reach the diagonal, >>>>>>>>>> because they _all_ produce an infinite sequence...
Right, and that diagonal never include the results of the
properly built anti_sloppier_H.
Remember, anti_sloppier_H is exactly the same code as
sloppier_H (including the number checked) except it outputs the >>>>>>>>> reversed digit.
Thus, if sloppier_H continues to run and produce output, so >>>>>>>>> does anti_sloppier_H
so they _should_ end up on the attempted diagonal computation, >>>>>>>>>> given we're simulating all of them in parallel, but that can't >>>>>>>>>> happen
Right, but it misses some, like anti_sloppier_H.
which means the fact some are missed is an independent facet of >>>>>>>> the enumeration
But, then the enumeration CAN'T BE COMPLETE.
the enumeration is it produced from _IS COMPLETE_
No it isn't.
The enumeratio of MACHINES that it starts from is complete.
yes it starts with a full enumeration of all machines, including all
computable numbers, and is still unable to produce a diagonal that
includes all computable numbers despite them all having enough
digits to be on the diagonal
Because determining which machines are non-circular is non-
computatable, in it spends too much time simulating machines that
will never produce a result.
...this doesn't decide what machines are non-circular, as it will mix
in circular machines onto the diagonal...
ur just making up wild claims rick
The problem is that if a given non-circular machine (m) takes N(k)
steps to compute its kth digit, it won't be used to simulate that
digit for output unless there are less than k machines in process
that have reached that point in the m+N(k) machines that are in the
running.
There exists enough circular machines fast enough, and some non-
circular machines slow enough, that the non-circular machine never
gets output.
Try to prove otherwise!
no, anti_sloppier_H is defined to only produce an output for some K
*after* sloppier_H produces an output for that K. even if
anti_sloppier_H skipped everything but computable sequences,
anti_sloppier_H still could never produce some K *after* sloppier_H
does...
After all, I have shown a machine that is in that situtation, at
least if your sloppier-H actually produces a computable number
becausse it is non-circular (my anti-sloppier-H). It produces its
k'th digit in exactly the same number of steps as the sloppier-H it
was modeled after, but
no richard, for each cycle it must simulate all of sloppier_H + extra
steps for anti_sloppier_H
clearly never gets output, because it is always beaten to the line by
other machines.
The enumeration that the diagonal is defined to be computed of is
not, as you claim it need to get to a machine for every computable
number.
We can PRODUCE such a diagonal, but not computationally.
The problem is that the progress that sloppier-H makes gets
slower and slower as the infinite number of circular machines get >>>>>>> added to the set of machines being simulated to find the one that >>>>>>> makes the next digit, and thus the number of steps that sloppier- >>>>>>> H needs to perform grows, and that sum becomes a divergent sum
that doesn't converge, and thus it never actually gets to anti- >>>>>>> sloppier-H.
i'm aware of the problem that given an enumeration which certainly >>>>>> includes _all_ computable sequences, we cannot seem to actually
form a diagonal with that which includes _all_ computable sequences >>>>>
if u can't write me down the diagonal, i can't agree u "PRODUCED" it
Then you dom't understand what the words mean and how the axiom of
choice works.
that's fine. u keep boasting about producing something that results in
no actual product and i'll just keep staring blankly at how stupid a
claim that is
Since the diagonal in infinite in length, it can't be written down,
so to you logic, it can't exist.
you can't write down any amount of it, as u have no method to
therefor even if given an enumeration which includes _only_ _all_ >>>>>> computable numbers, we should not expect to be able to use that to >>>>>> produce a diagonal which includes _all_ computable sequences...
What are you considering the difference between a "Computable
Number" and a "Computable Sequence"?
| A sequence is said to be computable if it can be computed
| by a circle-free machine. A number is computable if it
| differs by an integer from the number computed by a
| circle-free machine
Where do you get that definition of a computable number, that it
DIFFERS from a number computed by a circle-free machine?
the same source i always quote: /on computable numbers/ richard
He says earlier that:
According to my definition, a number is computable if its decimal can be written down by a machine.
and:
We have said that the computable numbers are those whose decimals are calculable by finite means.
and:
Some of the symbols written down will form the sequence of figures which
is the decimal of the real number which is being computed.
and:
The real number whose expression as a binary decimal is
obtained by prefacing this sequence by a decimal point is called the
number computed by the machine.
All of these show that he means that what he is talking about as a computable number is a numbers whose representation can be generated as
a computable sequence.
He seems to be refering to the idea her that if 0.abcdefghighklmopqurstuvwxyz... is a computable number from directly interpreting a computable sequence then 1.abcdefghighklmopqurstuvwxyz...
and 2.abcdefghighklmopqurstuvwxyz... and so on would also be computable numbers.
Thus, we can split a "computable numbers" into a finite length integer
part and then an infinite length fractional part.
Thus, a set of all computable numbers WILL include all computable
sequences (many times) as the fractional part of all the numbers.
Note, we can PRODUCE an enumeration of all computable numbers,
under the
u can "DEFINE" it i guess, i can't agree u can actually PRODUCE it
as show me a production of it ... as u can't actually write it down
without a method to compute it
Which shows the hole in your logic.
what hole is that?
You dpn't understand what the words mean. Production doesn't mean
writing, as in fact, you can't write ANY of the computable numbers, as
they are BY DEFINITION infinitely long.
i'm pretty whatever about the axiom of choice
It seems you are pretty "whatever" abput logical thinking in general.
axiom of choice, but we can not GIVE that to a machine, as that
enumeration isn't finite or computable,
no?
superset??? to create this we enumerated out and simulate _all_
And without all the numbers, it isn't COMPLETE, and thus
uninteresting.
not all machines even produce output, so ofc trying to compute a >>>>>>>> diagonal across all machines can include all machines ...
Right, which is why we CAN compute an enumeration of all machines >>>>>>> but not the diagonal generated by them.
but all computable numbers do have outputs for all K, so they >>>>>>>> should be includable in attempting to compute a diagonal across >>>>>>>> all machines
The problem is that you are NOT making an enumeration of ALL
machines, but only machines that reach the diagonal when sorted >>>>>>> by your criteria.
Where we sort the machines this way, we create a super-set of the >>>>>>
machine, there is _no_ superset of that (which consists of only
machines)...
Sure there is, as you keep on changing the ORDER of the machines as >>>>> you investigate.
machines, and thus get to an uncountable infinity, so we can't
enumerate
BRO, what are you talking about???
You don't understand an uncountable infinity?
honestly bro u just fucking backing urself into a corner by
completely misapplying basic number theory
Try to show me wrong.
oh my fucking god bro... ur gunna double down on this??? classic rick...
So, you admit you can't.
Your problem is you just don't understand how logic work.
machine enumeration _ONLY_ form countable infinities, forming an
uncountable infinity with machines is diagonalizing them which is >>>>>> a _contradiction_
Right, WHEN YOU ENUMERATE THEM, and don't suffle them.
Your code keeps on updating the "set of machines" it is looking at,
each set of machines it looks at, for any given cycle, is _finite_,
as each cycle of the dovetailing algo is and must be _finite_ ...
you cannot create an uncountable set of sets using only finite
length sets of finite objects (like machines/natural number), richard
But the set your goal is trying to compute IS, and that is why you
can never produce it.
this is basic number theory
No, you are just showing why you can't count the uncountable infinity.
That exact same arguement occurs in any attempt to enumerate an
uncountable infinity, you always only have a finite set of things under
are you suggesting that we've diagonalized the set of all output sets,
showing it to be an uncountable infinity?
No, the problem is that to talk about the "diagonal" you have to talk
about what it is the diagonal OF, and if you try to say that the listing includes ALL computable numbers, you are wrong.
You can claim to write a program that enumerate all real numbers using
some pattern, and try to claim that it WILL eventually reach all
thenumbers, even though it is an uncountable infinity, and your machine might continue to spit out digits, so by your argument the reals are countable.
The problem is that for an actual computable enumeration, we can pick
ANY member of the list, and find the FINITE value which is the position
in the enumeration, but you can't do that with yours.
The problem with the enumeration that sloppier_H works on that value
can't be computed except by finding your machine in the list.
consideration at the time, you just never get to anywhere near the end.
and _no_ just because each machine may produce an infinite set of
output does not turing this into an uncountable situation... like
any given computable sequence, the entire output set is equatable
with the /finite length/ machine that produced it, so therefor sets
of output sets will not produce countability issues anymore than
sets of the machines which produce them will
Because countable infinity can be counted.
bro, are you literally contradicting urself one sentence down by
agreeing that the set of all output sets is a countable infinity???
What is the contradiction?
When we COUNT (and not via computing) we can use the axiom of chioce to generate the list, and then count them.
When we try to effectively enumerate them, we need to computationally
find each element, which takes too long.
You don't seem to understand the difference between Countable, and computable, which is like the difference between the moderen definition
of enumerate, and effectively enumerate.
If we have an O(1) method of finding the "next" machine in sequence, we
this has nothing to do with big O and certainly does not need to be
O(1) 🤣🤣🤣
Sure it does, but somewhat indirectly. The problem is that when we are
dealing with infinite output, a method based on an O(1) algorithm for enumeration might converge, while slower methods might not.
can compute the number of steps needed to find the Kth digit of the
Nth number, and it will be finite.
Because YOUR method of computing the diagonal doesn't follow that
method, since your selecting isn't O(1), it turns out that to compute
how many steps it takes to do that same thing by our method is no
longer a bounded number and thus you haven't actually enumerated the
system.
huh this brings up another question in my mind:
can we enumerate _all_ the output from _all_ the machines???
Nope. The problem is while we can effectively enumerate all the
machines, we can not effective compute the kth digit output by an
arbitrary machine, as it might not get that far (if it becomes
circular), and we can't universally determine that fact.
And you can't use your intertwining system, as that would fix the order
of the enumeration as soon as you start to output a given machine, and
thus you can't delay it later. And, you can't hold off until a given
machine "finishes" as this class of machine never "finishes" but just continually outputs numbers.
which gets enough different sets to reach something of the same
cardinaltiy of the power set.
it.
Of course, uncountable infinities doen't follow the logic that
you want to try to think with.
BRO, LOOK WHAT UR WRITING!
you've gone off the fucking deep end claiming that machines, which >>>>>> are bijectable with natural nubmers, form _uncountable
infinities_ ... that's a _contradiction_ dude!
Right, the MACHINES are bijectable, but you don't just simply
process them.
After all, the set of the mappings of the Natural Numbers to 0 or 1 >>>>> is an uncountable set.
the set of *all* mappings sure, but not necessarily all subsets of
that, obviously...
Not ALL, but some. Your problem is you need to try to show that the
one you are working with isn't one of them, while I have shown it is
by the existance of anti-sloppier-H, which is a computable number not
in the set (that is defined to need to include it) if the subset you
are trying to generate wasn't.
the set of all computable mappings obviously isn't uncountable
Right, but that isn't the set you are working with.
uhhh... yes it is? i'm only working with the outputs of machines, and
if it was output by a machine obviously it was a computable mapping...
But you said your defined set included ALL computable numbers, but your actual set doesn't.
If you admit that your set doesn't include all computable numbers, it is
no longer actually related to the problem of effectively enumerating the computable numbers.
my god, this fucking group???
what the fuck are you all smoking???
IT seems YOU are the one smoking something, as you refuse to
understand the problems you are trying to just ignore.
why are others just letting u making wild-ass claims like that???
... the whole _point_ of §8 from /on computable numbers/ is that >>>>>> we _cannot_ be able to prove machines produce an uncountable
infinity ...
Where do you get that from?
The point is that we can not in finite steps decide if a given
machine is circular or not,
And we can not produce a machine that computationally enumerates
the compuational numbers or the non-circular machines.
Where do you see him talking about anything about "countability".
literally the first sentence of §8:
| It may be thought that arguments which prove that the
| real numbers are not enumerable would also prove that
| the computable numbers and sequences cannot be enumerable
Which shows that he isn't using a counting arguement, because he is
showing that isn't applicable.
Note, you have to watch out on the meaning of the words, as Turing
uses "enumerable" here to mean what we now call effectively
enumerable, to mean an enumeration that is computable.
no, it is specifically mentioning "arguments which prove that real
numbers are not enumerable" which is a reference to cantor's
diagonlization argument proving real numbers aren't enumerable/
countable vs natural numbers
Yes, sometimes he uses it that way, but he also uses it with (sometimes implied) qualification by terms like "by finite means" or similar words,
and it is THIS version that he points can't be done.
By THAT definition, the computable numbers are not enumerable, even
it's not by "THAT" definition. turing refers to "THAT" as
"computability":
| In a recent paper Alonzo Church has introduced an idea of
| "effective calculability", which is equivalent to my "computability", >> | but is very differently defined. Church also reaches similar
| conclusions about the Entscheidungsproblem. The proof of equivalence >> | between "computability" and "effective calculability" is outlined in >> | an appendix to the present paper
But then he talks about:
It would be true if we could enumerate the computable sequences by
finite means,
(In talking about how to compute the diagonal from the enumeration)
Note, he points out that the computable numbers *ARE* "enumerable" but
not enumeratable by finite means, and in the rest of the paper he is
talking about this, computing such an enumeration by "finite means" (or equivalently by a program)
So, he never says that the computable numbers can't be "enumerated" in
the general sense, only that they can't be enumerated by finite means,
which allows for the diagonal to not be computable.
though they can by put into a bijection with the Natural Numbers, and
are thus a countable infinity.
the whole point of the H paradox was to prevent a diagonalization
proof on computable numbers that would show them to be not
enumerable, more commonly now known as uncountable ...
Which is a wrong statement as I just explained.
There are only a countable number of machines, and just by bi-jection
they must be enumerable by your definition, but that enumeration is
not what we now call effective, so isn't what Turing was calling
enumerable.
so you casually throwing uncountability in regards to computing a
_single set_ of machines is just mindbogglingly detached from even
turing's proof, which is crazy because ur trying to defend his proof
bro,
Because in his language, enumerating and being countable are
different things.
no they aren't
They are when the implication is by finite means, or by a program.
_and fucking nonsense like this is exactly why i'm pursuing this
research_
And the "fucking nonsense" is based on you just failing to learn what
things mean in their context.
the fucking tards that have been handling this thus far are
incredibly lacking in their critical thinking and coherency
faculties, and have now ended up attacking me with the very same
ideas turing was trying to keep from being applied to computable
numbers, _IN THE FIRST PLACE_
No, YOU lack the critical thinking ability to understand what is
being discussed, as you don't understand the need to understand the
language as it is being used.
The fact that your logic depends on the need to assume false
statements just shows how fucked up your brain is. Of course, you
don't see the falseness of the statements, as you just don't
understand what they actually mean because you don't understand the
language being used.
You blaim the great minds of being stupid because they aren't using
words the way you want them to be, but the way they were defined at
the time they wrote their papers.
While the sum of the number of steps needed to get to the Kth
output of anti-sloppier-H is finite, when you multiply each
element by the number of machines included by sloppier-H to
compute that, the sum doesn't converge, thus your "enumeration" >>>>>>> puts anti- sloppier-H at an uncountable value in the enumeration >>>>>>> even though the machine itself is circle-free.
It seems that is just all you can do, since you don't understand >>>>>>> how to do actual logic, but just want to use fallacies.
It seems you have a fundamental problem about thinking
through the requirements, as "requirements" are just optional >>>>>>>>>>> ideas to you.
clearly being able to enumerate a set of machines, does >>>>>>>>>>>> _not_ then imply one can certainly construct a diagonal >>>>>>>>>>>> across the computable numbers within that set
Because the determination that a given machine create a >>>>>>>>>>> computable number is an uncomputable operation.
What is so hard about that?
that determination is _still_ not involved with the sloppier_H >>>>>>>>>> computation that i proposed
And it never reaches ALL the numbers, because it keeps on
pushing off when to get to anti_sloppier_H.
Since sloppier_H never puts a digit of anti_sloppier_H on the >>>>>>>>> diagonal, anti_sloppier_H doesn't need to figure out what its >>>>>>>>> diagonal digit is.
And, it seems you don't understand what I was talking about. >>>>>>>>>>>>>
Apparently you can't even understand the arguement, as "K" >>>>>>>>>>>>> isn't a VALUE output, but the id number of the row being >>>>>>>>>>>>> output, and the digit on that row being outputed.
Your just implied that every row makes it to the diagonal, >>>>>>>>>>>>> as sloppier_H can generate the diagonal, which means that >>>>>>>>>>>>> anti_sloppier_H can't be in that enumeration, and thus >>>>>>>>>>>>> anti_sloppier_H can't get "stuck" on it trying to get there. >>>>>>>>>>>>>
For sloppier_H to work, the Kth row need to compute at >>>>>>>>>>>>> least K digits, and thus any machine like turing's original >>>>>>>>>>>>> H that looks to see what it does can't be on the diagonal. >>>>>>>>>>>>>
You fix the issue for sloppier_H with your reference to a >>>>>>>>>>>>> special number, but anti_sloppier_H won't do that, so >>>>>>>>>>>>> sloppier_H will never put it on the diagonal
Remember, anti_sloppier_H uses the same "special self- >>>>>>>>>>>>> reference" number as sloppier_H, NOT its own, and thus it >>>>>>>>>>>>> WILL get the anti- diagonal that is the opposite of >>>>>>>>>>>>> sloppier_H, and won't get hung up on itself, since neither >>>>>>>>>>>>> did sloppier_H get hung up on anti_sloppier_H.
Otherwise, you are just showing that you just refuse to >>>>>>>>>>>>> follow instructions, possible because you are just mentally >>>>>>>>>>>>> unable to do accurate work because "correct" isn't a word >>>>>>>>>>>>> you understand.
y do u think i disagree with any of that?
So, you agree with the statement that you just refuse to >>>>>>>>>>> follow instructions because you are mentally unable to do >>>>>>>>>>> accurate work becuae "correct" isn't a word you understand? >>>>>>>>>>>
At least you know that you are that stupid, you just don't >>>>>>>>>>> understand what that impies.
lol, talk about bad faith discussion dick
But you agreed to it, at least in implication.
Or, are you just admitting you are just a liar.
my god dick, what is with the endless childish word games 🥱🥱🥱 >>>>>>>
i'm sorry u fallacy wot now?
Your logic is just based on fallacies.
Things like assuming the conclusion, or ignoring the facts.
After all, you ARE proving you don't understand what a
requirement is.
this is exploring the bounds of theory mate, not engineering a >>>>>>>> system
But, you forget that you need to actually PROVE what you claim.
Try to prove that your enumeration is complete.
Because machines that are eventually circular get into your mix, >>>>>>> you can not show that you compute "fast" enough to get to any
particuar machine, as there are an infinite number of machines
that can get to their kth output before this one, (even if they >>>>>>> eventually become circular and stop outputing).
Ultimately, the problem is that the sorting that your
"enumeration" is based on creates a super-set of the Natural
Numbers, which is uncountable, so you can't get to all the
elements of that set.
oh my god bro ... see you've gone down a fucking road bro.
machines _cannot_ produce an uncountable infinity. avoiding that
was _why_ turing pursued proving the H paradox in the first place!
Right, they can not actually produce it, but if the algorith would
generate it they just will not finish.
yet here you are trying to shut my down by casually claiming
actually machines form uncountable infinities now???
SETS of machines can.
no, an infinite set of infinite sets of machines can be uncountable,
but just an infinite set of machines cannot be uncountable, richard
Right,
the set of computable numbers is _not_ uncountable
Right.
nothing here is trying to compute an uncountable set
Right, but computable is a proper subset of countable.
When we look at the space being examined by your computation, it is
looking at VARIOUS sets of machines. And this set that is built
INTERNALLY, if expaded to its definition, would be uncountable.
Thus, the EXTERNAL set of the problem might be countable, but the
INTERNAL space being examined goes uncountable, and thus the
comutation can't complete, even given countable infinite time.
no idea what you mean by INTERNALLY uncountable and EXTERNALLY
countable in regards to the any particular set of machines or their
output...
The set of machines in the definition of the program is a countable
infinite set.
But, in the processing of that set, the program tries to compute results based on different assortments of these sets, and in doing so, creates
an uncountable subset of the power-set of that set.
This happens in your program as there is no upper bound to the number machines that are being simulated in parrallel to a given machine, not
even as a function of a given machines number, or the digit number being looked at.
u bringing up uncountablity is just u ramming in a pathetic excuse
for us failing to study this further for almost a century now...
And the problem is that if the path only generated a countable number
of possibilities, you could compute it.
what are you talking about??? there are only a countable number of
machines that could be added to the diagonal...
Right, but since for each digit produced, there isn't a bound for the
number of steps needed to compute it, the number of steps needed to "compute" the results is unbounded, and thus the results are not
computable.
Bounded * countable infinite -> countable infinite
Unbounded * countable infinite -> uncountable infinite.
are you suggesting there is a uncountable subset of machines???
YES.
The power-set, the set of all possible subsets of the machines, is uncountable.
There are sub-sets of that power-set that are also uncountable.
Since, to evaluate each digit of the results can require an unbounded
number of machines to be looked at to get that digit, you end up needing
to evaluate an uncountable number of subsets of machines, which makes
your result take uncountable number of steps, and thus not actually computable.
Your problem is you aren't looking at *A* subset of machines, but a set
of subsets of machines, and THAT can be uncountable in number.
I guess your ignorance is approaching infinity.
No, he was pointing out that we can not get a result that depends
_that was what turing was trying to avoiding in the first place_ !!! >>>>>
on an uncountable infinity.
I can easily write a program that "when it completes" would have
produced and uncountable infinite set, it just can't ever get that
far.
The fact you don't understand this is part of your problem.
In other words, for you 1 = 2 is just a fact of life. >>>>>>>>>>>>>>>
You need to stop smoking your fairy dust.
Its ok to not to be able to compute something that >>>>>>>>>>>>>>> doesn't exist (like the diagonal of an enumeration that >>>>>>>>>>>>>>> includes circular machines) so there isn't a diagonal to >>>>>>>>>>>>>>> compute.
That is like the inability to compute an even prime >>>>>>>>>>>>>>> greater than 2 doesn't affect our ability to compute >>>>>>>>>>>>>>> other primes.
All you are doing is showing your ignorance and >>>>>>>>>>>>>>>>> stupidity.\
My guess is you are not going to actually answer with a >>>>>>>>>>>>>>>>> real inconsistance, but just throw out a strawman, and >>>>>>>>>>>>>>>>> that is your modus operandi.
On 4/3/26 7:08 PM, Richard Damon wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last digit of
pi. Never know.
On 4/4/26 2:55 PM, Chris M. Thomasson wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last digit
of pi. Never know.
posting insults, but refusing to listen to them back
On 4/4/26 9:04 PM, dart200 wrote:
On 4/4/26 2:55 PM, Chris M. Thomasson wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last digit
of pi. Never know.
posting insults, but refusing to listen to them back
Yep, that's you.
On 4/11/26 9:50 AM, Richard Damon wrote:
On 4/4/26 9:04 PM, dart200 wrote:
On 4/4/26 2:55 PM, Chris M. Thomasson wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last
digit of pi. Never know.
posting insults, but refusing to listen to them back
Yep, that's you.
no it's not, i read everything u write dick,
i just don't agree
completely different than blocking you
On 4/11/26 8:03 PM, dart200 wrote:
On 4/11/26 9:50 AM, Richard Damon wrote:
On 4/4/26 9:04 PM, dart200 wrote:
On 4/4/26 2:55 PM, Chris M. Thomasson wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last
digit of pi. Never know.
posting insults, but refusing to listen to them back
Yep, that's you.
no it's not, i read everything u write dick,
i just don't agree
completely different than blocking you
But you can't answer the question back, so you just ignore the statements.
If you actually listened, you would justify your statements when the
error is pointed out,
That, or you are just agreeing that you are actually as stupid and being
an ignorant liar as is being pointed out.
Sorry, but you live in a world of fantasy, and the neglect of reality.
On 4/11/26 8:10 PM, Richard Damon wrote:
On 4/11/26 8:03 PM, dart200 wrote:
On 4/11/26 9:50 AM, Richard Damon wrote:
On 4/4/26 9:04 PM, dart200 wrote:
On 4/4/26 2:55 PM, Chris M. Thomasson wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last
digit of pi. Never know.
posting insults, but refusing to listen to them back
Yep, that's you.
no it's not, i read everything u write dick,
i just don't agree
completely different than blocking you
But you can't answer the question back, so you just ignore the
statements.
If you actually listened, you would justify your statements when the
error is pointed out,
That, or you are just agreeing that you are actually as stupid and
being an ignorant liar as is being pointed out.
Sorry, but you live in a world of fantasy, and the neglect of reality.
i'm sorry that debunking a 100 year old consensus is a lot harder than
just supporting it
On 4/12/26 12:19 AM, dart200 wrote:
On 4/11/26 8:10 PM, Richard Damon wrote:
On 4/11/26 8:03 PM, dart200 wrote:
On 4/11/26 9:50 AM, Richard Damon wrote:
On 4/4/26 9:04 PM, dart200 wrote:
On 4/4/26 2:55 PM, Chris M. Thomasson wrote:
On 4/3/26 7:08 PM, Richard Damon wrote:
[...]
You are conversing with a special type of Olcott.
Keep that in mind.
It might even be one of those people that think there is a last >>>>>>> digit of pi. Never know.
posting insults, but refusing to listen to them back
Yep, that's you.
no it's not, i read everything u write dick,
i just don't agree
completely different than blocking you
But you can't answer the question back, so you just ignore the
statements.
If you actually listened, you would justify your statements when the
error is pointed out,
That, or you are just agreeing that you are actually as stupid and
being an ignorant liar as is being pointed out.
Sorry, but you live in a world of fantasy, and the neglect of reality.
i'm sorry that debunking a 100 year old consensus is a lot harder than
just supporting it
Yes, a LOT harder, as in IMPOSSIBLE.
Your CLAIMING to be doing so just shows your utter insanity, and stupidity.
Remember, YOU are the one claiming to have something, but can't actually show anything, because your work is just riddeled with mistakes.
Claiming a work that is riddled with errors is an easy task if you allow yourself to ignore those errors.
If you want to claim you are doing a hard task, you need to acknowled
and deal with those errors, not just use Olcottian logic and shuffle
words to try to sweep them under the rug.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,114 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492511:58:46 |
| Calls: | 14,267 |
| Calls today: | 3 |
| Files: | 186,320 |
| D/L today: |
26,243 files (8,505M bytes) |
| Messages: | 2,518,394 |