Re: Refuting the {Linz, Sipser and Kozen} HP Proofs (deciders within

[olcott]

On 12/14/2020 2:02 PM, Kaz Kylheku wrote:
> On 2020-12-14, olcott <No...@NoWhere.com> wrote:
>> On 12/14/2020 9:32 AM, Malcolm McLean wrote:
>>> On Monday, 14 December 2020 at 15:16:13 UTC, olcott wrote:
>>>> On 12/14/2020 8:48 AM, André G. Isaak wrote:
>>>>> On 2020-12-14 07:25, olcott wrote:
>>>>>> On 12/12/2020 2:37 PM, André G. Isaak wrote:
>>>>>>> On 2020-12-12 13:01, olcott wrote:
>>>>>>>> On 12/12/2020 1:40 PM, André G. Isaak wrote:
>>>>>>>>> On 2020-12-12 12:25, olcott wrote:
>>>>>>>>>> On 12/12/2020 1:13 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2020-12-12 12:08, olcott wrote:
>>>>>>>>>>>> On 12/12/2020 1:00 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2020-12-12 11:26, olcott wrote:
>>>>>>>>>>>>>> On 12/12/2020 12:08 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2020-12-12 10:45, olcott wrote:
>>>>>>>>>>>>>>>> On 12/12/2020 11:40 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2020-12-12 10:38, olcott wrote:
>>>>>>>>>>>>>>>>>> On 12/12/2020 11:12 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2020-12-12 09:24, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <snip>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The outermost Halts() always returns a value to its
>>>>>>>>>>>>>>>>>>>> caller even though it must sometimes abort the
>>>>>>>>>>>>>>>>>>>> simulations of inner infinite invocations of itself.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And since it claims to be simulating those inner
>>>>>>>>>>>>>>>>>>> instances and to abort those instances only in cases
>>>>>>>>>>>>>>>>>>> where they would not otherwise halt, it is asserting that
>>>>>>>>>>>>>>>>>>> there *are* inputs to Halts() which will not halt. Ergo,
>>>>>>>>>>>>>>>>>>> it is asserting that Halts() is *not* a decider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ...in those cases where it does not halt and return a
>>>>>>>>>>>>>>>>>> value to its caller Halts() is not a decider. On those
>>>>>>>>>>>>>>>>>> invocations of Halts() where it does halt and return a
>>>>>>>>>>>>>>>>>> value to its caller it is a decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A program is either a decider or it isn't. There's no such
>>>>>>>>>>>>>>>>> thing as a program which is sometimes a decider and
>>>>>>>>>>>>>>>>> sometimes isn't.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You already know that is pure bullshit or the term "partial
>>>>>>>>>>>>>>>> decider" would not exist. What motive do you have for saying
>>>>>>>>>>>>>>>> things that you know are pure bullshit?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A partial decider is not a decider. More importantly, it is
>>>>>>>>>>>>>>> not a "sometimes decider".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A partial decider makes a correct decision for a particular
>>>>>>>>>>>>>>> class of inputs but may fail to halt for other inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your program sometimes halts and sometimes doesn't for the
>>>>>>>>>>>>>>> *same* inputs. So you cannot even claim your program is a
>>>>>>>>>>>>>>> partial decider, let alone an actual decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So in other words you "believe" against logic that some
>>>>>>>>>>>>>> infinitely recursive invocations <do> return a result to their
>>>>>>>>>>>>>> caller. That sounds nutty to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How you can possibly get that idea from what I wrote is utterly
>>>>>>>>>>>>> beyond me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am saying that anything which has the possibility of getting
>>>>>>>>>>>>> caught in infinite recursion cannot return a result and
>>>>>>>>>>>>> therefore cannot constitute a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except in those cases that it has not been caught in infinite
>>>>>>>>>>>> recursion and does return a result to its caller.
>>>>>>>>>>>>
>>>>>>>>>>>> Alternatively a function that can and does correctly detect
>>>>>>>>>>>> infinite recursion on itself and return its decision to its
>>>>>>>>>>>> caller does not count.
>>>>>>>>>>>>
>>>>>>>>>>>> Basically you are saying that it is wrong all of the time even
>>>>>>>>>>>> though it is right some of the time.
>>>>>>>>>>>
>>>>>>>>>>> No. I am saying that it is not a decider. A decider *must* return
>>>>>>>>>>> a result for *all* inputs. That's the definition of 'decider'.
>>>>>>>>>>> Something that only returns results in some instances is not a
>>>>>>>>>>> decider. I don't know how I can make this any clearer...
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The way that you are defining it when a function does correctly
>>>>>>>>>> decide that it has been infinitely invoked that even though this
>>>>>>>>>> decision is correct it does not count.
>>>>>>>>>>
>>>>>>>>>> Since a partial decider <is> a decider for some inputs and not for
>>>>>>>>>> other inputs, then this same idea can be extended to some
>>>>>>>>>> invocations and not all invocations, otherwise correctly deciding
>>>>>>>>>> infinite recursion does not count even when the decision is correct.
>>>>>>>>>
>>>>>>>>> A partial decider is not a decider any more than a half-dollar is a
>>>>>>>>> dollar. A partial decider is something that correctly decides some
>>>>>>>>> cases, not something which is a decider in some cases. Things are
>>>>>>>>> either deciders or they aren't.
>>>>>>>>>
>>>>>>>> A partial decider that decides the {Linz, Sipser, Kozen}
>>>>>>>> counter-examples refutes these three proofs.
>>>>>>>>
>>>>>>>>> That a program correctly decides some cases does not make it a
>>>>>>>>> decider in those cases. You could call it a partial decider, but
>>>>>>>>> not a decider.
>>>>>>>>>
>>>>>>>>> However, in the case of your program, you can't even call it that
>>>>>>>>> because it sometimes returns and other times does not return *on
>>>>>>>>> the same input*. A partial decider is something which decides some
>>>>>>>>> set of inputs and fails to decide another, *disjoint* set of
>>>>>>>>> inputs. Something which gets different results for the same input
>>>>>>>>> isn't even a function, let alone a decider or partial decider.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> So in other words when a partial decider correctly determines that
>>>>>>>> it has been invoked in infinite recursion it must fix the bug in
>>>>>>>> this infinitely recursive invocation so that it can report its
>>>>>>>> infinitely recursive invocation to its infinitely recursive caller,
>>>>>>>> that is no longer infinitely recursive because it fixed this bug.
>>>>>>>>
>>>>>>>> <sarcasm>
>>>>>>>> That makes perfect sense to me.
>>>>>>>> </sarcasm>
>>>>>>>
>>>>>>> No, I did not say that. You need to make at least some effort to read
>>>>>>> for comprehension. I said that something which can be caught in
>>>>>>> infinite recursion is *not* a decider. This is getting rather
>>>>>>> tedious. Something that correctly decides some cases but not others
>>>>>>> could be a partial decider, but not if it decides the *same* input in
>>>>>>> some cases but not others.
>>>>>>>
>>>>>>
>>>>>> 01 void H_Hat(u32 P)
>>>>>> 02 {
>>>>>> 03 u32 Input_Halts = DebugTrace(P, P);
>>>>>> 04 if (Input_Halts)
>>>>>> 05 HERE: goto HERE;
>>>>>> 06 else
>>>>>> 07 HALT
>>>>>> 08 }
>>>>>>
>>>>>> Halts((u32)H_Hat,(u32)H_Hat) is correctly decided** as not halting
>>>>>> because it aborts the invocation of itself on line 03.
>>>>>
>>>>> You've switched back from using Halts() to using DebugTrace(). Are these
>>>>> intended to be distinct functions?
>>>>>
>>>>>> ** Halts returns the correct halting determination.
>>>>>>
>>>>>> According to your way of defining a decider:
>>>>>> (a) Halts is not a decider even though it correctly decides.
>>>>>> (b) Halts would be a decider if it aborted the infinite recursion of
>>>>>> any other function besides itself.
>>>>>>
>>>>>> That is ridiculous!
>>>>> Look, a decider is a type of *function*. To be a function, something
>>>>> must consistently map the same input to the same result, but that isn't
>>>>> what you get above. Assuming that your DebugTrace() and Halts() are
>>>>> intended to be the same, you are claiming that
>>>>>
>>>>> Halts(H_Hat, H_Hat)
>>>>>
>>>>> returns false. This means Halts(H_Hat, H_Hat) is a finite computation.
>>>>>
>>>>> But by returning false is is also claiming that the instance of
>>>>> Halts(H_Hat, H_Hat) invoked from within H_Hat must be aborted as a
>>>>> non-halting function.
>>>>>
>>>>> This is a contradiction.
>>>> As I have said very many times (no one notices because they only glance
>>>> at a few of my words to contrive some lame basis for a rebuttal that
>>>> would fool the gullible):
>>>>
>>>> Halts(H_Hat, H_Hat) is only a finite computation because it aborts the
>>>> otherwise infinite recursion of its input according to this criteria:
>>>>
>>>> On 11/27/2020 9:02 PM, Ben Bacarisse wrote:
>>>>> A computation that would not halt if its simulation were not
>>>>> halted is indeed a non-halting computation.
>>>>
>>> If Halts aborts itself, is it halted or aborted? That's the question.
>>>
>>
>> Halts() simulates H_Hat() that invokes Halts() in infinite recursion.
>> Halts() stops simulating H_Hat() including its infinite recursive
>> invocation of Halts(), returning its non-halting decision to main()
>> where it is output.
>>
>>> If we say "halted" then H_Hat inverts whatever result it returns,
>>
>> It is not possible for an aborted function to invert any damn thing.
>>
>>> and :Halts" is wrong. If we say "aborted" then "Halts" isn't a function,
>>> which is a slightly more subtle requirement of H_Hat.
>>
>> Certainly an at least partial halt decider that bases its halting
>> decision by looking for patterns of behavior of its inputs can stop
>> simulating this input as soon as it detects any non-halting pattern.
>>
>> It does not make any damn difference if it detects an infinite loop, or
>> infinite recursion. It also does not make any damn difference which
>> function is involved in infinite recursion. As long as Halts() detects
>> the non-halting behavior of its input then it can stop simulating this
>> input and report non-halting.
>>
>> void H_Hat(u32 P)
>> {
>> u32 Input_Halts = Halts(P, P);
>> if (Input_Halts)
>> HERE: goto HERE;
>> else
>> HALT
>> }
>>
>>
>> int main()
>> {
>> u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
>> Output("[Input_Would_Halt] =", Input_Would_Halt);
>> HALT;
>> }
>>
>> I finally renamed my internal DebugTrace() to Halts() now that it
>> finally does return its correct halting decision to main().
>
> Your techique is suspicious, because you're transcribing the pseudo-code
> from the usual halting proofs into the higher level C language, but then
> are messing with the execution at a lower level. The mapping between the
> C language and abstract concepts like "pure function of certain
> arguments" only depends on certain conventions being upheld in the
> machine language translation, and the expected execution model for which
> the translation is made.
>

At the TM level is is merely the execution of a TM on a finite string,
in this case the TM a a halt decider based on a UTM.

It is not the details of the C/x86 implementation that are important it
is whether or not the architecture of the C/x86 implementation maps to a
TM solution.

> Halts is not a pure function, or else not a pure function of the
> two arguments that are visible at the C source code level.
>

We need the mapping to the x86 level so that we have a complete di-graph
graph of all control flow, the C level does not provide this.
https://en.wikipedia.org/wiki/Directed_graph

> I have a similar C program for GNU/Linux which doesn't require any
> complicated virtual machine. In my program, I reveal everything I'm
> doing.
>
> My program calls H_Hat(H_Hat), showing that it halts, and then
> it shows that Halts(H_Hat, H_Hat) decides correctly:
>
> $ ./fakehalt
> Got here so H_Hat(H_Hat) halted!
> H_Hat(H_Hat) halts!
>
> Source of fakehalt.c follows. Note that Halts does not rely on any
> mutating global state or anything. The subterfuge is that because
> Halts uses debugging introspection to inspect the machine state, it is
> not simply a function of the declared arguments. My Halts is a function
> of the entire call stack, and using that call stack it can tell that
> it's being called directly from main, with no H_Hat involved.
>

I don't currently need to look at the stack. I merely examine the
complete sequence of every x86 instruction that has been executed in
user code.

In any case it does not matter what the Hell that I do as long as there
are no inputs that are provably undecidable.

> You must be perpetrating the moral equivalent of this trick in your
> code. This will be easily shown when you reveal all the end-to-end
> processing details.
>
> #include <stdio.h>
> #include <execinfo.h>
>
> typedef void (*fun_t)(void *data);
> typedef int (*decider_t)(fun_t, void *data);
>
> int Halts(fun_t, void *);
>
> void H_Hat(void *data)
> {
> if (Halts((fun_t) data, data)) {
> for (;;)
> fflush(stdout);
> } else {
> return;
> }
> }
>
> int Halts(fun_t fun, void *data)
> {
> void *buffer[10];
> int i, ncallers = backtrace(buffer, 10);
>
> (void) fun;
> (void) data;
>
> for (i = 0; i < ncallers; i++)
> if (buffer[i] >= (void *) H_Hat && buffer[i] < (void *) Halts)
> return 0;
>
> return 1;
> }
>
> int main(void)
> {
> H_Hat((void *) H_Hat);
>
> puts("Got here so H_Hat(H_Hat) halted!");
>
> if (Halts(H_Hat, (void *) H_Hat))
> puts("H_Hat(H_Hat) halts!");
> else
> puts("H_Hat(H_Hat) doesn't halt!");
>
> return 0;
> }
>


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[wolfgang kern]

removed theory etc.

On 14.12.2020 22:56, olcott wrote and cyted:

A LOT of useless HLL lines.
please don't bother us here with this, it's an assembler group.
__
wolfgang

[olcott]

That last message was sent by mistake.

This is the only one that might be relevant to this group:
I refuted the halting problem proofs by building a universal Turing
machine that has the x86 language as its machine description language.
The key aspect of this proof is the x86 execution trace at the bottom of
this message.

If you have a good understanding of:
(a) software engineering,
(b) The C programming language
(c) The x86 programming language

You will be able to easily verify that Halts() does correctly decide the
halt status of H_Hat().

The x86utm operating system provides the operating environment to
execute virtual machines computationally equivalent to universal Turing
machines having the x86 language as their machine description language.
x86utm executes the COFF object file output of the Microsoft C compiler.
The x86utm operating system is based on a world class x86 emulator that
has been developed and tested for decades.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
It is common knowledge that all x86 based programs are computationally
equivalent to UTMs for every computation that does not require more
memory than they have.

This is the generic halt deciding criteria:
On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote:
> Every computation that would not halt if its simulation
> were not halted is by logical necessity a non-halting computation.

We can verify that the following execution trace of the computational
equivalent of:
(a) {Peter Linz: H, Michael Sipser: H, Dexter Kozen: K}
Correctly decides halting on the the computational equivalent of:
(b) {Peter Linz: Ĥ, Michael Sipser: D, Dexter Kozen: N}

The following execution trace can be verified as correctly deciding the
halting status of its input with only these three prerequisites and
nothing more:

(a) An elementary understanding of software engineering, such things as:
(a) infinite loops do not have a fixed number of iterations and (b)
infinitely recursive invocations never return any value to their caller.

(b) A basic understanding of how the C programming language maps to x86
instructions. This is used to verify that the translations of the "C"
functions into their x86 equivalents are correct. It is also used to
verifiy that the execution trace of these x86 functions is correct.

(c) An understanding of one very elementary infinite recursion detection
algorithm: Whenever an execution trace shows a second call to the same
function from the same machine address with no control flow instructions
in-between this second invocation is always an instance of infinite
recursion. From this it is very easy to see that the halt decider did
apply this simple criteria in its halt deciding decision, thus meeting
he generic criteria shown above.

Actual debug trace of Halts() deciding halting on H_Hat()

#define HALT __asm hlt

void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
else
HALT
}

int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);

Output_Debug_Trace();

Output("Input_Would_Halt =", Input_Would_Halt);
HALT;
}

_H_Hat()
[000005e6](01) 55 push ebp
[000005e7](02) 8bec mov ebp,esp
[000005e9](01) 51 push ecx
[000005ea](03) 8b4508 mov eax,[ebp+08]
[000005ed](01) 50 push eax
[000005ee](03) 8b4d08 mov ecx,[ebp+08]
[000005f1](01) 51 push ecx
[000005f2](05) e8effdffff call 000003e6
[000005f7](03) 83c408 add esp,+08
[000005fa](03) 8945fc mov [ebp-04],eax
[000005fd](04) 837dfc00 cmp dword [ebp-04],+00
[00000601](02) 7404 jz 00000607
[00000603](02) ebfe jmp 00000603
[00000605](02) eb01 jmp 00000608
[00000607](01) f4 hlt
[00000608](02) 8be5 mov esp,ebp
[0000060a](01) 5d pop ebp
[0000060b](01) c3 ret

_main()
[00000616](01) 55 push ebp
[00000617](02) 8bec mov ebp,esp
[00000619](01) 51 push ecx
[0000061a](05) 68e6050000 push 000005e6
[0000061f](05) 68e6050000 push 000005e6
[00000624](05) e8bdfdffff call 000003e6
[00000629](03) 83c408 add esp,+08
[0000062c](03) 8945fc mov [ebp-04],eax
[0000062f](05) e8f2fcffff call 00000326
[00000634](03) 8b45fc mov eax,[ebp-04]
[00000637](01) 50 push eax
[00000638](05) 68a3020000 push 000002a3
[0000063d](05) e894fcffff call 000002d6
[00000642](03) 83c408 add esp,+08
[00000645](01) f4 hlt
[00000646](02) 8be5 mov esp,ebp
[00000648](01) 5d pop ebp
[00000649](01) c3 ret

Output_Debug_Trace() Trace_List.size(24)
---[00000616](01) 55 push ebp
---[00000617](02) 8bec mov ebp,esp
---[00000619](01) 51 push ecx
---[0000061a](05) 68e6050000 push 000005e6
---[0000061f](05) 68e6050000 push 000005e6
---[00000624](05) e8bdfdffff call 000003e6 --CALL [000003e6]
---[000005e6](01) 55 push ebp
---[000005e7](02) 8bec mov ebp,esp
---[000005e9](01) 51 push ecx
---[000005ea](03) 8b4508 mov eax,[ebp+08]
---[000005ed](01) 50 push eax
---[000005ee](03) 8b4d08 mov ecx,[ebp+08]
---[000005f1](01) 51 push ecx
---[000005f2](05) e8effdffff call 000003e6 --CALL [000003e6]
---[000005e6](01) 55 push ebp
---[000005e7](02) 8bec mov ebp,esp
---[000005e9](01) 51 push ecx
---[000005ea](03) 8b4508 mov eax,[ebp+08]
---[000005ed](01) 50 push eax
---[000005ee](03) 8b4d08 mov ecx,[ebp+08]
---[000005f1](01) 51 push ecx
---[000005f2](05) e8effdffff call 000003e6 --CALL [000003e6]
Input Aborted because of INFINITE RECURSION from [000005f2] to [000003e6]
---[00000629](03) 83c408 add esp,+08
---[0000062c](03) 8945fc mov [ebp-04],eax
===[0000062f](05) e8f2fcffff call 00000326
....[00000634](03) 8b45fc mov eax,[ebp-04]
....[00000637](01) 50 push eax
....[00000638](05) 68a3020000 push 000002a3
===[0000063d](05) e894fcffff call 000002d6
Input_Would_Halt = 0
....[00000642](03) 83c408 add esp,+08
....[00000645](01) f4 hlt

Every time that the same function is called from the same machine
address a second time without any control flow instructions in-between
is a case of infinite recursion.
This is shown at execution trace lines 14-22 above.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

http://www.liarparadox.org/sipser_165.pdf

Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (165-167)

http://www.liarparadox.org/kozen_233.pdf

The Kozen computation is identical to the Peter Linz computation merely
swapping function names Linz.H is swapped for Kozen.K and Linz.Ĥ is
swapped for Kozen.N

Kozen, Dexter 1997. Automata and Computability. New York:
Springer-Verlag. (231-234).

[Frank Kotler]

On 12/16/2020 08:40 PM, olcott wrote:
> On 12/15/2020 3:05 AM, wolfgang kern wrote:
>> removed theory etc.
>>
>> On 14.12.2020 22:56, olcott wrote and cyted:
>>
>> A LOT of useless HLL lines.
>> please don't bother us here with this, it's an assembler group.
>> __
>> wolfgang
>>
>
> That last message was sent by mistake.
>
> This is the only one that might be relevant to this group:

Hi Pete,

As moderator of this newsgroup, I am very reluctant to reject your
messages just because I'm not interested (but I'm not). Woifgang's
message makes me think I'm not the only one...

Could I ask you to not post on this topic here?

Could I ask Wolfgang (and others) to simply ignore messages you don't
like? It only takes you a second to click "next".

There's an "issue" here. If clax86 is on the lost of newsgroups, it
comes to my attention. If I reject it - NONE of the messages get posted!
If it were up to me, it wouldn't work this way, but it isn't.

So I think we'll all be happier if clax86 is off your list

I'm sorry this is a problem.

Best,
Frank
moderator
fbkk...@myfairpoint.net

[Terje Mathisen]

This is a _big_ problem imho, you Frank have been a lot more patient
that I would have been, I would have at a minimum grey-listed olcott,
i.e. only manually forwarded any messages that were clearly relevant to
clax.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[olcott]

One of my messages accidentally got cross-posted to this group.
Everytime that I reply to this message it gets cross-posted again.
I will try and find it and remove the cross-post link.

The people on comp.theory don't understand the x86 language well enough
to understand that my infinite recursion detection algorithm is correct.

[Frank Kotler]

On 12/17/2020 06:48 AM, Terje Mathisen wrote:

> This is a _big_ problem imho, you Frank have been a lot more patient
> that I would have been, I would have at a minimum grey-listed olcott,
> i.e. only manually forwarded any messages that were clearly relevant to
> clax.
>
> Terje
>

Sorry. I hope it is solved.

Best,
Frank

[olcott]

I initially accidentally added this group to the cross-post list because
I am unable to wear my glasses for a few weeks. I try to always post to
comp.theory and two other groups.

[James Harris]

On 17/12/2020 06:41, Frank Kotler wrote:

...

> Hi Pete,
>
> As moderator of this newsgroup, I am very reluctant to reject your
> messages just because I'm not interested (but I'm not). Woifgang's
> message makes me think I'm not the only one...
>
> Could I ask you to not post on this topic here?
>
> Could I ask Wolfgang (and others) to simply ignore messages you don't
> like? It only takes you a second to click "next".
>
> There's an "issue" here. If clax86 is on the lost of newsgroups, it
> comes to my attention. If I reject it - NONE of the messages get posted!
> If it were up to me, it wouldn't work this way, but it isn't.

Thanks for what you are doing, Frank. IIRC you are the only one who took
up the challenge of moderating this group and what you do for us is
appreciated.

At the risk of continuing a thread that is already off the topic of x86
asm I wonder if there's not some way the rest of us could make the job
of the moderator easier. Maybe that's something we should discuss.


--
James Harris

[Kerr-Mudd,John]

On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
<james.h...@nospicedham.gmail.com> wrote:

> On 17/12/2020 06:41, Frank Kotler wrote:
>
> ...
>
>> Hi Pete,
>>
>> As moderator of this newsgroup, I am very reluctant to reject your
>> messages just because I'm not interested (but I'm not). Woifgang's
>> message makes me think I'm not the only one...
>>
>> Could I ask you to not post on this topic here?
>>
>> Could I ask Wolfgang (and others) to simply ignore messages you don't
>> like? It only takes you a second to click "next".
>>

Sounds a sensible approach.

>> There's an "issue" here. If clax86 is on the lost of newsgroups, it
>> comes to my attention. If I reject it - NONE of the messages get
>> posted! If it were up to me, it wouldn't work this way, but it isn't.
>
> Thanks for what you are doing, Frank. IIRC you are the only one who
> took up the challenge of moderating this group and what you do for us
> is appreciated.
>
> At the risk of continuing a thread that is already off the topic of
> x86 asm I wonder if there's not some way the rest of us could make the
> job of the moderator easier. Maybe that's something we should discuss.
>

Is there any need for moderating? Just ignore any religious posts.

--
Bah, and indeed, Humbug.

[olcott]

My post was not totally off-topic because the most important part of
this post is examining the semantic meaning of the execution trace of
this sequence of x86 instructions:

---[000005e6](01) 55 push ebp
---[000005e7](02) 8bec mov ebp,esp
---[000005e9](01) 51 push ecx
---[000005ea](03) 8b4508 mov eax,[ebp+08]
---[000005ed](01) 50 push eax
---[000005ee](03) 8b4d08 mov ecx,[ebp+08]
---[000005f1](01) 51 push ecx
---[000005f2](05) e8effdffff call 000003e6 --CALL [000003e6]
---[000005e6](01) 55 push ebp
---[000005e7](02) 8bec mov ebp,esp
---[000005e9](01) 51 push ecx
---[000005ea](03) 8b4508 mov eax,[ebp+08]
---[000005ed](01) 50 push eax
---[000005ee](03) 8b4d08 mov ecx,[ebp+08]
---[000005f1](01) 51 push ecx
---[000005f2](05) e8effdffff call 000003e6 --CALL [000003e6]
Input Aborted because of INFINITE RECURSION from [000005f2] to [000003e6]

Every time that the same function is called from the same machine
address a second time without any control flow instructions in-between

(within an execution trace) is a case of infinite recursion. This is
shown at execution trace lines 1-16 above.

People on other groups do not know the x86 language well enough to
understand that this execution trace does specify infinite recursion.

[Terje Mathisen]

(To any comp.theory readers: I am getting this as scatter noise in the
moderated clax86 newsgroup where it is totally offtopic. :-( )

And you _really_ have no idea whatsoever about mathematical proofs if
you think that dressing your "proof" up as x86 asm makes _any_
difference at all. You could just as well have been trying to refute the
second law of thermodynamics. :-(

A few days ago you even provoked a math guy to explain why your idea is
totally bonkers.

"Extraordinary claims require extraordinary proof", what you have is
similar to my math teacher in secondary school who thought he had
invented a construction which could trisect an arbitrary angle. Even at
that time (i.e. when I was about 14/15 years old I found it quite easy
to prove that what he had was a method which quickly brought the error
down to well less than his pencil line thickness, but that's like
claiming that a specific rational number is equal to sqrt(2).

Again, this has nothing to do with x86 asm.

Terje

--
- <Terje.Mathisen at tmsw.no>

"almost all programming can be viewed as an exercise in caching"

[olcott]

All that I am asking members of the comp.lang.asm.x86 group to do is
explain that the above execution trace does specify infinite recursion.

If you don't know the x86 language or software engineering well enough
to answer this then you can simply refrain from responding.

[Frank Kotler]

On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
> On Sat, 19 Dec 2020 11:57:28 GMT, James Harris

...

>> At the risk of continuing a thread that is already off the topic of
>> x86 asm I wonder if there's not some way the rest of us could make the
>> job of the moderator easier. Maybe that's something we should discuss.
>>
> Is there any need for moderating? Just ignore any religious posts.
>

Thank you,,,

Unfortunately, without approval from a moderator, nothing will get
posted at all. I am advised that removing the group from moderation will
make matters worse. Perhaps we should try it?

comp.lang.asm - the unmoderated group - may still exist. We could try
that. Last I tried it, it worked. Your server may not carry it.

I would like to have an "assistant" - if I can even remember that
address - just to have a moderator in line when I kick off. The mailbox
is the real moderator. Terje is providing the mailbox and may be stuck
with it. Any "approved:" header works... you may need special permission
to post with such a header. Depends om the server, I think.

Meanwhile, I'll try to approve the on-topic stuff - just ohnore the
off-topic stuff that slips by me...

Best,
Frank

[Rod Pemberton]

On Sat, 19 Dec 2020 19:13:31 -0500
Frank Kotler <fbko...@nospicedham.myfairpoint.net> wrote:

> On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:

> > Is there any need for moderating? Just ignore any religious posts.
> >
>
> Thank you,,,
>
> Unfortunately, without approval from a moderator, nothing will get
> posted at all. I am advised that removing the group from moderation
> will make matters worse. Perhaps we should try it?

Well, I seem to recall asking for a casual "vote" on this a few times,
but no one ever really did state their preferences ... Is everyone just
indifferent about CLAX's future?


Option A: keep comp.lang.asm.x86 (CLAX) alive
1) auto-approve all messages to CLAX
2) alternately, find a backup moderator

Option B: kill the group
1) halt approval of all messages to CLAX

Option C: move the group
1) auto-approve everyone posting to CLAX
2) but, post all messages to a different newsgroup
3) optionally, set message follow-ups to the new newsgroup

> comp.lang.asm - the unmoderated group - may still exist. We could try
> that. Last I tried it, it worked. Your server may not carry it.

I don't see comp.lang.asm (CLA) on either of two free-to-read Usenet
servers. Google Groups now requires an account to read or search Usenet
groups there. The CLA group is also not listed for Eternal-September's
webpage Usenet hierarchy search. Personally, I would prefer to have CLAX
traffic re-routed to alt.lang.asm (ALA). ALA has seemed to be widely
available over the past fifteen years or so, and has less traffic than
CLAX. IIRC, you sent rejected messages there in the past. The only
disadvantage - besides nuisance posts - is that ALA is on alt.*
hierarchy instead of comp.* hierarchy. I.e., some servers might not
have the alt.* hierarchy because of binaries, and I don't recall ever
seeing Terje post there. IIRC, Herbert is the only one to get a
non-moderator Approved header through, or was that Wolfgang? ...

--
The EU mocked the US response to Covid in the spring of 2020. With a
massive resurgence of Covid in the EU, they aren't laughing now.

[James Harris]

On 20/12/2020 00:13, Frank Kotler wrote:
> On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
>> On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
>
> ...
>>> At the risk of continuing a thread that is already off the topic of
>>> x86 asm I wonder if there's not some way the rest of us could make the
>>> job of the moderator easier. Maybe that's something we should discuss.
>>>
>> Is there any need for moderating? Just ignore any religious posts.

I think there is. I appreciate the moderation. It stops this group being
flooded with posts which are completely off topic as is happening to
other groups.

That said, I wonder if those of us who post here could make the job of
the moderator a bit easier. Specifically:

For me, the best thing about moderation is that it filters out the
garbage which is unquestionably spam. I mean things such as adverts for
manuals or for medicines etc. Personally, I don't mind topics like
olcott's which are only vaguely related to asm programming: such things
could be a problem if the group was very busy with them but it's not.
And it's no problem at all for the rest of us to delete or ignore any
messages we personally feel are too far away from x86 asm.

Don't get me wrong. It would be nice to have only the 'right' messages
here but IMO that's an unnecessary ask of a moderator. For one thing,
each person will have his own idea as to which messages are 'right'. For
another, each of us can decide for himself which messages to read. It's
no great trouble to do so.

So ISTM (and this is just my view) the best balance is to whitelist
those who write about anything vaguely connected with x86 assembly,
causing all spam (adverts etc) to be filtered out, and to leave it to
the members of the group to deal with questions of what they consider to
be strictly on topic or not.

Further, if a whitelisted poster goes rogue and starts to try to use the
group to proselytise or publish other clearly off-topic writings that he
knows it's wrong to post I would be happy to see him removed from the
whitelist without mercy! And to be kept off for a long, long time. There
is at least one unmoderated asm group for such people to use.

AISI that lot would ask the least of the moderator while also keeping
the group clear of spam.

But that's just my view.

...

> comp.lang.asm - the unmoderated group - may still exist. We could try
> that. Last I tried it, it worked. Your server may not carry it.

I don't think there's a comp.lang.asm but there is an alt.lang.asm which
is unmoderated.

...

> Meanwhile, I'll try to approve the on-topic stuff - just ohnore the
> off-topic stuff that slips by me...

Thanks for what you've been doing for us, Frank.


--
James Harris

[Robert Prins]

On 2020-12-20 00:13, Frank Kotler wrote:
> On 12/19/2020 07:22 AM, Kerr-Mudd,John wrote:
>> On Sat, 19 Dec 2020 11:57:28 GMT, James Harris
>
> ...
>>> At the risk of continuing a thread that is already off the topic of
>>> x86 asm I wonder if there's not some way the rest of us could make the
>>> job of the moderator easier. Maybe that's something we should discuss.
>>>
>> Is there any need for moderating? Just ignore any religious posts.
>>
>
> Thank you,,,
>
> Unfortunately, without approval from a moderator, nothing will get posted at
> all. I am advised that removing the group from moderation will make matters
> worse. Perhaps we should try it?

Probably not before someone's figured out what would happen... I'm pretty sure I
once read that making a group moderated is easier than undoing it!

> comp.lang.asm - the unmoderated group - may still exist. We could try that. Last
> I tried it, it worked. Your server may not carry it.

That's a big show-stopper, Eternal September doesn't carry it, just as is
doesn't carry comp.lang.pascal, whereas is does carry all its
"comp.lang.pascal.*" descendants!

> I would like to have an "assistant" - if I can  even remember that address -
> just to have a moderator in line when I kick off. The mailbox is the real
> moderator. Terje is providing the mailbox and may be stuck with it. Any
> "approved:" header works... you may need special permission to post with such a
> header. Depends om the server, I think.

Just explain what's involved being a moderator. If it's merely a matter of
ticking some boxes, more than a few of us would probably be willing to give a hand!

I'm an admin on <http://zos.efglobe.com/index.php> and weeding out the spam
would just take a few minutes of my time. (Would, because we've closed to forum
(for now/ever?) as the z/OS system is no longer available)

> Meanwhile, I'll try to approve the on-topic stuff - just ohnore the off-topic
> stuff that slips by me...

I like the earlier posted suggestion of an approved-poster list.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

[Terje Mathisen]

This seems like a no-brainer:

Three lists:

White - pass through automatically.
Grey - require manual approval, increment good/bad counters until N
messages. Here I would guess that N = 3 is sufficient as long as they
are all of the same type. Maybe require something like

(good >= 3) && ((good-bad)/all > 0.8)

Black - remove automatically

A former good poster who starts spamming would then be given an email
warning and moved to the grey list with initial good/bad counts of 0/0.

Terje

--
- <Terje.Mathisen at tmsw.no>

"almost all programming can be viewed as an exercise in caching"

[Frank Kotler]

On 12/20/2020 04:40 PM, Terje Mathisen wrote:

...

> This seems like a no-brainer:
>
> Three lists:
>
> White - pass through automatically.

This is what I've got. I'm thinking of changing the name to
karenlist" so it won't be so racist (joke).

> Grey - require manual approval,

This is everything else.

increment good/bad counters until N
> messages. Here I would guess that N = 3 is sufficient as long as they
> are all of the same type. Maybe require something like
>
>   (good >= 3) && ((good-bad)/all > 0.8)
>

???

> Black - remove automatically

With one exception, I do not automatically reject anything. When I first
got into this, there were many messages - several per day - with the
word "Viagra" in the subject line. Those I rejected. Doesn't happen any
more - there are very few "bad" messages. I don't know why. Once in a
while, a long (50k or more) "binary" (no regular linefeeds) message
named "Confirmation of your order" or so. Malware, I assume. Only a few
that want to sell us a fake watch or a fake diploma. An occasional gal
who has seen our profile and wants to be our girlfriend... Used to be
much more... I can't predict the names. so can't have a "blacklist". I
just delete 'em by hand,

> A former good poster who starts spamming would then be given an email
> warning and moved to the grey list with initial good/bad counts of 0/0.

I think there is only one individual who has been permanently removed
from the whitelist. (not Rick - he is very cooperative!). He was
insulting to a member (Rod). If he'd posted something on-topic_he would
have been back on, but he just wanted to argue with me. There is no
point in arguing with a moderator... you might be right, but you won't
win. :)

Then there are certain messages from Pete, which are - at least
sometimes - "sorta" on-topic or "almost" on-topic. but which we don't
seem to want to see here. I'm hoping I can leave Pete on the whitelist
and ask him not to post them here and ask the rest of us to be tolerant.
One way or another I hope it'll work out...

Best,
Frank

[wolfgang kern]

On 19.12.2020 22:25, olcott wrote:

> All that I am asking members of the comp.lang.asm.x86 group to do is
> explain that the above execution trace does specify infinite recursion.

> If you don't know the x86 language or software engineering well enough
> to answer this then you can simply refrain from responding.

you wont see any answer to this because of "unknown call target".
it's only recursive (error stack overflow) if 05e6 is part of 03e6.
there are much easier ways to produce such errors.
__
wolfgang
sorry Frank, I cannot stay quiet on illogical assumptions.

[Bernhard Schornak]

olcott wrote:

_H_Hat:

[000005e6](01) 55 push ebp
[000005e7](02) 8bec mov ebp,esp
[000005e9](01) 51 push ecx
[000005ea](03) 8b4508 mov eax,[ebp+08]
[000005ed](01) 50 push eax
[000005ee](03) 8b4d08 mov ecx,[ebp+08]
[000005f1](01) 51 push ecx
[000005f2](05) e8effdffff call 000003e6
[000005f7](03) 83c408 add esp,+08
[000005fa](03) 8945fc mov [ebp-04],eax
[000005fd](04) 837dfc00 cmp dword [ebp-04],+00
[00000601](02) 7404 jz 00000607
[00000603](02) ebfe jmp 00000603
[00000605](02) eb01 jmp 00000608
[00000607](01) f4 hlt
[00000608](02) 8be5 mov esp,ebp
[0000060a](01) 5d pop ebp
[0000060b](01) c3 ret

0603 jumps to itself. Reduce to

_H-Hat:movl 0x0C(%esp), %eax
subl $0x08, %esp
movl %eax, 0x00(%esp)
movl %eax, 0x04(%esp)
call _WHATEVER_THAT_IS
testl %eax, %eax
je 0f
L00:jmp L00 # loop forever
0:hlt # CLI/STI?
addl $0x08, %esp
ret



As long as the code at 0x03E6 is unknown, it is impossible to tell
anything. _H_Hat itself does nothing ... except wasting clocks and
electrical power when the returned value is not zero.

The only thing I can see in your debug trace is that you would run
out of stack, if the debugger did not stop your attempts with this
error message before ESP reached your stack's bottom. Maybe a good
proof the debugger works well, but nothing else... ;)


Merry Winter Solstice!

Bernhard Schornak

[olcott]

That is the answer that I expected and confirms that I am correct.

I am using the x86 code that was translated from C as the machine
description language of a Universal Turing Machine equivalent. I wrote a
whole x86utm operating system for this purpose. This means that the
assumption is infinite memory and thus infinite stack.

> if the debugger did not stop your attempts with this
> error message before ESP reached your stack's bottom. Maybe a good
> proof the debugger works well, but nothing else... ;)
>

In my actual test case the debugger is a halt decider that recognizes
the pattern, (in my prior post) stops simulating this code and reports
not halting.

It turns out that all the halting problem proofs depend on the
assumption that such a halt decider is impossible.

Thanks for your help. The people in the other forums don't seem to have
a clue about the x86 language.

>
> Merry Winter Solstice!
>
> Bernhard Schornak
>

[Robert]

In comp.lang.asm.x86 olcott <No...@nospicedham.nowhere.com> wrote in part:

> On 12/22/2020 4:07 AM, Bernhard Schornak wrote:
>> olcott wrote:
>>
>> _H_Hat:

>> [000005e6](01)? 55????????????????? push ebp
>> [000005e7](02)? 8bec??????????????? mov ebp,esp
>> [000005e9](01)? 51????????????????? push ecx
>> [000005ea](03)? 8b4508????????????? mov eax,[ebp+08]
>> [000005ed](01)? 50????????????????? push eax
>> [000005ee](03)? 8b4d08????????????? mov ecx,[ebp+08]
>> [000005f1](01)? 51????????????????? push ecx
>> [000005f2](05)? e8effdffff????????? call 000003e6
>> [000005f7](03)? 83c408????????????? add esp,+08
>> [000005fa](03)? 8945fc????????????? mov [ebp-04],eax
>> [000005fd](04)? 837dfc00??????????? cmp dword [ebp-04],+00
>> [00000601](02)? 7404??????????????? jz 00000607
>> [00000603](02)? ebfe??????????????? jmp 00000603
>> [00000605](02)? eb01??????????????? jmp 00000608
>> [00000607](01)? f4????????????????? hlt
>> [00000608](02)? 8be5??????????????? mov esp,ebp
>> [0000060a](01)? 5d????????????????? pop ebp
>> [0000060b](01)? c3????????????????? ret

>>
>>
>> 0603 jumps to itself. Reduce to
>>

>> _H-Hat:movl? 0x0C(%esp), %eax
>> ?????? subl? $0x08,????? %esp
>> ?????? movl? %eax,?????? 0x00(%esp)
>> ?????? movl? %eax,?????? 0x04(%esp)
>> ?????? call? _WHATEVER_THAT_IS
>> ?????? testl %eax,?????? %eax
>> ?????? je??? 0f
>> ?? L00:jmp?? L00????????????????????? # loop forever
>> ???? 0:hlt??????????????????????????? # CLI/STI?
>> ?????? addl $0x08,?????? %esp
>> ?????? ret

>>
>>
>>
>> As long as the code at 0x03E6 is unknown, it is impossible to tell
>> anything. _H_Hat itself does nothing ... except wasting clocks and
>> electrical power when the returned value is not zero.
>>
>> The only thing I can see in your debug trace is that you would run
>> out of stack,

If it doesn't get caught in the infinite loop at 603, likely less
than one million before you hit the stack guard page.

> That is the answer that I expected and confirms that I am correct.
>
> I am using the x86 code that was translated from C as the
> machine description language of a Universal Turing Machine
> equivalent. I wrote a whole x86utm operating system for
> this purpose. This means that the assumption is infinite
> memory and thus infinite stack.

??? I don't think any general-use compiler will emit a HLT
instruction. No need, this is a priviliged ring0 instruction
on modern x86 p-mode OSes.

-- Robert

[Frank Kotler]

Okay Wolfgang - I w0n't remove ya from the whitelist. :)

This seems "on-topic" to me. Weren't you one of the ones who was
complaining? Apologize to Terje! (seriously - hope this isn't a problem)

Best,
Frank

[olcott]

It is only this portion of the excution trace of H_Hat that I am
referring to. The second call 000003e6 from the same machine address
[000005f2] without any control flow instructions inbetween indicates
infinite recursion. Many of the comp.theory people could not understand
this.

---[000005e6](01) 55 push ebp
---[000005e7](02) 8bec mov ebp,esp
---[000005e9](01) 51 push ecx
---[000005ea](03) 8b4508 mov eax,[ebp+08]
---[000005ed](01) 50 push eax
---[000005ee](03) 8b4d08 mov ecx,[ebp+08]
---[000005f1](01) 51 push ecx
---[000005f2](05) e8effdffff call 000003e6 --CALL [000003e6]
---[000005e6](01) 55 push ebp
---[000005e7](02) 8bec mov ebp,esp
---[000005e9](01) 51 push ecx
---[000005ea](03) 8b4508 mov eax,[ebp+08]
---[000005ed](01) 50 push eax
---[000005ee](03) 8b4d08 mov ecx,[ebp+08]
---[000005f1](01) 51 push ecx
---[000005f2](05) e8effdffff call 000003e6 --CALL
[000003e6]

>> That is the answer that I expected and confirms that I am correct.
>>
>> I am using the x86 code that was translated from C as the
>> machine description language of a Universal Turing Machine
>> equivalent. I wrote a whole x86utm operating system for
>> this purpose. This means that the assumption is infinite
>> memory and thus infinite stack.
>
> ??? I don't think any general-use compiler will emit a HLT
> instruction. No need, this is a priviliged ring0 instruction
> on modern x86 p-mode OSes.
>
> -- Robert
>

I use it in the x86 emulator to indicate the that system definitely
stopped executing at this point. Before I used this instruction the
emulator tended to try to execute garbage. When it popped the return
from main() it had no where to go.

[Bernhard Schornak]

olcott wrote:


> I use it in the x86 emulator to indicate the that system definitely stopped executing at this point.
> Before I used this instruction the emulator tended to try to execute garbage. When it popped the
> return from main() it had no where to go.

This is circular reasoning, because your thought depends on
the unproven assumption your x86 emulator throws the proper
results under any circumstance. Does it work with any other
emulator, as well?


Greetings from Augsburg

Bernhard Schornak