Friday, May 7, 2021

Digest for comp.lang.c++@googlegroups.com - 20 updates in 5 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 07 12:34AM -0700

On 5/5/2021 6:27 PM, Chris M. Thomasson wrote:
>> executes COFF object files that have not been linked to libraries.
 
> Iirc, you mentioned that you did not create the simulator/emulator?
> Right? What one are you using?
 
Don't be afraid. Its okay. For instance, I have C/C++ code that
generates files that a wonderful program called PovRay can read. I
create a shit load of files and PovRay reads and renders them. I did
that to create the following animation. My C/C++ can be used as a
generator, then PovRay can read the results and render the damn thing!
 
https://youtu.be/skGUAXAx6eg
 
So, My work was in C++ for this. The ray tracer was in PovRay:
 
http://www.povray.org
 
Its a text format, easy...
olcott <NoOne@NoWhere.com>: May 07 09:14AM -0500

On 5/7/2021 8:25 AM, Ben Bacarisse wrote:
 
> The same as ever: that Halts(H_Hat, H_Hat) is false when the arguments
> denote a finite computation. I.e. that it gives the wrong answer. You
> can't get round this with words.
 
void Infinite_Loop()
{
HERE: goto HERE;
}
 
int main()
{
Halts(Infinite_Loop(), Infinite_Loop());
}
 
How is it that you are not making the mistake of calling Infinite_Loop()
a finite computation because its simulation was stopped?
 
That would be like called a dead cow alive on the basis that it moves
when the rendering plant workers pick up its corpse.
 
 
> You keep trying to make the wrong answer sound reasonable, but even if
> you could, you are not saying anything about the halting problem because
> I tell /you/ what the right answers are for that problem.
 
If you are saying that infinite loops are not infinite then what you are
saying makes much less sense than what I am saying and others will know
this and agree.
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Christian Gollwitzer <auriocus@gmx.de>: May 07 06:01PM +0200

Am 02.05.21 um 22:08 schrieb olcott:
 
>> 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.
 
Then you haven't understood the point. This program demonstrates that
your halt decider, if it actually works, can decide the Goldbach
conjecture (which is an unsolved problem in maths today).
 
So it is far more likely that your halt decider is wrong than that it
solves the Goldbach conjecture. In fact, by extending on the idea, if a
correct halt decider would exist, it could be used to prove *any* such
conjecture about the natural numbers.
 

Christian
olcott <NoOne@NoWhere.com>: May 07 01:15PM -0500

On 5/7/2021 11:01 AM, Christian Gollwitzer wrote:
 
> Then you haven't understood the point. This program demonstrates that
> your halt decider, if it actually works, can decide the Goldbach
> conjecture (which is an unsolved problem in maths today).
 
Yes and in this same way we can make a program that only halts when it
knows what Donald Trump has for lunch two years from now.
 
Such a halt decider would solve the "predicting the future" problem.
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Tim Woodall <news001@woodall.me.uk>: May 07 08:33PM

> solves the Goldbach conjecture. In fact, by extending on the idea, if a
> correct halt decider would exist, it could be used to prove *any* such
> conjecture about the natural numbers.
 
AIUI, there is no known 'halting proof' of the Collatz conjecture.
 
I'm not enough of a mathematician to say I have a gut feeling but I
wouldn't be surprised to learn that there are far more decision problems
that cannot be answered by a halting decider than that can be answered.
Christian Gollwitzer <auriocus@gmx.de>: May 07 10:54PM +0200

Am 07.05.21 um 22:33 schrieb Tim Woodall:
 
> I'm not enough of a mathematician to say I have a gut feeling but I
> wouldn't be surprised to learn that there are far more decision problems
> that cannot be answered by a halting decider than that can be answered.
 
Of course you are right, it can not prove any such theorem. Correctly
stated:
 
If a program P exists which decides the truth of a given hypothesis for
any natural number N in finite time, then the halt decider could be used
to decide if the hypothesis is true for all natural numbers by running
it on the code
 
void test() {
 
for (int i=1; P(i); i++) {}
 
}
 
That would still be a mighty tool. As for the Collatz conjecture, we
would need to nest it. The Collatz conjecture for number N is true, if
the sequence arrives at 1, so we use the halt decider to check whether
the sequence comes to an end, and this then goes into the test function
above. This is very simlar as the regular proof with the contradicting
halting program, that no such decider can exist.
 
I like the Goldbach thing more because it does not need to
self-reference the halt decider.
 
Christian
Ben Bacarisse <ben.usenet@bsb.me.uk>: May 07 11:35PM +0100

I've set followup-to in case this off topic subthread continues...
 
> wouldn't be surprised to learn that there are far more decision problems
> that cannot be answered by a halting decider than that can be
> answered.
 
Yes. Formally, decision problems are really about decidable subsets of
N. A set of natural numbers, D, is decidable iff there is a Turing
machine that, for every n in N, halts and accepts if n is in D, and
halts and rejects if n is not in D.
 
Since there are uncountably many subsets of N, and only countably many
Turing machines, what you say is correct. A similar point was made
Turing in his 1936 paper: almost all real numbers are not computable.
 
If, however, you insist that a decision problem be written down as a
finite string using a finite alphabet, then the answer is different!
 
--
Ben.
Boris Dorestand <bdorestand@example.com>: May 07 07:07PM -0300

I'm trying to compile Pavel's bulk copy program
 
https://github.com/zodiacon/Win10SysProgBookSamples/tree/master/Chapter11/BulkCopy
 
Not a C++ programmer, nor a Windows person. I wonder if the context is
on-topic. I also don't know which group would be more appropriate.
 
With the WTL latest version obtained from
 
https://wtl.sourceforge.io/
 
I get some compiler errors. I then tried to use the previous version of
WTL, which dates back to 2015. I get other error messages.
 
I suppose my problem is having either the wrong compiler or the wrong
headers. Any directions you point me to will be useful. Thank you.
 
(/) WTL 10, year 2020
 
``c:\sys\emacs\usr\win\tmp\Win10SysProgBookSamples\Chapter11\BulkCopy>cl MainDlg.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
 
MainDlg.cpp
MainDlg.cpp(33): error C2664: 'int WTL::CListViewCtrlT<ATL::CWindow>::InsertColumn(int,LPCTSTR,int,int,int,int,int)': cannot convert argument 2 from 'const wchar_t [7]' to 'LPCTSTR'
MainDlg.cpp(33): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast``
[...]
 
(/) WTL 9.1, year 2015
 
``c:\sys\emacs\usr\win\tmp\Win10SysProgBookSamples\Chapter11\BulkCopy>cl MainDlg.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
 
MainDlg.cpp
\sys\ms\WTL91_5321_Final\include\atlctrls.h(5101): error C2039: 'CString': is not a member of 'WTL'
\sys\ms\WTL91_5321_Final\include\atlctrls.h(83): note: see declaration of 'WTL'
[...]
olcott <NoOne@NoWhere.com>: May 07 12:44PM -0500

On 5/6/2021 6:53 PM, Kaz Kylheku wrote:
> Output("Halt returned");
> return 0;
> }
 
Below is the corrrected source code, assembly language and complete
exuection trace.
 
 
#define NRES 4
 
struct HaltResult
{
u32 P, I, H;
};
 
struct HaltResult res[4] = {{1,1,1},{2,2,2},{3,3,3},{4,4,4}};
 
 
void H_Hat(u32 P)
{
if (HaltsProxy(P, P))
loop: goto loop;
}
 
void Init_res()
{
u32 P = (u32)H_Hat, I = (u32)H_Hat;
u32 H = Halts(P, I);
for (u32 N = 0; N < NRES; N++)
{
res[N].P = P;
res[N].I = I;
res[N].H = H;
}
}
 
 
u32 HaltsProxy(u32 P, u32 I)
{
int i;
u32 H = Halts(P, I); // call real Halts
for (i = 0; i < NRES; i++)
{
struct HaltResult *r = &res[i];
 
if (r->P == P && r->I == I)
{
// Repeat call for same P, I.
H = Halts(P, I); // call real Halts
if (r->H != H)
{
// Halts has returned a different value
OutputString("Halt decider is not an algorithm!");
loop0: goto loop0;
}
// Same value; we are done checking.
break;
}
if (i >= NRES)
{
// Array has filled up, what? We only call this twice.
OutputString("Unexpected excess calls to HaltsProxy!");
loop1: goto loop1;
}
}
return H;
}
 
 
 
int main()
{
Init_res();
u32 H = HaltsProxy((u32) H_Hat, (u32) H_Hat);
Output("Input halts = ", H);
H_Hat((u32) H_Hat);
OutputString("Halt returned");
return 0;
}
 
 
_H_Hat()
[00000bf5](01) 55 push ebp
[00000bf6](02) 8bec mov ebp,esp
[00000bf8](03) 8b4508 mov eax,[ebp+08]
[00000bfb](01) 50 push eax
[00000bfc](03) 8b4d08 mov ecx,[ebp+08]
[00000bff](01) 51 push ecx
[00000c00](05) e810000000 call 00000c15
[00000c05](03) 83c408 add esp,+08
[00000c08](02) 85c0 test eax,eax
[00000c0a](02) 7402 jz 00000c0e
[00000c0c](02) ebfe jmp 00000c0c
[00000c0e](01) 5d pop ebp
[00000c0f](01) c3 ret
Size in bytes:(0027) [00000c0f]
 
_HaltsProxy()
[00000c15](01) 55 push ebp
[00000c16](02) 8bec mov ebp,esp
[00000c18](03) 83ec0c sub esp,+0c
[00000c1b](03) 8b450c mov eax,[ebp+0c]
[00000c1e](01) 50 push eax
[00000c1f](03) 8b4d08 mov ecx,[ebp+08]
[00000c22](01) 51 push ecx
[00000c23](05) e8ddfdffff call 00000a05
[00000c28](03) 83c408 add esp,+08
[00000c2b](03) 8945f4 mov [ebp-0c],eax
[00000c2e](07) c745fc00000000 mov [ebp-04],00000000
[00000c35](02) eb09 jmp 00000c40
[00000c37](03) 8b55fc mov edx,[ebp-04]
[00000c3a](03) 83c201 add edx,+01
[00000c3d](03) 8955fc mov [ebp-04],edx
[00000c40](04) 837dfc04 cmp dword [ebp-04],+04
[00000c44](02) 7d67 jnl 00000cad
[00000c46](04) 6b45fc0c imul eax,[ebp-04],+0c
[00000c4a](05) 052f020000 add eax,0000022f
[00000c4f](03) 8945f8 mov [ebp-08],eax
[00000c52](03) 8b4df8 mov ecx,[ebp-08]
[00000c55](02) 8b11 mov edx,[ecx]
[00000c57](03) 3b5508 cmp edx,[ebp+08]
[00000c5a](02) 753a jnz 00000c96
[00000c5c](03) 8b45f8 mov eax,[ebp-08]
[00000c5f](03) 8b4804 mov ecx,[eax+04]
[00000c62](03) 3b4d0c cmp ecx,[ebp+0c]
[00000c65](02) 752f jnz 00000c96
[00000c67](03) 8b550c mov edx,[ebp+0c]
[00000c6a](01) 52 push edx
[00000c6b](03) 8b4508 mov eax,[ebp+08]
[00000c6e](01) 50 push eax
[00000c6f](05) e891fdffff call 00000a05
[00000c74](03) 83c408 add esp,+08
[00000c77](03) 8945f4 mov [ebp-0c],eax
[00000c7a](03) 8b4df8 mov ecx,[ebp-08]
[00000c7d](03) 8b5108 mov edx,[ecx+08]
[00000c80](03) 3b55f4 cmp edx,[ebp-0c]
[00000c83](02) 740f jz 00000c94
[00000c85](05) 687b030000 push 0000037b
[00000c8a](05) e866f7ffff call 000003f5
[00000c8f](03) 83c404 add esp,+04
[00000c92](02) ebfe jmp 00000c92
[00000c94](02) eb17 jmp 00000cad
[00000c96](04) 837dfc04 cmp dword [ebp-04],+04
[00000c9a](02) 7c0f jl 00000cab
[00000c9c](05) 689f030000 push 0000039f
[00000ca1](05) e84ff7ffff call 000003f5
[00000ca6](03) 83c404 add esp,+04
[00000ca9](02) ebfe jmp 00000ca9
[00000cab](02) eb8a jmp 00000c37
[00000cad](03) 8b45f4 mov eax,[ebp-0c]
[00000cb0](02) 8be5 mov esp,ebp
[00000cb2](01) 5d pop ebp
[00000cb3](01) c3 ret
Size in bytes:(0159) [00000cb3]
 
_Init_res()
[00000cb5](01) 55 push ebp
[00000cb6](02) 8bec mov ebp,esp
[00000cb8](03) 83ec10 sub esp,+10
[00000cbb](07) c745f8f50b0000 mov [ebp-08],00000bf5
[00000cc2](07) c745f4f50b0000 mov [ebp-0c],00000bf5
[00000cc9](03) 8b45f4 mov eax,[ebp-0c]
[00000ccc](01) 50 push eax
[00000ccd](03) 8b4df8 mov ecx,[ebp-08]
[00000cd0](01) 51 push ecx
[00000cd1](05) e82ffdffff call 00000a05
[00000cd6](03) 83c408 add esp,+08
[00000cd9](03) 8945f0 mov [ebp-10],eax
[00000cdc](07) c745fc00000000 mov [ebp-04],00000000
[00000ce3](02) eb09 jmp 00000cee
[00000ce5](03) 8b55fc mov edx,[ebp-04]
[00000ce8](03) 83c201 add edx,+01
[00000ceb](03) 8955fc mov [ebp-04],edx
[00000cee](04) 837dfc04 cmp dword [ebp-04],+04
[00000cf2](02) 7329 jnb 00000d1d
[00000cf4](04) 6b45fc0c imul eax,[ebp-04],+0c
[00000cf8](03) 8b4df8 mov ecx,[ebp-08]
[00000cfb](06) 89882f020000 mov [eax+0000022f],ecx
[00000d01](04) 6b55fc0c imul edx,[ebp-04],+0c
[00000d05](03) 8b45f4 mov eax,[ebp-0c]
[00000d08](06) 89822f020000 mov [edx+0000022f],eax
[00000d0e](04) 6b4dfc0c imul ecx,[ebp-04],+0c
[00000d12](03) 8b55f0 mov edx,[ebp-10]
[00000d15](06) 89912f020000 mov [ecx+0000022f],edx
[00000d1b](02) ebc8 jmp 00000ce5
[00000d1d](02) 8be5 mov esp,ebp
[00000d1f](01) 5d pop ebp
[00000d20](01) c3 ret
Size in bytes:(0108) [00000d20]
 
_main()
[00000d25](01) 55 push ebp
[00000d26](02) 8bec mov ebp,esp
[00000d28](01) 51 push ecx
[00000d29](05) e887ffffff call 00000cb5
[00000d2e](05) 68f50b0000 push 00000bf5
[00000d33](05) 68f50b0000 push 00000bf5
[00000d38](05) e8d8feffff call 00000c15
[00000d3d](03) 83c408 add esp,+08
[00000d40](03) 8945fc mov [ebp-04],eax
[00000d43](03) 8b45fc mov eax,[ebp-04]
[00000d46](01) 50 push eax
[00000d47](05) 68c7030000 push 000003c7
[00000d4c](05) e8b4f6ffff call 00000405
[00000d51](03) 83c408 add esp,+08
[00000d54](05) 68f50b0000 push 00000bf5
[00000d59](05) e897feffff call 00000bf5
[00000d5e](03) 83c404 add esp,+04
[00000d61](05) 68d7030000 push 000003d7
[00000d66](05) e88af6ffff call 000003f5
[00000d6b](03) 83c404 add esp,+04
[00000d6e](02) 33c0 xor eax,eax
[00000d70](02) 8be5 mov esp,ebp
[00000d72](01) 5d pop ebp
[00000d73](01) c3 ret
Size in bytes:(0079) [00000d73]
 
===============================
...[00000d25][001018e9][00000000](01) 55 push ebp
...[00000d26][001018e9][00000000](02) 8bec mov ebp,esp
...[00000d28][001018e5][00000000](01) 51 push ecx
...[00000d29][001018e1][00000d2e](05) e887ffffff call 00000cb5
...[00000cb5][001018dd][001018e9](01) 55 push ebp
...[00000cb6][001018dd][001018e9](02) 8bec mov ebp,esp
...[00000cb8][001018cd][90909090](03) 83ec10 sub esp,+10
...[00000cbb][001018cd][90909090](07) c745f8f50b0000 mov
[ebp-08],00000bf5
...[00000cc2][001018cd][90909090](07) c745f4f50b0000 mov
[ebp-0c],00000bf5
...[00000cc9][001018cd][90909090](03) 8b45f4 mov
eax,[ebp-0c]
...[00000ccc][001018c9][00000bf5](01) 50 push eax
...[00000ccd][001018c9][00000bf5](03) 8b4df8 mov
ecx,[ebp-08]
...[00000cd0][001018c5][00000bf5](01) 51 push ecx
...[00000cd1][001018c1][00000cd6](05) e82ffdffff call 00000a05
Begin Local Halt Decider Simulation at Machine Address:bf5
...[00000bf5][00211989][0021198d](01) 55 push ebp
...[00000bf6][00211989][0021198d](02) 8bec mov ebp,esp
...[00000bf8][00211989][0021198d](03) 8b4508 mov
eax,[ebp+08]
...[00000bfb][00211985][00000bf5](01) 50 push eax
...[00000bfc][00211985][00000bf5](03) 8b4d08 mov
ecx,[ebp+08]
...[00000bff][00211981][00000bf5](01) 51 push ecx
...[00000c00][0021197d][00000c05](05) e810000000 call 00000c15
...[00000c15][00211979][00211989](01) 55 push ebp
...[00000c16][00211979][00211989](02) 8bec mov ebp,esp
...[00000c18][0021196d][90909090](03) 83ec0c sub esp,+0c
...[00000c1b][0021196d][90909090](03) 8b450c mov
eax,[ebp+0c]
...[00000c1e][00211969][00000bf5](01) 50 push eax
...[00000c1f][00211969][00000bf5](03) 8b4d08 mov
ecx,[ebp+08]
...[00000c22][00211965][00000bf5](01) 51 push ecx
...[00000c23][00211961][00000c28](05) e8ddfdffff call 00000a05
...[00000bf5][0025c3b1][0025c3b5](01) 55 push ebp
...[00000bf6][0025c3b1][0025c3b5](02) 8bec mov ebp,esp
...[00000bf8][0025c3b1][0025c3b5](03) 8b4508 mov
eax,[ebp+08]
...[00000bfb][0025c3ad][00000bf5](01) 50 push eax
...[00000bfc][0025c3ad][00000bf5](03) 8b4d08 mov
ecx,[ebp+08]
...[00000bff][0025c3a9][00000bf5](01) 51 push ecx
...[00000c00][0025c3a5][00000c05](05) e810000000 call 00000c15
...[00000c15][0025c3a1][0025c3b1](01) 55 push ebp
...[00000c16][0025c3a1][0025c3b1](02) 8bec mov ebp,esp
...[00000c18][0025c395][90909090](03) 83ec0c sub esp,+0c
...[00000c1b][0025c395][90909090](03) 8b450c mov
eax,[ebp+0c]
...[00000c1e][0025c391][00000bf5](01) 50 push eax
...[00000c1f][0025c391][00000bf5](03) 8b4d08 mov
ecx,[ebp+08]
...[00000c22][0025c38d][00000bf5](01) 51 push ecx
...[00000c23][0025c389][00000c28](05) e8ddfdffff call 00000a05
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[00000cd6][001018cd][90909090](03) 83c408 add esp,+08
...[00000cd9][001018cd][00000000](03) 8945f0 mov
[ebp-10],eax
...[00000cdc][001018cd][00000000](07) c745fc00000000 mov
[ebp-04],00000000
...[00000ce3][001018cd][00000000](02) eb09 jmp 00000cee
...[00000cee][001018cd][00000000](04) 837dfc04 cmp dword
[ebp-04],+04
...[00000cf2][001018cd][00000000](02) 7329 jnb 00000d1d
...[00000cf4][001018cd][00000000](04) 6b45fc0c imul
eax,[ebp-04],+0c
...[00000cf8][001018cd][00000000](03) 8b4df8 mov
ecx,[ebp-08]
...[00000cfb][001018cd][00000000](06) 89882f020000 mov
[eax+0000022f],ecx
...[00000d01][001018cd][00000000](04) 6b55fc0c imul
edx,[ebp-04],+0c
...[00000d05][001018cd][00000000](03) 8b45f4 mov
eax,[ebp-0c]
...[00000d08][001018cd][00000000](06) 89822f020000 mov
[edx+0000022f],eax
...[00000d0e][001018cd][00000000](04) 6b4dfc0c imul
ecx,[ebp-04],+0c
...[00000d12][001018cd][00000000](03) 8b55f0 mov
edx,[ebp-10]
...[00000d15][001018cd][00000000](06) 89912f020000 mov
[ecx+0000022f],edx
...[00000d1b][001018cd][00000000](02) ebc8 jmp 00000ce5
...[00000ce5][001018cd][00000000](03) 8b55fc mov
edx,[ebp-04]
...[00000ce8][001018cd][00000000](03) 83c201 add edx,+01
...[00000ceb][001018cd][00000000](03) 8955fc mov
[ebp-04],edx
...[00000cee][001018cd][00000000](04) 837dfc04 cmp dword
[ebp-04],+04
...[00000cf2][001018cd][00000000](02) 7329 jnb 00000d1d
...[00000cf4][001018cd][00000000](04) 6b45fc0c imul
eax,[ebp-04],+0c
...[00000cf8][001018cd][00000000](03) 8b4df8 mov
ecx,[ebp-08]
...[00000cfb][001018cd][00000000](06) 89882f020000 mov
[eax+0000022f],ecx
...[00000d01][001018cd][00000000](04) 6b55fc0c imul
edx,[ebp-04],+0c
...[00000d05][001018cd][00000000](03) 8b45f4 mov
eax,[ebp-0c]
...[00000d08][001018cd][00000000](06) 89822f020000 mov
[edx+0000022f],eax
...[00000d0e][001018cd][00000000](04) 6b4dfc0c imul
ecx,[ebp-04],+0c
...[00000d12][001018cd][00000000](03) 8b55f0 mov
edx,[ebp-10]
...[00000d15][001018cd][00000000](06) 89912f020000 mov
[ecx+0000022f],edx
...[00000d1b][001018cd][00000000](02) ebc8 jmp 00000ce5
...[00000ce5][001018cd][00000000](03) 8b55fc mov
edx,[ebp-04]
...[00000ce8][001018cd][00000000](03) 83c201 add edx,+01
...[00000ceb][001018cd][00000000](03) 8955fc mov
[ebp-04],edx
...[00000cee][001018cd][00000000](04) 837dfc04 cmp dword
[ebp-04],+04
...[00000cf2][001018cd][00000000](02) 7329 jnb 00000d1d
...[00000cf4][001018cd][00000000](04) 6b45fc0c imul
eax,[ebp-04],+0c
...[00000cf8][001018cd][00000000](03) 8b4df8 mov
ecx,[ebp-08]
...[00000cfb][001018cd][00000000](06) 89882f020000 mov
[eax+0000022f],ecx
...[00000d01][001018cd][00000000](04) 6b55fc0c imul
edx,[ebp-04],+0c
...[00000d05][001018cd][00000000](03) 8b45f4 mov
eax,[ebp-0c]
...[00000d08][001018cd][00000000](06) 89822f020000 mov
[edx+0000022f],eax
...[00000d0e][001018cd][00000000](04) 6b4dfc0c imul
ecx,[ebp-04],+0c
...[00000d12][001018cd][00000000](03) 8b55f0 mov
edx,[ebp-10]
...[00000d15][001018cd][00000000](06) 89912f020000 mov
[ecx+0000022f],edx
...[00000d1b][001018cd][00000000](02) ebc8
Kaz Kylheku <563-365-8930@kylheku.com>: May 07 06:38PM

["Followup-To:" header set to comp.theory.]
> u32 P, I, H;
> };
 
> struct HaltResult res[4] = {{1,1,1},{2,2,2},{3,3,3},{4,4,4}};
 
I don't understand the purpose of this initializer, given
that Init_res is called.
 
If omission of the initializer is sufficient for zero initialization
(as normally required by ISO C for a static object) please remove it.
 
Otherwise use res[NRES] = {{0}};
 
By the way [4] is my mistake; it was intended to be [NRES]. NRES is 4,
but could change, causing a problem.
 
 
> res[N].H = H;
> }
> }
 
This doesn't make a whole lot of sense. The initialization has no need
to call Halts at all; that should be left to the experiment.
 
We want the database to be initially empty, not having any knowledge
about any halts results.
 
Filling the array with *identical* keys makes no sense, and leaves no
room for any other P, I value should that happen.
 
> {
> // Repeat call for same P, I.
> H = Halts(P, I); // call real Halts
 
Calling Halts(P, I) more than once in this function does not make sense.
 
Halts(P, I) was already called at the top, and H holds the result.
Please delete this call to Halts.
 
> break;
> }
 
> if (i >= NRES)
 
This statement was originally outside of the loop.
 
The condition i >= NRES indicates that the loop completed without a
"break". That means that (P, I) was not found in the array, and that the
array contains no more blank space toc reate a new entry for the newly
observed (P, I) value.
 
NOte that testing (i >= NRES) inside the for loop makes no
sense, because the loop guard assures that the condition is always
false: for (i = 0; i < NRES; i++). See the "i < NRES"? The loop body
does not execute unless i < NRES< therefore i >= NRES is false inside
the loop body.
 
You've turned a piece of my code that serves a purpose into unreachable
code.
 
Also, please restore the logic which adds new entries into blank spots in
the array.
 
{
> }
> return H;
> }
 
In spite of these problems, I think it look as if the the code should
still catch the situation of Halts being inconsistent.
> Output("Input halts = ", H);
> H_Hat((u32) H_Hat);
> OutputString("Halt returned");
 
My mistake: please correct to H_Hat returned.
 
> return 0;
> }
 
OK, so onto the trace. In the trace we see:
 
> Input halts = 0
 
thus Halts(H_Hat, H_Hat) returned 0 when called out of main via
HaltsProxy.
 
In the trace we also see this output:
 
> Halt returned
 
This actually means H_Hat returned, the code being
 
H_Hat((u32) H_Hat);
OutputString("Halt returned");
 
Since "Input_Halts = 0" means "H_Hat(H_Hat) does not halt", but
H_Hat(H_Hat) returns, that means it's the wrong halting answer,
doesn't it?
 
So while we didn't see an inconsistent return value from Halts (which is
good!) the program's behavior appears to support the halting proof,
rather than refute it.
 
Of course if Halts(H_Hat, H_Hat) consistently returns 0, that
consistency being required, then H_Hat(H_Hat) returns. It obtains the
that 0 from Halts and "behaves opposite" by just returning, making that
the wrong answer.
 
I specifically did not miss these two pieces of output in your trace:
 
> Begin Local Halt Decider Simulation at Machine Address:bf5
 
Firstly, you had previously claimed that the local decider mode was
a mistake and have abandoned it; does Local Halt Decider not refer
to this mode, or is that something else now.
 
And, more importantly:
 
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
 
Though it claims it has detected infinite recursion and that the simulation has
stopped, the fact is that the traces continue after this diagnostic. The
simuation has not actually stopped!
 
Moreover, the claim of infinite recursion is difficult to accept given that:
 
1. Halts((u32) H_Hat, (u32) H_Hat) cheerfully terminated with value 0.
 
2. H_Hat((u32) H_Hat) returned to subsequent Output statement
 
I understand you have some talking points around all this, but they don't make
sense, especially in relation to the simplicity of arriving at the conclusion
that the apparatus is simply confirming the proof.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
olcott <NoOne@NoWhere.com>: May 07 04:13PM -0500

On 5/7/2021 3:37 PM, Kaz Kylheku wrote:
> in the COFF file.
 
> Then you can explore whatever C code you want without workarounds
> for zero-initialized statics.
 
Yes as soon as my halt decider is accepted as correct this is first on
the list of enhacements.
 
 
> Nitpick: that should still be restored to its position outside of the
> loop. We never run into this condition either way, since we don't work
> with multiple unique P, I pairs.
 
I only corrected syntax errors in your code.
Your code stipulates that it is inside the loop.
 
You probably got confused by your formatting conventions. I always match
curly braces on a line by themselves with the same indentation level.
 
 
>> }
>> return H;
>> }
 
It is not unreachable.
 
 
>> void H_Hat4(u32 P)
 
> Seeing you use different names for different H_Hat versions is
> encouraging.
 
Good.
 
>> H_Hat4((u32) H_Hat4);
>> OutputString("Halt returned");
 
> Please correct to "H_Hat4 returned"; that was my intent.
 
OK
 
 
>> Halt returned
 
> Oops, H_Hat4(H_Hat4) returns due to getting getting a 0 from Halts.
 
> So the 0 is incorrect: a direct call to H_Hat4(H_Hat4) returns.
 
Halts(H_Hat, H_Hat) is an instance of both of these truisms:
 
It is true that every computation that would never halt unless its
simulation was stopped is a non-halting computation. Some may disagree
out of ignorance or deception none-the-less it remains a truism.
 
Every at least partial halt decider that decides to stop simulating its
input on the basis that the execution trace of this input matches a
correct non-halting behavior pattern does decide not halting correctly.
 
Do you understand that disagreeing with an actual truism is always
necessarily incorrect?
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
"Öö Tiib" <ootiib@hot.ee>: May 06 06:21PM -0700

On Monday, 3 May 2021 at 21:38:53 UTC+3, Paavo Helde wrote:
> known beforehand. A lot of C++ code goes into reusable libraries, and
> when writing a library function it is often not known how many times it
> will get called by different client programs.
 
Yes. I agree. You are saying same thing. The subpart where performance
matters often becomes known only after correctness has been reached
from end to end and the code is put into use by different clients. Usually
because it does everything it was intended to do and nothing that it wasn't
intended to do. Often the context and data we considered "realistic" when
we profiled it was far from needs that arise in few years. But fortunately
software can be profiled and improved in few years too.
 
> So if there is an easy way
> to write some code line to run 10x faster, in library code it should be
> done IMO.
 
But you somehow conclude from above that that we should ponder each
line of code if there is some easier or harder way to make it faster. Why?
The whole file with that line may be will be erased entirely when we get
actual performance issue and data with what to profile.
"Öö Tiib" <ootiib@hot.ee>: May 06 09:40PM -0700

On Tuesday, 4 May 2021 at 13:44:10 UTC+3, Juha Nieminen wrote:
> When Knuth wrote "premature optimization is the root of all evil"
> in 1974, I doubt he was thinking about std::string::substr()
> vs. std::string::compare() in a language standardized in 1998.
 
Demagogy ... perhaps read the book.
 
> program as inefficient as you possibly can, because optimization,
> any kind of optimization, is one of the worst things you could
> possibly do".
 
Most problems with C++ come from that wrong focus to unneeded
micro-optimizations (that are always possible) instead of using it
as language with what software can be written rapidly safely and
correctly.

> more efficient one is available, because "premature optimization
> is the root of all evil", and there's literally zero reason not to
> use the more efficient version.
 
All we have met insane things but someone deliberately and specially
writing inefficient code is hard to believe ... I have never met nor heard
it. Maybe the evil of preliminary optimizations made you to misrepresent
someone or to make that story up? Then it is truly root of *all* evil. :D
 
> manually inlining code, and other such hacks. The more such hacks
> are used, the less readable and maintainable the code belongs, and it
> becomes.
 
There are lot of faces of evil and only precious few of those are visibly
ugly. Lets look at that "time-wasting face" in context of passing string?
 
1) Should we move the string here instead of copying? No idea, just copy
right now, later may appear that we need it down the line.
2) Should we make it constexpr? Maybe, as it is currently just string constant
but such things are wanted configurable later, so let it be just string.
3) Should we use string_view? Who knows, maybe we want to pass it to
different thread. Leave it as string now.
 
See? All questions were about C++ micro-optimizations
none of what is ugly hack but time was wasted to considering.
If to apply those prematurely these add constraints that potentially
waste time in the future too.

> "Premature optimization" does not mean using quicksort instead of
> bubble sort.
 
Usage of std::sort is not premature optimization. Usage of something
else without clear reason is premature optimization or pessimization
or just foolishness.
 
> Or using a balanced binary tree instead of an array (and
> linear searches).
 
Usage of std::multiset or sorted std::vector with std::lower_bound or
std::unordered_multiset is just usual usage of usual containers so
not premature optimization.
Usage of things with what rare are familiar like boost::intrusive::sgtree
or your own implementation of such is premature optimization or
pessimization or just foolishness.
 
> Or using std::string::compare() instead of
> std::string::substr().
 
Depends how it is done. If someone used it, changed it within other
work or suggested in code review then it is fine. But if someone
raised issue management ticket then ... premature optimizations have
done outright sabotage there IMO.
Juha Nieminen <nospam@thanks.invalid>: May 07 07:38AM

>> The more such hacks
>> are used, the less readable and maintainable the code belongs, and it
>> becomes.
 
I don't know what kind of brainfart happened to me here. Obviously I meant
to write "the less readable and maintainable the code becomes".
I think I wrote something longer first, but then re-edited it to be shorter
but somehow I botched the editing and didn't remove something I should have.
 
But anyway.
 
> none of what is ugly hack but time was wasted to considering.
> If to apply those prematurely these add constraints that potentially
> waste time in the future too.
 
I think that an experienced C++ programmer can gain enough knowledge of
the language and its standard library that using the more efficient
version of things becomes second nature and happens fluently and without
much disruption.
 
In this particular case, for example, it shouldn't be a question of
thinking that taking a substr() and comparing it to another string is
the way to do the comparison but then starting to think if there might
be a better way and spending ten minutes researching cppreference.com
to see if there might be something more efficient.
 
Instead, optimally it should be a case that you already know of
std::string::compare() (or at a very minimum remember that something
like it exists) and directly implementing the comparison using it, because
you know it's the more efficient way. No time is wasted on this kind of
"micro-optimization". Your code will be ready equally fast, but it will
not be so wasteful.
 
To me it makes no sense to think "I'll just use substr() and maybe
consider changing it to compare() later". Why? I just use compare()
from the get-go. I see no problem with it.
Paavo Helde <myfirstname@osa.pri.ee>: May 07 12:05PM +0300

07.05.2021 04:21 Öö Tiib kirjutas:
> line of code if there is some easier or harder way to make it faster. Why?
> The whole file with that line may be will be erased entirely when we get
> actual performance issue and data with what to profile.
 
For me it seems very easy, the programmer anyway needs to choose for
each line how they write it. For each line or task there are many ways
to code it incorrectly, there are some ways to code it more or less
correctly, and then there are optimizations which might not be obvious,
so cannot be taken into account when first writing that line.
 
This correctness for me also includes reasonable performance. For
example, choosing a solution with O(log N) complexity over O(N). Even
though the latter would also work and produce the needed result, it
would not be a "correct" solution in my book, unless it is known and
documented that the function will only be used with very small N. The
time and effort for documenting and checking this assumption may easily
turn out to be more time consuming than using the correct O(log N)
algorithm in the first place.
 
For the OP's example, there are two ways to compare the substring in
C++, either with string::substr()== or with string::compare(). In my
book, as the former is 2-10x slower than the latter, only the latter is
a "correct" way to code this line IMO. When the compilers get smarter
and become able to optimize them to the same speed, one can reconsider.
 
That's the same as with passing by value or by reference. In C++ one
should prefer passing non-trivial objects by reference if possible, as
pass by value might often waste both speed and memory for no reason.
Yet, passing by reference involves writing some more keystrokes, so
according to some opinions which I have seen in this thread it should
not be done before profiler shows there is a bottle-neck.
Paavo Helde <myfirstname@osa.pri.ee>: May 07 12:10PM +0300

07.05.2021 07:40 Öö Tiib kirjutas:
 
> Usage of std::sort is not premature optimization. Usage of something
> else without clear reason is premature optimization or pessimization
> or just foolishness.
 
Correct. And similarly, using std::string::compare() for comparing
substrings is not a premature optimization either, because that's
exactly what it does and what it is meant for. Usage of something else
without clear reason is not justified.
Hans Bos <hans.bos@xelion.nl>: May 07 04:06PM +0200

Op 1-5-2021 om 15:51 schreef Öö Tiib:
> Performance starts to matter only after correctness has been
> reached from end to end and then only to minor subpart of
> whole program.
 
This quote is from his paper "Structured Programming with go to
Statements" (1974)
 
He also wrote in there:
The conventional wisdom shared by many of today's software engineers
calls for ignoring efficiency in the small; but I believe this is simply
an overreaction to the abuses they see being practiced by penny-
wise-and-pound-foolish programmers, who can't debug or maintain their
"optimized" programs. In established engineering disciplines a 12 %
improvement, easily obtained, is never considered marginal;
 
 
So I think he means: don't get carried away with unnecessary code
optimization, but don't use inefficient constructs if efficient
constructs can be "easily obtained".
 
Hans.
"Öö Tiib" <ootiib@hot.ee>: May 07 09:40AM -0700

On Friday, 7 May 2021 at 12:10:45 UTC+3, Paavo Helde wrote:
> substrings is not a premature optimization either, because that's
> exactly what it does and what it is meant for. Usage of something else
> without clear reason is not justified.
 
For me it is as basic_string::compare is set of overloads, longest has
perhaps 5 arguments that few do remember and it isn't guaranteed
to be more efficient by anything else but by profiling. Also its starship
nature is good bear trap for novices if you want to be asshole:
 
if (!a.compare(b)) {
// get here when a and b are equal
// but majority of novices read opposite
}
Paavo Helde <myfirstname@osa.pri.ee>: May 07 10:32PM +0300

07.05.2021 19:40 Öö Tiib kirjutas:
>> without clear reason is not justified.
 
> For me it is as basic_string::compare is set of overloads, longest has
> perhaps 5 arguments that few do remember
 
You mean, you do not remember the arguments, because you are not using
that function. I'm using it all the time and have no problem with
arguments, they are pretty logical.
 
BTW, std::sort also has 4 overloads and up to 4 arguments plus up to 3
template arguments. Just saying...
 
> and it isn't guaranteed
> to be more efficient by anything else but by profiling.
 
So what's the reason for its existence? There are certain reasons why
something is included in the C++ standard, and avoiding creation of
totally unneeded temporaries might well be one of them.
 
> // get here when a and b are equal
> // but majority of novices read opposite
> }
 
There are bad news for those novices as they now have to cope with even
more ternary result values, with this brand new spaceship operator in C++20.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 06 07:34PM -0700

On 4/30/2021 7:34 PM, Sam wrote:
 
> The question to resolve: is this a false positive from -O2 and
> -Wstringop-overflow, or is gcc miscompiling it…
 
> I don't grok assembler to be able to tell the difference.
 
It must be a compiler error. The assembly aside for a moment, its been a
while since I wrote asm from scratch. The MEMBAR instruction in the
SPARC was very fun in RMO mode! ;^)
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)