forked from hvds/divrep
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathTODO-coul
More file actions
31 lines (29 loc) · 1.41 KB
/
TODO-coul
File metadata and controls
31 lines (29 loc) · 1.41 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
TODO (high priority):
- calculate even more accurate mintau()
- and beyond oul for suppressed factors
- fix linear search in pell.c:contfrac()
- 'coul -p20 -x1e80 66 5' spends all its time finding allrootmod()
results, almost all of which are immediately greater than endr
- when n=36 and we allocate p^5, the remainder cannot allocate p^2 so
we can require a 5th power. But our "have_square" support is predicated
on the assumption of a square: how readily can we extend it to cater
for this case? This case kicks in when (x > t/2 && x.high == t.high),
and will be useful for n in { 36, 54, 72, 100 }. n=18 is a more extreme
case.
CHECKME:
- inject failures can clash with walk_1() successes
- can best_v do better by picking the most constrained?
TODO (lower priority):
- add parallelization support to walk_1
- maintain a dummy alloc[0] on values[], to save lots of special handling
- this may remove the need for m[] and t[] in walk_v()
- short-circuit "used" check with cur->maxp
- on recover, parse 001 line to check consistency of critical options
- reimplement small_divmod()
- reimplement next_prime()
- cater for end value > 2^64 in walk_v, if needed
- add support for -o
- build it over parallel is_tau() checks, so it can be configurable
- prep the simple_valuation() checks for apply_batch()
- for unforced primes, do constant apply_alloc() work in advance
- avoid recursing when best_v() will find nothing