Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can someone at least validate this criterion measure ?

36 views
Skip to first unread message

olcott

unread,
Jul 21, 2022, 11:21:10 PM7/21/22
to
*Infinite recursion / infinitely recursive emulation detection criteria*

int H(ptr p, ptr i)
{
p(i);
}

void P(ptr x)
{
H(x, x);
return;
}

int main()
{
H(P,P);
}

If the execution trace of function P() called by function H() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no control flow instructions between the invocation of P() and
the call to H() from P().

Then the function call from P() to H() is infinitely recursive.
The exact same pattern applies when H() simulates its input with an x86
emulator.

When H is an infinite recursion detector it simply matches the above
criteria in its execution trace of P, aborts its simulation of its input
and reports that its simulated input would never reach its "return"
instruction.

To avoid using static local memory for its stored execution trace H must
know its own address and see itself called from P with the same
arguments that it was called with.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

gdo...@gmail.com

unread,
Jul 22, 2022, 2:16:23 AM7/22/22
to

gdo...@gmail.com

unread,
Jul 22, 2022, 2:19:57 AM7/22/22
to
On Thursday, July 21, 2022 at 11:21:10 PM UTC-4, olcott wrote:
> *Infinite recursion / infinitely recursive emulation detection criteria*
>
You do realize this can not work right?
You are just having fun with it, right?

olcott

unread,
Jul 22, 2022, 5:04:33 AM7/22/22
to
On 7/22/2022 1:19 AM, gdo...@gmail.com wrote:
> You do realize this can not work right?
> You are just having fun with it, right?

That you made sure to erase everything that I said and reply in an empty
message seems like a dishonest play.

If you were to make an honest critique you would point out an example
where (1)(2)(3) are met and infinite recursion is not the case.

gdo...@gmail.com

unread,
Jul 22, 2022, 6:01:05 AM7/22/22
to
On Friday, July 22, 2022 at 5:04:33 AM UTC-4, olcott see.
Oh no, just figured there was no need to read the joke again.
We read it already, we get it.

You really aren’t serious right? But if you are, lol, I know you are just goofin around, where is your mathematical proof. I mean at least give it a shot. As you pursue it you will see it doesn’t work. Well if you prove it, won’t happen, then you have your answers.

How about where does it fail and why?
You need to phrase your question in such a manner before presentation.or are you saying you know it fails you just don’t see how?

olcott

unread,
Jul 22, 2022, 7:13:53 AM7/22/22
to
On 7/22/2022 5:00 AM, gdo...@gmail.com wrote:
> On Friday, July 22, 2022 at 5:04:33 AM UTC-4, olcott see.
> Oh no, just figured there was no need to read the joke again.
> We read it already, we get it.
>
> You really aren’t serious right? But if you are, lol, I know you are just goofin around, where is your mathematical proof.

The proof is provided in the semantics of the code that you keep erasing.

int H(ptr p, ptr i)
{
p(i);
}

void P(ptr x)
{
H(x, x);
return;
}

int main()
{
H(P,P);
}

If the execution trace of function P() called by function H() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no control flow instructions between the invocation of P() and
the call to H() from P().

Then the function call from P() to H() is infinitely recursive.
The exact same pattern applies when H() simulates its input with an x86
emulator.

A rebuttal would provide code that meets the criterai yet is not
infinitely recursive. It seems that you are technically incompetent to
provide this thus resort to playing head games in a lame attempt to mask
your incompetence.

>I mean at least give it a shot. As you pursue it you will see it doesn’t work. Well if you prove it, won’t happen, then you have your answers.
>
> How about where does it fail and why?
> You need to phrase your question in such a manner before presentation.or are you saying you know it fails you just don’t see how?


Mr Flibble

unread,
Jul 22, 2022, 7:19:50 AM7/22/22
to
Your H still gets the answer to the following wrong:

void Px(ptr x)
{
int Halt_Status = H(x, x);
(void) Halt_Status;
return;
}

Px always halts; the fact that your H disagrees is a symptom of the
fact that:

1) [Strachey 1965] and associated proofs have no recursion.
2) You are incorrect to map "infinite recursion" to "non-halting".
3) Given (1) and (2) your H is invalid.

/Flibble


olcott

unread,
Jul 22, 2022, 7:26:37 AM7/22/22
to
I have no idea what the second line means, casting an in to a void and
throwing away the result?

I am not asking whether or not Px(Px) halts.
I am asking whether or not the simulated Px reaches its "return"
instruction.

olcott

unread,
Jul 22, 2022, 7:28:14 AM7/22/22
to
casting an int to a void and

Richard Damon

unread,
Jul 22, 2022, 7:53:43 AM7/22/22
to
The standard idiom to indicate that the value will not be used to
silence the warning about that fact.

That you don't know this is an indication of your programming skill.

>
> I am not asking whether or not Px(Px) halts.
> I am asking whether or not the simulated Px reaches its "return"
> instruction.
>

Then you are asking the wrong question.

Yes, we can prove that H can never reach the ret instruction in its own
simulation, but any H that aborts based on this and returns 0 shows that
it does an incomplete emulation, which doesn't prove non-halting.

Giving that exact same input to a simulator that does run to completion,
while show that the COMPLETE simulation of the input WILL reach its
final instruction, thus if H is supposed to be using a criteria that is
compatible with the Halting Problem (the actual behavior of complete
machines, or the complete and correct emulation of them) then it is wrong.

All you have done is shown that your criteria doesn't match that so you
H is using an incorrect criteria to be an actual Halt Decider.

olcott

unread,
Jul 22, 2022, 9:00:24 AM7/22/22
to
Please to not reply here

olcott

unread,
Jul 22, 2022, 5:44:11 PM7/22/22
to
On 7/22/2022 4:12 PM, olcott wrote:
> On 7/22/2022 3:51 PM, Skep Dick wrote:
>> On Friday, 22 July 2022 at 22:08:28 UTC+2, olcott wrote:
>>> I do this by showing the criteria that humans use to recognize ordinary
>>> infinite recursion between two functions.
>>
>> The criteria humans use are not applicable to Turing machines.
>>
>> Because Turing-decidability and Human-decidability are not the same
>> thing.
>>
>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>
>
> If Turing machines cannot not see what humans see then Turing machines
> may be an incorrect model of computation.
>
>

Please stop cutting out the immediate context, leave at least the last
four messages.

If a Turing Machines cannot see that the input to a halt decider
specifies infinitely recursive simulation and humans can see this then
Turing machines must be not the best model of computation.

*Includes link to the entire halt deciding system including a link to*
*the compiler that compiles it: Microsoft Visual Studio Community 2017*

*Halting problem proofs refuted on the basis of software engineering* ?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

Chris M. Thomasson

unread,
Jul 22, 2022, 7:52:46 PM7/22/22
to
On 7/22/2022 2:43 PM, olcott wrote:
> On 7/22/2022 4:12 PM, olcott wrote:
>> On 7/22/2022 3:51 PM, Skep Dick wrote:
>>> On Friday, 22 July 2022 at 22:08:28 UTC+2, olcott wrote:
>>>> I do this by showing the criteria that humans use to recognize ordinary
>>>> infinite recursion between two functions.
>>>
>>> The criteria humans use are not applicable to Turing machines.
>>>
>>> Because Turing-decidability and Human-decidability are not the same
>>> thing.
>>>
>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>
>>
>> If Turing machines cannot not see what humans see then Turing machines
>> may be an incorrect model of computation.
>>
>>
>
> Please stop cutting out the immediate context, leave at least the last
> four messages.
[...]

The last 1000 messages?

olcott

unread,
Jul 22, 2022, 9:29:22 PM7/22/22
to
I apologize I meant to make very few posts to comp.c and comp.c++ and
always make the followup to comp.theory.

*If anyone replies to this post please change the group to comp.theory*

Mut...@dastardlyhq.com

unread,
Jul 23, 2022, 6:30:06 AM7/23/22
to
On Fri, 22 Jul 2022 20:28:58 -0500
olcott <No...@NoWhere.com> wrote:
>On 7/22/2022 6:52 PM, Chris M. Thomasson wrote:
>> On 7/22/2022 2:43 PM, olcott wrote:
>>> On 7/22/2022 4:12 PM, olcott wrote:
>>>> On 7/22/2022 3:51 PM, Skep Dick wrote:
>>>>> On Friday, 22 July 2022 at 22:08:28 UTC+2, olcott wrote:
>>>>>> I do this by showing the criteria that humans use to recognize
>>>>>> ordinary
>>>>>> infinite recursion between two functions.
>>>>>
>>>>> The criteria humans use are not applicable to Turing machines.
>>>>>
>>>>> Because Turing-decidability and Human-decidability are not the same
>>>>> thing.
>>>>>
>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>
>>>>
>>>> If Turing machines cannot not see what humans see then Turing
>>>> machines may be an incorrect model of computation.
>>>>
>>>>
>>>
>>> Please stop cutting out the immediate context, leave at least the last
>>> four messages.
>> [...]
>>
>> The last 1000 messages?
>>
>
>I apologize I meant to make very few posts to comp.c and comp.c++ and
>always make the followup to comp.theory.

No followup was set. You just crosspost everywhere.

>*If anyone replies to this post please change the group to comp.theory*

Hopefully that means he's buggered off!

0 new messages