Open builtbybrayne opened 6 years ago
the PR looks ok, but I'm a bit worried about growing nimber of options like yours. Maybe we should move to much simple api, for example toNumber()
callback that takes number-like string as an input and decides what to return - JS number, BigNumber or something else. If not present the behaviour is automatic ( BigNumber if not all integer digits can be preserved accurately )
@sidorares why not merge this PR ?
This bug with parsing very long decimal numbers is making the package unusable for people who want to stick to the built-in number/bigint instead of using bignumber package. :/
@sidorares any chance this can be merged and a new minor released?
Two new options for strategies for converting to floats.
The problem I had was that a number like '1.234567890123456789' is longer than 15 characters and therefore was being converted to a BigNumber. In my case, I definitely want this left as a float and don't care about the loss of precision.
To this end I created 2 options for parsing numbers as floats:
options.floatHints
andoptions.strictFloatHints
. Both are documented in the updated readme. But long story short; the strict version always treats the presence of a decimal as an instruction to parse the number as a float. The loose version will only parse the number as a float if the mantissa is non-zero. If it is zeroable, then it is stripped, with the integer part then subject to the same logic that existed previously.Tested.