• can't think of any more stupid names (unregistered)

"Why fabs(number1) > 0, and not, I don't know, number1 != 0?"

Habit. When comparing floats to 0, it's prudent to use > rather than != because "0" can be a bit of a moveable feast.

Whether you need to do that here or not is up for discussion, but NAWTF.

• Industrial Automation Engineer (unregistered)

unless we're counting molecules, I don't think we can call a default value of 10000000000000000000 "small"

Why fabs(number1) > 0, and not, I don't know, number1 != 0?

Maybe because "number1 !=0" won't catch negative values would be my guess

Addendum 2022-10-18 07:10: Doh! Totally missed the "fabs" part of the.

Seriously though Bruce Dawson had an excellent blog article (randomascii at wordpress) about comparison of floating point numbers and what can go wrong.

• AnotherNonSignedIn (unregistered) in reply to Brian Boorman

• (author)

Sure, but in this case, we are only checking against divide by zero errors.

• Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

The `fabs(number1)` call might have been intended to protect against negative 0. Might have been. Except, negative 0 compares as equal to positive 0, so a test for `== 0` would still have correctly handled negative 0 as well.

• (nodebb) in reply to can't think of any more stupid names

When comparing floats to 0, it's prudent to use > rather than != because "0" can be a bit of a moveable feast.

Well there are multiple representations of zero in IEEE 754, but I would hope the compiler or fp hardware would understand that.

I think this is cargo cult programming. Somebody has heard the "do not compare floating point values for equality" rule and compared for equality without using an equals sign. They have adapted the `fabs(a - b) > some_small_value` pattern and broken it by using 0 instead of some small non zero value.

Addendum 2022-10-18 09:20: Technically, they are comparing for inequality.

• (nodebb)

Back in the mid to late 90's I encountered a situation where 0 != -0. This would have been on a Pentium Pro with some version of MS Visual C. I had to go with the fuzzy equal route to get that code to work.

• Ollie Jones (unregistered)

On the scale of Good / Bad / File Not Found, I fear this WTF comes down at File Not Found. What's this file being validated? And what does the mythical file have to do with percentages?

• Sole Purpose Of Visit (unregistered) in reply to Jeremy Pereira

Half-way to a decent solution in the engineering domain.

That small number should be a tolerance, not a pointless initialisation. And (assuming no operator overload, which would require a class constant for the tolerance at the least), you need to test for "zero" by taking the absolute value of one double minus another double, and comparing that result to the tolerance.

At which point you have a "zero" case. Whether that is meaningful in this instance depends upon whether the values really need to be doubles or floats in the first place. But it's basically your special case: do whatever you want with it, but calculating a percentage off some tiny little denominator (or numerator) is a mug's game and will rapidly decay using basic numerical analysis.

I had to do three code reviews on a mathematician's version of something very like this. Apparently those versed in pure mathematics do not care to consider real world consequences.

• DJ Dizzy Spudplucker (unregistered)

So, delta (0.25, 1) = 0.75 , not 3.00? Interesting definition of "percentage"

• Barry Margolin (github) in reply to Ollie Jones

This is a pretty common pattern. When receiving regular updates to a file, you compare the old size with the new size, to make sure it hasn't changed too much. A big change, especially large shrinkage, can indicate that something went wrong when generating or downloading the update.

But when I've done this, it's the old size that I divide by. Except for the first time, we shouldn't have to worry about the old file being zero-length, and I deal with that by handling a nonexistent old file separately. If the new file is zero-length, the percentage difference will be 100%, which should fail validation.

• Gaetan (unregistered)

The funny thing is that, in the context of the code, this works. The developper calling delta() was aware of its peculiarities. They just didn’t document the dratted thing (that’s the usual boring WTF).

• @stupid names : agreed.
• @engineer : that’s basically what the program does !
• @Keith : Good point! the code was developped with Visual C++ in the 90s, so that could actually be a precaution against a bug like this;
• @Ollie : the program reads values from a file, and it has to decide whether they are too different (or not) from the values it expects;
• @Sole Purpose : thankfully there isn’t any overload here. My guess is that the implementor was actually aware of the zero case, and thus decided to write the function this way. I just wish they had documented their reasons somewhere, and cleaned up the messy parts (delta initialization, and the "zero" case);
• Gaetan (unregistered) in reply to DJ Dizzy Spudplucker

I guess "ratio" would be the proper word. Personnally I have always considered that % meant /100, so 0.75, 75/100 and 75% are all the same (as a kid that would lead to some heated discussions with math teachers who expected things like 3/4*100=75%)

• (nodebb) in reply to Sole Purpose Of Visit

That small number should be a tolerance, not a pointless initialisation.

I don't know if Remy is trolling us, but 1e19 is not a small number, it's enormous.

• (nodebb) in reply to Industrial Automation Engineer

Oh, Industrial Automation Engineer got there first...

unless we're counting molecules, I don't think we can call a default value of 10000000000000000000 "small"

• cellocgw (unregistered) in reply to stoborrobots

You may think 1E19 is enormous, but it's peanuts compared to how large the galaxy is...

• akozakie (unregistered) in reply to cellocgw

Size of the galaxy in micrometers or in milions of light years? Again, numbers without units...

• akozakie (unregistered) in reply to Industrial Automation Engineer

Even if counting molecules, 1e19 would still be almost 0,02 mmol, so eg. over 1/3 mL of gas - small, but still a non-negligible, macroscopic amount. Not so for water, a fraction of a microliter is far too small to even call it a droplet.

• (nodebb)

I can see a possible reason for that useless initialization. I've done a few of them over the years because the system wasn't bright enough to realize that the value was assigned in all possible paths and was complaining about using an uninitialized value.

• xtal256 (unregistered) in reply to Gaetan

It helps to remember that % is literally "per cent", which means per 100.

• Chris (unregistered)

If one value is 0, and the other is non-zero, I would call that 100% difference for practical reasons (I think it's undefined in theory). But then again, when I use code like this, I'm usually looping until the difference is less than some very small value (e.g. 1E-12).

• MaxiTB (unregistered)
Comment held for moderation.
• Chris (unregistered)

"23 comments - Last comment @ 02:03" - but when?!

• (nodebb) in reply to Chris

Today. If the last comment is on a previous day, it's always shown as just a date on these pages.

• (nodebb) in reply to Gaetan

math teachers who expected things like 3/4*100=75%

If they only replaced that "100" with "100%" then everything would be fine.

• MaxiTB (unregistered) in reply to Steve_The_Cynic

There is no today, as long as it isn't in UTC :-)

• Andrew Klossner (unregistered)
Comment held for moderation.
• Ninos (unregistered)
Comment held for moderation.