Crates.io | acid2 |
lib.rs | acid2 |
version | 0.2.1 |
source | src |
created_at | 2022-11-10 01:34:22.536065 |
updated_at | 2022-12-10 03:55:56.353226 |
description | 2-adic double-precision floating-point implementation |
homepage | https://github.com/suremarc/acid2 |
repository | https://github.com/suremarc/acid2 |
max_upload_size | |
id | 709125 |
size | 54,300 |
2-adic floating-point implementation, for maximum hardware affinity and performance.
This project is in its very early stages. No guarantees can be made about its correctness until the testing infrastructure is more robust.
The goal of this project is to implement 2-adic floating point arithmetic with maximum performance. Currently, the only known use case is for approximating p-adic integrals, where exactness is not a hard requirement.
Explicitly branchless code is preferred where possible, at the expense of some readability. However, since 2-adic addition requires counting trailing zeros, this may not be possible for some architectures. On some x86 platforms, LLVM's cttz
intrinsic is implemented using a bitscan (bsfl
) and a conditional jump.
Having numerous, table-driven unit tests with cases covering over/underflow and inf/NaN would be ideal. Manually constructed, hand-worked test cases are probably still useful, even for something as complex as floating-point arithmetic.
Fuzz-testing might also be useful for detecting broken invariants. Currently, the only invariant is that the significand is odd. This invariant may disappear if we change the internal representation to have an implicit lowest bit of 1.
Python support would make experimentation with this library extremely quick. More investigation is needed as to what would be involved here (read: I have no idea how to do this).
Being able to convert to/from string representations of p-adic numbers would be very helpful in debugging -- not just for the author, but presumably for consumers of this library as well. Currently there is a placeholder implementation of fmt::Debug
that just shows the exponent and significand as a tuple.
This is less of a wishlist item, and more a note that that not much thought has been given to subnormal numbers and how they're handled, as of now.
The additive inverse of any integer in the p-adic numbers is the limit of a convergent sequence of positive integers under the p-adic metric. Hence, there is no need for a sign bit.
As a corollary of the above, since negatives of integers have infinitely many digits, they cannot be represented exactly. Consider the number -1. Its 2-adic representation is the following:
...1111111111.0
Because there are infinitely many digits, the floating-point representation is truncated to 53 bits. A corollary of this is that self-subtraction does not result in zero: given a p-adic floating-point value x
, we have that (x - x).abs() != 0
.