Configurable unit formatting

[ericman314]

The formatting of units works well 90% of the time, but sometimes the results are surprising. We should make the formatting of units transparent and totally configurable. The current behavior is strange enough to have drawn a lot of issues.

A successful fix ought to address most of these related issues:
#1481
#1452
#1449
#1314
#1306
#1300
#1282
#1008
#898

[zcohan]

I'd love to see an auto style mode that "does the right thing" however does not do any implicit unit conversions based on previous calculations or custom units. Result predictability is critical for my use case.

[ericman314]

Here's a list of ideas of taken from all the related issues so far:

• Units formatting is deterministic and totally predictable by default
• Configurable selection of prefixes, with defaults that make sense (like, stay away from the less commonly used prefixes)
• The default configuration is like the current auto, which does the right thing and is predictable
• No side effects on format or toString, or any other unit function
• Config options live in the math.config object, rather than on the Unit prototype (can have several instances of math at one time but only one Unit). Where should custom units live then?
• Setting a unit system causes units to always be formatted using in that system if possible
• Ability to unset the unit system
• Formatting of units depends on configurable parameters, not on use history
• Be able to select sub-systems within a group of units, such as GiB vs. GB and US vs. metric tablespoons, etc.
• Not have overly complicated rules for choosing units -- normal people should be able to understand what's happening
• Be able to disable autoselection of the prefix
• Separate the format function into multiple functions, each taking care of one step in the formatting pipeline
• Perhaps, rather than auto-selecting the best prefix, each unit has a list of common prefixes. So you would never get Mm or megameters, the highest SI prefix for meters that you would ever see formatted would be km kilometers. You could still parse them, though.
• Configurable parameter to decide whether to simplify a compound unit based on the number of symbols such a simplification would remove. For example, if the threshold is removing 5 symbols, and the result of a calculation is 10 kg / m s^2, this would be simplified to 10 Pa, but 10 N / m^2 would be unchanged, since a simplification can only remove 4 symbols.

[josdejong]

Thanks @ericman314 for collecting all these ideas 👍 ! I think predictability and no side effects are indeed very important, and more configuration options can make that work.

can have several instances of math at one time but only one Unit

I think that should not be the case, every math instance should have it's own instance of Unit. I'm not entirely sure but I think this is already taken care of in the upcoming v6 that I'm working on branch modular_architecture.

About global config vs. options: may depend on which direction we want to go with Unit.js too, see #1486.

@ericman314 if you start playing around with implementing these ideas, can you please create a branch based on modular_architecture? We're close to releasing a first beta and I would like to save us a painful merge.

[ericman314]

You bet, these will all be breaking changes anyway.

[josdejong]

FYI: I've merged modular_architecture into develop now.

[Chris1234567899]

Is there any news on this one?
Or workarounds meanwhile?

[ericman314]

I'm working on it in https://github.com/ericman314/UnitMath. Most of the checklist items above have been addressed. There's just a bit more work to do regarding custom units, and when it's ready we'll schedule it for the v7 release I think, with UnitMath as a Math.js dependency.

[TheOneTheOnlyJJ]

Is there any progress on UnitMath integration?

[josdejong]

No, not lately.