Friday, April 30, 2021

Digest for comp.lang.c++@googlegroups.com - 8 updates in 4 topics

TDH1978 <thedeerhunter1978@movie.uni>: Apr 30 05:08PM -0400

On 2021-04-27 11:02:01 +0000, Paavo Helde said:
 
> os << proxy.get_value();
> return os;
> }
 
Thank you; I'm sure that would work, but I would have expected
operator<<() to prefer the 'const':
 
X operator[](const Y& y) const
 
over the 'non-const':
 
MyDBProxy_& operator[](const Y& y)
 
 
Do you know why the compiler is choosing one over the other?
 
What if, instead of operator<<(), I had a function:
 
void foo(const X& x);
 
and I pass it:
 
foo(mydb[y]);
 
Would the compiler complain because it thinks mydb[y] returns the proxy
and not x?
TDH1978 <thedeerhunter1978@movie.uni>: Apr 30 04:53PM -0400

On 2020-12-31 22:24:46 +0000, Keith Thompson said:
 
> problem (what you posted won't compile because uint8_t is not defined),
> along with the exact command line you used to compile it and the output
> of "gcc --version"?
 
I have upgraded to Fedora 34 and I can confirm that this warning does
not appear with gcc/g++ 11.0.1. This confirms my suspicion that this
was probably a compiler bug.
 
cmd> gcc --version
gcc (GCC) 11.0.1 20210324 (Red Hat 11.0.1-0)
olcott <polcott2@gmail.com>: Apr 29 07:08PM -0500

On 4/29/2021 5:24 PM, Ben Bacarisse wrote:
> important. But you refused to address this fundamental point. I asked:
 
> "First, do you really disagree with my simple statement that a
> computation that halts, for whatever reason, is a halting computation?
 
Yes you and I both disagree with this:
Yes you and I both disagree with this:
Yes you and I both disagree with this:
Yes you and I both disagree with this:
 
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. But a computation that
> would not halt and one that is halted are different computations.
 
 
void Infinite_Loop()
{
HERE: goto HERE;
}
 
The first sentence corresponds to a halt decider that simulates its
input and examines the execution trace to determine that a finite string
specifies infinite execution such as the above infinite loop. After the
halt decider determines that a finite string does specify infinite
execution the halt decider stops simulating this input and reports not
halting.
 
The second sentence is false because it would decide that the above
infinite loop is a halting computation on the basis that the halt
decider stopped simulating it.
 
 
--
Copyright 2021 Pete Olcott "Great spirits have always encountered
violent opposition from mediocre minds." Einstein
olcott <NoOne@NoWhere.com>: Apr 30 09:10AM -0500

On 4/30/2021 8:10 AM, Ben Bacarisse wrote:
 
>> I created those words, yours are merely a paraphrase of my words.
 
> Well that's good news. So you now agree with me that the computation
> that "would not halt" and the one that "is halted" are different?
 
I notice my error after I posted.
These are the words that are only a paraphrase of my own words:
>>>> 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.
 
< You
> that would not halt) as the answer for the one that is halted. But if
> you know they are different computations, you must surely reject your
> own trick.
 
Every computation that never stops unless its simulator stops simulating
it <is> a non halting computation.
 
void Infinite_Loop()
{
HERE: goto HERE;
}
 
void Infinite_Recursion(u32 N)
{
Infinite_Recursion(N);
}
 
void H_Hat2(u32 P)
{
u32 Input_Would_Halt = Simulate(P, P);
}
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
}
 
int main()
{
u32 Input_Would_Halt = Halts((u32)Infinite_Loop, (u32)Infinite_Loop);
u32 Input_Would_Halt = Halts((u32)Infinite_Recursion, 1);
u32 Input_Would_Halt = Halts((u32)H_Hat2, (u32)H_Hat2);
u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat);
}
 
All of the above functions are computations that never stop unless their
simulator stops simulating them and you know it.
 
 
 
> gone off the rails elsewhere. Unless you can agree that every
> computation that halts is halting computation, discussion of the halting
> problem is utterly pointless.
 
It depends on how you are defining your terms and the scope of what is
considered the computation.
 
When we have an infinite loop that halts because its simulator stopped
simulating it then we have an infinite loop that did halt yet its finite
string retains the property of infinite execution.
 
This counter-example correctly refutes your claim:
On 4/30/2021 8:10 AM, Ben Bacarisse wrote:
 
> I suppose we should add it to your other Great Equivocation. You need
> to accept, once and for all, that
 
> (A) Every instance of the halting problem has a correct yes/no answer.
 
I would not word it that way. Every complete Turing machine description
either halts on its input or fails to halt on its input when simulated
by a UTM.
 
> (B) Every computation that halts, for whatever reason, is a halting
> computation.
 
The equivocation on this statement is the last refuge for people that
have disagreement and rebuttal as a much higher priority than the mutual
understanding that can be achieved through an honest dialogue.
 
We can say that an infinite loop that was forced to halt by its
simulator on the basis that this simulator discerned that its input
finite string has the property of infinite execution is a halting
computation because it was forced to halt.
 
If we look at it this way then building a universal halt decider is
trivial we simply say that all inputs halt. It does not matter that they
halt on their own or are forced to halt because their simulation was
stopped, every input falls into one of these two categories.
 
// Proving that your reasoning is incorrect
bool Universal_Halt_Decider(u32 P, u32 I)
{
return true;
}
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
wij <wyniijj@gmail.com>: Apr 30 10:27AM -0700

On Friday, 30 April 2021 at 08:08:44 UTC+8, olcott wrote:
 
> --
> Copyright 2021 Pete Olcott "Great spirits have always encountered
> violent opposition from mediocre minds." Einstein
 
Let X(), Y() be the functions we had discussed before. (X the halt decider, Y the input program)
Y() is written AFTER X(). Such a Y() can do anything opposing what X() expect.
Otherwise, X() is probably not a deterministic function.
 
X() implies "P=NP", at least a one million dollar answer, maybe more.
Anyone has the answer you expect will win the prize, NOT YOU and no need to tell you.
olcott <NoOne@NoWhere.com>: Apr 30 01:04PM -0500

On 4/30/2021 12:27 PM, wij wrote:
> Otherwise, X() is probably not a deterministic function.
 
> X() implies "P=NP", at least a one million dollar answer, maybe more.
> Anyone has the answer you expect will win the prize, NOT YOU and no need to tell you.
 
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);
}
 
Although the "P=NP" stuff is totally out of the scope of my
investigation I have discovered that all of the conventional halting
problem undecidability proof counter-examples can be decided as not
halting on the basis that the specify infinite recursion to any halt
decider that bases its halting deciding decision on examining the
execution trace of its input.
 
I have the above fully operational in the x86utm operating system that I
wrote that is based on an x86 emulator.
 
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
Juha Nieminen <nospam@thanks.invalid>: Apr 30 10:10AM

> Because that bottleneck does not exist. All that time wasted and 1%
> of performance gained. Meanwhile possible opportunities to improve
> performance several times lost.
 
If an action that could take a hundreth of a second is instead
taking a second, there certainly is a bottleneck.
 
The problem is that if the bottleneck is distributed among
thousands of sloppily written lines, each with an attitude of
"this doesn't need to be efficient", you aren't going to fix
that bottleneck any time soon.
 
 
> I don't think someone deliberately wrote c.size()==0 when it was less
> efficient than c.empty() ... or it++ when ++it was more efficient. Their
> focus was simply on things that mattered.
 
When the attitude is "this doesn't need to be efficient", and
"it doesn't matter if this takes 10 times longer because the
time is still in the microseconds", then you *are* deliberately
and willingly writing inefficient code.
Bo Persson <bo@bo-persson.se>: Apr 30 03:33PM +0200

On 2021-04-30 at 12:10, Juha Nieminen wrote:
>> performance several times lost.
 
> If an action that could take a hundreth of a second is instead
> taking a second, there certainly is a bottleneck.
 
It's not a bottleneck if that program runs 3 times a day. At non peak hours.
 
> "it doesn't matter if this takes 10 times longer because the
> time is still in the microseconds", then you *are* deliberately
> and willingly writing inefficient code.
 
It is often more efficient use of the developer's time to focus on the
applications that has the most runtime on a specific system - perhaps
using several CPU-hours per day. Not trying to get everything else down
from 5 to 4 microseconds.
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)