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

Dirk Hohndel dirk at hohndel.org
Wed Jan 22 08:25:07 UTC 2014


On Tue, 2014-01-21 at 20:31 -0800, Linus Torvalds wrote:
> 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..

Thank you for the exhaustive explanation. Sometimes I am really feeling
like I'm not seeing the forest for the trees. And this cleared up a lot
for me.

What I think would be the right thing to do is similar to what I think
most dive computers do as well:

Calculate a constant rate ascent until we would actually cross above the
ceiling (so not, "ascend from where we are NOW to the ceiling for NOW",
but instead "ascend until by going up another 3m/10ft we would violate
the then current ceiling"). Then wait in increments of full minutes
until we can ascend to the next 3m/10ft potential stop (using the same
logic as above).

This is reasonably realistic, it gives you a reasonable TTS, and it
gives you stopdepth and stoptime.

Makes sense?

Who wants to implement this?

/D




More information about the subsurface mailing list