From: Carlo Wood (carlo_at_[hidden])
Date: 2006-06-08 09:19:37
On Thu, Jun 08, 2006 at 08:31:37AM +0100, Andy Little wrote:
> > "Deane Yang" wrote
> > Carlo Wood wrote:
> > > English: meter per second
> > > Dutch: meter per seconde
> > > French: mtres par seconde
> > > German: meter pro sekunde
> > > Spanish: metro por segundo
> > >
> > > I think that 'per' is as much english as 'divided by'.
> > > People who know english won't be confused by it.
> > >
> > I also vote for "per".
I never "voted" for per, I just said that div and per are
both English and one shouldn't worry about one being confusing
while the other is not. The few language examples that were
given are just to back that up for this particular case.
I agree with Paul Giaccone that's it's just a red herring, actually.
Sorry for the confusion.
I have to agree with Paul's remark about not actually doing
a division too. And now I think about it, there is another reason
to prefer 'per' over 'div': If you use 'div' then you insinuate
that you are dividing, and therefore that you are multiplying
the other terms. Thus, pascal (pressure, in N/m^2) is kg/(m s^2)
would be kg_div_m_s2, insinuating: kg / m * s^2
However, that means (mathematically): (kg / m) * s^2
By using 'per', it is more plausible to give '_' a higher precedence
than 'per'. kg_per_m_s2 can more easily be defined to mean kg/(m s^2).
It seems that the correct way to pronounce it normally seems to be
kilogram per meter per second per second, or
kilogram per meter per second-squared.
The 'per' is repeated, thus.
So, should it be: kg_per_m_s2 or kg_per_m_per_s2 ? In the latter case,
my argument against div doesn't hold anymore, of course.
> in this case, as typedefs for declaring a quantity of a particular type , you
> end up with
> velocity:: m_per_s
> velocity:: mi_per_h
> It might even be possible to abbreviate it and keep the sense:
> velocity:: m_p_s
> velocity:: mi_p_h
I'd prefer the full 'per'.
What is 'mi'? Shouldn't you use the full english word everywhere?
That is less confusing. You also don't write 'rec_mass::per_kg'.
The only exception to the rule of abbreviation should be for
the (SI?) units and the prefixes: nm, mm, km, kg, Pa, N, cd, etc.
I'm not even sure if we want to abbreviate non-SI units:
feet, calories, barrels, acres, inches, buckets...
By the way - if you abbreviate kilo to k, and mili to m.
Then what is the full list? (from http://www.ex.ac.uk/cimt/dictunit/dictunit.htm)
yotta [Y] 1 000 000 000 000 000 000 000 000 = 10^24
zetta [Z] 1 000 000 000 000 000 000 000 = 10^21
exa [E] 1 000 000 000 000 000 000 = 10^18
peta [P] 1 000 000 000 000 000 = 10^15
tera [T] 1 000 000 000 000 = 10^12
giga [G] 1 000 000 000 (a thousand millions = a billion)
mega [M] 1 000 000 (a million)
kilo [k] 1 000 (a thousand)
hecto [h] 100 (a hundred)
deca [da]10 (ten)
deci [d] 0.1 (a tenth)
centi [c] 0.01 (a hundredth)
milli [m] 0.001 (a thousandth)
micro [µ] 0.000 001 (a millionth)
nano [n] 0.000 000 001 (a thousand millionth)
pico [p] 0.000 000 000 001 = 10^-12
femto [f] 0.000 000 000 000 001 = 10^-15
atto [a] 0.000 000 000 000 000 001 = 10^-18
zepto [z] 0.000 000 000 000 000 000 001 = 10^-21
yocto [y] 0.000 000 000 000 000 000 000 001 = 10^-24
I could agree with the more known ones:
peta (P), tera (T), giga (G), mega (M), kilo (k), deci (d),
centi (c), milli (m), nano (n), pico (p), femto (f)... but
then again, that's just me (being familiar with those and
not the others). I suppose you should support them all.
I suppose that using 'u' as abbreviation for micro makes
most sense (there isn't a 'mu' symbol in the C++ character
-- Carlo Wood <carlo_at_[hidden]>