Add acceleration due to gravity and pounds force units

[c42f]

The acceleration due to gravity and pounds force are common engineering units. (I yesterday had the misfortune to encounter these on data sheets for accelerometers and vibration isolators, respectively :-) )

Here I've added the official value of gn from CODATA (http://physics.nist.gov/cgi-bin/cuu/Value?gn) as a constant in m/s^2.

I wasn't sure what to use as the symbolic name for the associated unit of acceleration. Unfortunately g is often used in applications, which is obviously completely ambiguous with grams, so I've used ge for now, as the wikipedia page suggests it as a synonym for gn (https://en.wikipedia.org/wiki/Gravity_of_Earth). Is there a standard place to go looking for a better or official name for this? The unit vs constant seem to usually be conflated, it's pretty cool that this package expresses those concepts independently!

[coveralls]

Coverage remained the same at 69.102% when pulling f20d8e0 on c42f:earth-gravity into b1b85b5 on ajkeller34:master.

[ajkeller34]

Sorry for the delayed response, and thanks a lot for your interest in the package! These are good additions but I'm actually a little worried that the naming scheme could become confusing if we do this differently for a lot of dual purpose units/constants. Perhaps you could help me hash out how to handle this?

One option would be to distinguish by consistent naming convention. For example, right now in Unitful there's c (a unit) and c0 (a constant). The reason behind this choice was simply that I've never seen c0 used as a unit. More generally, one could imagine just appending something to the name of a unit to get the corresponding constant, but that could feel kludgey, and in this case the 0 indicates something specific (="speed of light in vacuum") that wouldn't be true for all cases.

Another option is that I could make a separate package for constants-as-units. There'd be a separate string macro to return a constant as a unit. This could be annoying, since then you wouldn't be able to put everything in one string macro. On the other hand, it would be pretty clean, and I bet it would be possible to have this work anonymously to support using any constant as a unit (to be used sparingly...)

Maybe there are other alternatives? Or perhaps I'm overthinking it and I should just merge as is.

[c42f]

Thanks for the response, these seem like great questions. I took a while to reply because I don't have any great answers, only more questions :-)

One thing I'm trying to understand is the utility of a constant c0 vs the corresponding unit c. I can see that sometimes you'd want to use c0 in a calculation, but perhaps from a user's perspective 1u"c" works almost as well? I don't know the internals of the package, so maybe there's quite a performance penalty to be paid for mixing many constants-as-units, but I've already found myself having to pepper code with various calls to uconvert() to get a sensible output, even when working in a combination of Hz and s, for example.

So which units will a constant be defined in? I don't think there's a general answer to this, given that Unitful supports various customary units (thanks btw, this package is already amazing for dealing with unfamiliar customary units). Physical quantities will naturally be defined in SI units, at least.

I wouldn't be keen on having constants like gn in a separate package, if that meant we couldn't define naturally quantities like pounds force and access it with u"lbf" just like all the other units - the u macro is what makes this package so usable IMHO, as it allows the unit namespacing problem to be dealt with in a reasonable way without also completely bloating the usage syntax. Perhaps I misunderstood you here.

Hmm, so far I'm somewhat liking the idea of very systematically mangling the names, hopefully with a symbol which just can't be confused with a unit. _ seems like the only really obvious candidate - so gn_ would be the constant, and gn the unit. c_ the constant and c the unit? It's a bit ugly, I admit.

Or what about putting all constants into a separate submodule (rather than a separate package), and just conflating the names of unit and constant? Thus Consts.c, vs u"c"; Consts.gn vs u"gn"? Admittedly this conflation isn't completely completely conceptually clean, but at least you'd have one name for two very related things.

[c42f]

Well, I actually want to use this, so regardless of the larger issues, perhaps you'd consider merging a simplified version of this, perhaps one where the name of the constant is stashed away from the public API if you'd rather not commit to it right now?

What I wanted in making this change was primarily to gain access to the following via the u_str macro:

• A unit for pounds force. The symbol lbf for this seems straightforward and non controversial.
• A unit for standard gravity. I spent some more time just now searching for an appropriate symbol for this, but didn't find anything definitive, other than the CODATA value which seems more like a constant than a unit.

Defining the actual constant was a side issue, simply to make the above two things cleaner.

Now that I look back on what I've got here, I wonder whether it might have been better to use g0 for the constant, and gn for the unit, given the potential to confuse ge with the equatorial gravity (at least according to https://en.wikipedia.org/wiki/Gravity_of_Earth). There doesn't seem to be an obvious right answer.

[ajkeller34]

You could always put your lbf,gn,ge in a module and call Unitful.register on the module. (If the module is part of a larger precompiled package, you need to call Unitful.register in your __init__() function.) This mechanism allows you to make any units/constants available to the @u_str macro.

That being said, I don't want to inconvenience you if that solution doesn't work for you for whatever reason, so I'll just merge this for now, with the warning that I might change it in the future.

[c42f]

Oh, thanks! I was quite happy to wait a little longer, just wanted to restart the conversation to avoid the PR falling off my radar completely as I've had to move on to other work. I'm fine if you change this later. Regarding register, I'm sure this would have worked, it just seemed sensible to have lbf in here at least, along with other US customary units :-)