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

[Dirk Hohndel]

On Jan 19, 2014, at 2:06 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:

> On Sun, Jan 19, 2014 at 1:51 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>> 
>> And it turns out that change has a rather significant impact on the results.
>> 
>> Try it on my dive 222. I see differences of 3 minutes in TTS with and without this patch.
>> 
>> e.g., 15:00 into that dive I get 23 minutes without your patch but 26 minutes TTS with
>> the patch using 60 seconds granularity (this is with GF 30/75 in case you want to reproduce).
> 
> So the difference is that with time_stepsize set to one minute, it
> will assume that you go up the next three meters at most every minute.
> Which is why you get a longer TTS.
> 
> But I actually think that's more correct! Without that, your TTS is
> calculated as "you can go up 3 meters every ten seconds". Which is
> borderline fine, but is that really a good assumption? That's
> 18m/minute. Not a safe ascent rate.
> 
> (yeah, yeah, 18m/min is borderline. It's what people used to use. But
> it's not considered good practice any more).
> 
> So I'd argue that the 26-minute TTS is because with the change, we're
> being *better* at calculating TTS.
> 
> That said, the truth is probably somewhere in between. the "go up at
> most three meters a minute" is a rather slow ascent rate, I agree.

That part I hadn’t thought through. My mistake.

I think a realistic expectation for tech diving is that people will limit themselves
to the more common 30ft / 9m per minute. Which means that we’d do the 
calculation every 20 seconds instead of every 10. I agree that 3m per minute is
safer, but if I look at the profiles that tech divers have submitted in the past, I
don’t think it’s realistic. And if I look at our tech dives we tend to travel at about 
6m/min between deco stops (and based on the 10 sec sample rate I have briefly
gone as fast as 12m/min).

/D