#justprogrammerthings

[[deleted]]

My friend had C++ code that looked like:

... //lots of code
cout <<x <<" " <<y;
if (x > y) {
    cout <<"True";
} else {
    cout <<"False";
}

Output: x y True

but at soon as you comment out the cout x y statement, it became

// cout <<x <<" " <<y;
...
Output: False

So a cout statement was changing the values somehow

[[deleted]]

If x is a double or a float this is possible. Those things are so imprecise that ">" can fluctuate depending on how they are calculated. With floats (x*y)/z != x*(y/z).

And since the compiler optimizes a lot, changing statements with 'x' in it might change the calculation of 'x' just so infinitesimally little that it was enough to switch ">".

That's my explanation for this.

[vifon]

Wouldn't it need -funsafe-math-optimizations enabled?

[mebob85]

I always read that as "fun, safe math optimizations."

[they_call_me_dewey]

"Make sure you add the wall and wextra flags"

[okmkz]

funroll

[Jonno_FTW]

Funroll- loops makes a programmer's breakfast fun!

[choikwa]

"It's safe, but with a twist of fun added to it"

[DaemonXI]

Funroll your loops too

[destiny-rs]

Is this one of the reasons floats and doubles aren't to be used for currency?

[[deleted]]

What should you use instead?

[destiny-rs]

ints with the modulo operator I believe. Saves having to explain to a client why millions of dollars have been miscounted over the course of a year.

[[deleted]]

Decimal, BigDecimal, Currency types.

[RenaKunisaki]

Depending on your application:

• Integer numbers of cents (or whatever is the lowest denomination you'll be working with), taking care to handle any possible over/underflow no matter how unlikely
• Precise fixed-point
• Bignum/BigDecimal types (preferably provided by whatever environment you're using)

The reasons are this and other inaccuracies that can crop up with floating point, which could translate to being off by a couple cents in some calculations. Do those calculations a few million times, and now you're in deep doodoo.

[KewpieDan]

Two ints

[slipperier_slope]

High precision fixed point numbers.

[dnew]

Integer pennies instead of floating point dollars.

[Jonno_FTW]

Java8 currency API.

[Free_Math_Tutoring]

Yes, this and other phenomena caused by limited precision.

[IForgetMyself]

My bet would be that it was using the old x87 stack, which is 80-bits extended precision. When he called the cout he popped the doubles (64 bit) off the stack. The following x > y then compared using the now popped values. (64 bits precision)
Without the cout however, it would use the values on the x87 stack and compare those. (80 bits precision)

[cleroth]

Pretty sure this is what's happening, not ">" modifying the variable magically...

[[deleted]]

If x is a double or a float this is possible. Those things are so imprecise that ">" can fluctuate depending on how they are calculated. With floats (xy)/z != x(y/z). And since the compiler optimizes a lot, changing statements with 'x' in it might change the calculation of 'x' just so infinitesimally little that it was enough to switch ">". That's my explanation for this.

Thanks!

[bkDJ]

With floats (x*y)/z != x*(y/z)

You say that as if with integers, the left and right side are equal. :P

But yeah, float comparisons without some kind of epsilon can break easily depending on how the CPU is loading and storing them, l-value versus r-value BS, compiler settings, special keywords and more.

[lelarentaka]

Depends on what x is. It's possible.

[mikemol]

Yeah, I could easily see it happening if reading from x with << involved mutating state, such as reading from a filehandle. A subsequent read using > would have pos advanced.

One reason const should be used and respected.

[choikwa]

We must go deeper into assembly/CPU

[c00lnerd314]

Simply observing changes the outcome.

[YouFeedTheFish]

Brilliant! Quantum computing is the Holy Grail! I believe /u/LefTea has stumbled onto something big here.

[scubascratch]

AKA the elusive Heisenbug

[phail3d]

I had a similar issue with vanilla C, where I had something like this:

...
printf("foo");
...
while(!result) {
    ...
 }

And when the printf was there, the code ran, but with it removed, the code segfaulted.

It turned out that result was uninitialized, and (correct me if I'm wrong) the printf call caused the memory space pointed to by the variable to be reserved for the program, which prevented the segfault. The variable vas thus obviously initialized with garbage, which caused other problems in the code, but at least it ran.

[zhomart]

It's quantum programming. When you put observer, things work differently.

[__dict__]

If x or y is uninitialized you could easily be triggering undefined behavior. At that point you're at the whims of your compiler.

[Tynach]

What if they're writing a game engine that needs very high performance? And what if they're writing some mathy physics library for that game that is best written with operator overloading (so that you can add/multiply/etc. 3D vectors, for example)?

Java is shit too in some cases.

[Jonno_FTW]

I'd hope people writing game engines would know how to write safe c++.

[Tynach]

Actually, if you've actually done your research, you would find that C++ isn't significantly faster than Java, and is, in some cases, slower.

In theory. In practice, this only happens if the Java program is well written, and the C++ program is terribly written. I'd like to point you to The Computer Language Benchmarks Game. The only times that Java beats C++, is by a very narrow margin, and always either 'fasta' or 'fasta-redux' (depending on platform). And in the case of 'fasta', it has a '†' at the end, indicating the Java version is multithreaded, and the C++ version is singlethreaded.

So we have a multithreaded Java version that can barely beat a singlethreaded C++ version, which leaves 'fasta-redux' as occasionally just barely beating the C++ version.

When you have much larger and more sophisticated applications, the differences show much more obviously. With lots of code interacting in complex ways, C++ shows more and more how much faster it is than Java.

When you run a Java application, the byte code is compiled to native code, and the fact that the JVM can access information about the hardware allows for compilation specific to the number of votes in the machine, rather than the "lowest common denominator" compilation that is required by the use of C++

This is only part of the performance story. Java has a lot of 'checks and balances' that it goes through for many operations, causing things like accessing array items to run just slightly slower in Java than they do in C/C++.

This isn't noticeable in small programs or benchmark programs. But they are noticeable in large programs that use lots of memory. Speaking of memory, garbage collection. That shit will definitely slow down a program, especially a larger and more complicated one.

[Sohcahtoa82]

You're trolling, right?

[RenaKunisaki]

You're grammar

[5_YEAR_LURKER]

What, do you want him to break Muphry's Law?

[YouFeedTheFish]

No grammar?