From: Jesse Booher (jbooher_at_[hidden])
Date: 2003-12-16 10:23:36
Mr. Schabel skipped over the most obvious unit friendly form of the expression sin(theta + theta^2):
sin(theta + theta * theta / _radians);
I can't say that I can recall applying trig functions to polynomial expressions, but it is extremely common to apply some sort of function to the result of a polynomial expression that is expected to have some sort of unit. It might seem like a pain to specify explicitly what the appropriate unit for the coefficient of each polynomial term is, but this might arguably be worth the effort when working with problems in applied math.
>>> Walter Landry <wlandry_at_[hidden]> 12/15/03 08:37PM >>>
Matthias Schabel <boost_at_[hidden]> wrote:
> > | It is not uncommon to have expressions like sin(theta + theta^2). It
> > | sure doesn't look clear to me that theta and theta^2 should have
> > | different units. They should certainly be allowed to mix.
> > |
> > This might be what you want, but it may conflict with what dimensional
> > analysis/checking system is possible in C++.
> > To achieve this in practice, could you reasonably require the user to
> > cast to
> > some POD?
> > sin(static_cast<float>(theta) + static_cast<float>(theta^2) );
> There are a couple of options for those who don't feel that degrees and
> should be classified as units :
> 1) continue to use the <cmath> functions and go on your merry way.
That seems pointless
> 2) extract the value from the unit like this :
> 3) convert the units to dimensionless like this :
> std::sin(theta/_radians + (theta/_radians)^2)
> 4) write your own dimensional analysis/unit library and prohibit the
> use of angle tags somehow.
> I personally feel like this discussion is largely tangential
> (and am under the distinct impression that Mr. Landry couldn't be
> bothered to give the SI web site I referenced his time)
No. It doesn't address the theta + theta^2 issue either.
> Whether or not your personal religion admits degrees, radians,
> bunches of grapes, dozens, or any other random existing or future
> tag is largely irrelevant. There are people for whom it will be
> helpful in decreasing the error potential of their code to be able
> to use dimensional analysis, and those people are the users I'd like
> to target with this library. If you don't like the fact that
> radians appear in the SI unit system, there is no compulsion to use
> them nor any consequence to not doing so.
I have no problems with making degrees a unit. Those shouldn't be
mixed with anything else without conversions. But radians are a
different matter. If I take arctan(1.0), I expect a number, not
something with units.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk