Software Suggestions

[ajduplessis]

I really like Baltic deco planner for the iPhone. I haven't tested the multi-level stuff extensively. Baltic has a separate gas blender for the iPhone as well. Great interface IMO.



Likely the change was to correct the problem pointed out here.

Try V-Planner

 

[KenGordon]

ZHL 16 is a simple thing to implement. It would suit a school science project for 14 year olds. Ross will be doing that correctly. The GF part is a bodge. I disagree with most of what Ross says but I agree with that. It really is a fudge to add fashionable behaviour to an easy to implement algorithm.

If you think what Ross says is a cause for concern about multideco you ought to treat it as a cause for concern about the whole set of GF planners and computers.

My other concern is a soft one. How does a user decide which GF pairs to dive?

Personally I plan all my deco dives twice. Once for the GF computer on my left wrist and once for the Suunto computer on my right wrist (and probably my buddy). I use multideco for the GF computer (the vendor being too small/mean/shortsighted/unable/not bothered/happy to have Ross do it (delete as appropriate) to provide matching planning software) and use the Suunto software for the Suunto. The biggest issue with it is if is not available for an iPad or iPhone so I do not take it on day boats, but I usually plan those dives well ahead.

As Stuart has discovered using subversion, being able to edit levels easily is nice.

I have the paid versions of Baltic and PastoDeco on my iPad and IPhone but still use Multideco and still recommend Multideco, despite having read every post of all the deep stops threads.

Here is a challenge. I will buy beer (at the pub of my choice) for anyone that can generate a wrong plan with multideco ZHL-16/GF (ignoring metric vs imperial confusion).

 

[UWSojourner]

Here is a challenge. I will buy beer (at the pub of my choice) for anyone that can generate a wrong plan with multideco ZHL-16/GF (ignoring metric vs imperial confusion).

That's a challenge without reward -- beer at the pub of your choice? So I win the bet -- you say "I'll buy you a beer in hell." I say, "I don't think I'll be there with you." You say, "Well, those were the terms of the bet." So how about offering the license fee of another deco program?

Throwing down the gauntlet like that would imply some independent standard that you could appeal to. To my knowledge that doesn't exist. If I pointed out a problem, how would I overcome the retort "That's not a bug, that's a feature!" All of these methods require judgement calls at some point since all the published code was designed for essentially square profiles, and certainly not profiles as complex as those where you enter deco, descend out of deco, then reenter deco, etc.

Having said all that, I can easily show parts of profiles in V-Planner that I don't think fairly represents VPM-B (I don't have Multi-Deco). So if you change your reward, put VPM-B into the mix, and agree on a set of rules for fairly judging, then I'll pick up the TruDive license (on you) and write a review . PM me if you're interested.

I write this half in jest of course. I really have no intention of spending another several hundred posts arguing about the ins and outs of VPM-B or GF for a beer. I'm more just saying that if you hold up something as the gold standard then you certainly should have done some detailed independent testing yourself. Because not all that glitters is gold.

 

[KenGordon]

That's a challenge without reward -- beer at the pub of your choice? So I win the bet -- you say "I'll buy you a beer in hell." I say, "I don't think I'll be there with you." You say, "Well, those were the terms of the bet." So how about offering the license fee of another deco program?

Throwing down the gauntlet like that would imply some independent standard that you could appeal to. To my knowledge that doesn't exist. If I pointed out a problem, how would I overcome the retort "That's not a bug, that's a feature!" All of these methods require judgement calls at some point since all the published code was designed for essentially square profiles, and certainly not profiles as complex as those where you enter deco, descend out of deco, then reenter deco, etc.

Having said all that, I can easily show parts of profiles in V-Planner that I don't think fairly represents VPM-B (I don't have Multi-Deco). So if you change your reward, put VPM-B into the mix, and agree on a set of rules for fairly judging, then I'll pick up the TruDive license (on you) and write a review . PM me if you're interested.

I write this half in jest of course. I really have no intention of spending another several hundred posts arguing about the ins and outs of VPM-B or GF for a beer. I'm more just saying that if you hold up something as the gold standard then you certainly should have done some detailed independent testing yourself. Because not all that glitters is gold.

You have been reading Scubaboard too long.

The beer can be at any London pub, some inNova Scotia, Orkney, Gozo (but you had better be quick for that) or even New York (subject to intense scheduling pressure).

I'd be the judge of whether the the error was an error or not. I have the means to do that. I don't for VPM and am not very interested in writing an implementation.

It's not like you have to buy me beer if you can't find one, although maybe if you claim to have found one and I disagree...

 

[UWSojourner]

You have been reading Scubaboard too long.

Guilty.

I'd be the judge of whether the the error was an error or not. I have the means to do that. I don't for VPM and am not very interested in writing an implementation.

I don't have multi-deco but given the thrashing of GF by you-know-who, and his repeated claims that you can't change Baker's code, I'd have some concerns. But again, if there are problems there's still no standard to appeal to for a ruling since, as we've seen, you can just blame the GF method itself or Baker's original code rather than a poor implementation of the idea. FWIW I doubt there would be any problems for easy scenarios like square profiles.

I might be in Manhattan in November (if I can get the tickets I'm looking for). If you're there I'll mortgage my house and buy you a beer .

 

[KenGordon]

I very much doubt that the various multideco implementations, or indeed PDCS or other planners are running Baker's fortran code. To run a random little bit of fortran in an iOS app vs recoding it in C or some other easy to run anywhere language is a bit of a pain. So I guess he has his own implementation. However that implementation must give the same answers as everyone else's similar rewrite or the goal of the planner matching the on the wrist computer is not met.

There is scope for errors such as floating point error explosion, stupid edge cases and so forth. However this is a bit of software which has had use for many years. This builds confidence.

As for changing the behaviour of Baker's GF, Ross can't do that alone. Suppose a bunch of people decided that rather than messing based on depth that conservatism could be introduced by messing with the first couple of compartments' constants and that was a superior and proper algorithm. To be useful a bunch of vendors would need to take it up (or you get stuff like the various Zhl-8 computers with nobody really knowing what they do). Then there is still a disadvantage because this new version doesn't even have the anecdotal backing which GF sort of has.

I think I understand Ross's point about GF, and I think it is a fair point to make. I think it extends to all the planners and computers which use it. I also think it doesn't really matter.

Because of this I think this thread starts from a faulty premise. If you are going to use GF you might as well use his.

I might yet produce my own, so I am in effect praising the competition. It would not compete on algorithm, but on usability. Maybe I'd put work into being able to plan for my Suunto on the boat too. My expectation is that the revenue would not stretch to a proper night out in the pub. I have however worked on the odd thing that hardly covered the coffee we drank watching it go live...

It will be January when I am in New York.

 

[UWSojourner]

As for changing the behaviour of Baker's GF ...

It's not so much changing Baker's code (regardless of the language it's ported to), but completing it to account for all the cases his code didn't really contemplate. And for the "edge cases" as you say that need to be thought through. Based on you-know-who's criticisms, he has had quite a lot of problems thinking those cases through. And he does appeal to Baker's code to justify his critique of GF as having unresolvable issues.

 

[KenGordon]

I disagree with that assertion. The fortran code and accompanying commentary are enough to produce something which works. Perhaps the questions of 'how?' are well enough covered by more recent publications such as Deco For Divers that it is easier to write that code today than when Ross first did his. (Actually, I may be wrong about this as Multi Deco is new compared to vplanner).

However I think that the claim that GF is a bodge is valid.

 

[UWSojourner]

However I think that the claim that GF is a bodge is valid.

I'm not familiar with the what makes GF a "bodge". Care to elaborate?

 

[KenGordon]

Really the ZHL thing is that there are limits of supersaturation and the algorithm works by keeping within those limits. The bodge is to reduce those limits according to where the first stop lies. One part is a tested algorithm, developed by well regarded scientist in the field. The other part is an addon produced by someone else with a view to adding conservatism at depth. Other than lots of opinion, is there really anything to support how that is done? The choice of those numbers is subject to the same flaws as whatever critical bubble radius applies to a bubble model.

GF is deceptively accessible 'dial a profile', they ought to be more conservative than raw ZHL-16C, but without testing how do we know? We are back to the same place as arguing over VPM etc.