Wednesday, October 12, 2022

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

JiiPee <kerrttuPoistaTama11@gmail.com>: Oct 12 11:48PM +0300

I have been pondering this many times. I keep it short:
If I have hundreds of lines like this:
 
short a;
std::vector<int> v;
...
a = v.size();
 
This gives a warning: "warning, assigning size_t to short".
I know this can be fixed:
a = static_cast<short>(v.size());
 
but if we have hundreds of those lines, how would you fix this? Place a
static cast in all of them? Of create some helper funktion to do this?
 
How about if I have a function created by me before:
size_t CalcLength(int a);
 
and then I call it 100 places like this:
short b;
b = CalcLength(466);
 
again type warning. Would you fix it by placing static cast in 100
places like this:
 
b = static_cast<short>(CalcLength(466));
 
wherever this cast can be done? And what if CalcLength() can in some
code places return a large number also? So we cannot just blindly change
the return type to "short" to solve this.
olcott <polcott2@gmail.com>: Oct 12 10:08AM -0500

Professor Michael Sipser of MIT said that this verbatim paragraph looks
correct:
 
If H does correctly determine that its correct simulation
of D would never stop running unless aborted, would it be
correct for H to abort this simulation and report that D
specifies a non-halting sequence of configurations?
 
This validates the idea of a simulating halt decider referenced in this
paper.
 
*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
 
 
Professor Sipser has not had the time to carefully review this paper
presented to him.
 
*The exact words posted above have been approved by Michael Sipser*
 
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
olcott <polcott2@gmail.com>: Oct 12 11:48AM -0500

On 10/12/2022 10:54 AM, Fred. Zwarts wrote:
>      of D would never stop running unless aborted, would it be
>      correct for H to abort this simulation and report that D
>      specifies a non-halting sequence of configurations?
 
Professor Michael Sipser of MIT said that this verbatim paragraph looks
correct:
 
If H does correctly determine that its correct simulation
of D would never stop running unless aborted, would it be
correct for H to abort this simulation and report that D
specifies a non-halting sequence of configurations?
 
This validates that the behavior of D correctly simulated by H is the
correct behavior that H must report on, thus affirming that the notion
of a simulating halt decider is correct.
 
Complete halt deciding system (Visual Studio Project) Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_10_08.zip
 
Ordinary software engineering verifies the simulation of Sipser_D by
Sipser_H is correct. Ordinary software engineering also verifies that
Sipser_H does correctly determine that Sipser_D is stuck in what would
otherwise be infinitely recursive simulation unless H aborts its
simulation of Sipser_D.
 
As can be seen from the above quote Professor Sipser has agreed that
this would be the correct basis for Sipser_H to report that Sipser_D
specifies a non-halting sequence of configurations.
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
olcott <polcott2@gmail.com>: Oct 12 12:04PM -0500

On 10/12/2022 11:46 AM, Ben Bacarisse wrote:
> "would" do "unless" it does what it actually does is irrelevant. H(P,P)
> returns 0 and P(P) halts. 0 is the wrong answer for a halting
> computation.
 
Professor Sipser essentially validates the same notion of a simulating
halt decider that I have had all along:
 
When-so-ever simulating halt decider H correctly determines that its
correct simulation of its input D would never stop running unless
aborted then it is always correct for H to abort its simulation of D and
report that D specifies a non-halting sequence of configurations.
 
<quoted email>
Professor Sipser:
 
Here is what I would like to say:
 
Professor Michael Sipser of MIT said that this verbatim paragraph looks
correct:
 
If H does correctly determine that its correct simulation
of D would never stop running unless aborted, would it be
correct for H to abort this simulation and report that D
specifies a non-halting sequence of configurations?
 
This validates the idea of a simulating halt decider referenced in this
paper.
 
*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
 
 
Professor Sipser has not had the time to carefully review this paper
presented to him.
</quoted email>
 
<quoted reply>
Looks ok. Thanks for checking.
</quoted reply>
 
 
 
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 12 06:24PM +0100

On Wed, 12 Oct 2022 10:08:20 -0500
 
> Professor Sipser has not had the time to carefully review this paper
> presented to him.
 
> *The exact words posted above have been approved by Michael Sipser*
 
Whilst the paragraph you sent to Sipser is correct the crucial detail
that you are glossing over is that you do NOT perform a correct
simulation for all inputs:
 
void Px(void (*x)())
{
(void) H(x, x);
return;
}
 
The correct simulation of Px above is to simulate Px halting.
 
Sipser confirms that the Flibble Signaling Halt Decider (TM) is a
solution however it does not confirm that the Olcott Simulation
Detector is a valid halt decider.
 
/Flibble
olcott <none-ya@beez-waxes.com>: Oct 12 12:38PM -0500

On 10/12/2022 12:24 PM, Mr Flibble wrote:
 
> Whilst the paragraph you sent to Sipser is correct the crucial detail
> that you are glossing over is that you do NOT perform a correct
> simulation for all inputs:
 
Complete halt deciding system (Visual Studio Project) Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_10_08.zip
 
Anyone with sufficient software engineering skill can easily verify that
Sipser_D is correctly simulated by Sipser_H and that Sipser_D remains
stuck in infinitely recursive simulation unless and until Sipser_H
aborts its correct simulation of Sipser_D.
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 12 06:52PM +0100

On Wed, 12 Oct 2022 12:38:31 -0500
> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
> remains stuck in infinitely recursive simulation unless and until
> Sipser_H aborts its correct simulation of Sipser_D.
 
You chose to not fully address my reply by snipping the important part
so I will give you another chance:
 
Whilst the paragraph you sent to Sipser is correct the crucial detail
that you are glossing over is that you do NOT perform a correct
simulation for all inputs:
 
void Px(void (*x)())
{
(void) H(x, x);
return;
}
 
The correct simulation of Px above is to simulate Px halting.
 
Sipser confirms that the Flibble Signaling Halt Decider (TM) is a
solution however it does not confirm that the Olcott Simulation
Detector is a valid halt decider.
 
/Flibble
olcott <polcott2@gmail.com>: Oct 12 01:04PM -0500

On 10/12/2022 12:52 PM, Mr Flibble wrote:
> return;
> }
 
> The correct simulation of Px above is to simulate Px halting.
 
Not at all. It must be a correct simulation of the actual input by the
simulating halt decider.
 
int main() { H(Px,Px); }
(a) The executed H simulates Px that calls a simulated H
(b) that simulates Px that calls a simulated H
(c) that simulates Px that calls a simulated H ...
 
 
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 12 07:07PM +0100

On Wed, 12 Oct 2022 13:04:17 -0500
> (a) The executed H simulates Px that calls a simulated H
> (b) that simulates Px that calls a simulated H
> (c) that simulates Px that calls a simulated H ...
 
Yes indeed it must be a correct simulation and a correct simulation of
Px is to simulate Px halting.
 
/Flibble
olcott <polcott2@gmail.com>: Oct 12 01:25PM -0500

On 10/12/2022 1:07 PM, Mr Flibble wrote:
 
> Yes indeed it must be a correct simulation and a correct simulation of
> Px is to simulate Px halting.
 
> /Flibble
 
Sipser agreed that the correct simulation of Px by H is the correct
measure of the behavior of Px.
 
When we look at the above execution trace of: int main() { H(Px,Px); }
We see that Px remains stuck in recursive simulation until H aborts this
simulation.
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 12 07:30PM +0100

On Wed, 12 Oct 2022 13:25:34 -0500
 
> > /Flibble
 
> Sipser agreed that the correct simulation of Px by H is the correct
> measure of the behavior of Px.
 
Of course he did but you don't do a correct simulation of Px: a
correct simulation of Px is to simulate Px halting as that is how Px
behaves.
 
/Flibble
olcott <polcott2@gmail.com>: Oct 12 02:17PM -0500

On 10/12/2022 1:30 PM, Mr Flibble wrote:
> correct simulation of Px is to simulate Px halting as that is how Px
> behaves.
 
> /Flibble
 
A correct simulation of Px by H derives the execution trace that I
specified. Every line of the execution trace of the x86 emulation of Px
by H precisely corresponds to exactly what the x86 source code of Px
specifies.
 
void Px(void (*x)())
{
(void) H(x, x);
return;
}
 
int main()
{
Output("Input_Halts = ", H(Px, Px));
}
 
_Px()
[00001256] 55 push ebp
[00001257] 8bec mov ebp,esp
[00001259] 8b4508 mov eax,[ebp+08]
[0000125c] 50 push eax // push 2nd arg to H
[0000125d] 8b4d08 mov ecx,[ebp+08]
[00001260] 51 push ecx // push 1st arg to H
[00001261] e8b0fcffff call 00000f16 // call H
[00001266] 83c408 add esp,+08
[00001269] 5d pop ebp
[0000126a] c3 ret
Size in bytes:(0021) [0000126a]
 
H: Begin Simulation Execution Trace Stored at:111fcb
Address_of_H:f16
[00001256][00111fb7][00111fbb] 55 push ebp
[00001257][00111fb7][00111fbb] 8bec mov ebp,esp
[00001259][00111fb7][00111fbb] 8b4508 mov eax,[ebp+08]
[0000125c][00111fb3][00001256] 50 push eax // push Px
[0000125d][00111fb3][00001256] 8b4d08 mov ecx,[ebp+08]
[00001260][00111faf][00001256] 51 push ecx // push Px
[00001261][00111fab][00001266] e8b0fcffff call 00000f16 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped
 
We can see that the execution trace of the first six instructions of Px
exactly matches the x86 source-code of Px. We can also see that Px was
about to call H(Px,Px) again and this would repeat the cycle of the
first six instructions of Px.
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 12 08:26PM +0100

On Wed, 12 Oct 2022 14:17:35 -0500
> Px exactly matches the x86 source-code of Px. We can also see that Px
> was about to call H(Px,Px) again and this would repeat the cycle of
> the first six instructions of Px.
 
There are various methods of simulating an input: you have chosen an
incorrect method of simulation; if we substitute your H for another H
which uses a correct method of simulation, Px will correctly halt.
 
An SHD which uses a correct method of simulation would be the Flibble
Signaling Halt Decider (TM).
 
/Flibble
olcott <polcott2@gmail.com>: Oct 12 02:32PM -0500

On 10/12/2022 2:26 PM, Mr Flibble wrote:
 
> An SHD which uses a correct method of simulation would be the Flibble
> Signaling Halt Decider (TM).
 
> /Flibble
 
Everyone that is sufficiently technically competent at software
engineering can verify that H does correctly simulate Px on the basis
that the line-by-line execution trace of the simulation of Px by H
exactly matches the line-by-line x86 source-code of Px.
 
People that are not sufficiently technically competent might use
double-talk, misdirection and vagueness to provide a baseless rebuttal.
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 12 08:50PM +0100

On Wed, 12 Oct 2022 14:32:41 -0500
 
> People that are not sufficiently technically competent might use
> double-talk, misdirection and vagueness to provide a baseless
> rebuttal.
 
A valid halt decider MUST return a decision to its caller, in this case
Px, in finite time; Px will then halt, correctly. Your H does not do
this so is not a valid halt decider.
 
/Flibble
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 12 12:27PM -0700

On 5/12/2022 12:16 PM, Chris M. Thomasson wrote:
> Using my experimental vector field to generate a fractal formation. Here
> is generation two:
 
> https://fractalforums.org/gallery/1612-120522191048.png
 
An interesting field based DLA formation popped out of one of my C++
experiments! It looks fairly, turbulent, so to speak:
 
https://fractalforums.org/gallery/1612-121022033202.png
 
:^D
Mark <m.n.summerfield@googlemail.com>: Oct 12 02:06AM -0700

I have this tiny eg:
```cpp
// g++ -o t t.cpp && ./t
#include <exception>
#include <iostream>
 
using namespace std;
 
class Error : public std::exception {
public:
Error(const char* message) : message_(message_) {}
const char* what() const throw() { return message_; }
private:
char* message_;
};
 
class Value {
public:
virtual ~Value() {}
virtual size_t size() const {
throw Error("scalars don't have a size");
}
};
 
int main() {
auto v = new Value();
try {
cout << "t " << v->size() << endl;
} catch (Error& err) {
cout << "error:" << err.what() << endl;
return EXIT_FAILURE;
}
}
```
When I build & run it the output is:
```
t error:
```
with no following newline.
 
What am I doing wrong?
Ralf Fassel <ralfixx@gmx.de>: Oct 12 11:16AM +0200

* Mark <m.n.summerfield@googlemail.com>
| class Error : public std::exception {
| public:
| Error(const char* message) : message_(message_) {}
 
Look closely at what you're initializing message_ with.
 
R'
Mark <m.n.summerfield@googlemail.com>: Oct 12 02:19AM -0700

On Wednesday, October 12, 2022 at 10:17:10 AM UTC+1, Ralf Fassel wrote:
> | Error(const char* message) : message_(message_) {}
> Look closely at what you're initializing message_ with.
 
> R'
 
Thank you! (I also had to change the private member to `const char * message_`.)
Ralf Fassel <ralfixx@gmx.de>: Oct 12 11:26AM +0200

* Mark <m.n.summerfield@googlemail.com>
| On Wednesday, October 12, 2022 at 10:17:10 AM UTC+1, Ralf Fassel wrote:
| > * Mark <m.n.sum...@googlemail.com>
| > | class Error : public std::exception {
| > | public:
| > | Error(const char* message) : message_(message_) {}
| > Look closely at what you're initializing message_ with.
| >
| > R'
 
| Thank you! (I also had to change the private member to `const char * message_`.)
 
Given the const-to-non-const assignment in the CTOR, I was wondering why
this did compile w/o error.
Took me a little while until I spotted it, too ;-)
 
R'
David Brown <david.brown@hesbynett.no>: Oct 12 11:57AM +0200

On 12/10/2022 11:06, Mark wrote:
> I have this tiny eg:
> ```cpp
> // g++ -o t t.cpp && ./t
<snip>
 
> What am I doing wrong?
 
You forgot the critical compiler flags:
 
g++ -Wall -Wextra -O2 -o t t.cpp
 
Running your compiler without warnings enabled is like driving without
seatbelts and airbags - you might be lucky, but there might be a mess
that is hard to identify. Running it without optimisation is like
driving when stuck in first gear. C++ is not designed to be used
without optimising compilers. Use at least -O1 to inline all the "no
code generation" functions that abound in C++, and to enable analysis
for static error checking.
 
Compiling the Error class with -Wall -Wextra gives
 
<source>: In constructor 'Error::Error(const char*)':
<source>:5:5: warning: 'Error::message_' is initialized with itself
[-Winit-self]
5 | Error(const char* message) : message_(message_) {}
| ^~~~~
<source>:5:23: warning: unused parameter 'message' [-Wunused-parameter]
5 | Error(const char* message) : message_(message_) {}
| ~~~~~~~~~~~~^~~~~~~
Compiler returned: 0
 
 
The tools are there to help, and would have given you the answer
immediately. (But then we'd have missed this Usenet thread!)
Mark <m.n.summerfield@googlemail.com>: Oct 12 03:32AM -0700

On Wednesday, October 12, 2022 at 10:57:30 AM UTC+1, David Brown wrote:
 
> > What am I doing wrong?
> You forgot the critical compiler flags:
 
> g++ -Wall -Wextra -O2 -o t t.cpp
 
[snip]
 
Good point. I'm actually using scons so I'll add those now.
 
Thanks!
"daniel...@gmail.com" <danielaparker@gmail.com>: Oct 12 06:36AM -0700

On Wednesday, October 12, 2022 at 5:19:41 AM UTC-4, Mark wrote:
> > | Error(const char* message) : message_(message_) {}
> > Look closely at what you're initializing message_ with.
 
> Thank you! (I also had to change the private member to `const char * message_`.)
 
I would suggest instead you use
 
class Error : public std::runtime_error {
public:
Error(const char* message) : std::runtime_error(message) {}
}
 
std::runtime_error makes a copy of the message rather than
holding a pointer to it (usually in an internal ref counted string
because copying a std::runtime_error is not allowed to throw.)
 
Daniel
Mark <m.n.summerfield@googlemail.com>: Oct 12 08:31AM -0700

[snip]
> holding a pointer to it (usually in an internal ref counted string
> because copying a std::runtime_error is not allowed to throw.)
 
> Daniel
 
Why is that better? Most message strings will be constants "something happened", with some being created dynamically "something happened to " + obj.
Paavo Helde <eesnimi@osa.pri.ee>: Oct 12 09:26PM +0300

12.10.2022 18:31 Mark kirjutas:
>> because copying a std::runtime_error is not allowed to throw.)
 
>> Daniel
 
> Why is that better? Most message strings will be constants "something happened", with some being created dynamically "something happened to " + obj.
 
 
Right, and your solution won't work for the dynamically created
messages. Regardless however rare they are, it still won't work. So you
would need to add a second mechanism for handling them, and having two
mechanisms instead of one, without any justification, would be
definitely worse.
 
In case you come from C or otherwise have strong premature optimization
desires, rest assured that the exception throwing mechanism itself is
typically hundreds of times slower than an error message copy, so there
is no point to try to save on that.
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)