Fixed some minor bugs and improved interoperability (IMHO)

[ghost]

Summary

I really needed to exploit BigDecimals for a project of mine and soon I realized deveel-math was the only viable option. As soon as I adapted my code to deveel-math, I noted a few minor bugs & possible improvements. I tried to fix the former ones and i'm now proposing the latter ones, hoping you will accept them.

Bug fixes & Improvements

0. I fixed BigDecimals > and < operators which whose implementation was inverted
1. I made the == operator coherent with other operators by making it employ CompareTo instead of Equals
2. I made some casts operator explicit in order to adopt the very intuitive semantics of C-like languages casts, that is, loseless casts can be implicit while losy casts must be explicit. For instance:
   • Implicit casts for BigDecimal
     • from BigDecimal to floating point primitive types (float, double, decimal) and vice versa
     • from BigInteger to BigDecimal
   • Explicit casts for BigDecimal
     • from BigDecimal to integral primitive types (short, int, long)
     • from BigDecimal to BigInteger
     • from integral primitive types (short, int, long) to BigDecimal
       • this is actually an exception to the aforementioned general rule since this cast is loseless and should be implicit. My aim is to avoid the situation where an overloaded method, say someOp(BigInteger or someOp(BigDecimal), generates an error if applyed to an integral of floating argument, thus proving implicit conversion of integral number to BigIntegers and floating numbers to BigDecimals.
   • Implicit casts for BigInteger
     • from BigInteger to floating point types
     • from integral types to BigInteger
   • Explicit casts for BigInteger
     • from BigInteger to integral types
3. I added some tests for the aforementioned casts, but more are needed
4. I noted that, for instance, BigDecimal.Parse("-16.00").Compare((BigDecimal)BigInteger.Create(-16)) was != 0. The same happened for other values from time to time. I never really undestood why this happened by I unsterstood it was related the the BigDecimal.AproxPrecision() returning some wrong value withing the CompareTo method. So I replaced BigDecimal.AproxPrecision() by BigDecimal.Precision and now the problem is not occurring anymore.
   • I added some tests (namely, CompareToBigDecimal2, and CompareToBigDecimal3) which should fail in your old implementation and should succed in my proposal.
5. Finally, I introduced the BigDecimal.CreateExact(float|double|decimal) static methods enabling the creation of exact BigDecimals starting from float/double/decimal literals, so for instance, while new BigDecimal(1.9) actually creates BigDecimal("1.899999999999999911182158029987476766109466552734375"), BigDecimal.CreateExact(1.9) creates BigDecimal("1.9")

[NiccoMlt]

Hi, sorry to dig up this old PR, is there any intention of the mantainer to merge this improvements and release a new version with them?

[tsutomi]

Hello guys. This library was left unmaintained for a long time, and I have just resumed its maintenance. It's utterly late and I apologize for such a disgraceful job of maintenance: I had in fact to mark it as obsolete. In another branch, I did several updates to port it to .NET 6-8, but before merging to master I will review the changes that you have done back then (7 years ago now!! Sorry!!).