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

Wed Jan 22 08:29:14 UTC 2014

I'll pas that out to somebody else. :)

On Wed, Jan 22, 2014 at 2:25 PM, Dirk Hohndel <dirk at hohndel.org> wrote:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140122/ffaaec4c/attachment.html>