Mathemagix

[Joris van der Hoeven <address@concealed>]

On Tue, Dec 11, 2007 at 01:39:35PM +0100, Bernard Mourrain wrote:
> What about generic functions which applies for 
> dense_univariate_polynomial or bezier_univariate_polynomial
> but not sparse_multivariate_polynomial ?

Same thing: template over the class ***_polynomial.
C++ templates don't take into account any information on
the structure of their parameters anyway (contrary to what we plan
for Mathemagix). In other words, you are just are not supposed to
instantiate with sparse_multivariate_polynomial, just as you don't
instantiate a function like gcd on a domain where gcd's don't exist.

> I suggest to put them in namespaces (see VECTDSE, MATRDSE, MPOLDSE, ... 
> in algebrix).

I don't see any advantage of doing so:
I precisely try to *remove* unnecessary hierarchies.

> OK, so for polynomials  should we use:
> 
> dense_univariate_polynomial
> bezier_univariate_polynomial
> ...
> sparse_multivariate_polynomial
> ...
> 
> Any convention to adopt, in order to prepare the transition?

Yes. In fact, I assume by default univariate polynomials and
by default, the dense representation, so

        polynomial (=> univariate, dense)
        bezier_polynomial (=> univariate)
        sparse_polynomial (=> univariate)
        multivariate_polynomial (=> dense block representation?)
        lex_multivariate_polynomial (recursive dense representaton)
        sparse_multivariate_polynomial
        dag_multivariate_polynomial (straight line polynomial program)
        etc.

Also, the variant can select further algorithmic details, i.e.

        matrix_naive
        matrix_simd
        matrix_threads
        matrix_strassen
        polynomial_naive
        polynomial_karatsuba
        polynomial_kronecker
        polynomial_fft
        multivariate_polynomial_naive
        multivariate_polynomial_kronecker
        etc.

So I suggest to use prefixes for different representations
and postfixes for various implementation details. Notice that
variants can typically be constructed one on top of the other:
polynomial_fft<100,polynomial_karatsuba<8,polynomial_naive> > >.
An example of a concrete type is

        polynomial<rational,polynomial_kronecker>

Each coefficient ring also comes with a default variant.

Best wishes, Joris