v3.2.0

Moved Mixed Logarithm notation to core from community.

Note: This is a breaking change. I expect there may be other similar breaking changes (notations moving) in upcoming third-digit changes. I know this violates semvar but the convenience of adding one new notation to AD at a time and not having the version number become 10.0.0 outweighs it for me. You can do new (ADNotations[x] || ADCommunityNotations[x])(); where x is the notation name if you want to always update to the most recent version but not be affected by these changes. If you don't currently use any community notations, you should probably not be affected by these changes in any case.

v3.1.0

This version fixes an issue wherein mantissas of large numbers sometimes started with 0 due to rounding (e.g. 0.80e100,000,000,000,000 rather than 8.00e99,999,999,999,999, though this specific case may not have been an example).

v3.0.4

This version fixes a dependency version issue causing errors for almost all operations when installed via node.

v3.0.3

Fix various edge-case function parameters issues that weren't getting caught by the outdated compilation script.

v3.0.2

Fix an error that was stopping npm from accepting the package (but not stopping the compiler).

v3.0.1

Try uploading to NPM, under some guesses as to why the previous version didn't upload.

v3.0.0

This release adds a new placesExponent parameter to format for some notations, defaulting to places if not defined.

• This parameter is used to define how many places of precision to give exponents.
• For the builtin notations using this parameter, there will be at least two places of precision on the exponent regardless of this parameter's value, as added in version 2.2.3.
• This new parameter may be near-term changed and shouldn't be extremely relied on to keep working in this exact way.

v2.2.3

This release adds a minimum precision to all nested exponents in some notations, even if the precision parameter is smaller. E.g., for scientific notation, this minimum is 2, so formatting 1e1.2345e12 in Scientific with precision 0 will give 1e1.23e12, not 1e1e12.

v2.2.2

Update default precision on exponents to be a parameter definable in settings (ADNotations.Settings.exponentDefaultPlaces). By default, this is 3.

This precision is used when a call to .format leaves precision undefined (by e.g. not having that parameter at all), and only matters for certain notations (basically, those with an exponent). v2.2.1 behaved as if this was 3, v2.1.0-v2.2.0 inclusive behaved as if it was 0, and versions before v2.1.0 behaved as if it was 3.

v2.2.1

Restore pre-2.1.0 behavior on exponent formatting with undefined precision (this behavior was to have three digits of precision).