reworked precision to use bit precision everywhere except for output

[JohnCremona]

I tested this with gcc and clang, both with default (NTL multiprecision) and --disable-mpfp.

[JohnCremona]

Although the current tests pass it would be helpful if someone who is a travis expert could edit the test config file to make sure that on both osx and linux the tests are run both with and without --disable-mpfp? If you make a pull request into the prec branch I'll accept it and that will trigger the retesting. Thanks.

[JohnCremona]

I found a few places where the decimal/bit precision was not yet fixed (including documentation) so another push to the prec branch will be happening soon.

[JohnCremona]

The first failure is very small:

Testing comptest...
12c12
< whose cube is    (2.99999999999999999999,4)
---
> whose cube is    (2.99999999999999999999,3.99999999999999999999)

[JohnCremona]

Now there are 3 places where the Mac version gives slightly different output to the Linux version: comptest, telog and h1curve. Since NTL itself is supposed to be completely platform-independent I am guessing that it is the bigcomplex=CC class where differences are arising. This is defined (in line 188 of interface.h) as complex using the template complex construction. So it seems that the discrepancy is coming from the template complex stuff.

[JohnCremona]

This version very nearly passes with osx on Travis: just 6 lines differ (one in comptest in the complex AGM and 5 in telog). The output is cleaner too (fewer strings of 0s or 9s after the decimal point for numbers which are theoretically integers).

If someone reads this who understands the Travis config file better than I do could advise on how to add a 4th build option to the matrix, specifically the --disable-mpfp verrion on osx also, I would appreciate it.

[JohnCremona]

For the record I am giving details here of the discrepancies in the elliptic logs in telog. The curve is [1, 1, 0, -202, 1025]. For P=(-8,51) the actual elog / expected output value / osx output value are

2.1525156669616024162853317818644956119079357950575151027157635...
2.1525156669616024162853317818644956119079357950597
2.15251566696160241628533178186449561190793579505969

about which I have two observations: we should see 51 decimals output (bit precision is 175 and decimal output precision is int(0.3*175)-1=int(52.5)-1=51. As far as I can see the "expected" output (middle line) only shows 50 decimals. I will check to see what output precision NTL reports. Secondly neither is correct to displayed precision: depending on the number of digits displayed it should end "...575" or "5752".