LongCalc 0.5.1

• • Mpir.NET (>= 0.4.0)

Unsigned Assembly

This version reverses some foolish changes to the trigonometric functions which first showed up in version 0.4.10. The code used to replace those functions is from version 0.4.7 with some slight modification to accomodate the ZeroOrPiMatchPrecision parameter.

This release provides the capability to replace the following core constants, which would otherwise be calculated as needed, by uploading text files containing the replacement values: PI, Log(2), and Log(10). The function names are: GetPIFromFile, GetLog2FromFile, GetLog10FromFile and require supplying accurate Base, Base10Precision, and FilePath. The queryable booleans PiIsFromFile, Log2IsFromFile, and Log10IsFromFile provide verification as to the source of the current values (whether uploaded or internally calculated).

Another change is to correct inaccurate results in x.Exp(Precision) when x is large compared to Precision and in x.BesselJ(alpha, Precision) when x is large. The change required that, for example, if x is input as "new bf(string x0..., long Precision)" where x0 is written as ".1E+1000" and Precision is 100, x is computed to a precision of at least 1000. For the case of BesselJ, the change made was to compute x to a precision of an extra 1000 digits. It is then up to the user to make sure that the precision required for Exp or BesselJ is maintained at least at this level through whatever intervening functions are applied.

The reason for the use of version number 0.5.x rather than a 0.4.x series number however, is to indicate a change which could create unfavorable results for users seeking to use existing code or writing new code and finding intractable problems. With this version, the objects bf, bcr, and bcp have changed from being C# struct(s) to being C# class(es). As a result, the limitation in prior releases that required bf objects have mpz_t components with bitlength no more than 17179869120, and hence Base10 Precision no more than 5171655000, is gone. The thing to watch for when using the current release is that, although you may have a function 'static bf FunctionName(bf x, bf y)' for example, indicating that x and y are passed by value, you will find that changes to x or y internal to FunctionName may act as if you have really passed x and y by reference. To avoid these problems, it may be advisable to include, for the first code of the function, the line(s) x = new bf(x); y = new bf(y); . Similarly for bcr or bcp objects. This curious behavior has had me guessing for quite awhile in previous attempts to set up bf, bcr, and bcp as classes.

Checks for arithmetic overflow or underflow are again compiler-included in this release.