Re: Speed up RgX_mul, RgX_sqr, RgX_divrem over Z, Fp, FpXQ

[Peter Bruin <P.J.Bruin@math.leidenuniv.nl>]

Hi Bill,

> RgX_mul not calling ZX_mul was more or less a design decision done to
> avoid repeated type checks in low level code.

I can see the reasoning behind that, although the number of type checks
that RgX_mul (and the functions that it calls) needs to do when actually
doing arithmetic with the coefficients of the polynomials is going to be
asymptotically larger anyway.

> Instead, the idea was that highlevel functions like polresultant would
> call low-level functions like FpX_resultant.
>
> However this is not the case for polresultant:
>
> -- polresultant only call ZX_resultant and QX_resultant, but not the
> other resultant functions:
> Flx_resultant, FpX_resultant, Flx_FlxY_resultant, FlxX_resultant,
> FpX_FpXY_resultant, ZX_ZXY_resultant
>
> -- there is no FpXY_resultant, so this would not help you anyway.
>
> If we are going to keep this design decision, we should change
> resultant_all to call gmul instead of RgX_mul, etc.
>
> Maybe it would be better to have functions RgX_mul_i etc. that does
> what RgX_mul is doing now, and change RgX_mul to do what you suggest.

That last alternative certainly sounds like the better one to me.  I
guess that we would then call RgX_mul_i et al. only in cases where we
know (thanks to earlier checks) that the polynomials do _not_ have a
common "special" base ring, is that what you mean?

Peter