Thursday, December 17, 2015

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

David Brown <david.brown@hesbynett.no>: Dec 17 11:29PM +0100

On 17/12/15 20:07, Patricia Anaka wrote:
> issue, I don't know. Anyone know what might be the cause of a problem
> like this?
 
> Thanks!
 
I have often heard people claim their code is correct, and justify it by
"it works in debug mode" or "it works when the optimiser is disabled".
Almost invariably, the problem is the code - it is extraordinarily rare
that a compiler bug is at fault. It is not impossible - but it is far
down in the list of suspects.
 
In this case, as far as I can see you get division by zero in some cases
- some of your test points are vertically aligned.
 
When you subtract almost identical floating point values, you are likely
to have all sorts of numerical stability problems - the subtraction
could result in 0, or it could result in almost 0, and the results can
vary according to different details of the optimisation and the actual
instructions used for computation. In particular, on the x86 if the
arithmetic is done using x87 instructions, those instructions and the
registers used are 80 bit - but anything that gets moved into memory or
the stack will get translated to 64 bits. Disabling optimisation, or
calling functions like printf, will push other data out of registers and
onto the stack - hence the difference in the runs.
 
You are going to have to do a good deal of work on your algorithm to
make it numerically stable with the sort of points you have been giving
it here. Take extreme care when dealing with equal or almost-equal
floating point values - and in your re-designed algorithm, remember not
try to compare floating point values for equality (i.e., don't add a
test for "if (points[j].y == points[i].y)" as a special case).
David Brown <david.brown@hesbynett.no>: Dec 17 11:30PM +0100

On 17/12/15 20:27, Victor Bazarov wrote:
 
> compiler documentation for that). You can extract this function in a
> separate module of course, and disable optimizations on that module only.
 
> Experiment with different optimization levels, as well.
 
Think horses, not zebras. It is always much more likely to be a bug in
the users code - compiler bugs are not unknown, but they are extremely
rare in comparison to user bugs.
Patricia Anaka <panakabear@gmail.com>: Dec 17 02:35PM -0800

> floating point values - and in your re-designed algorithm, remember not
> try to compare floating point values for equality (i.e., don't add a
> test for "if (points[j].y == points[i].y)" as a special case).
 
I take your point but it has little to do with the reason I posted. The algorithm was failing in every case in the release build, with the simplest of coordinates, if you look at my test data. The people who posted about optimizations appear to have been right.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 18 12:23AM +0100

On 17.12.15 23.29, David Brown wrote:
> Almost invariably, the problem is the code - it is extraordinarily rare
> that a compiler bug is at fault. It is not impossible - but it is far
> down in the list of suspects.
 
You didn't work much with Borland C++ compilers, didn't you?
 
> When you subtract almost identical floating point values, you are likely
> to have all sorts of numerical stability problems - the subtraction
 
This might be part of the problem indeed.
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Dec 17 02:54PM -0800

On Thursday, 17 December 2015 03:04:11 UTC+2, Lynn McGuire wrote:
 
> "Today I write about a pair of less often discussed, less complicated features introduced in C++11, which are nevertheless useful.
> Both can provide some additional security and clarity when it comes to deriving classes and overloading virtual functions."
 
> Nice! Makes one scared to use const without painstakingly ensuring that you are consistent.
 
It forgets to mention that
 
clang-modernize -add-override
 
does the trick automatically.
flimflim1172@gmail.com: Dec 17 02:29PM -0800

On Thursday, December 17, 2015 at 2:27:27 PM UTC-7, David Brown wrote:
 
> If you have the freedom to consider D or Rust, then surely you also have
> the freedom to move to C++11? C++11 is a significantly better language
> than C++03 in many ways, and is worth pushing for.
 
I use C++11 everywhere I can. It's a great improvement to say the least. The reason I'm handcuffed to C++03 has to do with hardware vendor tools/libraries (a certain game console manufacturer providing only C++03 tools with no plans to ever move to C++11 so for current gen hardware, and who provides required SDKs compiled in said C++03 environment, exposed as C++ interfaces - not C, which sorta locks you into using the same compiler they do).
 
My thinking was:
1) A layer of Rust or D application code on top which consumes / calls into...
2) A thin C interface to our libraries (so the ABI is manageable) which wraps...
3) Our C++ library components (written in 11 or 03, whatever hw vendor provides) which calls into...
4) Required hardware vendor SDKs sometimes exposed as C++03 interfaces.
 
I suppose I could stick clang C++11 at #1 just as well as Rust or D - but sure doesn't feel right. If was going to go that far, I'd rather see what Rust and D had to offer up there - at least I'd know that when coding in layer #1 I'd have known default values for int/bool/etc - which is the only place I've found myself wanting that behavior.
 
Besides, there are other things about C++ that I find not very ergonomic when writing certain subsets of code. I didn't want to turn this into a C++ rant - I love the language dearly. I guess I was hoping D and/or Rust might help with those areas too (no idea - almost completely ignorant of their features).
 
> particular value, yet want to initialise to /something/. I realise it
> looks somewhat inconsistent, but C++ has always had a distinction
> between "plain" data types and object types.
 
int x = 0 isn't what I want to avoid. I want to avoid:
 
class Foo {
Foo();
int x_;
}
 
... and then somewhere else, perhaps a different file altogether:
 
Foo::Foo() : x_(0) { }
 
Which does come back to C++11 again.
 
> application where C++ is not the most efficient development language -
> but changing to something very different, such as Python, is likely to
> have much more impact.
 
You may be right.
 
 
GOD I hope I got the annotations right this time!!!!!!
legalize+jeeves@mail.xmission.com (Richard): Dec 17 10:24PM

[Please do not mail me a copy of your followup]
 
jacob@jacob.remcomp.fr spake the secret code
>When a compiler starts up it determines the cpu type it is running in.
>If the program is for the current machine, it can choose from a set of
>different code generators which model corresponds best to the machine.
 
To me this sounds more like a case of the Strategy pattern.
<https://en.wikipedia.org/wiki/Strategy_pattern>
 
>The code generators offer the compiler a common set of actions and
>produce different outputs.
 
>Is this a case of "dependency injection" ?
 
Dependency injection is a means for isolating a class from it's
dependencies. If class A collaborates with class B, then the
particular instance of B used by A is one of A's dependencies.
Injecting the particular B instance into A through it's constructor is
dependency injection.
 
Another method of dependency injection is to pass a reference or
pointer to B into the method of A that needs to collaborate with B.
Which you should use is a matter of judgment, there is no single
"right" answer.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Dec 17 10:26PM

[Please do not mail me a copy of your followup]
 
Juha Nieminen <nospam@thanks.invalid> spake the secret code
 
> [...] What is faster:
 
This is answered by measuring the code when operating real-world data sets.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
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)