# Just.PreciseMath

Extended-precision floating-point arithmetic for .NET using double-double
representations: a high/low pair of `double` values. The goal is to retain more
precision than a single `double` while using a fixed-size representation,
rather than arbitrary-precision arithmetic.

> **Work in progress.** The public API is incomplete and may change. Numerical
> contracts are covered by regression tests, not an exhaustive accuracy
> certification. The library is not ready for production use.

## DoubleDouble core

`DoubleDouble` stores a normalized high/low pair. Use `new DoubleDouble(value)`
for a single `double`, or `DoubleDouble.FromComponents(high, low)` for arbitrary
components. The factory normalizes finite sums and canonicalizes NaN/infinity
with a positive-zero low component. The two-component constructor is internal
and performs no normalization or validation; it is reserved for trusted,
already-normalized results. The constants `PI`, `E`, and `LN2` include binary64
residuals checked against independently computed high-precision values.

- Arithmetic: unary `+`/`-`, binary `+`, `-`, `*`, `/`, and both operand orders with
  a `double`. Addition retains residuals under cancellation; multiplication uses
  fused multiply-add; division uses residual corrections. Mixed `double` operators
  use specialized scalar paths rather than promoting the scalar to `DoubleDouble`.
  Their finite fast paths normalize once with a final sum transform; scalar
  division uses one compensated quotient correction within the error contract below.
- Exponent boundaries: bounded `BigInteger` calculations avoid intermediate
  overflow and underflow on the exceptional finite path. Ordinary arithmetic uses
  floating-point transforms without allocations. The stored value remains two
  doubles; this is not an arbitrary-precision API.
- Comparisons use both components. `Equals` treats NaNs as equal and signed zeros
  as equal for collections. `CompareTo` orders NaN before other values. Numerical
  equality and relational operators treat NaN as unordered, like `double`.
- Signed zero is preserved by single-value construction and unary negation.
  `FromComponents` with a zero low input preserves the high zero's
  sign. Exact cancellation of nonzero values yields positive zero. Arithmetic
  special values follow binary64 rules.

Arithmetic is approximate double-double arithmetic, **not a promise of correctly
rounded 106-bit results**. The deterministic rational-oracle tests check a
conservative error bound of `2^-100` relative plus one minimum binary64 subnormal,
with exact component checks for selected representable cases. Near underflow,
extended precision necessarily decreases; overflow produces infinity. Performance
of the allocating exponent-boundary path is not covered by the basic benchmarks.

## Conversions and formatting

- Explicit conversions support `double`, `float`, `int`, `long`, and `decimal`
  in both directions. Integer inputs are exact. Decimal inputs use their exact
  coefficient and scale to compute the high component and its residual.
- Integer casts truncate the complete expansion toward zero and throw
  `OverflowException` for nonfinite or out-of-range results. `IConvertible`
  integer conversions instead round to nearest, ties to even, with range checks.
- Binary32 output rounds the complete expansion directly, including low-component
  decisions at midpoints. Decimal output rounds to the greatest fitting scale up
  to 28; nonfinite values and magnitudes above `decimal.MaxValue` throw.
- `IConvertible` reports `TypeCode.Object`, supports conversion to itself, and
  treats only numerical zero as false. Char, DateTime, and enum conversions are
  unsupported and throw `InvalidCastException`.
- `ToString` formats the exact component sum, supports culture-sensitive
  `G`/`g`, `E`/`e`, and `F`/`f`, and rounds ties to even. Precision is bounded to
  0–999; other standard and custom formats throw `FormatException`. Default
  `G32` is **not** shortest-round-trip formatting. NaN, infinities, and signed
  zero are supported without converting through decimal.
- `TryFormat(Span<char>, ...)` implements `ISpanFormattable` with the same formats.
  It currently allocates via `ToString`; insufficient space returns `false`, writes
  zero characters, and leaves the destination unchanged.

`DoubleDouble` implements `ISignedNumber<DoubleDouble>`, including the inherited
`INumberBase` contracts: binary radix, classification, absolute value, magnitude
selection, increment/decrement, and generic numeric conversions. Integer/parity
tests and magnitude comparisons retain both components. Magnitude ties prefer
positive values for maximum and negative values for minimum, including signed zero;
the `Number` variants prefer a number over NaN.

`CreateChecked`, `CreateSaturating`, and `CreateTruncating` support built-in numeric
types and `BigInteger`. Floating overflow produces signed infinity in all modes.
Finite integer output truncates the exact sum, then throws on overflow, clamps,
or retains the low destination-width bits, respectively. Decimal nonchecked output
clamps out-of-range values and maps NaN to zero. These policies are distinct from
the existing casts and `IConvertible` conversions above.

Conversions, parsing, and formatting use allocating `BigInteger` intermediates
where needed to preserve precision; no additional dependency is required.

## Parsing

`Parse` and `TryParse` accept strings and `ReadOnlySpan<char>` and implement
`IParsable<DoubleDouble>` / `ISpanParsable<DoubleDouble>`. This initial parser
preserves high/low precision rather than parsing through `double` or `decimal`.
It converts an exact decimal coefficient/exponent into rounded high and residual
components, then normalizes the pair. It does not promise universally correctly
rounded 106-bit results or a general `ToString` round trip.

```csharp
using System.Globalization;
using Just.PreciseMath;

DoubleDouble value = DoubleDouble.Parse("9007199254740993", CultureInfo.InvariantCulture);
// value.High == 9007199254740992.0; value.Low == 1.0

bool success = DoubleDouble.TryParse("1.25e-2".AsSpan(), CultureInfo.InvariantCulture,
    out DoubleDouble parsed);
```

- Provider-only finite grammar: optional sign, ASCII decimal digits with an optional decimal
  separator, and optional `e`/`E` exponent with sign and digits. At least one
  mantissa digit is required; `.5` and `1.` are accepted with invariant culture.
  Surrounding whitespace is allowed; internal whitespace is not.
- Signs and the decimal separator come from the supplied culture; a null or
  omitted provider uses the current culture. Culture-specific NaN and infinity
  symbols are recognized case-insensitively. The additional alias `inf` accepts an
  optional culture-specific sign (`inf`, `+inf`, `-inf` with invariant culture).
  Exact custom special symbols take precedence over the alias. Special values accept
  surrounding whitespace and signs even with `NumberStyles.None`; ordinary finite
  numbers still obey the supplied style flags. Signed zero is preserved.
- Provider-only overloads reject grouping, currency, and parentheses. Explicit
  `NumberStyles` overloads support decimal flags through `NumberStyles.Any`, including
  grouping, currency, parentheses, and trailing signs; group sizes are not validated.
  Hexadecimal, binary, and undefined style flags throw `ArgumentException`, including
  in `TryParse`. Hexadecimal notation and programming-language digit separators
  remain unsupported.
- Input is limited to **2048 characters**, including surrounding whitespace.
  Huge exponents are bounded before constructing powers of ten. Well-formed
  overflow succeeds with signed infinity; underflow rounds to a subnormal or
  signed zero. A second rounding just below the overflow midpoint stays finite.
- `Parse` throws `ArgumentNullException` for a null string and `FormatException`
  for invalid, unsupported, or oversized input. `TryParse` returns `false` and
  positive `Zero` for those inputs.

## Deferred scope

The planned `PreciseMath` static class and its `Abs`, `Sqrt`, `Pow`, `Exp`, and
`Log` functions are not implemented. Generic-math interfaces beyond `ISignedNumber`,
additional text formats/general round-trip formatting, and broader performance
benchmarks remain deferred.
Replacing allocating arithmetic boundary fallbacks is also deferred; the current
`BigInteger` paths remain in place. That optimization does not require removing
`BigInteger` from conversions, parsing, formatting, or independent test oracles.

## Build and test

Requires the .NET 10 SDK in the `10.0.1xx` feature band, as selected by `global.json`.
Run from the repository root:

```sh
dotnet restore Just.PreciseMath.slnx --locked-mode
dotnet build Just.PreciseMath.slnx -c Release --no-restore
dotnet test --solution Just.PreciseMath.slnx -c Release --no-build --minimum-expected-tests 1
dotnet format Just.PreciseMath.slnx --verify-no-changes --no-restore
```

Test results and coverage reports are available in the `test-results` artifact
on CI workflow runs.

## Benchmarks

The BenchmarkDotNet suite compares same-type `+`, `-`, `*`, and `/` operations for
`DoubleDouble`, `decimal`, and `double`: 12 methods with two input cases each.
Each operation/input group uses `double` as its baseline and reports allocations.
Operands are stored in fields and results are returned to the harness; conversions
and construction happen in setup, outside the timed methods.

The left inputs are `1.25` (binary-exact) and `1.1` (a nonzero low component in
`DoubleDouble`); the right input is `0.75`. Decimal and double-double inputs originate
from the same decimal values, while `double` rounds to binary64. These types have
different precision and range contracts: this is a cost comparison, not an accuracy
test. Exceptional values, exponent-boundary fallbacks, mixed-type operators,
conversions, parsing, and formatting are not benchmarked yet.

After the Release build above, run from the repository root:

```sh
# Discover benchmark methods without running them.
dotnet run --project 2-benchmarks/Just.PreciseMath.Benchmarks -c Release --no-build -- --list flat

# Quick execution check (also run in CI); not useful for timing comparisons.
dotnet run --project 2-benchmarks/Just.PreciseMath.Benchmarks -c Release --no-build -- --job Dry --filter '*'

# Full measurement run; optionally select an operation with --anyCategories Addition.
dotnet run --project 2-benchmarks/Just.PreciseMath.Benchmarks -c Release --no-build -- --filter '*'
```

Reports are written under the ignored `BenchmarkDotNet.Artifacts/` directory.
Empty selections and failed benchmark runs return a nonzero exit code. CI only
checks execution, with no performance gate. Use full runs on an idle, controlled
machine for comparisons; a scalar `double` operation may approach harness overhead,
so inspect BenchmarkDotNet warnings before interpreting ratios. Do not compare
coverage-instrumented runs or treat Dry-job timings as performance measurements.

## Project structure

- `0-source/Just.PreciseMath/`: library implementation.
- `1-tests/Just.PreciseMath.Tests/`: unit tests.
- `2-benchmarks/Just.PreciseMath.Benchmarks/`: arithmetic benchmarks against `decimal` and `double`.

## Contributing

Follow `.editorconfig` and include regression tests with numerical changes.
Explain the algorithm's assumptions, the source of reference values, and any
error tolerances. Include updated `packages.lock.json` files with dependency changes.

## License

Licensed under the [MIT License](LICENSE).