Martin Rubey wrote:
>
> I think that FriCAS should be able to do the following:
>
> sage: K.<a,b> = QQ.extension([x^2 + 1, x^3 - 2]); K
> Number Field in a with defining polynomial x^2 + 1 over its base field
> sage: L.<c> = K.absolute_field()
> sage: to_L=(L.structure())[1]
> sage: to_L(a)^2
> -1
> sage: to_L(b)^3
> 2
> sage: to_L(a)
> -6/11*c^5 - 9/22*c^4 - 20/11*c^3 - 39/11*c^2 - 39/11*c + 91/22
> sage: to_L(b)
> -6/11*c^5 - 9/22*c^4 - 20/11*c^3 - 39/11*c^2 - 50/11*c + 91/22
>
> If I'm not mistaken, currently it cannot. Sage uses pari to find the
> "absolute_polynomial", i.e., the minimal polynomial in K. Maybe we could make
> SAE take optionally a list of polynomials as second argument, and have several
> generators?
>
1) It is not fully clear what FieldExtension(K, [p1, p2]) should
do. One possibility (assuming p2 is irreducible in extension
corresponding to p1) is to build tower of extensions. Another
possibility (apparently pari/sage is doing this) is to find
primitive element in the tower and ins minimal polynomial over K
and build corresponding simple extension. When working in positive
characteristic primitive elements not always exist, so only
tower is guaranted to work. Otherwise choice is probably
matter of performance: if primitive poly has small coefficients
then using single extension is more efficient. But primitive poly
may have very large coefficients, and due to this tower may
be better.
2) I think we have all tools to do actual computations: we can factorise
in algebraic extensions, so we can verify irreducibility assumptions.
We have functions to compute primitive elements.
3) Currently constructors can not be overloaded, so any extra
argument to SAE would be mandatory. One could try something
like:
SimpleAlgebraicExtension(R:CommutativeRing, _
UP:UnivariatePolynomialCategory R, M: Union(UP, List UP)) == ...
but that would complicate SAE. Also, there are problems with
arbitrary conditionals when choosing representation. So
I think that I would rather try a new domain (say 'AlgebraicTower').
I am not sure how much work such domain would require. Basicaly
we are the edge of what Spad allows -- in principle definition
could be quite simple but if one have to work around limitations
then it could be much more complicated.
4) Another possibilty would be to add type-valued function in the
interpreter. This may be simple (again modulo bugs/limitations).
5) There is a question how domain like AlgebraicTower would interact
with coercion mechanism in the interpreter. If domain is built
as tower of simple domains, then interpreter can synthtize coercion
for the whole tower from coercions of ingredients. Using complex
domains (such that tower structure is hidden) would break this
and require more work (either explicitly giving coercions for
AlgebraicTower or making interpreter smarter). OTOH I am not
sure how good coercion for SAE are now...
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
