Basic Arithmetic

Other SAGE Days 4 Project

Curent Rules cur_coerce.png cur_coerce_diagram.sage

Test cases Read these as "an element of S and an element of R"

  1. \mathbf{Z}[x]/\mathbf{Z} \in \mathbf{Q}[x] (not Frac(\mathbf{Z}[x]))

  2. \mathbf{Q} + \mathbf{Z}[x] \in \mathbf{Q}[x] and \mathbf{Z}/5\mathbf{Z} + \mathbf{Z}[x] \in \mathbf{Z}/5\mathbf{Z}[x]

  3. \mathbf{Q} * \mathbf{Z}[x] \in \mathbf{Q}[x]

  4. \mathbf{Q} * \mathbf{Z}/5\mathbf{Z} error due to no morphism from all of \mathbf{Q} into \mathbf{Z}/5\mathbf{Z}.

  5. \mathbf{Z}[x] + \mathbf{Z}[y] error due to unknown relation between x and y and ambiguous order

  6. \mathbf{Q}[\zeta_m] + \mathbf{Q}[\zeta_n] \in \mathbf{Q}[\zeta_{lcm(m,n)}] as cyclotomic fields are created with an embedding into \bar{\mathbf{Q}}

  7. \mathbf{F}_{p^n} + \mathbf{F}_{p^m} works using Conway polynomials

  8. \mathbf{Z}[x] + \mathbf{Q}[y] error, same as 5 (minus the symmetry concerns) It is unclear how to rule this out of generic base-extension code.

  9. \mathbf{Z}/16\mathbf{Z} + \mathbf{Z}/12\mathbf{Z} \in \mathbf{Z}/4\mathbf{Z}

  10. \mathbf{Q} + \mathrm{Matrix}_{n,m}(\mathbf{Z}). This is same as polynomials.

  11. \mathbf{Q} + \mathrm{Matrix}_{n,m}(\mathbf{Z}[x]). Similar, but need to recurse the change base ring stuff.

  12. \mathbf{Q}[x] + \mathrm{Matrix}_{n,m}(\mathbf{Z}[x]). Here you change base ring of the matrix space from \mathbf{Z}[x] to \mathbf{Q}[x].

  13. \mathbf{Q} + \mathcal{O}, where \mathcal{O} is an order in a number field. This also works by change base ring of \mathcal{O} from \mathbf{Z} to \mathbf{Q} (i.e. going to the number field itself).

  14. K + \mathcal{O}, where L/K is a field extension, and \mathcal{O} is an order in L. This is similar to the previous one, \mathcal{O} can be extended to \mathcal{L}.

This should be ring centric, i.e. the answer is dependant on a pair of rings (and should be computed without having to create pairs of elements)

Finding known morphisms

Every parent will hava a "incoming list" of other objects that it knows how to coerce from (as in the current coerce_try) and known embeddings (which it may append to the lists of existing rings), both created at ring creation time. When trying to find a map from (distinct) R to S we recursively try and find maps from R into the incoming list of S and vica-versa. This is implicitly the "comutative" part of the diagram, and the result may be the composition of several morphisms (represented as Homomorphism objects).

Given a set of objects, one wants to be able to extract, view, query, and even run consistancy checks on this data as a (commutative diagram) graph of known morphisms between them.

This is an atomic step in the procedure below.

Creating new morphisms

One can view most desired natural coersions as functorial operations from some simpler base object. E.g.

Given two objects S and R, first see if there is a natural morphism S \rightarrow R or R \rightarrow S. If there is one, use it. If there are two, by definition they are cannonically isomorphic and so we can use either.

Considering functors above, decompose each object R as a tower of simpler rings R^0 \rightarrow \cdots \rightarrow R'' \rightarrow R' \rightarrow R. Now try to complete the pushout diagram R \leftarrow Y \rightarrow S for maximal Y (as low as possible in the tower of R or S). If a unique such pushout exists, do arithmatic in this ring.

Some of these pushouts (e.g. coefficent rings) could be handled by generic code (e.g. base_extend). Others might be very special to the specific rings (e.g. compositum of number fields (perhaps with specified embeddings into an algebric closure).

Actions

There would be a parallel framework for actions, where the parents would not necessarily be identical. Pow would be worked into the coercion model, as an action of the integers (at least) on ring elements.

Efficiency concerns

The above procedures could be moderately expensive in some cases, and much more expensive than we want for basic arithmetic. The actual model would cache all operations. Specifically, one would have a hashtable

(R, S, op) -> (Hom(R,X), Hom(S, X), method_flag)

where X may be one of R or S, and one of the Hom's may be None (signifying the identity, i.e. due nothing)

method could be one of +, -, *, /, pow, rmul, lmul, r_act, l_act, ?

The reason to specify the op is so that actions can be detected and handled efficently, not so different ring operations would have different coersion routes.

Prototype (showing how to handle actions)

mul(left, right):

cdef canonical_coercion_c(x, y):

cdef inline _mul_c(self, RingElement right):

What about weakrefs?

Other

days4/projects/arith (last edited 2008-11-14 13:42:14 by localhost)