Sunday, May 2, 2021

Digest for comp.lang.c++@googlegroups.com - 11 updates in 2 topics

Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: May 02 02:15PM +0100

Does anyone know the solution to the problem of halting olcott's Usenet posts?
 
/Flibble
 
--
😎
Kaz Kylheku <563-365-8930@kylheku.com>: May 02 02:03PM

> Does anyone know the solution to the problem of halting olcott's Usenet posts?
 
Everyone halts. For this case, specifically, there is an unproven
and empirically untested hypothesis about an early halt that occurs
if everyone stops responding.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Richard Harnden <richard.nospam@gmail.com>: May 02 03:15PM +0100

On 02/05/2021 15:03, Kaz Kylheku wrote:
 
> Everyone halts. For this case, specifically, there is an unproven
> and empirically untested hypothesis about an early halt that occurs
> if everyone stops responding.
 
We can ask him to stop. We can't prove that he will.
Bonita Montero <Bonita.Montero@gmail.com>: May 02 04:59PM +0200


> Everyone halts. For this case, specifically, there is an unproven
> and empirically untested hypothesis about an early halt that occurs
> if everyone stops responding.
 
The only halting-problem is whether he will halt to post off-topic
issues to comp.lang.c/c++.
Real Troll <real.troll@trolls.com>: May 02 04:20PM +0100

On 02/05/2021 14:15, Mr Flibble wrote:
> Does anyone know the solution to the problem of halting olcott's
> Usenet posts?
 
> /Flibble
 
Killfile should work for you. Try it.
 
I am surprised you are asking this because you like trolls here. I have seen you are responding to that religious nutter on every post he writes about his saviour Mr Christ.
olcott <NoOne@NoWhere.com>: May 02 10:30AM -0500

On 5/2/2021 9:03 AM, Kaz Kylheku wrote:
 
> Everyone halts. For this case, specifically, there is an unproven
> and empirically untested hypothesis about an early halt that occurs
> if everyone stops responding.
 
I am going to continue to post until an accurate review proves that I a
right or proves that I am wrong. This will remain true even if no one on
this forum ever responds. In this case the reason for posting is to
establish my copyright ownership of every incremental improvement.
 
Occasional cross-posts are for redundant backup of my key ideas
 
The bigger question is when are my reviewers going to provide an
accurate review?
 
It is a fact that this infinite recursion detection criteria is correct:
 
If the execution trace of function Y() shows:
function X() is called twice in sequence from the same machine address
of Y()
with the same parameters to X()
with no conditional branch or indexed jump instructions in Y()
with no function call returns from X()
then the function call from Y() to X() is infinitely recursive.
 
It is a fact that this criteria correctly decides all calls from
H_Hat() to Halts() are infinitely recursive:
 
If the execution trace of H_Hat() by function Halts() shows:
(1) Function Halts() is called twice in sequence from the same machine
address of H_Hat().
(2) With the same parameters to Halts().
(3) With no conditional branch or indexed jump instructions in H_Hat().
(4) With no function call returns from Halts().
then the function call from H_Hat() to Halts() is infinitely recursive.
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
 
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
 
All of the details including a fresh execution trace are provided here:
 
http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
 
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Real Troll <real.troll@trolls.com>: May 02 05:01PM +0100

> I am going to continue to post until an accurate review proves that I
> a right or proves that I am wrong.
 
 
Don't be sure about that because people will get fed up of you and write to your NewsServer provider:
 
<
abuse@giganews.com
 
So be very careful before you test people's tolerance threshold here.
olcott <NoOne@NoWhere.com>: May 02 12:21PM -0500

On 5/2/2021 11:01 AM, Real Troll wrote:
 
> <
> abuse@giganews.com
 
> So be very careful before you test people's tolerance threshold here.
 
Since all of my posts have the analysis of "C" code as their primary
focus, none of my posts can be reasonably construed as off topic for C
or C++ groups.
 
This is the "C" code that is the primary focus of all of my posts:
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
 
int main() {
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
 
Can a C/C++ function be defined that correctly decides whether or not
H_Hat((u32)H_Hat) halts?
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
wij <wyniijj@gmail.com>: May 02 12:04PM -0700

On Monday, 3 May 2021 at 01:21:31 UTC+8, olcott wrote:
> Copyright 2021 Pete Olcott
 
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein
 
I have not really read all your posts, and still do not really understand the appeal
of your question. So far as I understand:
 
Y() (H_Hat(u32)) can be written such that X() (Halts(u32,u32)) has no way
recognizing being simulated...(Why so much focus on recursions?)
 
Another one has nothing to do with 'pathological form'
 
// [Return] true (n is even): There exist two prime numbers a,b such that n=a+b
// false: Otherwise
bool is_goldbach(BigNum n);
 
void Y() {
for(BigNum n=4; is_goldbach(n); n+=2) {
}
}
 
Can your halting decider program decide whether or not Y() terminate?
olcott <NoOne@NoWhere.com>: May 02 03:08PM -0500

On 5/2/2021 2:04 PM, wij wrote:
 
> Y() (H_Hat(u32)) can be written such that X() (Halts(u32,u32)) has no way
> recognizing being simulated...(Why so much focus on recursions?)
 
> Another one has nothing to do with 'pathological form'
 
My halt decider does correctly decide the simplest example of the
halting problem undecidability proof counter-examples that are supposed
to "prove" that a universal halt decider is impossible:
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
 
int main()
{
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt = ", Input_Would_Halt);
}
 
All of the details including a full x86 execution trace are in this paper:
 
http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
 
 
> }
> }
 
> Can your halting decider program decide whether or not Y() terminate?
 
I am not going to begin to look at these things until after my first
proof is accepted as correct or proven to be incorrect.
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Paavo Helde <myfirstname@osa.pri.ee>: May 02 10:15PM +0300

01.05.2021 00:08 TDH1978 kirjutas:
 
>   X operator[](const Y& y) const
 
> over the 'non-const':
 
>   MyDBProxy_& operator[](const Y& y)
 
Which operator<<()? I your example there was none, and there is no default.
 
I guess you mean the line:
 
> cout << mydb[y] << endl; // compiler error; tries to print proxy
object and not 'x'.
 
Here, operator[] is called before passing the result to any operator<<,
existing or not. IOW, the meaning of 'mydb[y]' does not change depending
on the expression where it appears in.
 
Whether a const or non-const overload is preferred, is determined simply
by if 'mydb' is const or non-const. You can always cast to const if
that's what you need:
 
const MyDB& cmydb = mydb;
cout << cmydb[y] << endl
 
 
>   foo(mydb[y]);
 
> Would the compiler complain because it thinks mydb[y] returns the proxy
> and not x?
 
Why don't you try out and see it by yourself what happens? Such
experiments are a must if you want to understand how a language works.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)