RFC: support for deco algorith and parameter fields

[wrob311 at gmail.com]

On Thu Oct 16 2014 16:09:06 GMT+0100 (IST), Jef Driesen wrote:
[...]
> 
> +typedef enum dc_deco_alg_t {
> 
> I'm not really in love with the "deco_alg" abbreviation. But 
> "deco_algorithm" becomes pretty long. Maybe just "algorithm", or 
> "decomodel"? Other suggestions are welcome too.

While 'algorithm' is used quite often, the 'model' is more correct, IMHO. Quite often a simple change to deco model parameters causes its name change i.e. ZHL-16B vs. ZHL-16C. Calling them two different algorithms does not make sense.
 
[...]

> 
> +	DC_DECO_ALG_BZH,    /* Buehlmann ZH, no GF */
> +	DC_DECO_ALG_BZHGF,  /* Buehlmann ZH, with GF */
> 
> The BZH name sounds a bit cryptic to me. How about naming it BUHLMANN 
> instead?

If I am not mistaken Buhlmann was calling  his models ZHL-XY, i.e. ZHL-16C. There are Buhlmann models with different number of tissue compatments than 16...

[...] 
> > DC_FIELD_DECO_INFO
> > 
> > and
> > 
> > struct dc_deco_information_t {
> > 	unsigned int algo;
> > 	unsigned int param1; /* e.g. GFhigh or GFS */
> > 	unsigned int param2; /* e.g. GFlow */
> > 	unsigned int param3; /* currently unused */
> > };
> 
> I'm not really sure what would be the best solution here. Are there any 
> other algorithms besides the GF that have parameters that make sense to 
> support? One concern is that with an integrated structure, we can't add 
> new parameters if that's ever necessary. I'm not really in love with 
> placeholder fields either. While with a separate DC_FIELD_DECOPARAMS 
> type, we can introduce different data structures for each deco 
> algorithm. For example:
> 
> struct dc_decoparams_gf_t {
> 	unsigned int low;  /* e.g. GFhigh or GFS */
> 	unsigned int high; /* e.g. GFlow */
> };

You are basically opening a can of worms. :) Manufacturers like to add their own parameters it seems. Look at OSTC custom functions where ZHL-16C is extended with desaturation/saturation multipliers ( note: non-GF version). Also there are parameters which I find hard to classify. Is calculating your deco 1m deeper than you are part of deco model extension or a safety feature? And these are probably specific to a dive computer  manufacturer. 

Maybe the best structure would be simple list of (name, value) pairs for all dive computer configration options (name being a string)?

Regards,

Artur

-- 
Sent from my Linux and Python powered mobile device