Boost logo

Boost :

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2007-03-05 15:46:06

Matthias Schabel writes:
> > In building probability and likelihood models, I often encounter the
> > issue of transforming from either to their logarithms and vice versa.
> > Code would be much simpler and less error-prone if the appropriate
> > domain was defined, the natural arithmetic operators were used, and
> > the conversions occurred (or could be prevented to catch errors) as
> > necessary, but without necessarily requiring explicit bookkeeping to
> > distinguish these quantities and their logarithms.
> >
> > This suggests a (small) set of types with appropriate conversions,
> > much as in the units library. However, probabilities are of course
> > unitless.
> >
> > Should this idea be developed as a separate library or does it make
> > any sense to fold it into the existing units framework?
> We've tried to make mcs::units as flexible and extensible as possible
> in order to accommodate a wide range of value types; as you point
> out, since probabilities and log probabilities don't have associated
> units (by definition, since taking the log of a unit doesn't make any
> sense from a dimensional analysis standpoint), so I don't think this
> is something that should be directly supported in the library
> itself.

 Voice from the back of the room:

  a) It might be handy, though, to have (for example) a log function
  that enforces unitless quantities. For example,

     log ( velocity * time / meters )

  is fine, but if you forget to multiply by the time, you get a
  helpful error message.

  b) It might also be handy, if possible, to have some functions that
  take units and know what to do; for example, sqrt (m*m) properly
  returns meters, and so forth.

  < returns to lurk mode >

Dave Steffen, Ph.D. Fools ignore complexity.
Software Engineer IV Pragmatists suffer it.
Numerica Corporation Some can avoid it.
ph (970) 461-2000 x227 Geniuses remove it.
dgsteffen_at_[hidden] -- Alan Perlis

Boost list run by bdawes at, gregod at, cpdaniel at, john at