New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should AlgebraicField be a Composite domain? #14442

Open
skirpichev opened this Issue Mar 9, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@skirpichev
Copy link
Contributor

skirpichev commented Mar 9, 2018

This issue triggered by that TODO. There is no a clear notion for "composite domain" (as usually), but it seems to mean "something that has both symbols and domain attributes". Which is valid for current CompositeDomain's and AlgebraicField. In addition, CompositeDomain currently must support order, which might be a bad idea, see this and has slightly different argument convention in the constructor (__init__(self, dom, symbols) vs __init__(self, dom, *ext)).

@jksuom

This comment has been minimized.

Copy link
Member

jksuom commented Mar 9, 2018

I have grown to think of "composite domains" as those that have transcendental (symbolic) generators. It is true that AlgebraicField has attribute symbols (a copy of gens) but those are not transcendental. I think that the attribute was introduced in view of generators that are represented by a single symbol like an AlgebraicNumber with alias alpha. So I would hesitate to make AlgebraicField composite.

@skirpichev

This comment has been minimized.

Copy link
Contributor

skirpichev commented Mar 9, 2018

In some sense, AlgebraicField class name is misleading. I suspect that the intention was (see e.g. #2100) - there should be one domain to handle both algebraic number fields (this only it currently does) and algebraic function fields (there are some support for them in numberfields.py, but no domain to represent it). Not sure, but maybe being "composite" does make sense in later case?

@jksuom

This comment has been minimized.

Copy link
Member

jksuom commented Mar 9, 2018

I think that the principal use of composite domain concept is unification. When two composite domains are unified, some generators may be common and the others are automatically algebraically independent. On the other hand, when two algebraic number fields are unified, it does not suffice to consider the (names of) the generators alone. The situation is even worse with algebraic function fields. On the surface, they may look like algebraic number fields, finitely generated extensions of Q. However, their implementation is different. An algebraic function field F is constructed as a three step extension: Q - k - K - F, where k/Q is a number field, K/k is a purely transcendental extension and F/K is finite algebraic extension. When two such fields are unified, only the K/k extensions can be unified in the same way as is currently done with composite domains. Both algebraic extensions k/Q and F/K have to be specially treated. They should probably not be considered composite.

@skirpichev

This comment has been minimized.

Copy link
Contributor

skirpichev commented Mar 9, 2018

Ok, as a practical consequence - TODO mark may be removed. Perhaps, something should be documented somewhere.

skirpichev added a commit to skirpichev/diofant that referenced this issue Jun 5, 2018

skirpichev added a commit to skirpichev/diofant that referenced this issue Jun 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment