arb/todo.txt
2013-03-26 11:41:12 +01:00

77 lines
2.9 KiB
Text

* Make sure that excessive shifts in add/sub are detected
with exact precision. Write tests for correctness of overlaps/contains
in huge-exponent cases.
* Work out semantics for comparisons/overlap/containment checks
when NaNs are involved, and write test code.
* Fix missing/wrong error bounds currently used in the code (see TODO/XXX).
* Add missing polynomial functionality (conversions, arithmetic, etc.)
* More transcendental functions.
* Add adjustment code for balls (when the mantissa is much more precise than
the error bound, it can be truncated). Also, try to work out more consistent
semantics for ball arithmetic (with regard to extra working precision, etc.)
* Do a low-level rewrite of the fmpr type.
The mantissa should probably be changed to an unsigned, top-aligned fraction
(i.e. the exponent will point to the top rather than the bottom, and
the top bit of the ).
This requires a separate sign field, increasing the struct size from
2 to 3 words, but ought to lead to simpler code and slightly less overhead.
The unsigned fraction can be stored directly in a ulong when it has
most 64 bits. A zero top bit can be used to tag the field as a pointer.
The pointer could either be to an mpz struct or directly to a limb array
where the first two limbs encode the allocation and used size.
There should probably be a recycling mechanism as for fmpz.
Required work:
memory allocation code
conversions to/from various integer types
rounding/normalization
addition
subtraction
comparison
multiplication
fix any code accessing the exponent and mantissa directly as integers
Lower priority:
low-level division, square root (these are not as critical for
performance -- it is ok to do them by converting to integers and back)
direct low-level code for addmul, mul_ui etc
* Native string conversion code instead of relying on mpfr (so we can have
big exponents, etc.).
* Add functions for sloppy arithmetic (non-exact rounding). This could be
used to speed up some ball operations with inexact output, where we don't
need the best possible result, just a correct error bound.
* Write functions that ignore the possibility that exponents might be
large, and use where appropriate (e.g. polynomial and matrix multiplication
where one bounds magnitudes in an initial pass).
* Write a faster logarithmic rising factorial (with correct branch
cuts) for reducing the complex log gamma function. Also implement
the logarithmic reflection formula.
* Rewrite fmprb_div (similar to fmprb_mul)
* Faster elementary functions at low precision (especially log/arctan).
* Document fmpz_extras
* Move zeta functions to own module and cleanup.
* Use the complex Newton iteration for cos(pi p/q) when appropriate.
Double check the proof of correctness of the complex Newton iteration
and make it work when the polynomial is not exact.
* Write a cleanup function that frees all cached data.