Fix float/double mismatches in source

[hollasch]

Lots of places where we're using double constants for use in float calculations, mixing up our widths when passing parameters, and such. We need to ensure that our code compiles without any warnings about mixing precision.

Ideally, it would be good to determine what the impact of float vs. double. Personally, I prefer double precision, as it's the native precision for math, and C++ constants, and is frequently faster on platforms that perform intrinsic computation in double-precision (and thus induce a performance hit when transforming from and to single-precision.

[trevordblack]

A possible solution here is to replace all decimal precision types with a "real" type that is typedef'd to doubles or floats

…

On Sat, Aug 17, 2019, 11:19 Steve Hollasch ***@***.***> wrote: Lots of places where we're using double constants for use in float calculations, mixing up our widths when passing parameters, and such. We need to ensure that our code compiles without any warnings about mixing precision. Ideally, it would be good to determine what the impact of float vs. double. Personally, I prefer double precision, as it's the native precision for math, and C++ constants, and is frequently faster on platforms that perform intrinsic computation in double-precision (and thus induce a performance hit when transforming from and to single-precision. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/RayTracing/InOneWeekend/issues/67?email_source=notifications&email_token=ACNZVKHLGQVU7I527F673U3QFA6MHA5CNFSM4IMQC6HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HFZNAVQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACNZVKCGXMBHY3NHCUYKWFDQFA6MHANCNFSM4IMQC6HA> .

[trevordblack]

I don't believe that my comment above is warranted. We should pick a precision type and stick with it.

I went ahead and created a benchmark.
On my own
Intel® Core™ i7-9750H CPU @ 2.60GHz × 12
running in Ubuntu 18.04.3 LTS
Compiled with Clang6.0.0 ubuntu
I found:
double: 442 seconds
float: 456 seconds
The difference is noise.

If more data is warranted,
$ git pull
$ git checkout origin/tdb/real_type_exp
$ cd src
$ mkdir build
$ cd build
$ cmake ..
$ make
$ time ./Real_Type_Double > double.ppm && time ./Real_Type_Float > float.ppm

To Be Clear
This is not a production branch.
Once a decision of floats vs doubles is made, I can go through and replace Reals with the selection.

[hollasch]

I also had the idea of using real = double or using real = float. However, your benchmark bears out my experience, that float is not a performance optimization, and indeed, working entirely in double values often yields a (tiny) performance benefit. Old habits die hard, though.

I say we convert the entire code base to use simple double-precision floats.

Anybody else care to comment?

[ronaldfw]

If double is not slower than float (single precision) here, I'd vote for just using double everywhere. With float you could get performance benefits when implementing certain parts with SIMD (SSE, AVX) but I don't think we should go there (and I don't know if there are even places where that would work well in any of the code here).

[hollasch]

I think we're starting to lean toward double at this point. The only reason to use single-precision is that GPUs typically work with floats, but we're not in that domain. Converting to float is fine for storage purposes, but we're not doing that either.

[trevordblack]

From all of this discussion, what I've arrived at is that the only significant difference between floats and doubles for this domain is that floats are much more likely to have shadow acne.

This is arguably a benefit because it would much more clearly illucidate the problem.

Other than that, I'm not seeing any real argument that isn't aesthetic. My vote is for doubles.

[hollasch]

I suspect that adopting double precision may not change the frequency of surface acne. Does it matter if your intersection point is 1e-10 inside the surface versus 1e-100 inside? Should be a simple test to verify, but agree with Trevor that it shouldn't really affect the decision.

Sounds like we're agreed on using double.

[vchizhov]

I am for using float rather than double. The main argument towards using double that I managed to gather from here was self intersection.
However self-intersection occurs even with double precision. And thus should be handled in a different manner, see #137.
On the other hand using float allows for a straightforward extension of the code through SIMD, as well as a minor scalar code speed up.

[hollasch]

No, see my comment just above yours. Self intersection is not one of the arguments. Instead,

• double is frequently faster, since it can avoid conversion overhead. This is not an argument in favor, however, since ultimate performance is not a goal of this book.
• Most math libraries are double-precision in arguments and return value.
• Floating point literals are double-precision.