Log Units?

[Dirk Hohndel]

On Apr 28, 2013, at 4:44 PM, Mark Kampe wrote:

> On 04/28/13 13:09, Dirk Hohndel wrote:
> 
>> No - the SI units are there for a reason. They make sense to the vast majority
>> of the planet (outside such forward thinking countries like Liberia, Birma and…
>> I keep forgetting the third one in the triumvirate of brilliance that's imperial
>> measurements),
> 
> I will make no excuses the stubborn resistance of the US Congress to
> the the adoption of a more rational system of measure.  All nations,
> and political systems are subject to fits of insanity.  But the most
> important person to whom a log entry must make sense is the diver in
> question.
> 
> Weights labelled in pounds, like (also inferior) yoke valves, are
> to be found all over the world ... so while the SI may well be used
> throughout (most of) the civilized world, the calibration of dive
> weights in kilograms is not (yet).  Presenting information in the
> form most natural to each user is just good user interface.

Yes. And our USER INTERFACE does that. While we do care about a readable
file format, the file format is not the user interface.

>> they allow us to avoid rounding errors (as they are the units
>> that we use internally).
> 
> I hope I didn't give you the impression I was suggesting a change
> in internal units.  The rounding in the conversion from pounds to
> grams is already (very explicitly) happening on input:
> 
>>      case LBS:
>>           weight->grams = val.fp * 453.6 + 0.5;
> 
> My weights are labelled in pounds, and that is how weights are
> entered for each new dive.  Whether that conversion is done once
> upon initial entry, or repeatedly every time the log is read in
> should have no computational consequences.

Since we store internally in grams we'd now get the rounding twice. Once 
when you enter, then again when you write it out. Then again when you read 
it in. Etc. 
The only way to avoid this would be to store the value internally in lbs as well.

> The argument for (my suggestion of) symmetric rounding on the
> output side is weaker.  It is more likely to be correct in the
> common cases, but could result in round-down if somebody actually
> entered small fractional pounds.  But this invites a question about
> the importance of precision in this particular metric ... as
> (a) lead weights are not precisely calibrated
> (b) such precision would be orders-of-magnitude dwarfed by tidal
>    lung volume changes.

Totally agree.

My problem is that users enter 13lbs. And then get 12.999 lbs in the XML.
And they will correctly state "that's wrong".

>> And most importantly they are well defined. A "pound"
>> and a "gallon" are actually different amounts, depending where in the world
>> you are.
> 
> The above code would seem to already ignore that complication, and
> assume that whenever pounds are entered, they are US pounds.

Yes - I'm saying "you want US pounds and US gallons". The next user wants
German pounds (500g) and british Gallons. 

I simply don't see the value in having these units in the data format.

I repeat. I'm not against changes to import files with explicit units correctly.
And you are always free to post-process your XML files if that's what you want.

/D