text:
Opened 5 years ago

Closed 22 months ago

# A class for ring extensions

Reported by: Owned by: caruso major sage-9.1 algebra sd75, padicBordeaux jsrn, defeo, bruno, nthiery, SimonKing, saraedum Xavier Caruso David Roe, Frédéric Chapoton N/A c43507c #26105

Sage provides a rich framework for dealing with all classical algebraic structures: rings, fields, algebras, etc. Nevertheless, given (for instance) two fields K and L with K \subset L, it is not possible to build the extension L/K as a Sage object. However one can easily imagine methods related to this extension (e.g. degree, discriminant, normal_basis, decompose_on_basis, etc.)

With Bruno Grenet, Johan Rosenkilde and Luca De Feo, we raised this issue at Sage Days 75. A summary of our discussion is available here.

This ticket implements a generic class for ring extensions, and more specific classes for finite free ring extensions (as finite degree field extensions).

Below is a small tutorial extracted from the documentation:

Extension of rings.

Sage offers the possibility to work with ring extensions L/K as
actual parents and perform meaningful operations on them and their
elements.

The simplest way to build an extension is to use the method
:meth:sage.rings.ring.CommutativeRing.over on the top ring,
that is L.
For example, the following line constructs the extension of
finite fields \mathbf{F}_{5^4}/\mathbf{F}_{5^2}::

sage: GF(5^4).over(GF(5^2))
Field in z4 with defining polynomial x^2 + (4*z2 + 3)*x + z2 over its base

By default, Sage reuses the canonical generator of the top ring
(here z_4 \in \mathbf{F}_{5^4}), together with its name. However,
the user can customize them by passing in appropriate arguments::

sage: F = GF(5^2)
sage: k = GF(5^4)
sage: z4 = k.gen()
sage: K.<a> = k.over(F, gen = 1-z4)
sage: K
Field in a with defining polynomial x^2 + z2*x + 4 over its base

The base of the extension is available via the method :meth:base (or
equivalently :meth:base_ring)::

sage: K.base()
Finite Field in z2 of size 5^2

It also possible to building an extension on top of another extension,
obtaining this way a tower of extensions::

sage: L.<b> = GF(5^8).over(K)
sage: L
Field in b with defining polynomial x^2 + (4*z2 + 3*a)*x + 1 - a over its base
sage: L.base()
Field in a with defining polynomial x^2 + z2*x + 4 over its base
sage: L.base().base()
Finite Field in z2 of size 5^2

The method :meth:bases gives access to the complete list of rings in
a tower::

sage: L.bases()
[Field in b with defining polynomial x^2 + (4*z2 + 3*a)*x + 1 - a over its base,
Field in a with defining polynomial x^2 + z2*x + 4 over its base,
Finite Field in z2 of size 5^2]

Once we have constructed an extension (or a tower of extensions), we
have interesting methods attached to it. As a basic example, one can
compute a basis of the top ring over any base in the tower::

sage: L.basis_over(K)
[1, b]
sage: L.basis_over(F)
[1, a, b, a*b]

When the base is omitted, the default is the natural base of the extension::

sage: L.basis_over()
[1, b]

The method :meth:sage.rings.ring_extension_element.RingExtensionWithBasis.vector
computes the coordinates of an element according to the above basis::

sage: u = a + 2*b + 3*a*b
sage: u.vector()   # over K
(a, 2 + 3*a)
sage: u.vector(F)
(0, 1, 2, 3)

One can also compute traces and norms with respect to any base of the tower::

sage: u.trace()           # over K
(2*z2 + 1) + (2*z2 + 1)*a
sage: u.trace(F)
z2 + 1
sage: u.trace().trace()   # over K, then over F
z2 + 1

sage: u.norm()            # over K
(z2 + 1) + (4*z2 + 2)*a
sage: u.norm(F)
2*z2 + 2

And minimal polynomials::

sage: u.minpoly()
x^2 + ((3*z2 + 4) + (3*z2 + 4)*a)*x + (z2 + 1) + (4*z2 + 2)*a
sage: u.minpoly(F)
x^4 + (4*z2 + 4)*x^3 + x^2 + (z2 + 1)*x + 2*z2 + 2

### comment:1 Changed 5 years ago by caruso

• Branch set to u/caruso/21413/class_ring_extension

### comment:2 Changed 5 years ago by git

• Commit set to 556da4d4c006f305384a3368018809323d0e0997

Branch pushed to git repo; I updated commit sha1. New commits:

 556da4d Coercion system improved

### comment:3 Changed 5 years ago by git

• Commit changed from 556da4d4c006f305384a3368018809323d0e0997 to c82968fff27df846064805774d1d3bf39ddc9759

Branch pushed to git repo; I updated commit sha1. New commits:

 b5e3eed Coercion in scalar restriction and scalar extension c82968f Small tutorial

### comment:4 Changed 5 years ago by git

• Commit changed from c82968fff27df846064805774d1d3bf39ddc9759 to 036fb2a439cd9ee534d8e9489da02a3dde2452ea

Branch pushed to git repo; I updated commit sha1. New commits:

 f0a7ce4 Doctest from the class AlgebraFromMorphism and some methods of this class b6c9a33 Doctest fixed 67c82c7 Merge branch 'develop' into 21413/class_ring_extension 8d70dbe Code split in several files. More doctests. efa3689 Doctest for BaseActionOnRing 7f8ce2d Doctest for the class AlgebraToRing_coercion 991cc70 Doctest for the class AlgebraFMElement 036fb2a Adding licence & author

### comment:5 Changed 5 years ago by caruso

• Description modified (diff)
• Status changed from new to needs_review

### comment:6 Changed 5 years ago by jsrn

Wow, this is great Xavier! Sorry for not being more active before - I promise to look more at it tomorrow.

I'm wondering whether it's a good idea to merge the "framework" before the first concrete instantiation? I.e. whether we should try to get the field-extension-algebra finished before considering this as mature? (I know you have bad experience with too large patches, but if we don't put too much stuff in the field extension as a first approximation, perhaps it's ok).

Best, Johan

### comment:7 follow-up: ↓ 8 Changed 5 years ago by jsrn

In the following, the extension is A = L/K with L and K rings. L.base() is B. Sometimes B is a subring of K.

Right now this AlgebraFromMorphism is mainly a thin wrapper around the L, so e.g. A elements are represented internally as elements of L, and this is also how you print them. Can you try to convince me of the value from a user's POV that he can do arithmetic on his elements inside this algebra, rather than dropping the whole Algebra idea and just letting RingExtension be some non-parent object with fancy methods on it like decompose_on_basis?

What I had in mind after SD75 is that RingExtension is an Algebra as in "a vector space equipped with a bilinear product"; in other words, when I want to see L as a vector space over K, I use RingExtension. In this world, it makes sense to have arithmetic on elements of A and they should print (and possibly be internally represented by) vectors over K; because that's the whole point of why I'm wrapping L.

In that world, AlgebraFromMorphism shouldn't have a gen method because it isn't really focused on its personality as a ring (it might have a multiplicative_generator if you like). But it should definitely have a basis method.

Other remarks that I got by looking at the code. Let's see where the above discussion takes us before doing much about the stuff below:

1. Why are you not giving self._base as argument to CommutativeAlgebra.__init__? You write in a comment that we don't want a coercion map base -> self -- I don't see why not? I guess this is related to the left/right action dichotomy you have?
2. The module doc for algebra_from_morphism is too short. It should explain what this module is and what is offered. Redundancy is not bad.
3. A method "def something(self)" should never have the doc-string "Return the something of self". That's utterly unhelpful :-)
4. from_base_ring has an extremely bad name considering that it doesn't embed an element of the base. I think we need to establish some proper nomenclature and do some commutation diagrams in the doc of this module.
5. The doc for scalar_restriction is very hard to read. Attempt to write before INPUT what this means. Could we write something like
If newbase is a sub-ring of self.base(), then the scalar restriction of self to newbase is the ring extension self.ring()/newbase. The defining morphism will be the composition of f and self.defining_morphism() where f is the coercion map from newbase to self.base().

newbase can be given as an extension, ...

newbase can be given as a morphism, ...

What is the argument for allowing extensions and morphisms as arguments to scalar_restriction? Is it really something you would normally do? Couldn't the user just do A.scalar_restriction(mymorphism.codomain()), etc.?

1. I don't like ring and base. They are too short and it's not clear which is which.
2. Speaking in parents, you let K * A = A but you let A * K = L. Won't this be a major source of confusion for users? I think your nasty example with non-commutativity at the end of RingExtension doc makes this even worse! I'm also very concerned that this might break several things in Sage since you're inheriting from CommutativeAlgebra.
3. Doc of RingExtension: can we make a commuting diagram to describe the coercion between L1/K1 and L2/K2? Something like
K1 -----> L1
^         |
|         |
|         v
K2 -----> L2

Best, Johan

### comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 5 years ago by caruso

Right now this AlgebraFromMorphism is mainly a thin wrapper around the L, so e.g. A elements are represented internally as elements of L, and this is also how you print them. Can you try to convince me of the value from a user's POV that he can do arithmetic on his elements inside this algebra, rather than dropping the whole Algebra idea and just letting RingExtension be some non-parent object with fancy methods on it like decompose_on_basis?

Maybe I misunderstand your proposal but I really think that a ring extension should be a parent because we really want to take advantage of the coercion stuff. Nonetheless, the question "should it derive from CommutativeAlgebra?" is arguable and I can imagine arguments in both directions.

What I had in mind after SD75 is that RingExtension is an Algebra as in "a vector space equipped with a bilinear product"; in other words, when I want to see L as a vector space over K, I use RingExtension.

It is definitely.

In this world, it makes sense to have arithmetic on elements of A and they should print (and possibly be internally represented by) vectors over K; because that's the whole point of why I'm wrapping L.

I agree. But all of this has to be implemented in subclasses. For now, I just wrote a very general class which is supposed to deal with all algebras (possibly not free, not finite...) so it is of course difficult to implement concrete methods.

But these methods clearly exist. Here is a far-from-exhaustive list: scalar_restriction (which is already implemented), __mul__ (usual product of algebras), tensor_product, scalar_extension, cayley_differentials, krull_relative_dimension, is_free, is_finite, is_flat, is_etale, is_smooth, is_open_immersion, is_closed_immersion, is_galois, galois_group. And for elements: trace, norm.

If you insist, I can put these methods in the general class and let them raise NotImplementedError... but it would be difficult to write the doctest :-)

In that world, AlgebraFromMorphism shouldn't have a gen method because it isn't really focused on its personality as a ring (it might have a multiplicative_generator if you like).

The generator of an algebra is a well-defined mathematical notion: the algebra L/K is generated by x if $K \cup {x}$ generates L as a ring. So it clearly makes sense to have a gen method.

But it should definitely have a basis method.

Well there does exist algebras which are not free. So the basis method is clearly something we want. However it should not be inserted in such a general class but in the subclass FreeAlgebraFromMorphism or FiniteFreeAlgebraFromMorphism (which is coming soon).

Why are you not giving self._base as argument to CommutativeAlgebra.__init__? You write in a comment that we don't want a coercion map base -> self -- I don't see why not? I guess this is related to the left/right action dichotomy you have?

Suppose that we create an algebra L/K with a defining morphism phi : K -> L which is not a coercion map. If K coerces to L/K through phi and L/K coerces to L, then we would derive that K coerces to L through phi.

Such a situation really occurs in every day life (at least for people working in algebraic geometry). For instance, if K has characteristic p, these people often consider K as an algebra over itself *through the Frobenius morphism* (which is definitely not a coercion map).

The module doc for algebra_from_morphism is too short. It should explain what this module is and what is offered.

A method "def something(self)" should never have the doc-string "Return the something of self". That's utterly unhelpful :-)

Ok for both. I'll try to fix this.

from_base_ring has an extremely bad name considering that it doesn't embed an element of the base. I think we need to establish some proper nomenclature and do some commutation diagrams in the doc of this module.

It is not my fault :-). This method is needed by the coercion model.

The doc for scalar_restriction is very hard to read. Attempt to write before INPUT what this means. Could we write something like

Ok. I'll do it.

What is the argument for allowing extensions and morphisms as arguments to scalar_restriction? Is it really something you would normally do? Couldn't the user just do A.scalar_restriction(mymorphism.codomain()), etc.?

Sure, it is something we normally do... just as composing ring homomorphisms.

I don't like ring and base. They are too short and it's not clear which is which.

Ok for changing. I'm also not completed satisfied with these names. Do you have some propositions?

Speaking in parents, you let K * A = A but you let A * K = L. Won't this be a major source of confusion for users? I think your nasty example with non-commutativity at the end of RingExtension doc makes this even worse!

I definitely agree that it is not perfect, but I have not found something better :-). The point is that I really want to have algebras_from_morphisms_which_are_not_coercion_maps and I think that implementing the action of scalars (through the defining morphism) is the least we can do.

I'm also very concerned that this might break several things in Sage since you're inheriting from CommutativeAlgebra.

It is one reason why I'm sure that we should inherit from CommutativeAlgebra

Doc of RingExtension: can we make a commuting diagram to describe the coercion between L1/K1 and L2/K2?

Ok.

Xavier

### comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 5 years ago by jsrn

• Status changed from needs_review to needs_info

Thanks for your careful explanations. I'm learning a lot here.

Maybe I misunderstand your proposal but I really think that a ring extension should be a parent because we really want to take advantage of the coercion stuff.

Nonetheless, the question "should it derive from CommutativeAlgebra?" is arguable and I can imagine arguments in both directions.

OK, so "coercion stuff" is an argument in favour of a Parent. I guess you mean that many objects will magically coerce to the Do-What-I-Mean behaviour on methods. But if a weird/surprising behaviour follows from forcing it into the category framework, perhaps that's an argument against it.

At least having a RingExtension being a class with lots of service methods, sort of like David's RelativeFiniteFieldExtension, there will be no arithmetic problems. You could also put norm and trace there.

In this world, it makes sense to have arithmetic on elements of A and they should print (and possibly be internally represented by) vectors over K; because that's the whole point of why I'm wrapping L.

I agree. But all of this has to be implemented in subclasses. For now, I just wrote a very general class which is supposed to deal with all algebras (possibly not free, not finite...) so it is of course difficult to implement concrete methods.

OK, that makes sense. I can see why the general class would have very weak functionality then.

But these methods clearly exist. Here is a far-from-exhaustive list: .... If you insist, I can put these methods in the general class and let them raise NotImplementedError... but it would be difficult to write the doctest :-)

Perhaps that's not a bad idea: it's nicer that any algebra will have the methods you expect and then throw NotImplementedError rather than not advertising the method at all.

The doc-test can be on a more concrete class that does implement the method. If none exist for this ticket, the doc-test will just be one demonstrating the NotImplentedError for now, with the sole purpose of doc-test coverage ;-)

The generator of an algebra is a well-defined mathematical notion: the algebra L/K is generated by x if $K \cup {x}$ generates L as a ring. So it clearly makes sense to have a gen method.

Hmm, but couldn't there be multiple generators? E.g. F[x,y]/F?

Well there does exist algebras which are not free. So the basis method is clearly something we want. However it should not be inserted in such a general class but in the subclass FreeAlgebraFromMorphism or FiniteFreeAlgebraFromMorphism (which is coming soon).

OK, argument accepted. But I think this kind of stuff reinforces that we should try to design the first concrete RingExtension, e.g. FiniteFieldExtension simultaneously with this ticket. Then we'll better be able to judge what goes where and how it should look to be useful on both sides.

Suppose that we create an algebra L/K with a defining morphism phi : K -> L which is not a coercion map. If K coerces to L/K through phi and L/K coerces to L, then we would derive that K coerces to L through phi.

Such a situation really occurs in every day life (at least for people working in algebraic geometry). For instance, if K has characteristic p, these people often consider K as an algebra over itself *through the Frobenius morphism* (which is definitely not a coercion map).

Yikes! So we must disallow coercion from K -> L/K. But we should allow A(k) and k*a, a*k, k + a, etc. for k in K and a in A. And A(a * l) is different from a * A(l). Oh man...

It seems to me that this is really dangerous territory - but perhaps unavoidable. Someone implementing algorithms for CommutativeAlgebra is going to assume that there is coercion from base to self. And that multiplication of base and self elements commute!

Perhaps CommutativeAlgebra should be called something different, and AlgebraFromMorphism should have a different base class. I've cc'ed Nicolas Thiery and Simon King in this discussion to chip in.

from_base_ring has an extremely bad name considering that it doesn't embed an element of the base. I think we need to establish some proper nomenclature and do some commutation diagrams in the doc of this module.

It is not my fault :-). This method is needed by the coercion model.

Eew, yet another symptom that we're perhaps abusing the current hierarchy.

Why doesn't GF(9) have from_base_ring? What kind of Parent requires it?

What is the argument for allowing extensions and morphisms as arguments to scalar_restriction? Is it really something you would normally do? Couldn't the user just do A.scalar_restriction(mymorphism.codomain()), etc.?

Sure, it is something we normally do... just as composing ring homomorphisms.

So it is something where established mathematical notation supports this directly? It's much more explicit to just write A.scalar_restriction(Aother.ring()), so I'd prefer not supporting A.scalar_restriction(Aother), except if a properly educated mathematician would be very surprised if this didn't exist.

I don't like ring and base. They are too short and it's not clear which is which.

Ok for changing. I'm also not completed satisfied with these names. Do you have some propositions?

We should probably first figure out what to do hierarchy-wise. But perhaps keep ring -> ring_of_element and base -> ring_of_scalars. Alternative element_ring resp. scalar_ring.

Speaking in parents, you let K * A = A but you let A * K = L. Won't this be a major source of confusion for users? I think your nasty example with non-commutativity at the end of RingExtension doc makes this even worse!

I definitely agree that it is not perfect, but I have not found something better :-). The point is that I really want to have algebras_from_morphisms_which_are_not_coercion_maps and I think that implementing the action of scalars (through the defining morphism) is the least we can do.

What do you mean "is the least we can do"?

Why is this an argument to make left and right actions different? Couldn't you implement the same left/right action, namely mapping K -> A by phi, followed by multiplication in A.

Best, Johan

### comment:10 in reply to: ↑ 9 Changed 5 years ago by caruso

Perhaps that's not a bad idea: it's nicer that any algebra will have the methods you expect and then throw NotImplementedError rather than not advertising the method at all.

OK. But, on the other hand, the list of possible methods is possibly quite long. Having a parent with 90% not implemented methods is also not that nice.

The generator of an algebra is a well-defined mathematical notion: the algebra L/K is generated by x if $K \cup {x}$ generates L as a ring. So it clearly makes sense to have a gen method.

Hmm, but couldn't there be multiple generators? E.g. F[x,y]/F?

Yes, of course.

For traditional rings, the current behaviour of gen is rather stange (to me):

    sage: R.<x,y> = QQ[]
sage: R.gen()
x

Is that normal?

OK, argument accepted. But I think this kind of stuff reinforces that we should try to design the first concrete RingExtension, e.g. FiniteFieldExtension simultaneously with this ticket. Then we'll better be able to judge what goes where and how it should look to be useful on both sides.

I just do not want this ticket to become too big. But I agree for implementing FiniteFieldExtension here.

Yikes! So we must disallow coercion from K -> L/K. But we should allow A(k) and k*a, a*k, k + a, etc. for k in K and a in A. And A(a * l) is different from a * A(l). Oh man...

(First, let me emphasize that this issue only occurs when the defining morphism is not a coercion map.)

Currently A(k), a*k, k + a uses coercion maps (and not defining morphism): for instance, if K coerces to L then k+a is the addition in L while if K does not coerce to L, k+a produces an error. Only k*a (implemented by a left action of K on L/K) uses the defining morphism.

I agree that it is really confusing but the same confusion appears exactly in the same way in the "theory". So I assume that people who really wants to work with algebras whose defining morphisms are not coercion maps are very aware of this source of confusion!

Why left action and not right action? Because usually scalars act on the left (for instance, we write 2x and not x2 when x lies in some vector space). I nevertheless agree that this convention is not very strong. Another option would be to implement both actions (at some point I actually did this) but it then becomes impossible to multiply an element of K by an element of L without writing explicitly the conversion.

Probably the best solution would be to have a completely different operator for the action of the base through the defining morphism. But which one? Is it a good idea to override the dot operator?

Why doesn't GF(9) have from_base_ring? What kind of Parent requires it?

I think (but I'm not quite sure) that it is used when no coercing map is set from self._base to self.

So it is something where established mathematical notation supports this directly? It's much more explicit to just write A.scalar_restriction(Aother.ring()), so I'd prefer not supporting A.scalar_restriction(Aother), except if a properly educated mathematician would be very surprised if this didn't exist.

I think that sometimes mathematicians may want to invoke A.scalar_restriction(Aother). For instance assume that we have an algebra A defined over C[X]. The fibre of A at the point x is by definition the scalar extension of A with respect to the morphism C[X] -> C mapping X to x. (It is actually also A/(X-x), but sometimes we really want to think of it as a scalar extension.)

Actually we probably prefer to use the "base_change" in that case. So maybe we can implement two methods: first scalar_extension which always uses coercion maps and second base_change which accepts all constructions.

I think that implementing the action of scalars (through the defining morphism) is the least we can do.

What do you mean "is the least we can do"?

When we want to regard L as a K-algebra, a basic thing we want to have is the action of K on L defining the algebra.

### comment:11 follow-up: ↓ 12 Changed 5 years ago by klee

I just found this ticket and I only have a vague idea about what this ticket does. I am curious if the present ticket would solve or at least help one solve each of the following problems (of mine)? I believe that these cases are not supported by Sage yet.

1. Suppose F is a non-prime finite field, say GF(3^2). I want to construct an extension field E over F. So E,phi=F.extension(4,map=True) gives the extension field GF(3^8)and the embedding phi. This currently only works for prime fields.
1. Suppose K is a field and R is a subring of K. Suppose K is the fraction field of R. Let e be an element of K. Then d=e.denominator(R) gives a denominator of e in R such that d*e.numerator(R)  is in R.
1. Let E,F be rings. Suppose phi is a homomorphism from E to F. I want to extend phi to a homomorphism psi from the polynomial ring R=E[x] to F mapping x to c in F. Thus psi(a2*x^2+a1*x+a0)==phi(a2)*c^2+phi(a1)*c+phi(a0). Perhaps I want R.hom([c],F, base=phi) or like to work.

### comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 5 years ago by jsrn

1. Suppose F is a non-prime finite field, say GF(3^2). I want to construct an extension field E over F. So E,phi=F.extension(4,map=True) gives the extension field GF(3^8)and the embedding phi. This currently only works for prime fields.

That currently works fine, just try it.

If you want to go from F back to E for any of the elements phi(E), use phi.section().

If you want to express F as a vector space over E, things are more limited. We implemented basic support for it in sage.coding.relative_finite_field_extension. This ticket is about making that functionality much more general and thought out, and getting it into the core algebra of Sage.

1. Suppose K is a field and R is a subring of K. Suppose K is the fraction field of R. Let e be an element of K. Then d=e.denominator(R) gives a denominator of e in R such that d*e.numerator(R)  is in R.

That also currently works fine. I just tested with R = GF(3^2)['x']:

sage: R = GF(3^2)['x']
sage: K = R.fraction_field()
sage: e = K.random_element()
sage: e.denominator()
(z2 + 2)*x^2 + (z2 + 1)*x
sage: e.denominator().parent()
Univariate Polynomial Ring in x over Finite Field in z2 of size 3^2
sage: e.denominator() in R
True
sage: R( e.denominator() * e )
(2*z2 + 2)*x^2 + (z2 + 2)*x + z2

1. Let E,F be rings. Suppose phi is a homomorphism from E to F. I want to extend phi to a homomorphism psi from the polynomial ring R=E[x] to F mapping x to c in F. Thus psi(a2*x^2+a1*x+a0)==phi(a2)*c^2+phi(a1)*c+phi(a0). Perhaps I want R.hom([c],F, base=phi) or like to work.

That seems more tricky to do. Note that it can easily be split into the composition of two homomorphisms:

mapCoef:  E[x]  --> F[x]
a*x^i |-> phi(a)*x^i

eval:     F[x] --> F
x |-> c

The eval homomorphism can be created in the current Sage, but I don't know how to conveniently create mapCoef (as a Morphism object).

Best, Johan

### comment:13 in reply to: ↑ 12 Changed 5 years ago by klee

1. Suppose F is a non-prime finite field, say GF(3^2). I want to construct an extension field E over F. So E,phi=F.extension(4,map=True) gives the extension field GF(3^8)and the embedding phi. This currently only works for prime fields.

That currently works fine, just try it.

If you want to go from F back to E for any of the elements phi(E), use phi.section().

If you want to express F as a vector space over E, things are more limited. We implemented basic support for it in sage.coding.relative_finite_field_extension. This ticket is about making that functionality much more general and thought out, and getting it into the core algebra of Sage.

Nice. Good luck!

### comment:14 Changed 5 years ago by klee

The following reference might be useful for the design of the class:

Lattices of Compatibly Embedded Finite Fields - WIEB BOSMA, JOHN CANNON AND ALLAN STEEL 1997

as various extensions should be compatible to each other...

### comment:15 Changed 5 years ago by defeo

• Branch changed from u/caruso/21413/class_ring_extension to u/defeo/21413/class_ring_extension

### comment:16 Changed 5 years ago by defeo

• Commit changed from 036fb2a439cd9ee534d8e9489da02a3dde2452ea to 5c1c5b680fe08406fc6d34ccdddca13ee695ab78

Doctest failures:

sage -t src/sage/rings/algebra_from_morphism.py
**********************************************************************
File "src/sage/rings/algebra_from_morphism.py", line 260, in sage.rings.algebra_from_morphism.AlgebraFromMorphism._pushout_
Failed example:
E2._pushout_(E1) is E2
Expected:
True
Got:
False
**********************************************************************
File "src/sage/rings/algebra_from_morphism.py", line 262, in sage.rings.algebra_from_morphism.AlgebraFromMorphism._pushout_
Failed example:
E1._pushout_(E2) is E2
Expected:
True
Got:
False
**********************************************************************
File "src/sage/rings/algebra_from_morphism.py", line 265, in sage.rings.algebra_from_morphism.AlgebraFromMorphism._pushout_
Failed example:
E1._pushout_(L2) is L2
Expected:
True
Got:
False
**********************************************************************
File "src/sage/rings/algebra_from_morphism.py", line 272, in sage.rings.algebra_from_morphism.AlgebraFromMorphism._pushout_
Failed example:
E1p._pushout_(E2) is L2
Expected:
True
Got:
False
**********************************************************************
File "src/sage/rings/algebra_from_morphism.py", line 276, in sage.rings.algebra_from_morphism.AlgebraFromMorphism._pushout_
Failed example:
E1p._pushout_(E2p) is L2
Expected:
True
Got:
False
**********************************************************************
5 of  11 in sage.rings.algebra_from_morphism.AlgebraFromMorphism._pushout_
[119 tests, 5 failures, 0.86 s]
----------------------------------------------------------------------
sage -t src/sage/rings/algebra_from_morphism.py  # 5 doctests failed
----------------------------------------------------------------------
Total time for all tests: 0.9 seconds
cpu time: 0.9 seconds
cumulative wall time: 0.9 seconds

New commits:

 5c1c5b6 Merge 7.6.beta2

### comment:17 follow-up: ↓ 18 Changed 5 years ago by defeo

Had you guys notice that there is this interface in Sage, which returns a mostly empty shell:

sage: K = GF(5^2)
sage: L = GF(5^4)
sage: E = L.algebra(K, category=Semigroups())
sage: E
Free module generated by Finite Field in z4 of size 5^4 over Finite Field in z2 of size 5^2
sage: E.an_element()
2*B[0] + 2*B[z4] + 3*B[z4^2]
sage: E.categories()

[Category of finite dimensional semigroup algebras over Finite Field in z2 of size 5^2,
Category of semigroup algebras over Finite Field in z2 of size 5^2,
Category of associative algebras over Finite Field in z2 of size 5^2,
Category of rngs,
Category of magma algebras over Finite Field in z2 of size 5^2,
Category of magmatic algebras with basis over Finite Field in z2 of size 5^2,
Category of magmatic algebras over Finite Field in z2 of size 5^2,
Category of distributive magmas and additive magmas,
Category of magmas and additive magmas,
Category of finite semigroups,
Category of semigroups,
Category of magmas,
Category of finite dimensional modules with basis over Finite Field in z2 of size 5^2,
Category of set algebras over Finite Field in z2 of size 5^2,
Category of vector spaces with basis over Finite Field in z2 of size 5^2,
Category of modules with basis over Finite Field in z2 of size 5^2,
Category of finite dimensional modules over Finite Field in z2 of size 5^2,
Category of vector spaces over Finite Field in z2 of size 5^2,
Category of modules over Finite Field in z2 of size 5^2,
Category of bimodules over Finite Field in z2 of size 5^2 on the left and Finite Field in z2 of size 5^2 on the right,
Category of right modules over Finite Field in z2 of size 5^2,
Category of left modules over Finite Field in z2 of size 5^2,
Category of finite sets,
Category of sets,
Category of sets with partial maps,
Category of objects]

### comment:18 in reply to: ↑ 17 ; follow-up: ↓ 20 Changed 5 years ago by SimonKing

Had you guys notice that there is this interface in Sage, which returns a mostly empty shell:

In what sense would it be relevant for this ticket?

### comment:19 follow-up: ↓ 21 Changed 5 years ago by defeo

Hello, as you might have guessed, I'm trying to resurrect this ticket.

My biggest concern is the same as Johan's: I find k*a != a*k very confusing for two reasons:

• It is silently not commutative;
• The parent of a*k is neither A nor K.

However I think the fix is simple: explicit is better than implicit, get rid of the coercion A -> L. I find the following idiom completely reasonable:

sage: K = GF(5^2); z2 = K.gen()
sage: L = GF(5^4); z4 = L.gen()
sage: A = RingExtension(L, K, K.frobenius_endomorphism())
sage: z2 * E(z4)
4*z4^3 + 3*z4^2 + 2*z4 + 2
sage: E(z4) * z2
TypeError: ...
sage: L(E(z4)) * z2
z4^3 + 2*z4^2 + 4*z4 + 3

It could be useful if the left action was represented by an operator other than *, however there is no acceptable operator in Python (. cannot be overridden and @ (matmul) was only introduced in Python 3.5).

Or maybe just have the right action be the same as the left action, which apparently you already did.

### comment:20 in reply to: ↑ 18 ; follow-up: ↓ 22 Changed 5 years ago by defeo

Had you guys notice that there is this interface in Sage, which returns a mostly empty shell:

In what sense would it be relevant for this ticket?

At the very least, it is confusing that there is a method defined on L whose name suggests it might return RingExtension(L, K), and it returns a completely unrelated object instead.

We had already discussed of various possible APIs for this, and L.algebra_over(K) was one of those. I think Johan was in favour of this kind of API, rather than cluttering the namespace with yet another mysterious name RingExtension. It would be quite confusing to have L.algebra() and L.algebra_over().

### comment:21 in reply to: ↑ 19 ; follow-up: ↓ 23 Changed 5 years ago by SimonKing

My biggest concern is the same as Johan's: I find k*a != a*k very confusing for two reasons:

• It is silently not commutative;

No problem, from my perspective. While "+" normally denotes a commutative operation in mathematics, "*" is generally not supposed to be commutative.

• The parent of a*k is neither A nor K.

Why would that be a problem? If a=x+2 is in ZZ[x] and x=1/2 is in QQ then a*x neither is in ZZ[x] nor in QQ.

It could be useful if the left action was represented by an operator other than *, however there is no acceptable operator in Python (. cannot be overridden and @ (matmul) was only introduced in Python 3.5).

Perhaps x>>a and a<<x?

Best regards, Simon

### comment:22 in reply to: ↑ 20 ; follow-up: ↓ 24 Changed 5 years ago by SimonKing

At the very least, it is confusing that there is a method defined on L whose name suggests it might return RingExtension(L, K), and it returns a completely unrelated object instead.

I would not expect L.algebra(K) to return RingExtension(L,K) but to return the K-algebra with basis L whose multiplication is induced by the multiplication in L (hence L is only supposed to be a multiplicative monoid).

We had already discussed of various possible APIs for this, and L.algebra_over(K) was one of those. I think Johan was in favour of this kind of API, rather than cluttering the namespace with yet another mysterious name RingExtension.

I agree. When developing SageMath, we should avoid adding further stuff to the global namespace, whenever possible.

It would be quite confusing to have L.algebra() and L.algebra_over().

Perhaps a little variation: L.as_algebra_over(K). Or, changing perspective: L is an extension of K; so, L/K should be returned by a method of K, not by a method of L. Say, K.extension(L).

### comment:23 in reply to: ↑ 21 Changed 5 years ago by defeo

My biggest concern is the same as Johan's: I find k*a != a*k very confusing for two reasons:

• It is silently not commutative;

No problem, from my perspective. While "+" normally denotes a commutative operation in mathematics, "*" is generally not supposed to be commutative.

I expect it to be associative, at least. With the proposed code (k*a)*k != k*(a*k).

• The parent of a*k is neither A nor K.

Why would that be a problem? If a=x+2 is in ZZ[x] and x=1/2 is in QQ then a*x neither is in ZZ[x] nor in QQ.

I know the coercion system finds common parents, but in your example parent(a*x) == parent(x*a), and I expect the same here. I know there are exceptions even to this (e.g., matrices), but here we are talking about a commutative ring A, so I expect * to behave like its internal multiplication.

By a very common stretch of notation, I am glad to accept k*a as a shorthand for phi(k)*a, but I really don't see why a*k should be a shorthand for L(a)*L(k). If we want such exotic semantics, then we should use another symbol than *. See below

It could be useful if the left action was represented by an operator other than *, however there is no acceptable operator in Python (. cannot be overridden and @ (matmul) was only introduced in Python 3.5).

Perhaps x>>a and a<<x?

That's quite ugly, but as I said, it would be the only sensible way to support such exotic semantics.

Let's keep in mind that 90% of Sage users are going to use this to work with field extensions of finite fields or number fields. They expect k*a to mean "scalar multiplication of a by k", not to raise an exception.

The uses proposed by Xavier are certainly important, and it would be nice to support them, but I think those mathematicians who want to work with them should be ready to accept a slightly more explicit notation (an explicit conversion, or a different operator). If they really want to have k*a == a*k^p, then they should use a dedicated class such as SkewPolynomialRing.

### comment:24 in reply to: ↑ 22 Changed 5 years ago by defeo

At the very least, it is confusing that there is a method defined on L whose name suggests it might return RingExtension(L, K), and it returns a completely unrelated object instead.

I would not expect L.algebra(K) to return RingExtension(L,K) but to return the K-algebra with basis L whose multiplication is induced by the multiplication in L (hence L is only supposed to be a multiplicative monoid).

I frankly don't know what I expect from L.algebra(K). I would run it, and see what comes out.

Perhaps a little variation: L.as_algebra_over(K). Or, changing perspective: L is an extension of K; so, L/K should be returned by a method of K, not by a method of L. Say, K.extension(L).

We had already considered this possibility. The problem is that K.extension() is already defined for most rings, and it returns a ring. It wouldn't break compatibility, but it would be a bit surprising if QQ.extension(x^2+1) returned a number field, whereas QQ.extension(K) returned an algebra object.

Of course, it could be K.extension_algebra(L).

### comment:26 Changed 4 years ago by mderickx

I am just reading up on this ticket, it has quote a long discussion. Does it still really need info? If so could someone who knows what info put that in the ticket description?

### comment:27 Changed 4 years ago by jsrn

The "info" the ticket needs is a few decisions on trickier points of the design. But perhaps what would be most useful is a concrete suggestion by updating the ticket's code. I would personally also really like to see how e.g. a finite field extension of #20284 would be instantiated in the current - quite abstract - proposal.

### comment:28 Changed 4 years ago by mderickx

Yes I agree that is important to get the design right, especially since this touches something that touches quite a few areas of sage, since finite fields are far from the only place that one wants to consider relative extensions.

It is quite difficult for me to grasp what the "current proposal" is from the all the discussion that has been going on here. Or is the the one linked to in the description. I need this for something else as well so I plan to work on this.

What I think is that sage already has a class for relative extensions, and that class is called CommutativeAlgebra? from sage.rings.ring . The only problem is that right now that class is a dummy class which has almost nothing implemented yet.

So what I propose is the following, try to put as much general code as possible in CommutativeAlgebra? and set up a framework there that makes it easy later for concrete implementations of rings/fields to see themselves as Algebras over over other bases then their current base. And use this framework to make things work as follows:

sage: GF(81).vector_space() #note this already works
Vector space of dimension 4 over Finite Field of size 3
sage: GF81_as_GF_9_algeba = Algebras(GF(9))(GF(81))
sage: GF81_as_GF_9_algeba.vector_space()
Vector space of dimension 2 over Finite Field in z2 of size 3^2

For the more complicated cases where there is no coercion morphism yet we can try to make the following work

Algebras(GF(9))(GF(81), morphism=my_morhpism)

### comment:29 Changed 4 years ago by defeo

The main objection by @caruso, and the reason for the code he wrote, was that most on the interface, and some algorithms, can also be useful for non-commutative algebras.

He is especially interested in "skew algebras". Citing @caruso:

The point is that I really want to have algebras_from_morphisms_which_are_not_coercion_maps and I think that implementing the action of scalars (through the defining morphism) is the least we can do.

### comment:30 Changed 3 years ago by caruso

• Branch changed from u/defeo/21413/class_ring_extension to u/caruso/21413/class_ring_extension

### comment:31 Changed 3 years ago by git

• Commit changed from 5c1c5b680fe08406fc6d34ccdddca13ee695ab78 to 656ec777d4030fffa17a65f85c4cce87ca7d289e

Branch pushed to git repo; I updated commit sha1. New commits:

 656ec77 Small fixes

### comment:32 follow-up: ↓ 33 Changed 2 years ago by jsrn

• Status changed from needs_info to needs_work

I inexplicably got remotivated to revive and work on this, despite its marathon discussion and open questions. I'll try to summarise the design problems we are facing along with solution proposals in the following.

Naming: Of the now many suggestions, I really like that the algebra L/K could be obtained from K.extension_algebra(L). AlgebraWithMorphism should not be exposed in the global namespace since it is too abstract to have any useful functionality in itself.

The commutativity issue: The issue is that in the current proposal, if A = L/K uses a defining map phi which is _not_ the coercion map of K in L, then k*a == phi(k)*a, while a*k == a*L(k). This could cause confusion for users, but also developers since the class of A currently derives from CommutativeAlgebra (In A we do guarantee that a1 * a2 = a2 * a1)

It has been suggested to let * be commutative and mean k * a = a * k = a * L(k), and introduce a new operator for phi(k) * a. I propose using the binary-and operator for this purpose, &, and hence

   k & a = a & k = phi(k) * a = a * phi(k) = A(k) * a = a * A(k)

The issue with L.algebra: The issue is that there is an existing method

L.algebra(K), which does something different from what we want. One way to alleviate confusion suggested by Simon is to introduce the method L.as_algebra_over(K). I see no reason why we could not have both this as well as K.extension_algebra(L).

Writing GF(q^m)/GF(q) in this ticket: I still advocate that we should write a

(bare-bone) implementation of this particular ring extension in this ticket. We need to see the abstract class in action to properly judge whether the design is at least not crazy.

### comment:33 in reply to: ↑ 32 Changed 2 years ago by klee

Writing GF(q^m)/GF(q) in this ticket: I still advocate that we should write a

(bare-bone) implementation of this particular ring extension in this ticket. We need to see the abstract class in action to properly judge whether the design is at least not crazy.

Actually I have a plan to remove the experimental RelativeFiniteFieldExtension module from the coding section of Sage, right after the cleanup ticket #27634. For one thing, the module is ill-placed. For another, codes can live without it -- I checked this.

By the way, welcome back Johan!

### comment:35 Changed 2 years ago by roed

• Branch changed from u/caruso/21413/class_ring_extension to u/roed/21413/class_ring_extension

### comment:36 Changed 2 years ago by caruso

• Branch changed from u/roed/21413/class_ring_extension to u/caruso/21413/class_ring_extension

### comment:37 Changed 2 years ago by git

• Commit changed from 656ec777d4030fffa17a65f85c4cce87ca7d289e to ee0e0745a839dd9fc9cf2fae23f5245ef8fb1b86

Branch pushed to git repo; I updated commit sha1. New commits:

 ee0e074 Rewrite documentation and fix bugs

### comment:38 Changed 2 years ago by git

• Commit changed from ee0e0745a839dd9fc9cf2fae23f5245ef8fb1b86 to a785d8d8545f29620788d4c29f7ac9ef9996f257

Branch pushed to git repo; I updated commit sha1. New commits:

 a785d8d Fix bug in coercion

### comment:39 Changed 2 years ago by git

• Commit changed from a785d8d8545f29620788d4c29f7ac9ef9996f257 to 631f2281d11b602215cb9ba494b67023fd2d922c

Branch pushed to git repo; I updated commit sha1. New commits:

 77332e0 Disable the construction L/K 631f228 backend morphism and tower of extensions

### comment:40 Changed 2 years ago by git

• Commit changed from 631f2281d11b602215cb9ba494b67023fd2d922c to 07481dd4cb67027b44eb89eb24efef37da5bdc72

Branch pushed to git repo; I updated commit sha1. New commits:

 07481dd Ring extensions with basis

### comment:41 Changed 2 years ago by git

• Commit changed from 07481dd4cb67027b44eb89eb24efef37da5bdc72 to 22d7f4d50143d50c452983f70052375de439b35d

Branch pushed to git repo; I updated commit sha1. New commits:

 22d7f4d add class RingExtensionWithGen

### comment:42 Changed 2 years ago by git

• Commit changed from 22d7f4d50143d50c452983f70052375de439b35d to 2566db5c6d5b4e65fa074d4148685725033db02c

Branch pushed to git repo; I updated commit sha1. New commits:

 2566db5 Make things relative

### comment:43 Changed 2 years ago by git

• Commit changed from 2566db5c6d5b4e65fa074d4148685725033db02c to 6fc7e5fa1691e9a9827143fd03ca2893ffc78199

Branch pushed to git repo; I updated commit sha1. New commits:

 6fc7e5f move code and rename classes

### comment:44 Changed 2 years ago by git

• Commit changed from 6fc7e5fa1691e9a9827143fd03ca2893ffc78199 to 81e4a22cb6a554a7417dc081915ea82013001854

Branch pushed to git repo; I updated commit sha1. New commits:

 81e4a22 check arguments for finite free ring extensions

### comment:45 Changed 2 years ago by saraedum

is_finite should not return True btw as this is about cardinality.

### comment:46 Changed 2 years ago by saraedum

It appears that your homs cannot handle generators?

The following happens in the new finite field code:

sage: GF(3^2).extension(3, absolute=False)._any_embedding(GF(3^12))

produces

        if codomain.has_coerce_map_from(self):
File "sage/structure/parent.pyx", line 1969, in sage.structure.parent.Parent.has_coerce_map_from (build/cythonized/sage/structure/parent.c:16392)
cpdef bint has_coerce_map_from(self, S) except -2:
File "sage/structure/parent.pyx", line 1991, in sage.structure.parent.Parent.has_coerce_map_from (build/cythonized/sage/structure/parent.c:16343)
return self._internal_coerce_map_from(S) is not None
File "sage/structure/parent.pyx", line 2133, in sage.structure.parent.Parent._internal_coerce_map_from (build/cythonized/sage/structure/parent.c:17274)
mor = self.discover_coerce_map_from(S)
File "sage/structure/parent.pyx", line 2270, in sage.structure.parent.Parent.discover_coerce_map_from (build/cythonized/sage/structure/parent.c:17722)
user_provided_mor = self._coerce_map_from_(S)
File "sage/rings/finite_rings/finite_field_base.pyx", line 1334, in sage.rings.finite_rings.finite_field_base.FiniteField._coerce_map_from_ (build/cythonized/sage/rings/finite_rings/finite_field_base.c:15164)
return R.hom((self.gen() ** ((self.order() - 1)//(R.order() - 1)),))
File "sage/structure/parent_gens.pyx", line 291, in sage.structure.parent_gens.ParentWithGens.hom (build/cythonized/sage/structure/parent_gens.c:3689)
return parent.Parent.hom(self, im_gens, codomain, base_map=base_map, category=category, check=check)
File "sage/structure/parent.pyx", line 1363, in sage.structure.parent.Parent.hom (build/cythonized/sage/structure/parent.c:11767)
return self.Hom(codomain, **Hom_kwds)(im_gens, **kwds)
File "/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/rings/ring_extension_homset.py", line 7, in __call__
return RingExtensionHomomorphism(self, *args, **kwargs)
File "sage/rings/ring_extension_morphism.pyx", line 74, in sage.rings.ring_extension_morphism.RingExtensionHomomorphism.__init__ (build/cythonized/sage/rings/ring_extension_morphism.c:4992)
backend = backend_morphism(backend)
File "sage/rings/ring_extension_morphism.pyx", line 33, in sage.rings.ring_extension_morphism.backend_morphism (build/cythonized/sage/rings/ring_extension_morphism.c:3757)
g = _backend_morphism(f)
File "sage/rings/ring_extension_morphism.pyx", line 22, in sage.rings.ring_extension_morphism._backend_morphism (build/cythonized/sage/rings/ring_extension_morphism.c:3355)
if not isinstance(f.domain(), RingExtension_class) and not isinstance(f.codomain(), RingExtension_class):
AttributeError: 'list' object has no attribute 'domain'

where any_embedding looks like this:

    def _any_embedding(self, codomain):
if codomain.has_coerce_map_from(self):
return codomain.coerce_map_from(self)

base_hom = self.base_ring()._any_embedding(codomain)
minpoly = self.gen().minpoly().change_ring(base_hom)
return self.hom(codomain, [minpoly.any_root()], base_map=base_hom)

sage: k = GF(3^2).extension(3, absolute=False)
sage: l = GF(3^12)
sage: k._defining_morphism
Ring morphism:
From: Finite Field in z2 of size 3^2
To:   Finite Field in b729 of size 3^6
Defn: z2 |--> 2*b729^5 + 2*b729^3 + b729^2 + 2*b729 + 2
sage: l.has_coerce_map_from(k) *boom*

Last edited 2 years ago by saraedum (previous) (diff)

### comment:47 Changed 2 years ago by saraedum

Also, it seems that you want to make this change to ignore any check here

diff --git a/src/sage/rings/ring_extension_morphism.pyx b/src/sage/rings/ring_extension_morphism.pyx
index 3028d763ec..644273ddd3 100644
--- a/src/sage/rings/ring_extension_morphism.pyx
+++ b/src/sage/rings/ring_extension_morphism.pyx
@@ -63,7 +63,7 @@ cdef class RingExtensionHomomorphism(RingHomomorphism):
sage: E2 = RingExtension(L,K)

"""
-    def __init__(self, parent, backend):
+    def __init__(self, parent, backend, check=None):
RingHomomorphism.__init__(self, parent)
backend_domain = self.domain()
if isinstance(backend_domain, RingExtension_class):

### comment:48 Changed 2 years ago by saraedum

I think that RingExtension_class shouldn't be a UniqueRepresentation. Instead RingExtension should be a factory. Otherwise, I probably can't inherit from RingExtension_class for classes that are served through a UniqueFactory.

### comment:49 Changed 2 years ago by saraedum

Working on p-adic extensions with this I am now stuck at this that I cannot make much sense of.

Go to https://gitlab-hooks-flau3jeaza-ew.a.run.app/status/dev/branch/general-extensions click "Launch Binder" and type in

L.<a> = Qp(2).extension(x)

to get

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/rings/ring_extension.pyc in __init__(self, defining_morphism, basis, names, coerce, check)
616     def __init__(self, defining_morphism, basis, names=None, coerce=False, check=True):
617         RingExtension_class.__init__(self, defining_morphism, coerce)
--> 618         self._basis = [ self(b) for b in basis ]
619         if names is None:
620             names = [ ]

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/structure/parent.pyx in sage.structure.parent.Parent.__call__ (build/cythonized/sage/structure/parent.c:9203)()
898         if mor is not None:
899             if no_extra_args:
--> 900                 return mor._call_(x)
901             else:
902                 return mor._call_with_args(x, args, kwds)

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/rings/ring_extension_morphism.pyx in sage.rings.ring_extension_morphism.RingExtensionHomomorphism._call_ (build/cythonized/sage/rings/ring_extension_morphism.c:5278)()
85         if isinstance(self.domain(), RingExtension_class):
86             x = x._backend()
---> 87         y = self._backend_morphism(x)
88         if isinstance(self.codomain(), RingExtension_class):
89             y = self._codomain(y)

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/categories/map.pyx in sage.categories.map.Map.__call__ (build/cythonized/sage/categories/map.c:6517)()
771         if P is D: # we certainly want to call _call_/with_args
772             if not args and not kwds:
--> 773                 return self._call_(x)
774             return self._call_with_args(x, args, kwds)
775         # Is there coercion?

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/rings/morphism.pyx in sage.rings.morphism.RingHomomorphism_im_gens._call_ (build/cythonized/sage/rings/morphism.c:9428)()
1285             2*x + 3*y + 2*z
1286         """
-> 1287         return x._im_gens_(self.codomain(), self.im_gens(), base_map=self.base_map())
1288
1289

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/structure/element.pyx in sage.structure.element.Element._im_gens_ (build/cythonized/sage/structure/element.c:5592)()
615         tuple of elements of im_gens.
616         """
--> 617         raise NotImplementedError
618
619     cpdef base_extend(self, R):

NotImplementedError:

Last edited 2 years ago by saraedum (previous) (diff)

### comment:50 Changed 2 years ago by git

• Commit changed from 81e4a22cb6a554a7417dc081915ea82013001854 to 0433a1a3b46ef70fc7a958ad743c03a634aff865

Branch pushed to git repo; I updated commit sha1. New commits:

 c99fa82 morphisms between RingExtensions now support im_gens d4a35ac Add base_map to homomorphisms defined by images of generators 1f78dd4 Fix some doctests 84704ba Fix doctests and py3, incorporate small reviewer suggestion 6a52519 Merge branch 't/26105/26105_base_hom' into t/21413/21413/class_ring_extension 0433a1a more work on morphisms

### comment:51 Changed 2 years ago by caruso

• Dependencies set to #26105

### comment:52 Changed 2 years ago by git

Branch pushed to git repo; I updated commit sha1. New commits:

 e933a5d write a factory

### comment:53 Changed 2 years ago by saraedum

I think we should change this:

/projects/ab5d7b52-0433-4883-9a36-a20aa7103d52/sage/local/lib/python2.7/site-packages/sage/rings/ring_extension.py(699)__init__()
697             RingExtensionWithBasis.__init__(self, defining_morphism, basis, names, coerce, check)
698         except ValueError:
--> 699             raise ValueError("the given element is not a generator")

The actual error was: *** ValueError: too many values to unpack. Essentially a syntax error that now manifested in that strange way.

We probably do not want to catch at all here but instead add a comment in the line above RingExtensionWithBasis.__init__(…) that says something like if you see a ValueError here, gen is probably not a generator.

Last edited 2 years ago by saraedum (previous) (diff)

### comment:54 Changed 2 years ago by saraedum

You might want to cherry pick these two commits:

(or just manually copy them over.)

### comment:55 Changed 2 years ago by git

Branch pushed to git repo; I updated commit sha1. New commits:

 ed7c7b6 fix variable_name(s)

### comment:56 Changed 2 years ago by caruso

We worked with David Roe and Julian Rüth on this ticket this week and finally decided to follow a different approach. We defined a coercion map from K to the extension A = L/K (coming from the defining morphism) but no coercion map from A to L (except when K coerces to L through the defining morphism of the extension). Consequently a*k is always the same as k*a (and is equal to phi(k)*a where phi is the defining morphism) but differs from l*k.

This point of view looked good to us because, in the use cases we have in mind (typically implementing field towers), the defining morphisms are basically never coercion maps but we definitely don't want to use the @ operator to perform multiplications in the tower.

We also implemented special classes for finite field extensions. Below is a short demo showing the capabilities provided by this ticket.

We first create several a bunch of number fields and define a tower of extension QQ -> AA -> BB -> CC. (Currently, the tower is not that easy to define because we still miss a good extension method; we will implement it soon, hopefully.)

sage: A.<a> = QQ.extension(x^2 - 2)
sage: B.<b> = QQ.extension(x^4 - 2)
sage: C.<c> = QQ.extension(x^12 - 2)

# We create extensions
sage: AA.<a> = RingExtension(QQ)
sage: f = Hom(AA,B)(A.hom([b^2]))
sage: BB.<b> = RingExtension(f)
sage: g = Hom(BB,C)(B.hom([c^3]))
sage: CC.<c> = RingExtension(g)

Now we have our tower QQ -> AA -> BB -> CC. Let's play with it.

sage: AA
Ring in a with defining polynomial x^2 - 2 over its base
sage: BB
Ring in b with defining polynomial x^2 - a over its base
sage: CC
Ring in c with defining polynomial x^3 - b over its base

sage: CC.base_field()
Ring in b with defining polynomial x^2 - a over its base
sage: CC.base_field() is BB
True
sage: BB.base_field() is AA
True
sage: CC.intermediate_rings()
[Ring in c with defining polynomial x^3 - b over its base,
Ring in b with defining polynomial x^2 - a over its base,
Ring in a with defining polynomial x^2 - 2 over its base,
Number Field in void with defining polynomial x]

sage: CC.gens()
(c,)

The gens method has also a relative version

sage: CC.gens(AA)   # generators over AA
(c,b)
sage: CC.gens(QQ)
(c,b,a)

And also:

sage: CC.basis()
[1, c, c^2]
sage: CC.basis(AA)
[1, c, c^2, b, b*c, b*c^2]
sage: CC.basis(QQ)
[1, c, c^2, b, b*c, b*c^2, a, a*c, a*c^2, a*b, a*b*c, a*b*c^2]

Now let's play with elements

sage: u = CC.random_element(); u
((-1/2 + 2*a) - 31*b) + (2 + (1 + 1/2*a)*b)*c + ((5/2 - 1/2*a) + 3*b)*c^2
sage: u.trace()     # trace over the base field BB
(-3/2 + 6*a) - 93*b
sage: u.norm()
(95447/8 - 5353/8*a) + (-2443/4 - 115345/4*a)*b
sage: u.matrix()
[  (-1/2 + 2*a) - 31*b     2 + (1 + 1/2*a)*b   (5/2 - 1/2*a) + 3*b]
[3*a + (5/2 - 1/2*a)*b   (-1/2 + 2*a) - 31*b     2 + (1 + 1/2*a)*b]
[        (1 + a) + 2*b 3*a + (5/2 - 1/2*a)*b   (-1/2 + 2*a) - 31*b]
sage: u.polynomial()
((5/2 - 1/2*a) + 3*b)*x^2 + (2 + (1 + 1/2*a)*b)*x + (-1/2 + 2*a) - 31*b
sage: u.polynomial()(c) == u
True

Similarly, all the above functions have relative versions

sage: u.trace(QQ)
-6
sage: u.trace().trace().trace() == u.trace(QQ)
True
sage: u.matrix(AA)
[ -1/2 + 2*a           2 5/2 - 1/2*a         -31   1 + 1/2*a           3]
[        3*a  -1/2 + 2*a           2 5/2 - 1/2*a         -31   1 + 1/2*a]
[      1 + a         3*a  -1/2 + 2*a           2 5/2 - 1/2*a         -31]
[      -31*a       1 + a         3*a  -1/2 + 2*a           2 5/2 - 1/2*a]
[ -1 + 5/2*a       -31*a       1 + a         3*a  -1/2 + 2*a           2]
[        2*a  -1 + 5/2*a       -31*a       1 + a         3*a  -1/2 + 2*a]
sage: P = u.polynomial(QQ); P
3*x0^2*x1 - 1/2*x0^2*x2 + 1/2*x0*x1*x2 + 5/2*x0^2 + x0*x1 + 2*x0 - 31*x1 + 2*x2 - 1/2
sage: P(c,b,a) == u   # (c,b,a) are the generators of CC over QQ
True

Last edited 2 years ago by caruso (previous) (diff)

### comment:57 Changed 2 years ago by git

• Commit changed from ed7c7b69c8ebad23f56d4cc060df636ca3466e37 to f625e62b862c191ddb0f8824c9b8d9d53920b598

Branch pushed to git repo; I updated commit sha1. New commits:

 7d88f9a Working on p-adic free module isomorphisms f4f17d6 Fix precision problem in vector space maps by using new method _polynomial_list 23947e9 Working on vector_space and free_module 8db48a2 Reviewer suggestions 79f2458 One more Returns 9313b2c Adjust comment ad98d9c Address reviewer comments 8615a3d Merge branch 't/28481/free_module' into t/21413/21413/class_ring_extension 9faeb90 Fix small bugs f625e62 make free_module in number fields cooler

### comment:58 Changed 2 years ago by caruso

• Dependencies changed from #26105 to #26105, #28481

### comment:59 Changed 2 years ago by git

• Commit changed from f625e62b862c191ddb0f8824c9b8d9d53920b598 to 8dcf14910e8fe9282795ec9a01d849012b7939d8

Branch pushed to git repo; I updated commit sha1. New commits:

 8dcf149 implement fraction_field and fix division

### comment:60 Changed 2 years ago by git

• Commit changed from 8dcf14910e8fe9282795ec9a01d849012b7939d8 to eacadf68fe36556b10911010b758bef1eed90128

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

 1738aa9 Fix some doctests, remove category keywords from doctests d0e0953 Add base_map to finite_field homsets 16feb8d Fix some errors with positional check arguments c48e142 Fix pyflakes aa84741 Fix some doctests 1ec3234 Merge branch 'u/roed/26105_base_hom' of git://trac.sagemath.org/sage into t/21413/21413/class_ring_extension a76340a Replace vector_space by free_module ae19c87 improve _repr_ dd9abe7 small change in the behaviour of defining_morphism() eacadf6 more on morphisms between ring extensions

### comment:61 Changed 2 years ago by git

• Commit changed from eacadf68fe36556b10911010b758bef1eed90128 to 7c5871a237c53d5c31e791a2b99b34f89fb5bfe8

Branch pushed to git repo; I updated commit sha1. New commits:

 4cdaf1a Review coercion (one more time) 34b190b (re)implement fraction_field 6e3d1c4 small renaming 7c5871a implement minimal polynomial

### comment:62 Changed 2 years ago by git

• Commit changed from 7c5871a237c53d5c31e791a2b99b34f89fb5bfe8 to 69a15b4d5e170e392ab36be37f4fcc93edcc43f7

Branch pushed to git repo; I updated commit sha1. New commits:

 c9847a1 write classes for fraction fields 5fc70d4 More on fraction fields 69a15b4 add a method "over"

### comment:63 Changed 2 years ago by git

• Commit changed from 69a15b4d5e170e392ab36be37f4fcc93edcc43f7 to b18a10a13a61be72789ca2ccee8d220d1a1eb4fb

Branch pushed to git repo; I updated commit sha1. New commits:

 b18a10a cythonize and try to emulate inheritance (backend -> extension)

### comment:64 Changed 2 years ago by git

• Commit changed from b18a10a13a61be72789ca2ccee8d220d1a1eb4fb to 45b8e6a1f31da87e22458b5ac6bf639884a18f74

Branch pushed to git repo; I updated commit sha1. New commits:

 e568d58 implement pickling 3680b29 improve from_backend methods 99056ca implement printing options 45b8e6a fix small bug

### comment:65 Changed 2 years ago by git

• Commit changed from 45b8e6a1f31da87e22458b5ac6bf639884a18f74 to acd9e3b8c630b479987d6e7700a837c496015ef8

Branch pushed to git repo; I updated commit sha1. New commits:

 acd9e3b accelerate arithmetic operators

### comment:66 Changed 2 years ago by git

• Commit changed from acd9e3b8c630b479987d6e7700a837c496015ef8 to 9110c59197a873fa2ea2139f1c75d6cb26c71dba

Branch pushed to git repo; I updated commit sha1. New commits:

 9110c59 typo

### comment:67 Changed 2 years ago by git

• Commit changed from 9110c59197a873fa2ea2139f1c75d6cb26c71dba to 6ad8f804ef730906151651a151a09638ef5718b4

Branch pushed to git repo; I updated commit sha1. New commits:

 6ad8f80 Fix small bug in fraction field creation

### comment:68 Changed 2 years ago by git

• Commit changed from 6ad8f804ef730906151651a151a09638ef5718b4 to d5ffbd06fd9b349b277229c9b410f12b129ddc0a

Branch pushed to git repo; I updated commit sha1. New commits:

 4b4c9bc Merge branch 'u/caruso/21413/class_ring_extension' of git://trac.sagemath.org/sage into ring_extension 7885df6 add some documentation d5ffbd0 More documentation

### comment:69 Changed 2 years ago by git

• Commit changed from d5ffbd06fd9b349b277229c9b410f12b129ddc0a to b27c311b1f67c23ecf5b06b6c1b5abbce30af7ca

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

 3d73776 Fixing Lie algebra morphisms 72b677c change_ring -> map_coefficients and fix composition of morphisms defined by images of generators a62a47c Merge branch 'u/roed/26105_base_hom' of git://trac.sagemath.org/sage into base_hom 5324a83 Merge branch 'develop' into base_hom d780c6f Change base_map so that the codomain is always the codomain of the map 2f526f8 Merge branch 'u/roed/26105_base_hom' of git://trac.sagemath.org/sage into base_hom bfcbebe Fix bug in composition 3705163 Merge branch 'u/roed/26105_base_hom' of git://trac.sagemath.org/sage into base_hom e056cd3 Merge branch 'base_hom' into ring_extension b27c311 better heuristic to compute generators (over some base)

### comment:70 Changed 2 years ago by git

• Commit changed from b27c311b1f67c23ecf5b06b6c1b5abbce30af7ca to 990b2318899cd5c2c2e2b8ae4376f1329242f898

Branch pushed to git repo; I updated commit sha1. New commits:

 7ef3f54 documentation in ring_extension_morphism.pyx 9076d74 More documentation 15e8904 propagate print options 990b231 include documentation in the reference manual

### comment:71 Changed 2 years ago by caruso

• Dependencies changed from #26105, #28481 to #26105
• Status changed from needs_work to needs_review

### comment:72 Changed 2 years ago by git

• Commit changed from 990b2318899cd5c2c2e2b8ae4376f1329242f898 to 80bdcd66a5443b5804b165dc2c7c2598358fc1b9

Branch pushed to git repo; I updated commit sha1. New commits:

 80bdcd6 add one doctest

### comment:73 Changed 2 years ago by git

• Commit changed from 80bdcd66a5443b5804b165dc2c7c2598358fc1b9 to 3cd20d85cadb25252c6de4d25afa7650943af568

Branch pushed to git repo; I updated commit sha1. New commits:

 3cd20d8 typo

### comment:74 Changed 2 years ago by git

• Commit changed from 3cd20d85cadb25252c6de4d25afa7650943af568 to 8acb01923a727fa5031d67082727d95cefb6916a

Branch pushed to git repo; I updated commit sha1. New commits:

 243e72a Merge branch 'develop' into base_hom 626f4ca fix doctest e13f0a7 Merge branch 'base_hom' into ring_extension 8acb019 add tutorial

### comment:75 Changed 2 years ago by caruso

• Description modified (diff)

See the description of the ticket for a small tutorial showing the main functionalities provided by this ticket.

### comment:76 Changed 2 years ago by git

• Commit changed from 8acb01923a727fa5031d67082727d95cefb6916a to 1c76d15702b70b7b3bdaa665af655fb720ef7a74

Branch pushed to git repo; I updated commit sha1. New commits:

 1c76d15 small fixes

### comment:77 Changed 2 years ago by roed

• Branch changed from u/caruso/21413/class_ring_extension to u/roed/21413/class_ring_extension

### comment:78 Changed 2 years ago by git

• Commit changed from 1c76d15702b70b7b3bdaa665af655fb720ef7a74 to cde6ef9f5c3e1ea3dc2613a318f010265b11c6c5

Branch pushed to git repo; I updated commit sha1. New commits:

 cde6ef9 A few more whitespace changes

### comment:79 Changed 2 years ago by caruso

• Branch changed from u/roed/21413/class_ring_extension to u/caruso/21413/class_ring_extension

### comment:80 Changed 2 years ago by caruso

• Commit changed from cde6ef9f5c3e1ea3dc2613a318f010265b11c6c5 to 647b677b71dc895dd2756f4f6e28de840e40b881
• Milestone changed from sage-7.4 to sage-9.0

I changed the milestone, hoping that it will encourage the patchbot to run on this ticket.

New commits:

 1c76d15 small fixes a497ca1 Merge branch 'develop' into ring_extension 256f02e Merge branch 'u/roed/21413/class_ring_extension' of git://trac.sagemath.org/sage into ring_extension 647b677 typos

### comment:81 Changed 2 years ago by roed

• Authors set to Xavier Caruso
• Reviewers set to David Roe

Positive review once tests pass

### comment:82 Changed 2 years ago by caruso

Patchbot reported many errors of this shape:

Failed example:
type(K)
Expected:
<class 'sage.rings.ring_extension.RingExtensionWithGen'>
Got:
<type 'sage.rings.ring_extension.RingExtensionWithGen'>

This sounds weird.

Actually, on my laptop, the output I get is class and not type. Moreover, I noticed the same ambiguity in many other places in Sage. Even more bizarre, sometimes type appears in the doctest, my output is class but no error is reported.

Do you know what's going on here?

### comment:83 Changed 2 years ago by git

• Commit changed from 647b677b71dc895dd2756f4f6e28de840e40b881 to 1ee7798bf12ea64b43c0f92e42c35f285c356c19

Branch pushed to git repo; I updated commit sha1. New commits:

 36133d8 fix pyflakes ca596ac Merge branch 'develop' into ring_extension 1ee7798 small fix

### comment:84 Changed 2 years ago by chapoton

Python2 versus python3. You are supposed to use python3 for development..

### comment:85 Changed 2 years ago by caruso

OK. So does it mean that I should keep class as it is currently?

### comment:86 Changed 2 years ago by chapoton

You should do whatever it takes to have doctests pass in both py2 and py3.

Here this can be achieved by writing ... instead of type or class.

There is also an existing mechanism in the doctest framework that accepts "class" when "type" is required. The other direction has not been implemented. So you can use "type".

### comment:87 Changed 2 years ago by git

• Commit changed from 1ee7798bf12ea64b43c0f92e42c35f285c356c19 to e87e6f27299aca3931bb76db7270178d64b6bef5

Branch pushed to git repo; I updated commit sha1. New commits:

 e87e6f2 class -> type

### comment:88 Changed 2 years ago by git

• Commit changed from e87e6f27299aca3931bb76db7270178d64b6bef5 to 0b4882577644c58a0e0c218e5e5b701e1106a3f9

Branch pushed to git repo; I updated commit sha1. New commits:

 0b48825 remove generic_power

### comment:89 Changed 2 years ago by chapoton

Reste encore un problème sous python2:

sage -t --long src/sage/rings/ring_extension_homset.py
**********************************************************************
File "src/sage/rings/ring_extension_homset.py", line 26, in sage.rings.ring_extension_homset.RingExtensionHomset
Failed example:
type(H)
Expected:
<type 'sage.rings.ring_extension_homset.RingExtensionHomset_with_category'>
Got:
<class 'sage.rings.ring_extension_homset.RingExtensionHomset_with_category'>

qui me semble bizarre. Il devrait être réglé comme les autres par le mécanisme dont j'ai parlé. Utiliser ... pour celui-la, peut-être ?

### comment:90 Changed 2 years ago by git

• Commit changed from 0b4882577644c58a0e0c218e5e5b701e1106a3f9 to e5b7033b83d1e89af7750d7e6697bbbd5a931c85

Branch pushed to git repo; I updated commit sha1. New commits:

 e5b7033 replace type by ellipsis

All tests pass!

### comment:92 Changed 2 years ago by roed

• Status changed from needs_review to positive_review

Wonderful!

### comment:93 Changed 2 years ago by caruso

Mumble... build failed with sage 9.0.beta6

Here is the error:

[sagelib-9.0.beta6] Traceback (most recent call last):
[sagelib-9.0.beta6]   File "setup.py", line 22, in <module>
[sagelib-9.0.beta6]     import fpickle_setup
[sagelib-9.0.beta6]   File "/local/sage-patchbot/sage/src/fpickle_setup.py", line 8, in <module>
[sagelib-9.0.beta6]     from six.moves import copyreg
[sagelib-9.0.beta6] ModuleNotFoundError: No module named 'six'

I would say that it is not related to this ticket, is it?

### comment:94 Changed 2 years ago by chapoton

caused by the switch to python3. You need to do "make distclean" and "make"

### comment:95 Changed 2 years ago by caruso

Well, this error was reported (4 times) by the patchbot; it is normal?

### comment:96 Changed 2 years ago by chapoton

As explained on sage-devel, all patchbots were broken by the switch to python3

Last edited 2 years ago by chapoton (previous) (diff)

### comment:97 Changed 2 years ago by vbraun

• Status changed from positive_review to needs_work

PDF docs don't build

! Undefined control sequence.
l.7333 $$K_n/\cots \K_2/K_1$$ is the ring $$K_1$$.

### comment:98 Changed 2 years ago by git

• Commit changed from e5b7033b83d1e89af7750d7e6697bbbd5a931c85 to 0c284f39331259a9888fc60230118eaf285999f0

Branch pushed to git repo; I updated commit sha1. New commits:

 0c284f3 typo

### comment:99 Changed 2 years ago by caruso

• Status changed from needs_work to needs_review

Thanks. Fixed.

### comment:100 Changed 2 years ago by git

• Commit changed from 0c284f39331259a9888fc60230118eaf285999f0 to 0354850a40be44f74ddac18401c12adc02877f2e

Branch pushed to git repo; I updated commit sha1. New commits:

 0354850 make one doctest more compliant...

### comment:101 Changed 2 years ago by roed

• Status changed from needs_review to positive_review

I checked that the documentation builds now.

### comment:102 Changed 2 years ago by vbraun

• Status changed from positive_review to needs_work

pdf docs don't build:

[docpdf] ! Undefined control sequence.
[docpdf]
[docpdf] l.7333 $$K_n/\cdots\K [docpdf] _2/K_1$$ is the ring $$K_1$$.
[docpdf] ?

### comment:103 Changed 2 years ago by git

Branch pushed to git repo; I updated commit sha1. New commits:

 5291c86 Merge branch 'develop' into ring_extension 3ab2d0b typo 1e8d6d2 Merge branch 'develop' into ring_extension 7356a2a fix small issues in documentation

### comment:104 Changed 2 years ago by caruso

• Status changed from needs_work to needs_review

Should be OK this time...

### comment:105 Changed 23 months ago by embray

• Milestone changed from sage-9.0 to sage-9.1

Ticket retargeted after milestone closed

### comment:106 Changed 23 months ago by caruso

David, if my changes are okay with you, could you please give (again) a positive review to this ticket?

### comment:107 Changed 23 months ago by git

• Commit changed from 7356a2aafc735e0717e36659589b9adc7b9c14d9 to a7a6fa80638442e8d85e26ca54d967c9ee5801a7

Branch pushed to git repo; I updated commit sha1. New commits:

 a7a6fa8 Merge branch 'develop' into ring_extension

### comment:108 Changed 23 months ago by chapoton

• Reviewers changed from David Roe to David Roe, Frédéric Chapoton
• Status changed from needs_review to positive_review

ok, let it be

### comment:109 Changed 23 months ago by caruso

Thanks.

BTW, do you know why some patchbots report building errors?

### comment:110 Changed 23 months ago by vbraun

• Status changed from positive_review to needs_work

I'm getting a lot of failures like this on 32-bit

**********************************************************************
File "src/sage/categories/commutative_rings.py", line 156, in sage.categories.commutative_rings.CommutativeRings.ParentMethods.over
Failed example:
L = GF(5^12).over(K)
Exception raised:
Traceback (most recent call last):
File "/var/lib/buildbot/slave/sage_git/build/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 681, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/var/lib/buildbot/slave/sage_git/build/local/lib/python3.7/site-packages/sage/doctest/forker.py", line 1123, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.categories.commutative_rings.CommutativeRings.ParentMethods.over[17]>", line 1, in <module>
L = GF(Integer(5)**Integer(12)).over(K)
File "/var/lib/buildbot/slave/sage_git/build/local/lib/python3.7/site-packages/sage/categories/commutative_rings.py", line 212, in over
return RingExtension(self, base, gens, names)
File "sage/structure/factory.pyx", line 369, in sage.structure.factory.UniqueFactory.__call__ (build/cythonized/sage/structure/factory.c:2240)
return self.get_object(version, key, kwds)
File "sage/structure/factory.pyx", line 406, in sage.structure.factory.UniqueFactory.get_object (build/cythonized/sage/structure/factory.c:2444)
return self._cache[version, cache_key]
File "sage/misc/weak_dict.pyx", line 703, in sage.misc.weak_dict.WeakValueDictionary.__getitem__ (build/cythonized/sage/misc/weak_dict.c:3650)
cdef PyObject* wr = PyDict_GetItemWithError(self, k)
File "sage/categories/morphism.pyx", line 323, in sage.categories.morphism.Morphism.__hash__ (build/cythonized/sage/categories/morphism.c:4888)
return hash((domain, codomain, definition))
File "sage/rings/ring_extension.pyx", line 696, in sage.rings.ring_extension.RingExtension_generic.__hash__ (build/cythonized/sage/rings/ring_extension.c:10685)
return id(self)
OverflowError: Python int too large to convert to C ssize_t
**********************************************************************

### comment:111 Changed 23 months ago by chapoton

using id(self) for the hash may be a bad idea

### comment:112 follow-up: ↓ 113 Changed 23 months ago by roed

We can certainly fix that problem, but neither Xavier nor I have access to a 32-bit machine, so I'm not sure what other problems might arise.

### comment:113 in reply to: ↑ 112 Changed 23 months ago by dimpase

We can certainly fix that problem, but neither Xavier nor I have access to a 32-bit machine, so I'm not sure what other problems might arise.

just to mention that the access is now available :-)

### comment:114 Changed 22 months ago by git

• Commit changed from a7a6fa80638442e8d85e26ca54d967c9ee5801a7 to c43507cd8a4f320690fa164c46f6f027b24c019a

Branch pushed to git repo; I updated commit sha1. New commits:

 98dc411 Merge branch 'develop' into ring_extension c43507c use fonction hash_by_id

### comment:115 Changed 22 months ago by caruso

I'm trying with the function hash_by_id...

### comment:116 Changed 22 months ago by caruso

• Status changed from needs_work to needs_review

### comment:117 Changed 22 months ago by chapoton

did you check on a 32-bit machine ? If yes, you can set to positive on my name

### comment:118 Changed 22 months ago by roed

• Status changed from needs_review to positive_review

I just ran make ptestlong on a 32-bit machine and they all passed. Setting back to positive review.

### comment:119 Changed 22 months ago by vbraun

• Branch changed from u/caruso/21413/class_ring_extension to c43507cd8a4f320690fa164c46f6f027b24c019a
• Resolution set to fixed
• Status changed from positive_review to closed

### comment:120 Changed 22 months ago by caruso

• Commit c43507cd8a4f320690fa164c46f6f027b24c019a deleted

Champagne!

Note: See TracTickets for help on using tickets.


text:
# zbMATH — the first resource for mathematics

Augmented mixed beta regression and modeling of employed proportions in households. (Persian. English summary) Zbl 1413.62089
Summary: The Beta regression model is usually used for modeling the rates or proportions confined in an open interval $$(0,1)$$. In some studies, the data may also include zero and one. In this paper, an augmented Beta regression model that is a mixture of Beta distribution with two degenerated distributions at 0 and 1 is presented for rates or proportions confined in $$[0,1]$$. For the augmented mixed Beta model with reparametrization of Beta distribution, the mean and precision parameters were modeled including fixed and random effects. This is while taking into account that the random effects make these models applicable to correlated data. Here, the augmented mixed Beta model is presented. Then this model is evaluated in a simulation study. Next, the application of this model is shown for analyzing the proportions of employed persons in every household. Finally, conclusion and results are presented.
##### MSC:
 62J02 General nonlinear regression 62P99 Applications of statistics
R2WinBUGS
Full Text:
##### References:
 [1] Paolino, P. (2001). Maximum Likelihood E stimation of Models with Beta-Distributed Dependent Variables, Political Analysis, 9, 325-346. [2] Kieschnik, R. and McCullough, B.D. (2003). Regression Analysis of Variates Observed on (0,1): Percentage, Proportions and Fractions. Statistical Modelling, 3,193-213. · Zbl 1070.62056 [3] Ferrari, S. and Cribari, F. (2004). Beta Regression for ModellingR ates and Proportions, Journal of Applied Statistics, 31, 799-815. · Zbl 1121.62367 [4] Cepeda, E.D. and Gamerman, D. (2005). Bayesian Methodology for Modeling Parameters in the Two ParameterE xponentialF amily, Revista Estadística, 57, 168-169. [5] Smithson, M. and Verkuilen, J. (2006). A Better Lemon Squeezer? Maximum-Likelihood Regression with Beta-Distributed Dependent Variables, Psychological Methods, 11, 54-71. [6] Branscum, A.J., Johnson, W.O. and Thurmond, M. (2007). Baysian Beta Regression Applications to Houshold Expenditure Data and Genetic Distance Between Food and Mouth Dieseas Viruses, Australian & New Zealand Journal of Statistics, 49, 287-301. · Zbl 1136.62323 [7] Ospina, R. and Ferrari, S. (2010). Inflated Beta Distributions. Statistical Paper, 23, 193-213. [8] Ospina, R. and Ferrari, S. (2012). A General Class of Zeror-One Inflated Beta Regression Models. Computational Statistics & Data Analysis, 56, 1609-1623. · Zbl 1243.62099 [9] Galvis, M.D., Dipankar, B. and Victor, H.L. (2014). Augmented Mixed Beta Regression Models for Periodontal Proportion Data, Preprinted, Statistics in Medicine, 33,3759-3771. [10] Figueroa-Zúñiga, J.I., Arellano-Valle, R.B. and Ferrari, S.L. (2013). Mixed Beta Regression: A Bayesian Perspective, Computational Statistics & Data Analysis, 61, 137– 147. · Zbl 1348.62194 [11] Sturtz, S., Ligges, U. and Gelman, A. (2005). R2winbugs: A Package for Running Winbugs from R, Journal of Statistical Software, 12, 1–16. [12] نتایج آمارگیری نیروی کار (1392)، مرکز آمار ایران، تهران. [13] Gelman, A. and Rubin, D.B. (1992). Inference from Iterative Simulation Using Multiple Sequences, Statistical Science7, 457–511. · Zbl 1386.65060 [14] Heidelberger, P. and Welch, P.D. (1981). A Spectral Method for Confidence Interval Generation and Run Length Contral in Simulations, Communications of the ACM, 24, 233-245. [15] Brooks, S.P. and Gelman, A., (1998). General Methods for Monitoring Convergence of Iterative Simulations. Journal of Computational and Graphical Statistics7, 434–455. [16] Plummer, M., Best, N., Cowles, K. and Vines, K.
This reference list is based on information provided by the publisher or from digital mathematics libraries. Its items are heuristically matched to zbMATH identifiers and may contain data conversion errors. It attempts to reflect the references listed in the original paper as accurately as possible without claiming the completeness or perfect precision of the matching.

format: plain


text:
1. 概述

1.1 集合论地位

Set theory is commonly employed as a foundational system for mathematics, particularly in the form of Zermelo–Fraenkel set theory with the axiom of choice[1].

1.2 现代集合论历史[1]

（1）朴素集合论

（2）罗素悖论——第三次数学危机

（3）公理化集合论

In 1908, two ways of avoiding the paradox were proposed, Russell’s type theory and the Zermelo set theory, the first constructed axiomatic set theory. Zermelo’s axioms went well beyond Frege‘s axioms of extensionality and unlimited set abstraction, and evolved into the now-canonical Zermelo–Fraenkel set theory (ZFC).

The essential difference between Russell’s and Zermelo’s solution to the paradox is that Zermelo altered the axioms of set theory while preserving the logical language in which they are expressed (the language of ZFC, with the help of Skolem, turned out to be first-order logic) while Russell altered the logical language itself.

2. 一些基本概念

（1）ZFC

In mathematics, Zermelo–Fraenkel set theory, named after mathematicians Ernst Zermelo and Abraham Fraenkel, is one of several axiomatic systems that were proposed in the early twentieth century to formulate a theory of sets free of paradoxes such as Russell’s paradox.

Zermelo–Fraenkel set theory with the historically controversial axiom of choice (选择公理) included is commonly abbreviated ZFC, where C stands for choice (Ciesielski 1997). Today ZFC is the standard form of axiomatic set theory (公理集合论) and as such is the most common foundation of mathematics.

（2）集合（set）

（3）关系（relation）

（4）函数（function）

（5）等价（equivalence）

（6）选择公理（Axiom of Choice）

The axiom of choice, or AC, is an axiom of set theory equivalent to the statement that the Cartesian product (笛卡尔积) of a collection of non-empty sets is non-empty.

It states that for every indexed family of nonempty sets there exists an indexed family of elements such that for every .

To give an informal example, for any (even infinite) collection of pairs of shoes, one can pick out the left shoe from each pair to obtain an appropriate selection, but for an infinite collection of pairs of socks (assumed to have no distinguishing features), such a selection can be obtained only by invoking the axiom of choice.

3. 学习资料

Ernst Zermelo, Abraham Fraenkel. Zermelo–Fraenkel set theory with the axiom of choice (ZFC). Charles E. Merrill Publishing Company (1968)

Today ZFC is the standard form of axiomatic set theory and as such is the most common foundation of mathematics[2].

Nicolas Bourbaki. Elements of Mathematics: Theory of Sets.1970(English translation).

James Munkres. Topology(2nd Edition). Pearson.2010.

[1]维基百科词条：集合论,
[2]维基百科词条：Zermelo–Fraenkel set theory

2 thoughts on “集合论学习笔记”

• 2015年11月05日 星期四 at 01:06上午


text:
Find all School-related info fast with the new School-Specific MBA Forum

 It is currently 07 Feb 2016, 15:06

### GMAT Club Daily Prep

#### Thank you for using the timer - this advanced tool can estimate your performance and suggest more practice questions. We have subscribed you to Daily Prep Questions via email.

Customized
for You

we will pick new questions that match your level based on your Timer History

Track

every week, we’ll send you an estimated GMAT score based on your performance

Practice
Pays

we will pick new questions that match your level based on your Timer History

# Events & Promotions

###### Events & Promotions in June
Open Detailed Calendar

# Unexpected dilemma between Maryland and Georgetown

Author Message
TAGS:
Intern
Joined: 10 May 2012
Posts: 2
Followers: 0

Kudos [?]: 1 [1] , given: 0

Unexpected dilemma between Maryland and Georgetown [#permalink]  11 May 2012, 05:02
1
KUDOS
Looking for some advice on picking between the part-time evening program at McDonough/Georgetown and the full-time program at Smith/Maryland.

My plan has been to pursue a part-time MBA in the DC area beginning this fall (relocating isn't an option right now). I applied to UMD and Georgetown, and I was ready to pick McDonough over Smith pretty easily. I like the program on a lot of different levels, and I've been feeling good about my chances after my GMAT performance (730) and a strong interview. (Not accepted yet though, so the rest of this post might be moot).

But UMD threw me a curveball. I was contacted by the director of admissions inviting me to attend the full-time program instead. He expects to be able to offer me a two-year fellowship covering all tuition (and at a minimum, one year).

I am very strongly drawn to Georgetown, I really like the program, and I was willing to handle the tough lifestyle of juggling school, activities, a pretty demanding job and a new marriage for the next 3 years. I had also convinced myself that giving up 2 years' salary and work experience wasn't worth it. But 2 years for free at UMD seems like a hard deal to turn down. I'd start earning my post-MBA salary one year earlier without much debt, I'd be able to focus on school more completely, and my overall quality of life would probably be better. When I do all that math, it seems like a no-brainer to go with Smith.

My questions: How do you think these programs really compare? Is the downgrade in school quality, projected income and career prospects insignificant enough to make this trade a net positive? Am I overblowing G'town's value / underestimating Smith's? Am I even asking the right questions?

Sorry for the rambling, and thanks for the input!
 Kaplan GMAT Prep Discount Codes Knewton GMAT Discount Codes GMAT Pill GMAT Discount Codes
Intern
Joined: 30 Mar 2012
Posts: 8
Location: United States
Concentration: Sustainability, Strategy
Followers: 0

Kudos [?]: 5 [0], given: 0

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  11 May 2012, 05:19
Others will certainly disagree, and as you can see from my profile, I did not apply to Smith, but did to McDonough. That said, I would most probably take the scholarship at Smith. It's true that they are not ranked as high, but they still do have a good reputation, especially in the Maryland/DC/Virginia area. If you are looking to stay there short term, then it would work out nicely.

I have had a few friends attend Smith, and they were all happy with the program and quality of their education. I also think that the full time experience is not something to be passed up if you have the opportunity with a scholarship. Finally, don't overlook the debt associated with attending Georgetown or the stress involved with juggling work with school with a social life. You'd have to manage that balance for three years.

Again, just my thoughts, but I'd go with Smith. Congrats and good luck
Director
Status: Can't wait for August!
Joined: 13 Sep 2011
Posts: 988
Location: United States (MA)
Concentration: Marketing, Strategy
GMAT 1: 660 Q44 V37
GMAT 2: 680 Q45 V38
GMAT 3: 710 Q45 V42
GPA: 3.32
WE: Information Technology (Retail)
Followers: 25

Kudos [?]: 348 [0], given: 109

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  11 May 2012, 05:21
The question is, PT at a top 25 vs FT at a top 50.
What is your plan post MBA?
Are you switching careers?
What is Georgetown's policy of PT students using career services?

If the question were, Georgetown FT VS Smith FT with money, I'd say Georgetown, BUT a its hard to compare a PT program to a FT since the motivation to pursue the degree is usually different.
Intern
Joined: 10 May 2012
Posts: 2
Followers: 0

Kudos [?]: 1 [0], given: 0

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  11 May 2012, 06:55
Quote:
It's true that they are not ranked as high, but they still do have a good reputation, especially in the Maryland/DC/Virginia area. If you are looking to stay there short term, then it would work out nicely.

Actually, I expect to settle in the DC area for the long haul. This is one of the reasons I was more open to Smith. Not crazy about its national rep, but its pretty well regarded here (though not as well as McDonough).

Quote:
The question is, PT at a top 25 vs FT at a top 50.
What is your plan post MBA?
Are you switching careers?
What is Georgetown's policy of PT students using career services?

Yes, I think I'd get what I need from a PT program, and I was sold on the comprehensive approach G'town takes to career services for PT and FT students alike. But yes, I would be switching careers (or more accurately, industries/sectors), which is one reason a FT program is tempting.

I'm mostly stuck on three things:
1) Focused entirely on school, I think I can perform at a much higher level, assume leadership roles, finish near top of class, etc. Whereas I'm worried that by the end of the PT program, I'll be so worn out I'll be grinding to stay in the middle of the pack
2) The time and money equation -- 3 years + salary + lots of debt vs. 2 years + no salary + a little debt
3) Program reputation, strength of alumni network, employment and salary expectations. (and 3a - I like G'town a whole lot more)

1 and 2 go to Smith, 3 goes to McD. I just don't have a feel for how big the gap is for #3 (and 3a).
Senior Manager
Status: schools I listed were for the evening programs, not FT
Joined: 16 Aug 2011
Posts: 389
Location: United States (VA)
GMAT 1: 640 Q47 V32
GMAT 2: 640 Q43 V34
GMAT 3: 660 Q43 V38
GPA: 3.1
WE: Research (Other)
Followers: 3

Kudos [?]: 46 [0], given: 50

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  11 May 2012, 19:32
dcmba10 wrote:
Looking for some advice on picking between the part-time evening program at McDonough/Georgetown and the full-time program at Smith/Maryland.

My plan has been to pursue a part-time MBA in the DC area beginning this fall (relocating isn't an option right now). I applied to UMD and Georgetown, and I was ready to pick McDonough over Smith pretty easily. I like the program on a lot of different levels, and I've been feeling good about my chances after my GMAT performance (730) and a strong interview. (Not accepted yet though, so the rest of this post might be moot).

But UMD threw me a curveball. I was contacted by the director of admissions inviting me to attend the full-time program instead. He expects to be able to offer me a two-year fellowship covering all tuition (and at a minimum, one year).

I am very strongly drawn to Georgetown, I really like the program, and I was willing to handle the tough lifestyle of juggling school, activities, a pretty demanding job and a new marriage for the next 3 years. I had also convinced myself that giving up 2 years' salary and work experience wasn't worth it. But 2 years for free at UMD seems like a hard deal to turn down. I'd start earning my post-MBA salary one year earlier without much debt, I'd be able to focus on school more completely, and my overall quality of life would probably be better. When I do all that math, it seems like a no-brainer to go with Smith.

My questions: How do you think these programs really compare? Is the downgrade in school quality, projected income and career prospects insignificant enough to make this trade a net positive? Am I overblowing G'town's value / underestimating Smith's? Am I even asking the right questions?

Sorry for the rambling, and thanks for the input!

Kind of a tough position, but this is a good problem to have. If I was you and intended on staying in the DC area, I'd go to Maryland assuming they do offer the fellowship because like you said, that's a lot less money to borrow and it is something you can add to the resume which can't be a minus. This is also assuming that you're set on attending B School this fall. A 730 GMAT could get you to NYU, Michigan, Chicago or Kellogg part time as well, if you were willing to travel there for a weekend program. In fact GTown's part time average is higher than Michigan's and is the same as NYU's.

Maryland draws a great network from all the top employers in the DC area, like Georgetown does. If you want to consider going out of the DC area and you are totally fine with potentially tacking on considerable student loan debt, then it may be better to go to Georgetown because it has a wider network. From what I have seen at least, employers will pay MBA grads the same salaries, and Georgetown has a better shot at the highest ones in places like NYC, but at the same time, in DC, Maryland has as good of a shot at the top jobs as anyone too. Outside of DC and Baltimore, it may be more spotty.

Like you, I'm basically deciding between these two (and GW though I am swaying more toward UMD now though I was swaying the other way a month ago) before the R2 decision for Georgetown comes in. Hopefully we'll all know soon, so we can make those final decisions.... the suspense is killing me. good luck!
Intern
Joined: 12 Dec 2006
Posts: 3
Schools: McDodough, Smith
Followers: 0

Kudos [?]: 0 [0], given: 0

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  01 Oct 2012, 13:34
Sorry for jumping into this topic so late. So what did you decide (both first and last poster)? I am going to apply to both schools - I would be interested to hear your final reasons to choose one school over another. Thanks!
Intern
Joined: 01 May 2012
Posts: 32
Location: United States
Concentration: Accounting, Marketing
GMAT Date: 09-01-2012
WE: Sales (Manufacturing)
Followers: 0

Kudos [?]: 5 [0], given: 4

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  01 Oct 2012, 14:47
I'd go with Maryland. Can't beat a free MBA and the difference in post mba salary+ rankings isn't enough to turn it down.
Senior Manager
Status: schools I listed were for the evening programs, not FT
Joined: 16 Aug 2011
Posts: 389
Location: United States (VA)
GMAT 1: 640 Q47 V32
GMAT 2: 640 Q43 V34
GMAT 3: 660 Q43 V38
GPA: 3.1
WE: Research (Other)
Followers: 3

Kudos [?]: 46 [0], given: 50

Re: Unexpected dilemma between Maryland and Georgetown [#permalink]  02 Oct 2012, 06:38
In at MAryland.
Re: Unexpected dilemma between Maryland and Georgetown   [#permalink] 02 Oct 2012, 06:38
Similar topics Replies Last post
Similar
Topics:
Rice (50%) vs Maryland (100%) 1 04 Jan 2016, 04:03
Georgetown (no $) vs Maryland ($40k) 3 20 Dec 2015, 03:30
Indiana Kelley vs Maryland Smith 2 11 Mar 2015, 18:38
4 UNC (No $) vs Georgetown (No$) vs Carlson ($$) vs Maryland Smith($$\$) 6 08 Feb 2015, 06:40
Maryland ( Smith) / Georgetown 3 17 Oct 2007, 14:22
Display posts from previous: Sort by


text:
Home

 Solve any problem (step by step solutions) Input table (Matrix, Statistics)
Mode :
SolutionHelp
 Solution Find Reference angle 30Solution:Your problem -> Reference angle 3030 ^circ is in the first quadrantThe Reference angle of 30 ^circ=30 ^circ Solution provided by AtoZmath.com Any wrong solution, solution improvement, feedback then Submit Here Want to know about AtoZmath.com and me