Problems with using js-quantities to parse engineering input about js-quantities HOT 4 OPEN

No updates, but it already works out of the box:

Qty('1 N*m').to('lbf*ft') // outputs a quantity of roughly '0.74 lbf*ft'

One could add the unit 'Nm' though:

var UNITS = {
  // ... //
  /* torque */
  "<Newton-meter>" : [["Nm"], 1.0, "energy", ["<kilogram>","<meter>","<meter>"], ["<second>","<second>"]],
  // ... //
};

from js-quantities.

This seems like it should have been a few separate tickets. Or maybe a blog post.

This library is a port of https://github.com/olbrich/ruby-units.

• As far as "lb ft" goes, as you said, that is wrong. You need to use the correct type ("lbf" in this case). If you want your users to type incorrect (or ambiguous) stuff in by hand and still get the same results as if they typed in the unambiguous correct units, you will probably have to handle this context yourself.
• Force has dimensions "(kg_m)/(s_s)", energy "(kg_m_m)/(s*s)". I believe those should not be compatible units unless you divide your energy by a length (or multiply your force by a length). If you are able to convert incompatible units, that sounds like a bug and should be filed.
• This library needs a way to compute degF -> degC as a rate of change as well as tempF -> tempC as a temperature value. Since ruby-units used the deg/temp naming convention, so does js-quantities. This separation was done to avoid ambiguity and namespace collisions.
• In order to avoid ambiguity and namespace collisions, there are spaces (or "*"s) required between the different units. If you have a better way, perhaps with an additional "kind" parameter to the constructor, perhaps you should fork the project, add a new constructor, and file a pull request?

Conclusion: Yes, it looks like you are trying to do something that js-quantities was not intended to do. It was intended to convert values between 2 compatible unambiguous unit types, and it does that very well (my team is using it in production to convert weather station data to localized values). It was not intended to be used to guess a user's intention and decide what they really wanted was X despite what they asked for. For that you'll want to use Google. ;)

PS - If you do come up with a good (unit testable) new constructor, I would definitely be interested in merging it into my fork (and who knows, @gentooboontoo might merge it too). However, the unit tests would need to be thorough (possibly generated programmatically by looping through all possible unit types with and without prefixes and joining them to determine which ones are ambiguous -- there might not be many, but there definitely are some).

from js-quantities.

Looks like I'm wrong, lbf is pound-force not pound-foot maybe it's lbf*ft that is wanted? Which also explains why you said force (meaning torque) is compatible with energy (so not a bug). And there doesn't seem to be a simple way to differentiate torque from energy here.

from js-quantities.

Any update on js-quantities being able to handle torque?

from js-quantities.