dnum.from Incorrect number from String() converting to scientific notation about dnum HOT 7 CLOSED

got here because that's how the pyth api is setup btw https://docs.pyth.network/pythnet-price-feeds/best-practices

from dnum.

Oh good catch! Yes we should definitely handle this better. I’ve been doing some tests and noticed that even toFixed() can produce scientific notation numbers:

(10 ** 20).toFixed(20) // "100000000000000000000.00000000000000000000"
(10 ** 21).toFixed(20) // "1e+21"

From Number.toFixed:

If the absolute value of numObj is greater or equal to 10²¹, this method uses the same algorithm as Number.prototype.toString() and returns a string in exponential notation. toFixed() returns "Infinity", "NaN", or "-Infinity" if the value of numObj is non-finite.

I see two paths:

• We try to get it right, maybe by using something like https://github.com/shrpne/from-exponential which seems complete. It would make the library a little bit heavier but not by much.
• We detect the scientific notation and add a specific error message to let consumers know about the exact problem and how to solve it. An issue I see with this solution is that the error might not appear during the development phase but later.

Also I am thinking that it might be good to add some warning in the README about the limitations of using numbers as an input, compared to strings / bigints / dnums.

What do you think?

from dnum.

I think ethers throws a numeric underflow(?) well this lib users probably are already avoiding numbers so a warning on readme and custom error message may be enough
but if it's easily fixable I don't see why not, from-exponential is tinyy

from dnum.

looks like from-exponential loses precision 😢

from dnum.

Oh too bad, yes then I guess the simplest way to handle it would be a custom error for now. Let me know if you want to open a PR for it, otherwise I’ll do it later this week :)

from dnum.

Fixed 680f4ad

from dnum.

@greg-schrammel I changed my mind and decided to use from-exponential rather than throwing an error. The reasoning is that Number is always prone to precision loss so it doesn’t change that.

https://github.com/bpierre/dnum/releases/tag/v2.7.0

from dnum.