I know the version bump to 9.0.0 had no breaking changes, but for some developers the different version numbers in the doc can be confusing.

Bump it manually or automate the number with API call if only the latest documentation is shown:
https://api.npms.io/v2/package/bignumber.js

https://github.com/MikeMcl/bignumber.js/blob/986fd70e514e58e86d43bc9944547d82658e47ae/doc/API.html#L61

why would 0 * (-1) (as is negated() documented behavior) be considered negative?

Decimal('0').negated().isNegative() // true (1)
Decimal('0').isNegative() // false (2)

and that is a contradition when I compare 0 with itself, negated or not:

Decimal('0').negated().lessThan(Decimal('0')) // false (3)
Decimal('0').lessThan(Decimal('0')) // false (4)
Decimal('0').neg

It would be nice to have an option to bypass adding zeros here.

What if we have dp = 1e6, and the value passed is just 0? We end up adding 1e6 zeros, which consumes a lot of time and may be pointless for most usage scenarios.

Also, I think that pushing constant value within cycle here (and in some other places in the code) is not

Describe the bug
README is not well structured

To Reproduce
Look at README file

Expected behavior
README should provide a quick overview what the library provides, way to contribute. Detailed descriptions should be moved to Wiki

The docs for round specify:

Round to the nearest integer (by default), returning the result as a BigDecimal.

However, this is inconsistent with what is actually happening:

> BigDecimal.new("10.5").round.class
=> Integer

> BigDecimal.new("10.5").round(1).class
=> BigDecimal

> BigDecimal.new("10.5").round(-1).class
=> BigDecimal

It would appear the issue lies h

• Benchmark suite.
• Compare with Rust.
• Compare with incoming javascript's BigInt.

I'm going to procrastinate on this until Razenpok does it probably