Groups | Search | Server Info | Login | Register
Groups > comp.theory > #109965
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Newsgroups | comp.theory |
| Subject | Re: Hypothetical possibilities --- Complete Proof |
| Date | 2024-08-02 19:15 -0400 |
| Organization | i2pn2 (i2pn.org) |
| Message-ID | <7f91c1a43d85d6e6ea261d729f516de30d5f2b9a@i2pn2.org> (permalink) |
| References | (23 earlier) <v8ibf5$2p7ho$1@dont-email.me> <s3CdnbweXt8ohDD7nZ2dnZfqn_ednZ2d@brightview.co.uk> <a287d1fc2c1fc90d4381e46eae05287b96e801b9@i2pn2.org> <-Vednah5VvbtwTD7nZ2dnZfqnPSdnZ2d@brightview.co.uk> <v8jmvr$31nt0$1@dont-email.me> |
On 8/2/24 6:35 PM, olcott wrote:
> On 8/2/2024 5:23 PM, Mike Terry wrote:
>> On 02/08/2024 19:25, Richard Damon wrote:
>>> On 8/2/24 1:39 PM, Mike Terry wrote:
>>>> On 02/08/2024 11:12, Mikko wrote:
>>>>> On 2024-08-01 13:29:24 +0000, olcott said:
>>>>>
>>>>>> On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
>>>>>>> Op 01.aug.2024 om 14:20 schreef olcott:
>>>>>>>> On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
>>>>>>>>> Op 31.jul.2024 om 23:23 schreef olcott:
>>>>>>>>>> On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
>>>>>>>>>>> Op 31.jul.2024 om 17:14 schreef olcott:
>>>>>>>>>>>> On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>> Op 31.jul.2024 om 06:09 schreef olcott:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>>>>> [00002192][00103820][00000000] 55 push ebp
>>>>>>>>>>>>>> [00002193][00103820][00000000] 8bec mov ebp,esp
>>>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ;
>>>>>>>>>>>>>> push DDD
>>>>>>>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ;
>>>>>>>>>>>>>> call HHH(DDD)
>>>>>>>>>>>>>> New slave_stack at:1038c4
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We don't show any of HHH and show the execution trace of
>>>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This assumption is incorrect if it means that HHH is an
>>>>>>>>>>>>> unconditional simulator that does not abort.
>>>>>>>>>>>> This algorithm is used by all the simulating termination
>>>>>>>>>>>> analyzers:
>>>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>>>>>>> 10/13/2022>
>>>>>>>>>>>> *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
>>>>>>>>>>>>
>>>>>>>>>>>> H can abort its simulation of D and correctly report
>>>>>>>>>>>> that D
>>>>>>>>>>>> specifies a non-halting sequence of configurations.
>>>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>>>>>>> 10/13/2022>
>>>>>>>>>>>
>>>>>>>>>>> So, Sipser only agreed to a correct simulation, not with an
>>>>>>>>>>> incorrect simulation that violates the semantics of the x86
>>>>>>>>>>> language by skipping the last few instructions of a halting
>>>>>>>>>>> program.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> int DD()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> HHH(DD);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> DD correctly emulated by HHH cannot possibly reach its own
>>>>>>>>>> second line. I switched to DDD correctly emulated by HHH
>>>>>>>>>
>>>>>>>>> But it has been proven that no such HHH exists that simulates
>>>>>>>>> itself correctly. So, talking about a correct simulation by HHH
>>>>>>>>> is vacuous word salad.
>>>>>>>>>
>>>>>>>>>> because only C experts understood the above example and we
>>>>>>>>>> never had any of those here.
>>>>>>>>>
>>>>>>>>> There are many C experts that looked at it, but you only got
>>>>>>>>> critic, because you keep hiding important properties of HHH,
>>>>>>>>> which made the conclusion impossible.
>>>>>>>>
>>>>>>>> The following is all that is needed for 100% complete proof
>>>>>>>> that HHH did emulate DDD correctly according to the semantics
>>>>>>>> of the x86 language and did emulate itself emulating DDD
>>>>>>>> according to these same semantics.
>>>>>>>
>>>>>>> You are repeating the same false claim with out any self-
>>>>>>> reflection. It has been pointed out that there are many errors in
>>>>>>> this proof.
>>>>>>> Why repeating such errors?
>>>>>>>
>>>>>>>>
>>>>>>>> _DDD()
>>>>>>>> [00002172] 55 push ebp ; housekeeping
>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>> [0000217f] 83c404 add esp,+04
>>>>>>>> [00002182] 5d pop ebp
>>>>>>>> [00002183] c3 ret
>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>>> at:1138cc
>>>>>>>> [00002172][001138bc][001138c0] 55 push ebp ;
>>>>>>>> housekeeping
>>>>>>>> [00002173][001138bc][001138c0] 8bec mov ebp,esp ;
>>>>>>>> housekeeping
>>>>>>>> [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
>>>>>>>> HHH(DDD)
>>>>>>>
>>>>>>> The trace stops and hides what happens when 000015d2 is called.
>>>>>>> Olcott is hiding the conditional branch instructions in the
>>>>>>> recursion.
>>>>>>>
>>>>>>
>>>>>> *Here is the full trace where nothing is hidden*
>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>>>>>
>>>>> On page 36 of that "trace"
>>>>> [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
>>>>> is not followed by the trace of 00000777. Instead the trace continues
>>>>> with the next instruction after the return without any comment about
>>>>> the omission. Meaning of 00000777 is not told.
>>>>>
>>>>
>>>> 777 is the address of Allocate, which is one of PO's "primative ops"
>>>> within his "computing model". (Similar to his DebugStep().)
>>>>
>>>> It is implemented inside x86utm.exe (his COFF obj code runner), not
>>>> in the user code DDD/HHH/etc. in the obj file, and so we would not
>>>> expect to see any trace entries for its internals. When the op
>>>> concludes, rax has the address of the allocated memory, which is
>>>> consistent with how a normal function would have returned the address.
>>>>
>>>> You can say correctly that PO has not explained this, but then he
>>>> provided the full trace under protest, so it's understandable that
>>>> he has not previously explained everything in it. I'm surprised
>>>> that his response to your post was both to ignore the question and
>>>> accuse you of playing sadistic head games, as the question was
>>>> perfectly sensible.
>>>>
>>>> You can look up the 777 address in the listing at the start of the
>>>> trace and it's there along with a bunch of other routines which
>>>> appear to just return without doing anything - those are all PO's
>>>> primitive ops. If you feel a need to understand exactly what they
>>>> do, you'll need to check his source code! (Although for Allocate
>>>> there is no big surprise...)
>>>>
>>>>
>>>> So your observation isn't really a problem beyond not being properly
>>>> explained. An actual problem seen in his trace data is that the
>>>> simulation of DDD does not track the behaviour of the unsimulated
>>>> DDD. I.e. his simulation is incorrect. (PO knows about that but
>>>> claims it doesn't matter, although on other occasions he still
>>>> claims the simulation is correct.)
>>>>
>>>>
>>>> Mike.
>>>>
>>>
>>> But the bigger error that totally negates this trace is if you at
>>> where it begins, it is at program address 00002197, which just the
>>> page before is shown to be the address of _main.
>>>
>>> Since HHH was not given the address of main to start with, this can
>>> not be the trace that HHH itself is generating and looking at, but is
>>> instead the trace of the running of that top level HHH.
>>
>> Well, all PO's trace logs start with main! Something has to set up
>> the required computation [aka the required TM + input tape]. That
>> could be HHH(DDD), or maybe DDD() or whatever. PO might have done
>> this through extra invocation arguments to x86utm.exe, and then there
>> would have been no need to code a main() in his halt7.c user code
>> file. But that would be decidedly fiddly, so having a fixed entry
>> function main() is an ok convenience I'd say. The main() is not
>> really part of his computation model, but x86utm traces the lot.
>>
>> Normally when PO gives code snippets, he includes the main() routine.
>> In this case it is main calling HHH(DDD), so HHH as you say is the
>> outer level HHH. (Later on in the trace we see simulated HHH entries...)
>>
>>> Since that shows the trace isn't what he claims it is, nothing it
>>> says means anything for his argument.
>>
>> I can't see what PO claims the trace to be. That trace was taken and
>> published some weeks ago, and doesn't match up exactly with todays
>> partial trace - e.g. the addresses of HHH/DDD don't match and so on.
>> If it's just wrong through being out of date, or because it has the
>> main() trace on the front, that's not the worst of crimes...
>>
>> I see upthread that someone pointed out that the filtered trace
>> "..stops and hides what happens when 000015d2 is called." Well, the
>> full trace does show the instructions of HHH being executed [even if
>> the data is a bit out of date], and of course there are loads of
>> conditional branches... so everyone should be happy! :)
>>
>>>
>>> In fact, the way the trace is produced, it is clear that the tracing
>>> code doesn't care about what level of simulation it is working but
>>> calls to "DebugStep" just inject the data they trace as part of the
>>> code that is being traced, which isn't actually what is happening in
>>> the processor.
>>
>> That's correct. The full trace proceeds showing HHH executing its
>> code as we would expect, and after some time HHH (actually a routine
>> called by HHH) invokes a DebugStep op. We can see that the DebugStep
>> op stepped HHH's simulation one instruction, which also appears in
>> trace. Here is where that happens:
>>
>> ,,,
>> [000011eb][00103783][00103863] 8b4d1c mov ecx,[ebp+1c]
>> [000011ee][00103783][00103863] 8b11 mov edx,[ecx]
>> [000011f0][0010377f][00103827] 52 push edx
>> [000011f1][0010377f][00103827] e8b1f5ffff call 000007a7 <===
>> DebugStep
>> [00002177][00113897][0011389b] 55 push ebp <===
>> simulated instruction
>> [000011f6][0010378b][90909090] 83c40c add esp,+0c <=== next
>> instructin after DebugStep
>> [000011f9][0010378b][90909090] e8e9f5ffff call 000007e7
>> ...
>>
>> The "push ebp" above is the first simulated instruction, and just
>> appears in the trace straight after the call to DebugStep. [Note the
>> apparent discontinuities in IP address and ESP (cols 1&2 resp.) Yeah
>> I know, /why isn't there a simulation level column/ ?]
>>
>> We could say that the trace as shown is a log of all the instructions
>> x86utm "executes" in succession, so it is a merge of entries from all
>> simulation levels - certainly it's not the x86 "processor trace" it
>> might be taken to be.
>>
>> Note - the "push ebp" instruction is the first simulated instruction
>> of DDD(), which at least is the instruction we would expect it to be.
>> In PO's normal "filtered" log output, all the other instructions above
>> wouldn't appear as they're not from DDD.
>>
>> Of course these traces don't support PO's overall case he is claiming,
>> because the (various) logs show that DDD halts, and that HHH(DDD)
>> reports DDD as non-halting, exactly as Linz/Sipser argue. Er, that's
>> about it!
>>
>> Whether it supports some minutia of what PO is currently arguing about
>> - you'd have to explain to me exactly what he is claiming! (um,
>> Please don't!)
>>
>>
>>>
>>> This seems to be part of the source for his confusion, and the tool
>>> he uses to try to spread his lies.
>>>
>>> such results should, at most, be inserted as a comment about what the
>>> results computed as meta-logic of the code just emulated did.
>>>
>>> But of course, noting that this second layer is just meta-results,
>>> and that the original emulator always had the option of stopping its
>>> emulation ruins his argument that the recursion is necessarily infinite.
>>
>> It's hard to pin down confusion sources. I agree PO doesn't need
>> x86utm logs to argue his case, and including them doesn't /prove/
>> anything, especially when he admits the simulated code uses mutable
>> static data to modify the behaviour of the simulation so that it does
>> not match the unsimulated (outer) computation.
>>
>> I think PO views x86utm as some kind of "ultra authority" he can
>> appeal to, to avoid having to actually prove his claims. [Which is
>> funny, because the logs don't support his claims, but for some reason
>> that passes him by...]
>>
>> Mike.
>>
>
>
> *No dumbo. The ultimate authority is the x86 semantics of DDD*
Which, without a definition of HHH, does HAVE semantics beyond 4
instructions.
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> I have proved my point such that someone mostly clueless
> about the semantics of the x86 language would have understood
> that I have been correct all along with the original H/P
> three years ago.
Nope, since you claim that these bytes alone define the behavior of DDD,
you have demonstrated that you do not understand at all, how compututers
work
>
> I have to simplify be proof so that anyone intentionally
> misconstruing it looks ridiculously stupid even to themselves.
No, you need to leave out the details that show you are just a liar.
>
> Who here is too stupid to know that DDD correctly simulated
> by HHH cannot possibly reach its own return instruction?
But, since you HHH doesn't do that, it is irrelevent.
Sorry, Non-existant hypotheticals don't count.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
>
Back to comp.theory | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Hypothetical possibilities Mikko <mikko.levanto@iki.fi> - 2024-07-24 12:01 +0300
Re: Hypothetical possibilities olcott <polcott333@gmail.com> - 2024-07-24 08:38 -0500
Re: Hypothetical possibilities Mikko <mikko.levanto@iki.fi> - 2024-07-26 11:05 +0300
Re: Hypothetical possibilities olcott <polcott333@gmail.com> - 2024-07-26 08:58 -0500
Re: Hypothetical possibilities Mikko <mikko.levanto@iki.fi> - 2024-07-27 09:54 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-27 08:55 -0500
Re: Hypothetical possibilities --- stupid rebuttal Alan Mackenzie <acm@muc.de> - 2024-07-27 14:28 +0000
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-27 09:45 -0500
Re: Hypothetical possibilities --- stupid rebuttal Alan Mackenzie <acm@muc.de> - 2024-07-27 14:59 +0000
Re: Hypothetical possibilities --- strawman deception based rebuttal olcott <polcott333@gmail.com> - 2024-07-27 10:30 -0500
Re: Hypothetical possibilities --- strawman deception based rebuttal Mikko <mikko.levanto@iki.fi> - 2024-07-28 11:12 +0300
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-07-28 11:10 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-29 11:20 -0500
Re: Hypothetical possibilities --- stupid rebuttal joes <noreply@example.org> - 2024-07-29 20:20 +0000
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-29 15:36 -0500
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-07-30 09:41 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-30 13:42 -0500
Re: Hypothetical possibilities --- stupid rebuttal Richard Damon <richard@damon-family.org> - 2024-07-30 21:21 -0400
Re: Hypothetical possibilities --- stupid rebuttal --- olcott <polcott333@gmail.com> - 2024-07-30 20:32 -0500
Re: Hypothetical possibilities --- stupid rebuttal by olcott--- Richard Damon <richard@damon-family.org> - 2024-07-30 21:34 -0400
Re: Hypothetical possibilities --- stupid rebuttal --- olcott <polcott333@gmail.com> - 2024-07-30 21:13 -0500
Re: Hypothetical possibilities --- stupid lying rebuttal by Olcott --- Richard Damon <richard@damon-family.org> - 2024-07-30 23:19 -0400
Re: Hypothetical possibilities --- stupid rebuttal by Olcott--- Richard Damon <richard@damon-family.org> - 2024-07-30 23:19 -0400
Re: Hypothetical possibilities --- stupid rebuttal --- olcott <polcott333@gmail.com> - 2024-07-30 23:09 -0500
Re: Hypothetical possibilities --- stupid rebuttal --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-31 10:44 +0200
Re: Hypothetical possibilities --- Correct emulation has been proven for three years olcott <polcott333@gmail.com> - 2024-07-31 10:14 -0500
Re: Hypothetical possibilities --- Correct emulation has been proven for three years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-31 22:01 +0200
Re: Hypothetical possibilities --- Correct emulation has been proven for three years olcott <polcott333@gmail.com> - 2024-07-31 16:23 -0500
Re: Hypothetical possibilities --- Correct emulation has been proven for three years joes <noreply@example.org> - 2024-08-01 07:20 +0000
Re: Hypothetical possibilities --- Correct emulation has been proven for three years olcott <polcott333@gmail.com> - 2024-08-01 06:28 -0500
Re: Hypothetical possibilities --- Correct emulation has been proven for three years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 13:46 +0200
Re: Hypothetical possibilities --- Correct emulation has been proven for three years olcott <polcott333@gmail.com> - 2024-08-01 07:34 -0500
Re: Hypothetical possibilities --- Correct emulation has been proven for three years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 15:03 +0200
Re: Hypothetical possibilities --- Correct emulation has been proven for three years olcott <polcott333@gmail.com> - 2024-08-01 08:11 -0500
Re: Hypothetical possibilities --- Correct emulation has been proven for three years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 16:26 +0200
Re: Hypothetical possibilities --- INCorrect emulation has been proven for three years Richard Damon <richard@damon-family.org> - 2024-08-01 19:33 -0400
Re: Hypothetical possibilities --- Correct emulation has been proven for three years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 10:10 +0200
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-01 07:20 -0500
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 15:12 +0200
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-01 08:29 -0500
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 16:23 +0200
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-01 09:30 -0500
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 16:36 +0200
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-01 10:49 -0500
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 21:40 +0200
Re: Hypothetical possibilities --- Complete Proof joes <noreply@example.org> - 2024-08-01 16:11 +0000
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-01 11:32 -0500
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-01 21:30 +0200
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-01 16:03 -0500
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-02 10:13 +0200
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-02 06:24 -0500
Re: Hypothetical possibilities --- Complete Proof *FAILED* Richard Damon <richard@damon-family.org> - 2024-08-02 10:41 -0400
Re: Hypothetical possibilities --- Complete Proof "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-08-03 10:25 +0200
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-03 11:54 +0300
Re: Hypothetical possibilities --- Completly incorrect Proof Richard Damon <richard@damon-family.org> - 2024-08-01 19:33 -0400
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-02 13:19 +0300
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-02 06:21 -0500
Re: Hypothetical possibilities --- Complete Proof *FAILED* Richard Damon <richard@damon-family.org> - 2024-08-02 10:41 -0400
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-03 11:58 +0300
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-02 13:12 +0300
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-02 06:11 -0500
Re: Hypothetical possibilities --- Complete Proof *FAILS* Richard Damon <richard@damon-family.org> - 2024-08-02 10:41 -0400
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-03 12:07 +0300
Re: Hypothetical possibilities --- Complete Proof Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-08-02 18:39 +0100
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-02 12:57 -0500
Re: Hypothetical possibilities --- Complete Proof *FAILED* Richard Damon <richard@damon-family.org> - 2024-08-02 14:32 -0400
Re: Hypothetical possibilities --- Complete Proof Richard Damon <richard@damon-family.org> - 2024-08-02 14:25 -0400
Re: Hypothetical possibilities --- Complete Proof Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-08-02 23:23 +0100
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-02 17:35 -0500
Re: Hypothetical possibilities --- Complete Proof Richard Damon <richard@damon-family.org> - 2024-08-02 19:15 -0400
Re: Hypothetical possibilities --- Complete Proof Ben Bacarisse <ben@bsb.me.uk> - 2024-08-02 23:42 +0100
Re: Hypothetical possibilities --- Complete Proof olcott <NoOne@NoWhere.com> - 2024-08-02 17:55 -0500
Re: Hypothetical possibilities --- Complete Proof Richard Damon <richard@damon-family.org> - 2024-08-02 19:17 -0400
Re: Hypothetical possibilities --- Complete Proof Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-08-03 02:19 +0100
Re: Hypothetical possibilities --- Complete Proof Richard Damon <richard@damon-family.org> - 2024-08-02 21:56 -0400
Re: Hypothetical possibilities --- Complete Proof -- more details olcott <polcott333@gmail.com> - 2024-08-02 22:30 -0500
Re: Hypothetical possibilities --- Complete FAILED Proof -- more details Richard Damon <richard@damon-family.org> - 2024-08-03 11:33 -0400
Re: Hypothetical possibilities --- Complete Proof Jeff Barnett <jbb@notatt.com> - 2024-08-02 22:32 -0600
Re: Hypothetical possibilities --- Complete Proof --- Halt State olcott <polcott333@gmail.com> - 2024-08-03 08:27 -0500
Re: Hypothetical possibilities --- Complete Proof --- halt state olcott <abc@def.com> - 2024-08-05 19:26 -0500
Re: Hypothetical possibilities --- Complete Proof Ben Bacarisse <ben@bsb.me.uk> - 2024-08-05 03:33 +0100
Re: Hypothetical possibilities --- Complete Proof olcott <abc@def.com> - 2024-08-04 22:56 -0500
Re: Hypothetical possibilities --- Complete Proof Richard Damon <richard@damon-family.org> - 2024-08-05 07:40 -0400
Re: Hypothetical possibilities --- Complete Proof olcott <abc@def.com> - 2024-08-05 19:41 -0500
Re: Hypothetical possibilities --- Completely *FAILED* Proof Richard Damon <richard@damon-family.org> - 2024-08-05 21:32 -0400
Re: Hypothetical possibilities --- Complete Proof olcott <abc@def.com> - 2024-08-05 19:34 -0500
Re: Hypothetical possibilities --- Complete Proof Richard Damon <richard@damon-family.org> - 2024-08-02 19:12 -0400
Re: Hypothetical possibilities --- Complete Proof Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-08-03 04:11 +0100
Re: Hypothetical possibilities --- Complete Proof olcott <polcott333@gmail.com> - 2024-08-02 22:36 -0500
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-03 12:29 +0300
Re: Hypothetical possibilities --- Complete Proof Mikko <mikko.levanto@iki.fi> - 2024-08-03 12:14 +0300
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-08-01 11:02 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-08-01 07:08 -0500
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-08-03 12:31 +0300
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-07-28 11:04 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-29 11:17 -0500
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-07-30 09:44 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-07-30 16:11 -0500
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-08-01 11:14 +0300
Re: Hypothetical possibilities --- stupid rebuttal olcott <polcott333@gmail.com> - 2024-08-01 07:23 -0500
Re: Hypothetical possibilities --- stupid rebuttal Mikko <mikko.levanto@iki.fi> - 2024-08-03 12:35 +0300
Re: Hypothetical possibilities --- Sipser approved criteria olcott <polcott333@gmail.com> - 2024-07-27 09:41 -0500
Re: Hypothetical possibilities --- Sipser approved criteria Alan Mackenzie <acm@muc.de> - 2024-07-27 14:50 +0000
Re: Hypothetical possibilities --- Sipser approved criteria olcott <polcott333@gmail.com> - 2024-07-27 09:59 -0500
Re: Hypothetical possibilities --- Sipser approved criteria Mikko <mikko.levanto@iki.fi> - 2024-07-28 11:21 +0300
Re: Hypothetical possibilities --- Sipser approved criteria olcott <polcott333@gmail.com> - 2024-07-29 11:25 -0500
Re: Hypothetical possibilities --- Sipser approved criteria Mikko <mikko.levanto@iki.fi> - 2024-07-28 11:13 +0300
Re: Hypothetical possibilities --- strawman deception olcott <polcott333@gmail.com> - 2024-07-30 16:35 -0500
Re: Hypothetical possibilities --- strawman deception Mikko <mikko.levanto@iki.fi> - 2024-08-01 11:20 +0300
Re: Hypothetical possibilities --- strawman deception olcott <polcott333@gmail.com> - 2024-08-01 07:25 -0500
Re: Hypothetical possibilities --- strawman deception Richard Damon <richard@damon-family.org> - 2024-08-01 19:33 -0400
Re: Hypothetical possibilities --- strawman deception Mikko <mikko.levanto@iki.fi> - 2024-08-03 12:42 +0300
csiph-web