Boost logo

Boost :

From: Dan W. (danw_at_[hidden])
Date: 2004-01-07 01:33:14


Deane Yang wrote:
> Exactly! In my humble opinion the whole "physical dimension" thing turns
> out to be a journey down the wrong road. A physical dimension library
> as proposed so far seems to me is useful only if
>
> a) you always want quantities using a common
> physical dimension to be allowed to be added together (so you want
> to be able to add the mass of an apple and the mass of an orange).

Indeed, I can think of some particular context in which I have
"different lengths": hight, width, depth; where adding mixtures of them
results in sqrt( h^2 + w^2 + d^2 ) and returns raw distance; and a
specialization for when two of them happen to be zero, in which case it
could return heigth or width or depth units. Though, personally, I'd use
vectors myself; but if it were a program for use in a carboard box
factory where those are the only lengths used, it might make sense.

> b) you want to be able to mix different units for the same dimension
> within a single line of code and allow the units to be set at runtime.

I'm not so sure I trust the runtime, in fact. If it were up to me, I
would just erradicate automatic conversions of any kind, let alone in a
units library. My test, I guess, would be, can I convert back and would
I get the exact same thing or value in...
   ( *every case* ) ? ok : use cast.

And my other cow is with assignment <-> equality "correctness".

template < T, U > T & operator=( T & t, U const & u )
{
     sticky POSTCONDITION( t == u && u == t );
}

There's a new keyword for ya :)

> c) The only dimensions or units you want to use are one of the seven
> physical dimensions. Moreover, you want to use, say, at least three
> of them (if you use only one or two of them, the full seven-dimensional
> library is overkill.)

Yup. One dimension: 83%, two dimensions 11%, three dims 4% ... but then
again, 62% of all statistics are made up on the spot...

> (At this point, I am in fact determined to write my own using MPL,
> following the approach outlined by Hugo Duncan. It just sounds like
> such a beautiful way to use C++, templates, and MPL. But given my other
> responsibilities, this should take no more than five years to finish.
> So don't hold your breath. I am haranguing the other proposers, hoping
> that someone else will do the work for me.)

If you can use any of my help, I'm game, though you'd have to hold my
hand at the beginning; I'd think of landing on Mars on a surfboard as
easier than using metaprogramming.

One thing I just became finally convinced of today is that the
dimension... er.. unit power simply can't be hard-coded; it HAS to be a
template parameter. It occurred to me, even if a fractional
implementation could be hacked for the rare case of someone needing an
irrational power, once it's released, academic types will complain that
they can't use an imaginary power. And if we hack it for imaginary
powers, someone will need a complex power. And if we hack it for
complex, someone will need an octonion power. There is no end to it, and
this is the kind of thing templates are for, anyways, so why not just
simplify the whole thing and just use generic add or multiply or divide
for the power, and let it use the operator defined by the generic type used?

The other issue I was thinking about is the fact that if we're dealing
with value types, inheritance does not apply, as polymorphism pertains
to functions on the interface of classes, and is orthogonal to such
issues as assignment and comparison. The issue with values is of range
limits, convertibility, belonging to a set. Maybe one should tackle all
these issues at once and get it over with, rather than deal exclusively
with issues of measurement.
I once heard about a language that tackled set theory, in which if you
have class rectangle, and you adjust an instance of it so that the two
dimensions are equal, it automatically becomes type square, and
viceversa. Can't remember what language it was.

I could see a new paradigm happening where you have mainly two classes
of classes: values and interfaces. Values would be connected to other
values by free-floating, template, binary operators that have to do with
value, like =, ==, !=, <, >, <=, >=, plus the ones I'm missing.
Interfaces would define one-ary operators only, and obey the laws of
polymorphism. Their only footprint would be a reference to a value type,
perhaps, given to it via a template parameter or something.

Cheers!


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk