[PATCH] Stop doing the (very expensive) pow() calculation pointlessly

[Linus Torvalds]

On Tue, Jan 21, 2014 at 7:49 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Sun, 2014-01-19 at 14:21 -0800, Linus Torvalds wrote:
>>
>> So the TTS code is actually being overly conservative.
>
> So what's the conclusion here (I know you are knee deep in the merge
> window, but I want to close on this)?

I don't think the problem is really well-defined.

So what happens right now is that the TTS calculations calculate when
it is ok to move up to the next 3m mark - and we do that at 10s
intervals. And then when it *would* be ok to move up, it generates a
ascent profile to do so in 15 seconds (using one-second increments),
so you have that "wait at depth until ok to move up, and then move up
at 12m/min ascent rate".

And it's really not wrong.

At the same time, it doesn't feel *right* either. Quite frankly, the
"stops" aren't really stops - they are just delays. I say that because
the whole "at 10s intervals" can mean that you have a 20s stop at 15m,
then go up to 12m, then have a 10-second stop there, go up to 9m, and
now perhaps your ceiling has gone away entirely, so you go up to the
surface at that 12m/min rate (although realistically, the stops are
likely to get longer as you get shallower, so a more realistic example
might be "10s delay at 15m, then 30s at 12m, then 1:10 at 9m, and then
2:30 at 6m and 7:10 at 3m)".

See what I'm saying? With the stops at 10s granularity, it feels more
like it's following the ceiling, rather than being really about
"stops". Would you ever do a stop that was one minute and ten seconds?
That's sounds just wrong to me. It's not a *stop*.

But at the same time, if what you *actually* wanted to follow the deco
ceiling (with some reasonable limit to ascent speed, and 12m/min
sounds fine), you wouldn't do that silly stop calculation at all, and
3m increments wouldn't be that magical. You'd literally instead just
do something much simpler:

 - every ten seconds, ask yourself, can I go up 0.5m?
 - if not, make the next 10s point at the same depth
 - if yes, make the next 10s point at 0.5m shallower.

that's a much more obvious algorithm, and doesn't mix "stops" with
"ascent speed". It just says "we have a max ascent speed, and
sometimes we can't go up". It would just do a very obvious thing.

And if we really want to talk about stops, I don't understand why the
granularity is so short. 10s granularity for a stop? That's insane.

BUT!

But the current code isn't *wrong*. Changing the time_stepsize to 60s
I think makes sense as long as it's stops (it will still then generate
the *ascent* as 15 one-second ascents of 20cm each, which is a bit
over the top too, but whatever). And that's what my one-liner thing
did. But you're right that it changes timings quite noticeably,
because now any partial minute stop always rounds up to the next
minute (not by any actual rounding action, but simply because we only
*check* at whole minutes). So the fact that your TTS changed from
23min to 26min (or whatever) is actually very simple: three minutes is
just about what you'd expect if you had six stops (ie half a minute
more waiting on average). So coming up from 18m or so?

So on the other hand...

And if we get rid of the notion of stops entirely, I think that would
simplify the code, and would actually make TTS more understandable in
one way ("TTS = time to surface, given the ceiling and a maximum
ascent speed"), but we actually *expose* the "stops" part right now to
users (that whole "stoptime_calc" and "stopdepth_calc", and I think we
show it in the Info window).

So I don't know. The current code isn't wrong. It's somewhat
inefficient, and not very logical imnsho. But while making the stops
longer makes them more logical as "stops", nobody really stops at 3m
intervals *anyway*. And if we make the code what I'd consider
*logical*, it would be simpler and make more sense, but we'd miss the
current stoptime/stopdepth parts.

We could obviously make the "stopdepth" be the first depth where we
actually have to wait. The thing is, if we do it right, that might
actually be never (because by the time we've ascended to the first
stop that we calculated as the ceiling _originally_, the 12m/min
ascent rate may mean that the ceiling has already gone away).

Anyway. End result: I don't know what the right thing to do is. I
could easily do the simplification, but see above..

             Linus