Liste des Groupes | Revenir à s logic |
On 03/12/2024 07:52 PM, olcott wrote:What I'm saying is that you'd need to solve allOn 3/12/2024 9:28 PM, Richard Damon wrote:>On 3/12/24 4:31 PM, olcott wrote:>On 3/12/2024 6:11 PM, Richard Damon wrote:>On 3/12/24 3:53 PM, olcott wrote:>On 3/12/2024 5:30 PM, Richard Damon wrote:>On 3/12/24 2:34 PM, olcott wrote:∀ H ∈ Turing_Machines_Returning_BooleanOn 3/12/2024 4:23 PM, Richard Damon wrote:>On 3/12/24 1:11 PM, olcott wrote:>On 3/12/2024 2:40 PM, Richard Damon wrote:>On 3/12/24 12:02 PM, olcott wrote:>On 3/12/2024 1:31 PM, immibis wrote:>On 12/03/24 19:12, olcott wrote:>∀ H ∈ Turing_Machine_Deciders>
∃ TMD ∈ Turing_Machine_Descriptions |
Predicted_Behavior(H, TMD) != Actual_Behavior(TMD)
>
There is some input TMD to every H such that
Predicted_Behavior(H, TMD) != Actual_Behavior(TMD)
And it can be a different TMD to each H.
>When we disallow decider/input pairs that are incorrect>
questions where both YES and NO are the wrong answer
Once we understand that either YES or NO is the right
answer, the whole rebuttal is tossed out as invalid and
incorrect.
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does
not halt
BOTH YES AND NO ARE THE WRONG ANSWER FOR EVERY Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
No, because a given H will only go to one of the answers. THAT
will be wrong, and the other one right.
>
∀ H ∈ Turing_Machine_Deciders
∃ TMD ∈ Turing_Machine_Descriptions |
Predicted_Behavior(H, TMD) != Actual_Behavior(TMD)
>
Not exactly. A pair of otherwise identical machines that
(that are contained within the above specified set)
only differ by return value will both be wrong on the
same pathological input.
You mean a pair of DIFFERENT machines. Any difference is
different.
Every decider/input pair (referenced in the above set) has a
corresponding decider/input pair that only differs by the return
value of its decider.
Nope.
>
∃ TMD ∈ Turing_Machine_Descriptions |
Predicted_Behavior(H, TMD) != Actual_Behavior(TMD)
>
Every H/TMD pair (referenced in the above set) has a
corresponding H/TMD pair that only differs by the return
value of its Boolean_TM.
That isn't in the set above.
>>Nope, since both aren't in the set selected.
That both of these H/TMD pairs get the wrong answer proves that
their question was incorrect because the opposite answer to the
same question is also proven to be incorrect.
>
>
>
When they are deciders that must get the correct answer both
of them are not in the set.
*IF* they are correct decider.
>
WHen we select from all Turing Machine Deciders, there is no
requirement that any of them get any particular answer right.
>
So, ALL deciders are in the set that we cycle through and apply the
following logic to ALL of them.
>
Each is them paired with an input that it will get wrong, and the
existance of the input was what as just proven, the ^ template
>>>
When they are Turing_Machines_Returning_Boolean the this
set inherently includes identical pairs that only differ
by return value.
But in the step of select and input that they will get wrong, they
will be givne DIFFERENT inputs.
>>>You just don't understand what that statement is saying.No the problem is that you are not paying attention.
>
I've expalined it, but it seems over you head.
>
No, you keep on making STUPID mistakes, like thinking that select a
input that the machine will get wrong needs to be the same for two
differnt machines.
>
>
>>>For Every H, we show we can find at least one input (chosen just forWhen we use machine templates then we can see instances of
that machine) that it will get wrong.
>
the same machine that only differs by return value where both
get the wrong answer on the same input. By same input I mean
the same finite string of numerical values.
>
But if they returned differnt values, they will have different
descriptions.
>
Otherwise, how could a UTM get the right answer, since it only gets
the description.
We can get around all of this stuff by simply using this criteria:
Date 10/13/2022 11:29:23 AM
*MIT Professor Michael Sipser agreed this verbatim paragraph is correct*
(He has neither reviewed nor agreed to anything else in this paper)
(a) If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then
(b) H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
>
*When we apply this criteria* (elaborated above)
Will you halt if you never abort your simulation?
*Then the halting problem is conquered*
>
When two different machines implementing this criteria
get different results from identical inputs then we
know that Pathological Self-Reference has been detected.
>
We don't even need to know that for:
*denial-of-service-attack detection*
*NO always means reject as unsafe*
>
But, Halting theorem never said "there's an input that halts
all machines", it just says "for any machine, there's an input
that halts it".
>
Where "halt the machine" means "put it in an infinite loop".
>
So, rather, Halting theorem never said "there's an input that
exhausts all machines", it just says, "for any machine, there's
an input that exhausts it".
>
I still don't see how that would be with infinite tapes though,
without a means of checking all the way right the tape in one
step, i.e. that it's 1's or 0's or any pattern at all, any
input that unbounded with respect to the machine basically
exhausts it or where the machine would run in the unbounded.
>
>
Of course any finite tape, has a static analysis that is
not infinite, that decides whether or not it halts
(or, loops, or grows, the state space of the decider).
>
Static analysis has to either enumerate or _infer_ the
state-space, where equal values in what's determined
the idempotent can detect loops, while inequalities
or proven divergence, ..., can detect unbounded growth.
>
Now, proving convergence or divergence is its own kind
of thing. For example, there are series that converge
very slowly, and series that diverge very slowly. These
are subtly intractable to analysis.
>
Then the usual idea of progressions that rapidly grow
yet return to what's detectable, are pathological to
analysis, only in resources not correctness or completion,
vis-a-vis the subtle intractability of the convergence or
divergence what either halts, or loops, or grows unboundedly.
>
Separately "not-halts" into "loops or grows unboundedly",
has that really for most matters of interest of understanding
the state-space of programs, is "halts or enters loops"
and not "grows unboundedly".
>
I.e. if the Halting problem is basically subject the
subtle intractability of slow convergence, that otherwise
it can just infer divergence and decide, practically
it's sort of more relevant what the machine would be
doing on the input on the tape, then with respect to
beyond the Turing theory, of the state of the read-head,
what happens when somebody modifies the tape, or events,
the write-head.
>
Anyways though for bounded inputs, besides slow divergence,
it's to be made clear that _most all_ and _almost all_
programs _are_ decided their behavior by static analysis.
>
Though, "most all" and "almost all" might be a bit strong,
but pretty much all that don't involve "the subtle intractability
of slow divergence".
>
>
>
Giving the idea that an existence result
is in any way the expected result here
seems sort of the root of this dilem-na.
>
>
>
>
>
>
(Though that the real numbers in ZFC have a well-ordering
and if they had a normal ordering that was a well-ordering,
that would be a thing, because ZFC has a well-ordering of
[0,1], but can't give one.)
>
>
Les messages affichés proviennent d'usenet.