Dear Paul,

  thanks for your report ! My current analysis is "not a bug => won't fix".
See below.

* Paul Voutier [2016-08-27 13:18]:
> Increasing precision for bnfinit() calculation results in an error when
> retrieving fundamental units that does not occur for default precision.
> Increasing the precision further, the error goes away and shows that the
> default precision calculation was correct.
>
> This only happens on 32 bit version (only tested on Windows 10).
> On 64 bit version (tested with 2.8.0 (development 19357-d770f77)), all the
> precisions tested work consistently without errors.
>
> Below is the output from the 32 bit version.
>
> ? f=x^4-213115048384*x^2+11354436394676863413121
> %1 = x^4 - 213115048384*x^2 + 11354436394676863413121
> ? allocatemem
>   ***   Warning: new stack size = 8000000 (7.629 Mbytes).
> ? allocatemem
>   ***   Warning: new stack size = 16000000 (15.259 Mbytes).
> ? nf1=bnfinit(f);
> ? nf1.fu
[...]

Note that this first bnfinit computation is actually (relatively) lengthy:

(18:17) gp > bnfinit(f);
time = 760 ms.

At a *higher* precision, the computation is faster:

(18:17) gp > \p50
   realprecision = 57 significant digits (50 digits displayed)
(18:17) gp > bnfinit(f);
time = 533 ms.

(18:17) gp > \p100
   realprecision = 105 significant digits (100 digits displayed)
(18:18) gp > bnfinit(f);
time = 612 ms.

What happens internally at very low precision is that the computation fails
miserably (nothing can be computed, not even the regulator), and everything
restarts at a higher accuracy, which happens to be sufficient to compute
fundamental units as well. Note that, with default flags, bnfinit does *not*
guarantee that fundamental units will be computed: only class group, regulator,
and solution to discrete log problems in both the class group and unit group;
anything else is a bonus.

> ? \p 50
>    realprecision = 57 significant digits (50 digits displayed)
> ? nf2=bnfinit(f);
> ? nf2.fu
>   ***   at top-level: nf2.fu
>   ***                     ^--
>   *** _.fu: missing units in bnf.

This is not a bug: the fundamental units have indeed not been computed
this time and so are not part of the nf2 structure (since at that
particular accuracy *most* of the computation succeeds, only the
fundamental units couldn't be computed in algebraic form).

The fact the fundamental units are missing is itself not a bug: we have
a flag specifically to force their computation (with a big fat warning
that this can tremendously increase running times; which can no longer
expected to be subexponential, even under the GRH).

18:22) gp > \p50
   realprecision = 57 significant digits (50 digits displayed)
(18:22) gp > nf2 = bnfinit(f, 1 /* insist on finding units */);
time = 857 ms. \\ slower than before, but in that case not that slower !
(18:22) gp > nf2.fu
%6 = [Mod(1/326431*x^2 - 327240, x^4 - 213115048384*x^2 + 11354436394676863413121), Mod(1/106557197761*x^3 + 1/326431*x^2 - 326433/326431*x - 326432, x^4 - 213115048384*x^2 + 11354436394676863413121), Mod(808/106557197761*x^3 - 263757864/326431*x + 652863, x^4 - 213115048384*x^2 + 11354436394676863413121)]

The fact that the computation proceeds differently on 32 bit and 64 bit
builds is to be expected as well. The "problematic" (but not faulty)
computation on 32 bit occurs at an accuracy which is not achievable in
the 64 bit build...

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite de Bordeaux         Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
`