On Wed, Feb 5, 2014 at 5:54 AM, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> wrote:

On Tue, Jan 28, 2014 at 01:47:20PM -0500, Igor Schein wrote:
> Package: pari
> Version: 2.6.2 (development 16105-120d04c)
>
> The following command never finishes:
>
> nfsubfields(x^32-152*x^30+9592*x^28-329344*x^26+6791636*x^24-87823728*x^22+723817584*x^20-3802250784*x^18+12604302140*x^16-26054878368*x^14+33346127520*x^12-26066364480*x^10+12062323568*x^8-3111766784*x^6+403544704*x^4-21688960*x^2+364816);

Hello Igor,
As far as I see, the command will finish eventually.
However it will be very slow, because we are unlucky: the d-1 test is failing for
all tests, and nfsubfields does not have a fast fallback code like nfgaloisconj
does.

Cheers,
Bill.

Thanks. Can nfsubfields() be improved in cases like this? If not, is there an efficient alternative? I am interested specifically in degree-16 subfield(s). Of course I could use polcompositum/galoisinit (reliable but far from efficient) or polred (fast but is not guaranteed to return all subfields). Anyway, I would be able to implement either fallback mechanism (even the inefficient one), but I need a way to determine upfront whether it's going to be a hard case or not. I ran nfsubfields) on thousands of degree-32, and found just 2 tough cases (otherwise it's close to instantaneous), but since I run it in a long loop, even a single exception is enough to hang the loop until manual intervention - not the desired behavior.

It'd be nice to have a mechanism (similar to ulimit in bash) to impose runtime limit on individual function calls - it would also be an adequate solution for me. I've had this on my mind for at least 15 years, but I don't recall if I ever brought it up.

Igor