summaryrefslogtreecommitdiffstats
path: root/planner.c
diff options
context:
space:
mode:
authorGravatar Linus Torvalds <torvalds@linux-foundation.org>2013-01-06 23:58:33 -0800
committerGravatar Dirk Hohndel <dirk@hohndel.org>2013-01-07 07:33:33 -0800
commitd281ad84fdce7990a09402c212885c7268ad8bd9 (patch)
tree66b2ad7548315467032e884a1edd633b88eccd79 /planner.c
parent1ee0101b280d582bbdea87ae9ae9c67314ea6fb1 (diff)
downloadsubsurface-d281ad84fdce7990a09402c212885c7268ad8bd9.tar.gz
Do pressure-time integral using integer values
Now that the pressure_time calculations are done in our "native" integer units (millibar and seconds), we might as well keep using integer variables. We still do floating point calculations at various stages for the conversions (including turning a depth in mm into a pressure in mbar), so it's not like this avoids floating point per se. And the final approximation is still done as a fraction of the pressure-time values, using floating point. So floating point is very much involved, but it's used for conversions, not (for example) to sum up lots of small values. With floating point, I had to think about the dynamic range in order to convince myself that summing up small values will not subtly lose precision. With integers, those kinds of issues do not exist. The "lost precision" case is not subtle, it would be a very obvious overflow, and it's easy to think about. It turns out that for the pressure-time integral to overflow in "just" 31 bits, we'd have to have pressures and times that aren't even close to the range of scuba cylinder air use (eg "spend more than a day at a depth of 200+ m"). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Diffstat (limited to 'planner.c')
0 files changed, 0 insertions, 0 deletions