Re: We finally know exactly how H1(D,D) derives a different result than H(D,D) --closure yet?--

Liste des GroupesRevenir à s logic 
Sujet : Re: We finally know exactly how H1(D,D) derives a different result than H(D,D) --closure yet?--
De : polcott2 (at) *nospam* gmail.com (olcott)
Groupes : comp.theory sci.logic
Date : 08. Mar 2024, 20:58:27
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <usfn4j$1s1nb$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : Mozilla Thunderbird
On 3/8/2024 11:56 AM, Richard Damon wrote:
On 3/8/24 9:13 AM, olcott wrote:
On 3/8/2024 1:40 AM, Richard Damon wrote:
On 3/7/24 11:07 PM, olcott wrote:
On 3/8/2024 12:34 AM, Richard Damon wrote:
On 3/7/24 10:00 PM, olcott wrote:
On 3/7/2024 9:28 PM, Richard Damon wrote:
On 3/7/24 4:00 PM, olcott wrote:
On 3/7/2024 5:18 PM, Richard Damon wrote:
On 3/7/24 3:02 PM, olcott wrote:
On 3/7/2024 4:32 PM, Richard Damon wrote:
On 3/7/24 1:05 PM, olcott wrote:
H1(D,D) maps its input + its own machine address 00001422 to its output.
  H(D,D) maps its input + its own machine address 00001522 to its output.
Thus both H1 and H are computable functions of their input.
>
And thus you are admitting that Neither H or H1 are actually correct Halt Deciders, as Halt Deciders must be only a function of the description of the Compuation to be decided.
>
>
It turns out that both H(D,D) and H1(D,D) do correctly determine
whether or not they must abort the simulation of their input.
>
Which isn't the halting question, so you are LYING.
>
As I completely explained yet you persistently ignore the
halting question can only be correctly answered indirectly
otherwise inputs that contradict the decider that is embedded
within these inputs have no answer at all.
>
In other words you argue by lying.
>
The QUESTION is, and always will be, does the computation described by the input Halt when run.
>
The Computation so described is FIXED and UNCHANGING reguards of what the decider that is deciding does, as is the behavior of the H that it is built on.
>
That was FIXED and made UNCHANGING when it was defined.
>
Thus, the question does THIS H^(H^) halt? HAS a definite and fixed answer. SO you LIE when you said it doesn't.
>
Your problem seems to be that you think "Get the Right Answer?" is a valid program instruction, or that H can somehow "change" itself after H^ gets defined. IT CAN'T.
>
YOU persistently ignore this fact, likely because you are too stupid and ignorant to understand that fundamental nature of programs, that they will do what their programming says they will do, and that programming doesn't change, EVER, with out the creation of some NEW program that is different from its predicesor.
>
YOU *NEVER* have the right to change the question for a problem.
>
You can try to point out the the problem is inconsistant, and propose a NEW PROBLEM, but that doesn't change the old.
>
You can talk about your new problem that you think is more useful than the actual Halting Problem, after all, someone might be more interested in the incorrect opinion of an admittedly faulty "Olcott-Halt Decider" than the actual behavior of the Computation they are interested in.
>
NOT.
>
What you can't to is say you are working on one problem, while trying to change it to mean something different. That is just call LYING, and you seem to know that you doing it (you might feel you have justified reasons to talk about a different problem) so the lie is DELIBERATE.
>
>
>
That you or others consider this somehow improper does not change
the verified fact that they both correctly determine whether or
not they must abort their simulation.
>
Which isn't the Halting Question, which you claim you are working on, so you are just LYING.
>
>
Already fully explained many many times (including above)
yet your ignorance is very persistent.
>
So, you think you can change the question and still be talking about the same question.
>
You ARE the LIAR PARADOX.
>
>
>
It is also the case that both H1(D,D) and H(D,D) are a pure function
of their inputs when we construe their own machine address to be an
element of these inputs.
>
Which means they are not computing the Halting Function, which isn't a function of the decider, so again, you are LYING.
>
>
Already fully explained many many times (including above)
yet your ignorance is very persistent.
>
Yes, you have ADMITTED that you are LYING about working on the Halting Problem.
>
>
>
>
Turing machines don't even have the idea of their own machine
address so this exact same thing cannot be Turing computable.
>
And it isn't a Halt Decider even in Olcott machines as the algorithm is shown to vary by a parameter that it isn't allowed to vary to be a Halt Decider.
>
>
Olcott machines entirely anchored in Turing machine notions
can compute the equivalent of H1(D,D) and H(D,D).
>
Because Olcott machines are essentially nothing more than
conventional UTM's combined with Conventional Turing machine
descriptions their essence is already fully understood.
>
The input to Olcott machines can simply be the conventional
space delimited Turing Machine input followed by four spaces.
>
This is followed by the machine description of the machine
that the UTM is simulating followed by four more spaces.
>
When this input is ignored Olcott machines compute the
exact same set as Turing machines.
>
Unlike Turing machines, Olcott machines have the basis to
determine that they have been called with copies of their
own TMD.
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>
With Olcott machines Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> and H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> do
not have the same inputs thus can compute different outputs
when they do not ignore their own TMD.
>
>
>
THen you build H^ wrong. Of course with your change in mechanics, the H^ that needs to be generated will be a bit different.
>
>
That Olcott machines always know their own TMD is unconventional.
>
And breaks much of the background of Turing Machines,
>
Not at all. Not in the least little bit.
Olcott machines are 100% fully specified
in terms of Turing machines.
>
Yes, BUT if you talk about an Olcott machine, you MUST include the added data as part of the description of that machine, or you are just LYING.
>
>
so if you what to use ANY establish property of Turing Machine, you must include that now extra data EXPLICITLY.
>
>
It is already explicitly included in the definition of an Olcott machine.
>
Which means that you can't actually write an Olcott-Machine that matches the requirements for a Halt Decider.
>
A Halt Decider MUST be able to defined as taking JUST the description of the Computation to be decided (the Allgorithm and the Data). In general this also holds, to be a Foo decider, the decider must be give JUST the information about the thing that we are deciding Foo on.
>
>
If Olcott machines that are essentially Turing machines configured in
a certain way can detect when they themselves are called in recursive
simulation then this reconfiguration defines a new machine that can
compute every function that a TM can and more.
>
Except that by having information that the ordinary Turing Machine can't have, you have lost the assurance that it can't use information that it shouldn't have.
>
This is merely conventions. When a slight reconfiguration of Turing
machines defines a new machine that computes every function that Turing
machines compute and more then Church-Turing seems to be refuted.
>
No, it is DEFINITON.
>
So, show a mapping that Olcott Machines can compute that a Turing Machine can not.
>
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>
Olcott machines have an ability that Turing machines do not
have they can correctly determine that they have been called
in recursive simulation thus giving them the same ability
that H(D,D) and H1(D,D) has.
>
*Criterion Measure*
H is assumed to be a simulating termination analyzer that aborts the
simulation of any input that would cause its own non-termination and
returns NO. Otherwise H always returns YES.
>
A halt decider must compute halting indirectly otherwise
Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ has no basis for any answer at all.
>
Both Linz Ĥ.H and Linz H have their basis when computed
as Olcott machines. When they compute haltiong indirect
>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
therefore
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy
>
>
The Linz machines really need to correctly determine whether or not
they have been called in recursive simulation. Olcott machines can do
that.
>
Nope. Proven otherwise.
>
The Recursion doesn't matter, and you Olcotts machines can't reliably detect it.
>
If you claim otherwise, show how H can detect that H^ contains a copy of it, or how the H at H^.Hq0 (H^) (H^) <H> [NOT <H^>] can tell that it is simulating an input that it is part of.
>
Or, explain why H^ can get to that state.
>
*I cannot allow divergence from Linz until we get closure on Linz*
>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> Does a string comparison between its first parameter
and its last parameter proving that it is about to simulate itself.
>
>
>
Since the mapping function for no practial problem actually will depend on the decider that is deciding it, NO Olcott-Machine meets the basic definition to be any of those deciders.
>
>
Olcott machines are always able to detect when they themselves
are called in recursive simulation. Since Turing machines cannot
possibly do that then Olcott machine are more powerful.
>
Nope. Since there "caller" can lie to them they can not know if THEY have been "called" recursively.
>
>
Unless a machine intentionally breaks this feature it remains available.
Making breaking changes to a machine doesn't change computability.
>
So, how does H compute halting when H^ is intentionally messing up H's plan to detect the recusion.
>
H^ is ALLOWED to be antagonistic and intentionally "breaking" things.
>
You don't get to tell the opponent they can't run trick plays. It isn't the Pro Bowl.
>
*I cannot allow divergence from Linz until we get closure on Linz*
>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> Does a string comparison between its first parameter
and its last parameter proving that it is about to simulate itself.
>
>
If they are doing a simulation, they MIGHT be able to detect that they are simulation that exact descritption of them, but it is trivial to make the description different, so they can't tell.
>
>
This is outside of the scope of refuting Linz.
I do not have enough time left to waste on unnecessary digression.
>
Nope, if you want to refute Linz, you need to actual PROVE what you claim.
>
Linz does not include the scope that you are trying to expand.
I wasted 15 years of allowing Ben Bacarisse the {change the subject}
rebuttal. Your question must be address, yet not now.
>
You are just proving you have nothing and are trying to get out of the game.
>
THis proves you were just a liar.
>
>
For instance, your OH never sees that the H^ that it is simulating has a copy of it inside it, because the description changed by being converted to a sub-machine, and that copy can't tell that it is simulating a copy of the machine it is in becausse H^ told it that it was a top level machine that was just H.
>
There is no such conversation to sub machine.
>
Do you mean "converted"?
>
Note, "Sub-machine" is a term to understand functionality. It breaks down the functionality of the full machine into manageable parts.
>
Yes, nothing in the machine itself indicates what is or is not a sub-machine.
>
>
That is the part that immibis did not seem to understand.
>
But by KNOWING (by defining) a piece as a sub-machine, we can mathematically handle that sub-piece from the desciption of the machine that was embedded there.
>
But, I suppose you don't understand any of that which is why it takes you so long to do anything.
>
>
You just don't understand what is happening and tried to define thing the way you wanted, but haven't actually acheived it.
>
>
You are forced to have the machine take an extra parameter that you then need to constrain that the machine can not actually depend on it.
>
>
>
That their own TMD is correctly construed as an additional input
to their computation (whenever they don't ignore it) does provide
the reason why Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> and H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can compute different
results and still be computations.
>
But not the RIGHT computation.
>
>
Not the same computation that conventional wisdom expects.
>
SO not the compution DEFINED for the problem.
>
Remember, the problem STARTS with the mapping function, which defines what the decider is allowed to have as inputs, and what answer each value of those inputs should generate.
>
By simply defining a reconfiguration of a Turing machine
Olcott machines can compute when they themselves are
called in recursive simulation. H1 and H need to do that.
>
Nope.
>
How does H detect that the machine it is simulating is has a copy of it in it?
>
Finally paying attention.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩ does not halt
>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> performs a string comparison of its first param:⟨Ĥ⟩ with
its last param:<Ĥ> when they match Ĥ.H knows that it is about to
simulate itself.
>
Except that its last parameter was <H> not <H^>
>
I cannot afford the [change the subject] rebuttal that Ben Bacarisse
used to waste 15 years. Your question is relevant yet not at this
point in time.
>
*Once three people agree that this is correct then we can move on*
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
therefore
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy
>
Can't you read?
>
Or, are you just still trying to Lie by ignoring the truth.
>
Just shows how stupid you are.
>
>
>
>
Right answer to the wrong question is still a WRONG ANSWER.
>
>
The right answer to a different question that can always
be construed as the right answer to the original question
by H ⟨Ĥ⟩ ⟨Ĥ⟩ is the right answer.
>
NOPE, more LIES.
>
If H(H^,H^) returns non-halting, then H^.H(H^,H^) will ALSO return non-halting, and H^ will halt, meaning H was wrong, and you are LYING.
>
>
*No matter how many times I tell you that there is a third*
*input you always immediately forget this right when I tell you*
>
>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn // must abort input
This one performs string compare on its first param:⟨Ĥ⟩ with
its last param:<Ĥ> proving that it *WILL* simulate itself.
>
But it last parameter is actually <H>
>
You are just lying with your strawmen again.
>
>
   H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy  // input halts
This one performs string compare on its first param:⟨Ĥ⟩ with its last
param:<H> proving that *WILL NOT* simulate itself.
>
>
Yes, so, you agree that H doesn't know that H^ includes a copy of itself in it.
>
Thus H will never stop its simulation.
>
Olcott machines merely give Turinng machines the same
ability to detect that they were called in recursive
simulation that H(D,D) and H1(D,D) has.
 Nope. They need an extra input that you could give to a Turing Machine, thus the do no extra COMPUTATION.
Turing machines seem to leave a loophole open where
halting is uncomputable for some TM/input pairs.
If the Linz H was a Turing machine that implemented
the Olcott protocol this H could not detect that
itself is not called in recursive simulation.
This seems to make Olcott machines strictly more
powerful than Turing machines.

Also, the input doesn't help them.
I have proven that it does help them very many times.
That you keep ignoring what I said is no kind of
actual rebuttal at all.
Olcott machine termination analyzers always perform
a string comparison of their first param with their
last param.
This tells them whether or not their input is having
them simulate an exact copy of themselves in recursive
simulation.

Your H can't tell that D has a copy of it in it
H does determine this by its Olcott machine extra parameter
of its own machine address. I have told you this same idea
many many times. Everyone here knows that simply ignoring
what I said forms no actual rebuttal what-so-ever.

 And the H in D can't tell it is looking at a copy of itself as D tell it that it is the same H as above, so it doesn't know either.
 
>
And when we fix your lie about what H^.H gets, ie (H^) (H^) <H>
we see that H can't tell this either, so will just continue simulating.
>
So we get the never abort case, and nobody answers.
>
If your only answer to the problem is to lie, I guess you are conceeding that this path is just broken too.
>
And all you are it the pathetic ignorant pathological lyint idiot you have shown yourself to be.
>
You know how I performed on the Mensa test (in the top 3%)
so you know that I am no idiot. You have not been able to
even show that what I say is false so you have no basis to
say that what I say is intentionally false.
 Can you PROVE your statement?
I have proven that most of your rebuttals simply ignore
what I said. My college grades prove that my IQ claim
is reasonably plausible.

 The fact that you repeat know false statements and refuse to beleive facts makes you an IDIOT.
I have not made any false statements they only seem that
way when you ignore what I said and merely speculate on
the truth of what I said on the basis of ignoring what
I actually said.

>
That you believe that I am incorrect yet cannot even show
this is no rebuttal what-so-ever.
 The fact that virtually every time I comment, I provide a rebuttal to your statements, referencing fundamental definitions shows that you are just a pathological liar.
Not at all. I say that Olcott machines have a certain
ability and you use the strawman deception to say that
I am wrong Turing machines do not have that ability.

You may not recognise them as rebuttal, as you are ignorant of the meaning of the words, so my statements SEEM "meaningless" to you, but they are fully disproving your claims.
 
I recognize your strawman deceptions even if you don't.

>
I have finally addressed how H(D,D) and H1(D,D) are able to
get their differing results thus addressing your very long
standing rebuttal.
 Right, by showing that youy have been LYING that they were the same computation.
Thus, you have agreed that you arguement was invalid.
I never claimed that they are the same computation.
I only claimed that identical machines can and do get
different results. This claim was not fully coherent
until I noticed that H(D,D) and H1(D,D) essentially
have the Olcott machine extra input.
The x86 execution traces did prove that by knowing their
own machine address that H(D,D) and H1(D,D) did correctly
get different results.
When you said this was impossible your were always incorrect.
What you mean by "impossible" was never {totally impossible}
at all. It was merely not Turing computable.

>
I have also showed all of the details of how slightly adapted
Turing machines can do this same thing.
 Nope.
Olcott machine termination analyzers always perform a string
comparison of their first param with their last param.
This enables them to know that they are about to simulate
an exact copy of themselves in recursive simulation.
Do I have to repeat that fifty times for you to notice
that I said it at least once?

You haven't even tried to answer my rebuttals, so you must be admitting that this is just another of your ignorant lie.
All of your "rebuttals" are either the strawman deception,
pure dogma when your say "nope" or simply ignoring what I
already said.
One very important key exception to this is your insistence
that I explain exactly how H(D,D) and H1(D,D) can possibly
get different results.
I did explain this many times and in several ways but my only
fully satisfactory explanation is that they use the Olcott
machine protocol thus have an extra input.

>
*That you ignore my correct rebuttals is no actual rebuttal at all*
>
 That you ignore MY correct rebuttal show that your rebuttal are just lies.
 WHen you TRY to rebut my statements, you just repeat the error that was pointed out, You can not go more basic, because that just exposes your lies more.
 You are just proving that you are just a pathetic ignorant pathological lying idiot.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Date Sujet#  Auteur
7 Mar 24 * We finally know exactly how H1(D,D) derives a different result than H(D,D)52olcott
8 Mar 24 +* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)49Richard Damon
8 Mar 24 i`* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)48olcott
8 Mar 24 i +* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)18olcott
8 Mar 24 i i+* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)2olcott
8 Mar 24 i ii`- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)1Richard Damon
8 Mar 24 i i+* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)10olcott
8 Mar 24 i ii+- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)1Richard Damon
8 Mar 24 i ii`* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)8Richard Damon
8 Mar 24 i ii `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)7olcott
8 Mar 24 i ii  `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)6Richard Damon
8 Mar 24 i ii   `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)5olcott
8 Mar 24 i ii    `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)4Richard Damon
8 Mar 24 i ii     `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)3olcott
8 Mar 24 i ii      `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)2olcott
8 Mar 24 i ii       `- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)1olcott
8 Mar 24 i i`* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)5olcott
8 Mar 24 i i `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)4olcott
8 Mar 24 i i  `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D) --closure yet?--3olcott
8 Mar 24 i i   `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D) --closure yet?--2olcott
9 Mar 24 i i    `- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D) --Richard goes around in circles--1immibis
8 Mar 24 i `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)29André G. Isaak
8 Mar 24 i  +* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)27immibis
8 Mar 24 i  i+* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)23olcott
8 Mar 24 i  ii`* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)22Richard Damon
8 Mar 24 i  ii `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)21olcott
8 Mar 24 i  ii  `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)20Richard Damon
8 Mar 24 i  ii   `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)19olcott
8 Mar 24 i  ii    `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)18Yaxley Peaks
15 Mar 24 i  ii     `* Re: H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct when reports on the actual behavior that it sees --outermost H--17olcott
15 Mar 24 i  ii      +* Re: H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct when reports on the actual behavior that it sees --outermost H--13Fred. Zwarts
15 Mar 24 i  ii      i`* Re: H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct when reports on the actual behavior that it sees --outermost H--12olcott
15 Mar 24 i  ii      i +* Re: H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct when reports on the actual behavior that it sees --outermost H--2Richard Damon
15 Mar 24 i  ii      i i`- Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--1olcott
15 Mar 24 i  ii      i `* Re: H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct when reports on the actual behavior that it sees --outermost H--9immibis
15 Mar 24 i  ii      i  `* Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--8olcott
15 Mar 24 i  ii      i   +* Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--5immibis
15 Mar 24 i  ii      i   i`* Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--4olcott
15 Mar 24 i  ii      i   i `* Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--3immibis
15 Mar 24 i  ii      i   i  `* Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--2olcott
15 Mar 24 i  ii      i   i   `- Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--1immibis
15 Mar 24 i  ii      i   `* Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--2Richard Damon
15 Mar 24 i  ii      i    `- Re: H(D,D)==0 is correct when reports on the actual behavior that it sees --outermost H--1olcott
15 Mar 24 i  ii      `* Re: H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct when reports on the actual behavior that it sees --outermost H--3immibis
15 Mar 24 i  ii       `* Re: H(D,D) ==0 is correct when reports on the actual behavior that it sees --outermost H--2olcott
15 Mar 24 i  ii        `- Re: H(D,D) ==0 is correct when reports on the actual behavior that it sees --outermost H--1immibis
8 Mar 24 i  i`* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)3Richard Damon
8 Mar 24 i  i `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)2immibis
8 Mar 24 i  i  `- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)1olcott
8 Mar 24 i  `- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)1olcott
8 Mar 24 `* Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)2immibis
8 Mar 24  `- Re: We finally know exactly how H1(D,D) derives a different result than H(D,D)1olcott

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal