improve Normal::normalityTest()

[kroeker@…]

Depending on situation, sometimes 'preimage' computation is fast, and sometimes 'eliminate' is fast. See also ticket www.singular.uni-kl.de:8002/trac/ticket/267

Proposal: (At least in Normal::normalityTest() ) replace the preimage()- call to a concurrent call to preimage() and eliminate() - the faster one wins.

Background: the preimage computation is one of the bottlenecks of 'Normal::normalP()' normalP may be sometimes preferred to normal, since normalP() result usually has less variables.

Example hitting the bottleneck:

 LIB("normal.lib");
 int   q = 17;
 ring  r = q,(y,x),wp(9,8);
 ideal I = y^8-y^2*x^3+2*y*x^6-x^9;
 list norp = normalP(I,"withRing");

^C// ** Interrupt at cmd:`preimage` in line:'      K = preimage(Q,phi,L);    //### Improvement by block ordering?'
abort after this command(a), abort immediately(r), print backtrace(b), continue(c) or quit Singular(q) ?b
-- called from normal.lib::normalityTest --
-- called from normal.lib::normalP --
-- called from normal.lib::normalP --
-- called from STDIN --
// ** Interrupt at cmd:`preimage` in line:'      K = preimage(Q,phi,L);    //### Improvement by block ordering?'

Remark: the example produces warnings in debug mode:

// ***dPolyReportError: wrong order 
 occured at
 occured for poly: y8-x9+...  addr:0x7fb502d29820 size:40 allocated at  ??

// ***dPolyReportError: wrong order 
 occured at
 occured for poly: y8-x9+...  addr:0x7fb502d29820 size:40 allocated at  ??

[hannes]

preimage and eliminate are internally the nearly same: preimage has a little bit more freedom in chosing an elimination ordering, yielding in general to a little faster results. Exceptions may happen, but are very, very rare.