LongCalc 0.4.9

There is a newer version of this package available.
See the version list below for details.
dotnet add package LongCalc --version 0.4.9
NuGet\Install-Package LongCalc -Version 0.4.9
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="LongCalc" Version="0.4.9" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add LongCalc --version 0.4.9
#r "nuget: LongCalc, 0.4.9"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install LongCalc as a Cake Addin
#addin nuget:?package=LongCalc&version=0.4.9

// Install LongCalc as a Cake Tool
#tool nuget:?package=LongCalc&version=0.4.9

LongCalc Arbitrary Precision Float and Complex Number Library

Product Compatible and additional computed target framework versions.
.NET Framework net45 is compatible.  net451 was computed.  net452 was computed.  net46 was computed.  net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
0.5.34 1,018 2/10/2023
0.5.33 1,073 12/28/2021
0.5.32 1,160 10/2/2021
0.5.31 1,009 8/1/2021
0.5.30 1,029 3/25/2021
0.5.29 1,207 10/15/2020
0.5.28 1,134 9/24/2020
0.5.27 1,170 9/18/2020
0.5.26 1,282 9/17/2020
0.5.25 1,186 9/6/2020
0.5.24 1,119 8/25/2020
0.5.23 1,180 8/5/2020
0.5.22 1,557 7/31/2020
0.5.21 1,560 7/30/2020
0.5.20 1,180 7/29/2020
0.5.19 1,184 7/28/2020
0.5.18 1,212 5/22/2020
0.5.17 1,177 5/19/2020
0.5.16 1,224 5/17/2020
0.5.15 1,212 5/17/2020
0.5.14 1,218 5/11/2020
0.5.13 1,299 5/3/2020
0.5.12 1,301 4/4/2020
0.5.11 1,183 3/31/2020
0.5.10 1,224 2/13/2020
0.5.9 1,269 2/8/2020
0.5.8 1,238 2/5/2020
0.5.7 1,354 1/21/2020
0.5.6 1,234 11/27/2019
0.5.5 1,216 11/16/2019
0.5.4 1,206 11/7/2019
0.5.3 1,219 11/2/2019
0.5.2 1,238 10/21/2019
0.5.1 1,460 7/29/2019
0.4.12 1,453 6/15/2019
0.4.11 1,441 6/10/2019
0.4.10 1,468 5/13/2019
0.4.9 1,540 4/15/2019
0.4.8 1,435 4/7/2019
0.4.7 1,446 3/23/2019
0.4.6 1,425 3/4/2019
0.4.5 1,470 3/4/2019
0.4.4 1,548 2/10/2019
0.4.3 1,750 1/30/2019
0.4.2 1,697 1/29/2019
0.4.1 1,728 1/29/2019
0.3.25 1,455 3/25/2019
0.3.24 1,456 3/4/2019
0.3.23 1,712 1/25/2019
0.3.22 1,763 1/23/2019
0.3.21 1,775 1/12/2019
0.3.20 1,751 1/4/2019
0.3.19 1,740 1/3/2019
0.3.18 1,743 12/30/2018
0.1.25 1,470 3/25/2019
0.1.24 1,477 3/4/2019
0.1.23 1,805 1/12/2019
0.1.22 1,720 12/24/2018
0.1.21 2,028 4/20/2018
0.1.16 1,874 9/2/2017
0.1.15 1,852 8/23/2017
0.1.11 1,758 8/4/2017
0.1.10 1,875 8/1/2017
0.1.8 1,746 7/27/2017
0.1.7 1,805 6/14/2017
0.1.6 1,852 6/14/2017
0.1.5 1,871 6/10/2017
0.1.2 2,136 11/22/2016
0.1.1 1,839 11/12/2016

Unsigned Assembly

Investigated crashes of the software. Found that bf object initializations work fine when x.mant and x.twoexp components (of type mpz_t) have bitlength less or equal 17179869120. Found that crashes consistently occur when bitlength of either is greater than 17179869120 (when testing on three machines, with memory 7.45GB, 6GB, 16GB. one machine early Intel i5, one machine a more recent AMD processor, one machine a more recent Intel i7. Although bf intitialization worked fine at or below the indicated threshold on all three, one machine experienced crashes of the debugger near the threshold when running in debug mode.) bcr and bcp object creations would work fine if the underlying bf objects were at or below threshold. This was independent of whether the twoexp component was of type mpz_t, long, or int, and whether or not the bf objects also contained an internal BL bitlength component of type long (which was not present in earlier versions of this software).

With this version, bf object initialization will throw an exception with message "Request exceeds capability of this software." if mant or twoexp components exceed the bitlength threshold. Also, a limitation of Precision values to 5171655000 or less is imposed (this value is the base 10 equivalent just under a few hundred bits of the threshold). Precision values exceeding this limit in public functions will result in an exception thrown, with message "Precision can be no larger than 5171655000.". In situations where internal processing might require that Precision values be increased by a substantial amount, the limit is checked and an exception is thrown, typically wth the same message, if the revised Precision exceeds that limit.  

Created and implemented the precise x.Multiply(y) functions for x of type bf, bcr, and bcp and y of various integer types. Updated the multiplication operators (x * y) to use this function if x or y is of an integer type (and unsigned, if x or y is of type bcp).

Updated the other x.Multiply and the x.Square functions to truncate results within these functions before creating output, rather than creating output and then calling x.Truncate. This avoids needlessly creating a temporary bf object which could easily exceed the bitlength limitation discussed above.

Revisited x.Euler and x.Bernoulli and reversed some rather recent changes which resulted in outputs with precision below that which was requested.

Revisited x.BesselJ and found that results can have less than requested Precision if inputs are computed with insufficient precision.

Made public the bcr function RadiusSquared and the static bf functions DegreesToRadians, GradiansToRadians, RadiansToDegrees, and RadiansToGradians.

Removed the restriction on bf function x.Exp where x needed to be less than about 1.E+1035. It turns out, after the x.Multiply and x.Square changes discussed, that x can be much larger and x.Exp still works.

Removed the code which threw out-of-memory exceptions. The restriction on bitlengths discussed above handles crash problems much better, and the underlying software usually handles memory requirements quite well enough.

Corrected an error in x.toString and x.Round in which results equal one were returned if x near one but farther away as required by rounding to Precision.

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