interesting little bug...

[Linus Torvalds]

On Sun, Mar 24, 2013 at 7:58 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> Diving with multiple dive computers. For some reason (let's ignore why)
> one of the computers has air as first gas and stage as second gas.
> Second computer has air as second gas and stage as first.
>
> Downloading from one then the other really gets us confused.

Yes. We have absolutely no support for that, and it's nontrivial to do.

We'd need to do something smart at divecomputer merge time, and it's
not even obvious how to do it. I think the best option would be to
have a per-dive-computer mapping from "dive computer cylinder number"
to "dive cylinder number" (which would *default* to 1:1 in the absense
of anything else), but it really is nontrivial.

At dive merge time, you'd have to look at the cylinder information for
the two dives, try to match them up by some best-effort thing, and
then modify the dive computer mapping according to that.

In math terminology, let's say that you have two dives, d1 and d2,
which both have one or more dive computers dc1'n' and dc2'n'. Each
dive computer has a mapping from the dive computer cylinder index to
the dive cylinder index f1'n' and f2'n', and they both end up
defaulting to the identity mapping (because when you do the initial
dive download, you create the dive cylinder mappings so that they are
the same as the dive computer cylinder mappings).

Now, when you merge dive d2 into dive d1, you need to create a new
function 'g()' to map the cylinders of dive d2 into the cylinders of
dive d1. And then when you insert the dc2'n' dive computers into d1 as
part of the merge, you change each f2'n' to be g(f2'n').

Nasty, nasty.

A variation of the above is to not actually ever have a mapping
function, but just instead remap all the cylinder indexes etc in the
dive computer data when merging (ie always force the mapping function
to be the identity mapping, and using the function 'g()'  to actually
change the samples data of the dive computer data when merging into
another dive. That would in some respects be simpler (avoid one
abstraction layer),. and is equivalent, so I guess that would be the
better appraoch, but it really requires rewriting the dive computer
data.

The alternative would be to not have any global notion of cylinders at
all, and make them per-dive-computer the same way we make many other
things be per-dive-computer. Then there would never be any mapping
(and never any issues of changing the mapping function when merging),
but the problem would be how to show it, and how to edit the
information. So you'd solve one problem by making the cylinder
information per-dive-computer, but you'd create another one.

Neither way is simple. There are serious problems with both
approaches. One big one is to just do the automatic cylinder pairing
the right way. It should be trivial if the two dive computers have
exactly the same cylinder gasmix information and the same gases, and
there are no ambiguous gases (ie no two cylinders are the same), but
if that is ever not the case you get into a lot of interestimg fuzzy
matching issues...

                    Linus