unit type for addition to std lib [was Re: D Language 2.0]

[BCS]

Hello SiegeLord,

> Avogadro's number is not know precisely, and because of that very
> reason the unit of mole is used. It is not even known precisely enough
> to fill out the 15 digits of precision that double type provides,
> which just makes it unacceptable as a hard-coded constant (unlike say,
> pi).

Aside from precision considerations (and IIRC there's a team working on moving 
off an artifact defined kg and, as a side effect, will solve that), your 
argument holds just as well for angles.

> 
> Secondly, defining it as a constant like that you are robbing the user
> of 9 digits of precision for no good reason. With that approach,
> amounts like 1.234567 mol are not representable in a double, almost as
> bad as using a float! Chemists will not be pleased.

Why are they not representable as a double? Also by treating the mole as 
unitless with a magnitude of one gets you almost everything you could want 
(in fact the only difference you get is that 1 and 1mole are different types, 
the math, the bits in memory and everything else is identical).

> 
> Thirdly, it's an SI unit. If you claim that the library supports the
> SI units, then you should do that. There are 7 base SI units, your
> personal objections non-withstanding. MKS and CGS do exist, but I've
> never seen them used in Chemistry in my experience. Similarly, I've
> never seen chemists converting moles to the numbers of atoms they
> represent.

Good point, however aside from naming the type "SI" (and I can change that) 
I never made that claim.

> 
> On a related note, and as a large limitation of this library, there
> are these things called 'natural' units, which are SI derived units
> with some complex constant in front. See here
> (http://en.wikipedia.org/wiki/Natural_units#.22Natural_Units.22_.28Par
> ticle_Physics.29 ) for example. It is impractical to treat them as
> derived units, primarily due to precision losses, so they must also be
> base units. Since there's an innumerable number of these
> (scientifically) valid units, it really should be possible to define
> custom units by the user somehow.

I /think/ you can show that as long as you stick to only SI or only natural 
units, the added error from not having natural units will be approximately 
equal to the round off error from a few multiplication and an equal number 
of divisions and be independent of the math in between or the precision of 
the convection constant used.

I'm adamantly opposed to a system that allows adding arbitrary units, particularly 
one that treats meters and some natural length units as different types. 
I'm opposed because those units are in fact the same and the only reason 
to not treat them the same is because of n implementation detail; limitations 
of discreet system.

That said, it wouldn't be to hard to set things up so that you can have an 
alternate set of base units (you would have one type that internally converts 
to SI and another, different, type that converts to, for example, the natural 
units for particle physics)