Re: [boost] Re: quantity libraries

From: Thomas Matelich (toms-mailing-lists_at_[hidden])
Date: 2001-08-13 13:41:10

Michael Kenniston wrote:

> Thomas Matelich also wrote:
>
> > One of the features I'm looking for in a quantity/units library is
> > less of a focus on the math side of things and more of a localization, i.e.
> > the customer gets to decide what units to use.  So, the feature that I
> > would want would be the unit of measurement being stored along with
> > the quantity.  I could, I suppose, translate all user interaction through a
> > localizer, but that introduces a lot of conversions.  Why should someone
> > who wants to use feet be forced to convert to/from meters every time?
>
> I'm not quite sure what you mean here.

Let me try to clear this up.  My focus is on allowing the users of my
application to use whichever unit for length, speed, etc. is native to them.
The majority of my calls to the library will be I/O.  The users selects speed
X, I show the user they are at position Y, etc..  And I also want (application)
users with different preferences to be able to work on the same files.
I'll continue below.

> I can think of at least four possible responses, all of which are at least
> moderately interesting:
>
> 1) The user has to use the explicit syntax:
>
>     length_t x = 3 * foot;
>     length_t y( 4 * foot );
>
> instead of:
>
>     length_t x = 3;
>     length_t y( 4 );
>
> This is quite deliberate.  Allowing the second form opens a hole in
> the compile-time type-checking that invites errors.  The first form
> isn't /that/ much more to type, and it is /much/ clearer to anyone
> reading the code.  Note that the word "meter" never appears in the
> application source code unless the user actually uses meters.

I agree with this decision.

> 2) The program incurs a run-time conversion cost when it executes:
>
>     length_t x = 3 * foot;
>
> because there is a real multiply there.  This is indeed overhead, but
> my expectation is that such "real" conversions only happen on input
> and output, and the cost of buffered I/O and string-to-numeric
> conversion should swamp the single multiplication necessary to do
> the conversion.  If this is really truly a problem, adding something
> similar to the SIunits "calibration" feature might help, but I'd
> want to see hard performance data proving its necessity.

Reasonable, discussed below.

> 3) You could save the units with each quantity, and do a "lazy
> conversion" only if and when it becomes necessary.  This would
> bloat the size of every quantity object and impose a run-time
> cost to do unit-comparison on every single operation, thereby
> defeating the whole purpose of using templates, so I rejected
> this idea completely.

I don't think your arguments are absolutely true, but the solution would
most likely decrease portablility.

> 4) In between "units" and "dimensionality" there is a third distinct
> concept of "quantity-type".  For example "radian", "mil_angle", and
> "degree_angle" are different units but have the same quantity type
> (plane angle) and are thus freely convertible.  However "pure number"
> and "plane angle" are different types, even though they have the same
> dimensionality, and so should not be freely convertible.  My intuition
> is that this concept would be very useful, but at this time I have no
> clear idea how to implement it (or even define it) correctly, so I'd
> rather concentrate on just getting dimension-checking right to start
> with.
>
> If none of this addressed your original question, could you provide
> a specific example of code where the user is "forced to convert to/from
> meters every time"?

I see your point about cost to convert units vs. cost to generate string.  My
problem is that most users of my software use English units and it makes me
squeamish to impose a conversion everytime and I'm also concerned about
the (extra) calls I'm sure I'll get about "I put in 11.2 and now it says 11.1999."
Conversion between units (meters to feet) is the rare situation for my usage.

My overall biggest concern when it comes to a library such as this is ease of use.
I want the other developers using it to be so comfortable using it that I don't have
to worry about it not getting adopted.  And I want an uncomplicated system for the
localization aspect.

Anyway, that's my take on quantities.  I just keep hoping I won't have to write one
myself :)

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
matelich_at_[hidden]
tmatelich_at_[hidden]