Re: [OctDev] Octave interface to GNU units

[Paul K. <pki...@us...>]

On Dec 30, 2005, at 5:03 PM, James R. Phillips wrote:

>
> --- Andy Adler  wrote:
>
>> I think that this is a much more important feature than
>> unit conversions. I would like to have software that gives
>> me an error when I say "1 apple + 2 oranges" rather
>> much more than one that tries to automatically find
>> the apple/orange conversion factor.
>>
>> One good way to do this in a strongly typed language
>> would be to create classes for each unit.
>>
>
> I must respectfully disagree with this approach (I've been a 
> dimensional
> analysis maven for years).  I think this concept is practical and 
> efficient
> only for high-level symbolic analyses, not for production numerical 
> analysis
> codes.
>
> IMHO, a better approach is to confine unit conversions, as much as 
> possible, to
> input and output routines, while the core internal calculations are 
> carried out
> in standard textbook-style equations that are correct in any 
> dimensionally
> homogeneous unit system.
>
> If this is done properly, than the actual "base" unit system for the
> calculations is irrelevant (within roundoff).  One way to check for 
> unit errors
> in the equations is then to switch the base unit system, and see if it 
> affects
> the results.
>
> To reiterate, each quantity is converted into the base system on 
> input, and
> into desired output units on output.  The "units" function provided 
> here could
> be used for that, but isn't as convenient as it could be if it were 
> possible to
> set a desired default set of base units.  Then the function could just 
> be
> interrogated for the necessary conversion from any unit into the 
> desired base
> system.
>
> Admittedly there are some fields of endeavor (econometrics) where the 
> standard
> equations of physics are not in much evidence, and can't be used to 
> check the
> correctness of the core calculations.  Again, however, I think that 
> symbolic
> analyses of the core equations are a better way to flush out unit 
> errors than
> embedding this sort of check into every numerical operation.

I wonder if the 125 M$ Mars Climate Orbiter could have afforded the 
extra
processing cost of carrying units with every quantity?  Perhaps not, but
clearly it couldn't afford to drop them either.

Carrying units is an aid to producing correct code, so having the 
facility
available in a prototyping environment would by helpful.  Whether they 
can
be handled efficiently enough to be used in a production environment
is a separate question.

- Paul