diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2013-01-06 23:58:33 -0800 |
---|---|---|
committer | Dirk Hohndel <dirk@hohndel.org> | 2013-01-07 07:33:33 -0800 |
commit | d281ad84fdce7990a09402c212885c7268ad8bd9 (patch) | |
tree | 66b2ad7548315467032e884a1edd633b88eccd79 /planner.c | |
parent | 1ee0101b280d582bbdea87ae9ae9c67314ea6fb1 (diff) | |
download | subsurface-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