arb/todo.txt
2012-09-06 15:50:57 +02:00

78 lines
2.5 KiB
Text

Urgent
------
* More test code. In particular, ball arithmetic needs test code that
tries to trigger corner cases. Aliasing tests are also missing.
* Documentation.
* Make sure that excessive shifts in add/sub are detected
with exact precision.
* Fix code duplication, add functions to encapsulate fiddly bits of code, etc.
* Fix missing/wrong error bounds currently used in the code (see TODO/XXX).
* Add missing polynomial functionality (conversions, arithmetic, etc.)
Important
---------
* Transcendental functions.
* Matrices.
* 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 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.).
Distant future
--------------
* 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).
* Add generic code for hypergeometric series (etc.) and if possible, use
for elementary functions.