• SiegeLord <ps335 cornell.edu> Jan 20 2010
• SiegeLord <ps335 cornell.edu> Jan 20 2010
• BCS <none anon.com> Jan 20 2010

SiegeLord <ps335 cornell.edu> writes:

Simen kjaeraas Wrote:

 On Wed, 20 Jan 2010 03:47:58 +0100, BCS <none anon.com> wrote:
 
 Hello SiegeLord,

 BCS Wrote:

 Also all of the imperial units that I don't care about, as well as
 the more obscure physical units.


 I recognised. The current vertion can have a new unit added as a
 single line of code.


 luminosity (candellas) and amounts (moles).


 They would be easy to add.

 That said All the other type systems (CGS, MKS, imperial, etc.) only  
 have those 5 and I find claiming the the last two are base units just a  
 bit silly (candelas are defined in terms of power, stradians and an  
 arbitrary curve and moles are a count). I left them out in protest but  
 I'll add them if anyone cares enough to make much of an issue of it.


 I can see reasons to add the Candela (though it is simply a function of
 other units, it is not as simple as an SI derived unit), but the mole is
 merely the Avogadro constant.
 I'd vote for this solution:
 
 enum Mole = 6.022_141_79e23;
 enum MolarMass = OfType.gram( 1 / Mole );
 
 -- 
 Simen


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).

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.

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.

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_.2
Particle_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.

-SiegeLord

SiegeLord <ps335 cornell.edu> writes:

Actually, nevermind on the precision arguments, precision doesn't work like
that. There may be other arguments for natural units that I can't think of now,
though...

-SiegeLord

BCS <none anon.com> writes:

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)