Mathemagix

[Bernard Mourrain <address@concealed>]

Dear Joris,

Regarding the first point:
> There are a few design issues with the Mathemagix libraries
> which continue to bother me. Maybe discussing them with you,
> would help me to make the appropriate decisions.
>
> First of all, there is the question whether the standard bracket
> notation [1,2,3] should rather be used for lists, arrays or vectors.
>
> Currently, we use the notation for lists. However, this is not very
> nice if we want to use the compact notation [1,2;3,4] for matrices.
> Also, it has turned out that at the typical places where one might
> expect lists to be used (e.g. the Mathemagix compiler), the map
> primitive has proven to be more useful than recursive programming.
> Finally, vectors are better than lists when raw performance is required,
> and also better in the case of parallelism. For these reasons, I am
> currently inclined to use [1,2,3] to denote vectors rather than lists.
>
> Now there is a second subtlety with arrays and vectors. Mathemagix
> currently implements both arrays and vectors. The difference is that
> vectors can be customized using variants and that they support
> a constructor C -> Vector C, which also accounts for some overhead.
> Indeed, using Vector C as a ring requires at least the existence
> of a homomorphism Integer -> Vector C, for which the size of
> the vector is not yet known (the same holds for matrices by the way).
>
> Currently, this is implemented by regarding Vector C as some kind
> of union of C and Vector C, using a special flag "bool scalar_flag"
> which indicates whether the vector is in fact in C or a real vector.
> Of course, this accounts for some overhead for most operations,
> which does not exist for arrays. Do we want to keep separate types
> array and vector, or try to modify vector in such a way that array
> becomes redundant and the overhead disappears. For instance,
> one might decide that a vector of size 1 behaves like a scalar
> when added to a vector of another size and only undertake special
> action if the sizes of operands don't coincide. We might also use
> negative sizes for scalar vectors so as to save some space.

I agree with your point of view to replace list by an
array type, for the syntax [...] in the interpretor.
We should have a structure which allows to store (and to access 
efficiently) a sequence of data (of the same type) as returned by some 
algorithms (example: sequence of roots of a polynomial).
It has not necessarely the properties of vectors (ie with +, -, . 
operators).
Thus we should be able to have both arrays and vectors.
  - arrays provided by basix with the semantic of sequences,
  - vectors provided by algebr*ix with the semantic of elements of a 
vector space. Conversion from arrays to vectors should be available
naturally/automatically if the value type is a ring type.

If we agree on this point, I can do the modification in basix and
propagate it on other packages which are currently using list<generic>
for the output of some functions: subdivix, mps,

Is this OK ?


Bernard

PS: the second point is a little more delicate (next mail).