4 ms·
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
by a_e_k 2y ago
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.
- amszmidt 2y agoThe 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.
- aulin 2y agoit's like they purposely add some controversial rule just for engagement
- ezconnect 2y agoHe even uses 'switch' on his code.
- mcinglis 2y agoAs 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!
- lifthrasiir 2y agoI 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.
- ack_complete 2y agoI'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.
- teddyh 2y agoI think you used the word “panacea” incorrectly. Judging by context, I would guess that the word “band-aid” would better convey your intended meaning.
- nine_k 2y agoA "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.
- zbentley 2y agoPerhaps "placebo" was intended?
- a1369209993 2y agoIIUC, they're using the word itself correctly, but they mean "double precision is often used with the intent of it being a panacea".
- sdk77 2y agoThere 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.
- AnimalMuppet 2y agoOK, 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...
- JKCalhoun 2y ago> 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.
- projektfu 2y agoThe 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.
- atiedebee 2y agoWhat'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
- Lvl999Noob 2y agoI 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.
- sixthDot 2y agofunnily 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 https://godbolt.org/z/Yr7Kn4vqr
- spookie 2y agoYeah, 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