$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Matthias Troyer (troyer_at_[hidden])
Date: 2005-10-20 13:47:36
On Oct 20, 2005, at 7:56 PM, Phil Richards wrote:
> On 2005-10-20, Deane Yang <deane_yang_at_[hidden]> wrote:
>
>> Phil Richards wrote:
>>
>>> I gave up trying to progress with boost-ing it because I couldn't
>>> see
>>> a path of consensus to what was actually wanted. There seemed to be
>>> a desire for more flexibility, and I couldn't see the point :-(
>>>
> [...]
>
>>> In fact, all I've ever needed is physical4_system (mass, length,
>>> time, temperature), and never need to convert units because we
>>> always insist on everything being in SI.
>>>
>> Yes, this was a major issue.
>>
>> Do we want a general dimensions library (without even predefining
>> ANY
>> dimensions at all) that I claim would have extremely broad
>> applicability outside physics, or do we want a physical-
>> dimensions-only
>> library that predefines a standard or basic collection of physical
>> dimensions.?
>>
>
> The difficulty with not having some basics defined is that it makes
> things a lot more complicated :-)
>
> SI length is defined as having unit in meters. meters has
> dimensionality of length^1, in SI (and Imperial, for that matter).
>
> If you change your basis set for dimensional analysis, then length
> may not be a basis dimension in this new basis set. This different
> new (derived) definition of "length" dimensionality has to exist in
> a different namespace to SI length. And it *can't* interoperate
> with it particularly easily - you would have to specify the
> transformation of each basis dimension from one family to the other.
>
> Which, funnily enough, is where I got to with my "dimensionality
> family" stuff. I was never enormously convinced of my solution, it
> has to be said, but it works if all you want to do is define disjoint,
> non-interacting, dimensional analysis systems.
>
> (You can define any basis set you like, and call things in it anything
> you like (everything is partitioned either by class or namespace
> scopes)
> but it won't let you mix-and-match things of different families.)
>
>
>> I am strongly in favor of the former, I have also never
>> understood why
>> the latter couldn't be built using the former anyway, so the library
>> could have two layers to it. The physicists could ignore the
>> lower layer
>> completely, and I could ignore the upper one.
>>
>
> Ok, give a few examples of different basis sets that may be wanted :-)
> The best thing to drive this forward are real use-cases for the
> library.
> Without them, we'll just go round in circles again.
Just one example: in Lorentz-invariant (relativistic) simulations I
might set the speed of light c=1, and consider time and space to be
the same unit. As a consequence also energy and mass then have the
same units. Or in q quantum simulation I might set the Planck
constant \hbar=1, with other consequences for the unit system.
A general purpose system, that could be used to implement SI or
totally alien unit systems --- even more alien than the US one :-)
--- would be the best way to go. An SI unit system could then be
easily built on top of it.
Mattthias