LongCalc Arbitrary Precision Float and Complex Number Library
See the version list below for details.
Install-Package LongCalc -Version 0.4.8
dotnet add package LongCalc --version 0.4.8
<PackageReference Include="LongCalc" Version="0.4.8" />
paket add LongCalc --version 0.4.8
Throw an error on ('type')x for a bf or bcr x, when x is out of range of type 'type'. The user should be aware that no such error is thrown for an integer-type explicit cast ('type')x for an mpz_t x.
The long-to-mpz_t and mpz_t-to-long Mpz_tVal and LongVal conversion functions have been re-done in such a way that parsing of strings for numeric value is avoided.
Correct an inefficiency in x.toString and x.Round for x very large or x near 1 and Precision large.
Added an optional parameter ZeroOrPiMatchPrecision to the trigonometric functions which, if greater than 0, returns (as appropriate) 1, 0, or -1 if the input matches a multiple of Pi/2 to ZeroOrPiMatchPrecision decimal digits.
A likely natural limitation (of which I am not certain) on the underlying Mpir.NET software is that the bitlength of an mpz_t variable cannot be greater than long.MaxValue. Operating under this assumption, the Bitlength, doBitlength, doIndexofOne are made to be of type long. The shiftLeft and shiftRight functions 'shift' parameter is now of type long.
The bf object is modified such that x.mant is now readonly for a bf x, and an internal long parameter 'BL' equal to x.Bitlength is included and tracked. BL is then re-calculated on the conclusion of any bf Add, Subtract, Multiply, or Divide or any 'new bf(...)' (other than 'new bf(x)' for a bf 'x'). This approach turns out to result in increased efficiency since the commonly used functions FloorLog2(x) and Log..(x) (among others) use the bitlength value. Operating under the assumption that an mpz_t Add, Subtract, Multiply or Divide result is (however briefly) fully contained in Process Memory, an estimate of the corresponding bf calculation memory requirements is made. If that estimate indicates the BL limitation would be exceeded, an error is thrown. If the estimate exceeds 3 gigabytes, garbage collection is forced and then memory availability is checked and an error is thrown if available memory is insufficient for the operation. This approach avoids the problem of an impasse which previously occurred in situations such as x.Add(y) when x is very large (or very small) compared to y (for bf 'x' and 'y').
Checks for arithmetic overflow or underflow are again compiler-included in this release.
- Mpir.NET (>= 0.4.0)
This package is not used by any popular GitHub repositories.