Hacker News Reader

Comment by a_e_k | Hacker News Reader

I feel like I probably agree with about 80% of this. It also seems like this would apply fairly well to C++ as well.

One thing that I'll strongly quibble with: "Use double rather than float, unless you have a specific reason otherwise".

As a graphics programmer, I've found that single precision will do just fine in the vast majority of cases. I've also found that it's often better to try to make my code work well in the single precision while keeping an eye out for precision loss. Then I can either rewrite my math to try to avoid the precision loss, or selectively use double precision just in the parts where its needed. I think that using double precision from the start is a big hammer that's often unneeded. And using single precision buys you double the number of floats moving through your cache and memory bandwidth compared to using double precision.

View on HN

I'm torn both ways on the double issue. On the one hand, doubles are much more widely supported these days, and will save you from some common scenarios. Timestamps are a particular one, where a float will often degrade on a time scale that you care about, and doubles not. A double will also hold any int value without loss (on mainstream platforms), and has enough precision to allow staying in world coordinates for 3D geometry without introducing depth buffer problems.

OTOH, double precision is often just a panacea. If you don't know the precision requirements of your algorithm, how do you know that double precision will work either? Some types of errors will compound without anti-drifting protection in ways that are exponential, where the extra mantissa bits from a double will only get you a constant factor of additional time.

There are also current platforms where double will land you in very significant performance problems, not just a minor hit. GPUs are a particularly fun one -- there are currently popular GPUs where double precision math runs at 1/32 the rate of single precision.

I think you used the word “panacea” incorrectly. Judging by context, I would guess that the word “band-aid” would better convey your intended meaning.

A "panacea" is something that cures.every illness. 64-bit floats could do just that, in the cases listed. The cost of it may be higher than one cares to pay though.

And when the cure fails to be adequate, well, it becomes a band-aid, a temporary measure in search of a real solution.

Perhaps "placebo" was intended?

IIUC, they're using the word itself correctly, but they mean "double precision is often used with the intent of it being a panacea".

Are there C++ libs that use floating points for timestamps? I was under the impression that most stacks have accepted int64 epoch microseconds as the most reasonable format.

> int64 epoch microseconds

surely nanoseconds is the truth.

LONG_MAX nanoseconds is just Friday, April 11, 2262 11:47:16.854 PM, not exactly a future-proof approach. I guess having Tuesday, September 21, 1677 12:12:43.145 AM as the earliest expressible timestamp neatly sidesteps the problem of proleptic Gregorian vs Julian calendars.

I think Apple is still doing that: https://developer.apple.com/documentation/foundation/nstimei...

Couple decades ago Microsoft did that too, VT_DATE in old OLE Automation keeping FP64 value inside. Luckily, their newer APIs and frameworks are using uint64 with 100-nanoseconds ticks.

Don't have a publicly visible reference to give at the moment, but it's still sometimes seen where relative timestamps are being tracked, such as in an audio library tracking time elapsed since start. It's probably less used for absolute time where the precision problems are more obvious.

It's very common in games.

Integers are always an option, of course, but in this context it's hard to beat the convenience of just storing seconds in a floating point number.

The one about not using 'switch' and instead using combined logical comparisons is terrible ... quite opinionated, but that is usually the case with these type of style guides.

it's like they purposely add some controversial rule just for engagement

He even uses 'switch' on his code.

As the author 10 years later, I agree. A hard-and-fast rule to ban switch, as that rule seems to advocate, is silly and terrible.

Switch has many valid uses. However, I also often see switch used in places where functional decomposition would've been much better (maintainable / testable / extensible). So I think there's still value in advocating for those switch alternatives, such as that rule's text covers. Not that I agree with everything there either. But, useful for discussion!

I think the fact that graphics care a lot more about efficiency over marginal accuracy qualifies for a specific reason. Besides from that and a few select areas like ML, almost any reason to use `float` by default vanishes.

There are popular embedded platforms like STM32 that don't have hardware double support, but do have hardware float support. Using double will cause software double support to be linked and slow down your firmware significantly.

OK, but if you're writing for that kind of platform, you know it. Don't use double there? Sure. "Don't use double on non-embedded code just because such platforms exist" doesn't make sense to me.

Sure, my code could maybe run on an embedded platform someday. But the person importing it probably has an editor that can do a search and replace...

> I feel like I probably agree with about 80% of this.

What I was thinking too. There's something in here to offend everyone, and that's probably a good thing.

I think your case comes under the "specific reason to use `float`"? If I am writing some code and I need floating point numbers, then without any more context, I will choose `double`. If I have context and the context makes it so `float`s are vastly better, then I will use `float`s.

The issue for me is that unlabeled constants are doubles and they can cause promotion where you don't expect it, leading to double arithmetic and rounding instead of single arithmetic. Minor issue, but hidden behavior.

What's even more annoying is that the *printf functions take in double which forces you to cast all of the floats you pass in when using -Wdouble-promotion

funnily the example used, i.e `printf` of single values is very special. Under the hood, variadic arguments that are `single` are actually converted to `double`. See the `cvtss2sd` in [1].

[1]: https://godbolt.org/z/Yr7Kn4vqr

Yeah, sometimes as a graphics programmer you don't even want the precision provided by built-in functions! As it has been pointed out though, be careful about error propagation

Reply on news.ycombinator.com