flintlib / flint

FLINT (Fast Library for Number Theory)
http://www.flintlib.org
GNU Lesser General Public License v3.0
425 stars 241 forks source link

Allocation behavior of nf_elem #1599

Open fredrik-johansson opened 3 years ago

fredrik-johansson commented 3 years ago

Is it really reasonable that nf_elem always initializes its polynomial (in degree >= 3) to hold a full unreduced product? In many circumstances, this will cause needless overallocation.

Worse, the current code is potentially dangerously broken. Some functions (like nf_elem_mul) assume that there is enough space to write an unreduced product without checking this. This is fine if the polynomial has been initialized with the current nf_elem_init. However, there are many functions in the nf_elem module that call non-underscore fmpq_poly methods. Such methods could potentially reallocate the output to a too short length (for instance when swapping the output to handle aliasing). I would feel more comfortable if nf_elems just used the normal dynamic fit_length approach.

wbhart commented 3 years ago

Functions in the general case should not assume there is enough space allocated. This is indeed a bug.

If we do check everywhere then I guess there is no need to initialise it to the unreduced length. It can be a performance hit because the length will first be initialised to one thing and then in linear algebra or polynomial arithmetic where the unreduced length is used extensively, essentially every single element will then be reallocated, which costs a lot of time.

Of course I still want the degree < 3 cases to allocate the extra space.