[PATCHES]

[Robert C. Helling]

Dirk,

> On 01 Sep 2015, at 16:27, Dirk Hohndel <dirk at hohndel.org <mailto:dirk at hohndel.org>> wrote:
> 
> Let's please remember that these algorithms are mathematical
> approximations of mostly unproven theories with random, made up limits
> that were tuned to make them match known good profiles. And then a safety
> factor was added for good measurement.
> 
> So "accurate" is a very ill defined term here.

The theory behind VPM-B is, as far as I can tell, totally made up and not even internally consistent. I have given up any hope in that direction. I don’t think of it as modelling anything in the divers body but only as an algorithm to come up with numbers for deco stops that have the advantage that there is a certain empirical basis for it, i.e. that people used these numbers in the past for their decompression and they are not all dead, yet.

There is no physics that we could try to model „better“ in any sense than the reference implementation, the best we can do is to imitate the reference implementation since that is the one with the empirical basis. This is sad but that’s the way it is.
> 
> That said, it would be a nice comfort booster if we did match the numbers
> by the reference algorithm exactly or at least didn't show any shorter
> deco (simply from a "risk of some idiot suing us" perspective.

My worry are not so much the lawyers but the users: They will compare the schedules computed with subsurface to their old schedules and based on that will decide if it is good or not (too often even the better algorithm is the one with shorter runtime). This has no empirical basis whatsoever but that is what people do (and have done in the past and discussed for example on diving web forums). People are stupid.

> 
>> Assuming there's no mistake that needs fixing in our implementation, we
>> could either live with the difference, or we could introduce a slight
>> conservatism to our nominal case.  The following is a very basic patch that
>> makes us pass all the tests again.  I'm not proposing it yes, at least not
>> until we've worked out there isn't some other tweak that we ought to do.
>> But it does work.
> 
> Um. On some level this makes me cringe (no offense Rick - this has nothing
> to do with your code) - it's yet one more "random number pulled out of a
> dark place to make profiles match.
> 
> But given what I said above, I'd be certainly willing to take this simply
> as insurance that we don't end up with shorter deco times than the
> reference.
> 
> Robert, what do you think?

I would apply this conservatism. After all, it changes a number that is not really measured by one percent which is surely very well within the measurement error if that had existed in the first place.

Best
Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150901/0422c482/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150901/0422c482/attachment.sig>