Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-08-22 07:37:10


"Matthias Troyer" <troyer_at_[hidden]> wrote in message
news:5639A1B4-1BA8-4D1E-852F-0B07F3BCFC3A_at_itp.phys.ethz.ch...
>
> On Aug 22, 2006, at 7:51 AM, Andy Little wrote:
>
>>
>> "Dave Steffen" <dgsteffen_at_[hidden]> wrote in message
>> news:17642.14441.683655.649056_at_yttrium.numerica.us...
>>>
>>> Comment from the back row: Some people will want automatic
>>> conversions. Some people will want a compilation failure. Both are
>>> perfectly reasonable behaviors, and which one is appropriate is
>>> project specific.
>>>
>>> If (either) units library fails to provide both capabilities, it will
>>> be unusable for some category of projects.
>>>
>>> I don't know how to control this, nor what the interface should look
>>> like, but I am certain that a good units library will be able to go
>>> both ways.
>>
>> What? By means of a Macro switch in the config header?
>
> If we really need it, then better with a template parameter in the
> classes so that both can coexist

Actually, just experimenting with using this feature shows it to be quite
useful.
I only experimented with one example and tried changing one length unit to
millimeters whereas previously it was meters. The ensuing game then was to try
to get the code to compile without using any explicit unit conversions. ( You
need to understand the semantics of Quan to understand that it is possible,
using SI units, to work ,for example in picometers, with exactly the same
accuracy as you get with meters, but you would need to study the docs ( and
maybe code) in some detail to see why this is possible).

I found I had to change velocity from m.s-1 to mm.s-1. Then forces to mN. I was
finally left with one constant , air_density, originally with a value of 1.225
kg.m-3. which I had to change to 1.225e-9 Tg.m-3, at which point the code
compiled OK without requiring any explicit conversions. (Each conversion
representing a loss in speed and accuracy)

It is clear from the above that the original choice of meters is probably best
because of the very small air density value, but in another application perhaps
different units would be a better choice.

Even sticking with meters ( and 'user units' of millimeters), using the macro
switch showed that some optimisation could be done by changing units of various
functions and so on.

So I reckon I'll leave this feature in the Quan toolbox :-)

regards
Andy Little


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