Changes to number field ideals
39 views
Skip to first unread message
David Roe
Nov 25, 2012, 9:55:46 AM11/25/12
to sag...@googlegroups.com
Hi number theorists,
Currently fractional ideals inherit from ideals, and there's a general lack of clarify between the two (and between the ideal monoids containing them). I'd like to propose the following changes for comments.
Let K be a number field, R its ring of integers and a an element of K or OK.
1. We should deprecate K.ideal(a) in favor of the more explicit K.fractional_ideal(a) and R.ideal(a). This abuse is incompatible with general algorithms that rely on K.ideal yielding an actual ideal of K. Only having fractional ideals available makes it more difficult to eventually implement non-maximal orders and their ideals.
2. We should have a NumberFieldIdeal class that is used for more than just the zero ideal. Eventually this class will be used for ideals of non-maximal orders, but for now we can distinguish between ideals of R and fractional ideals.
3. If I is a fractional ideal, I.ring() should return R. This is an incompatible change to the current behavior, but you can recover K from R by taking the fraction field; once we have ideals in non-maximal orders the other direction is impossible.
4. Neither NumberFieldIdeal nor NumberFieldFractionalIdeal should inherit from the other (rather I'm planning on having a common superclass that implements much of the functionality).
5. There should be parents in Sage for the monoid of integral ideals, the group of invertible fractional ideals and the monoid of R-submodules of K (satisfying aI \subset R for some a \in R), with coercions from the first and second to the third and a construction functor so that the product of an integral ideal and a fractional ideal lives in the third parent. Another option would be to just have the first and third parent.
Thoughts? What's the best way to make these changes in a way that doesn't break backward-compatibility? Do we deprecate K.ideal and I.ring and encourage the alternatives K.fractional_ideal and I.number_field?
David
Currently fractional ideals inherit from ideals, and there's a general lack of clarify between the two (and between the ideal monoids containing them). I'd like to propose the following changes for comments.
Let K be a number field, R its ring of integers and a an element of K or OK.
1. We should deprecate K.ideal(a) in favor of the more explicit K.fractional_ideal(a) and R.ideal(a). This abuse is incompatible with general algorithms that rely on K.ideal yielding an actual ideal of K. Only having fractional ideals available makes it more difficult to eventually implement non-maximal orders and their ideals.
2. We should have a NumberFieldIdeal class that is used for more than just the zero ideal. Eventually this class will be used for ideals of non-maximal orders, but for now we can distinguish between ideals of R and fractional ideals.
3. If I is a fractional ideal, I.ring() should return R. This is an incompatible change to the current behavior, but you can recover K from R by taking the fraction field; once we have ideals in non-maximal orders the other direction is impossible.
4. Neither NumberFieldIdeal nor NumberFieldFractionalIdeal should inherit from the other (rather I'm planning on having a common superclass that implements much of the functionality).
5. There should be parents in Sage for the monoid of integral ideals, the group of invertible fractional ideals and the monoid of R-submodules of K (satisfying aI \subset R for some a \in R), with coercions from the first and second to the third and a construction functor so that the product of an integral ideal and a fractional ideal lives in the third parent. Another option would be to just have the first and third parent.
Thoughts? What's the best way to make these changes in a way that doesn't break backward-compatibility? Do we deprecate K.ideal and I.ring and encourage the alternatives K.fractional_ideal and I.number_field?
David
John Cremona
Nov 25, 2012, 11:12:52 AM11/25/12
to sage-nt
This sounds like a good idea to me. There certainly will be
backward-compatibility problems, but if the new arrangement is clear
and logical and easy to use then I don't see who would object.
Your plan would also eliminate anomalies such as
sage: QQ.ideal(2/7)
Principal ideal (1) of Rational Field
sage: NumberField(x^2-2,'a').ideal(2/7)
Fractional ideal (2/7)
John
> --
> You received this message because you are subscribed to the Google Groups
> "sage-nt" group.
> To post to this group, send an email to sag...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-nt+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sage-nt?hl=en-GB.
backward-compatibility problems, but if the new arrangement is clear
and logical and easy to use then I don't see who would object.
Your plan would also eliminate anomalies such as
sage: QQ.ideal(2/7)
Principal ideal (1) of Rational Field
sage: NumberField(x^2-2,'a').ideal(2/7)
Fractional ideal (2/7)
John
> You received this message because you are subscribed to the Google Groups
> "sage-nt" group.
> To post to this group, send an email to sag...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-nt+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sage-nt?hl=en-GB.
Maarten Derickx
Nov 26, 2012, 9:14:50 AM11/26/12
to sag...@googlegroups.com, roed...@gmail.com
I also agree that this should be changed. Your proposal makes a lot of sense. I think in this case there is a legit reason for not being backward compatible. The reason being that R.ideal(a) should behave in the same way independent of what your ring R is (as you already mention). I guess one could even call it a bug that R.ideal(a) behaves differently when is R a number field. I guess it would not be to hard to find examples of generic code in sage that is correct but breaks for number fields because of this broken contract.
Maarten Derickx
Nov 26, 2012, 9:42:02 AM11/26/12
to sag...@googlegroups.com, roed...@gmail.com
And I was right. Every matrix over a PID can be put in smith normal form. In particular we should be able to do this for matrices over numberfields, because every field is a PID. But because of the none compatiblity of R.ideal() where R is a numberfield we get the following error.
sage: R.<x>=QQ[]
sage: L.<a>=QQ.extension(x^2+124125)
sage: L.class_group().gens()
[Fractional ideal class (13, 1/5*a + 12), Fractional ideal class (30, 1/5*a + 15), Fractional ideal class (3, 1/5*a)]
sage: M=Matrix(L,[[13,1/5*a+12],[1/5*a+12,13]])
sage: M.smith_form()
---------------------------------------------------------------------------
ArithmeticError Traceback (most recent call last)
/Users/maarten/Dropbox/Artikelen/MazurKamiennyDerickx/tex/<ipython console> in <module>()
/Applications/sage/local/lib/python2.6/site-packages/sage/matrix/matrix2.so in sage.matrix.matrix2.Matrix.smith_form (sage/matrix/matrix2.c:40335)()
/Applications/sage/local/lib/python2.6/site-packages/sage/matrix/matrix2.so in sage.matrix.matrix2._smith_onestep (sage/matrix/matrix2.c:44860)()
/Applications/sage/local/lib/python2.6/site-packages/sage/matrix/matrix2.so in sage.matrix.matrix2._generic_clear_column (sage/matrix/matrix2.c:43723)()
ArithmeticError: Ideal Fractional ideal (13, 1/5*a + 12) not principal
This was just a first attempt. I guess with enough of looking trough the source code I could find more examples that break. This clearly shows that we should fix K.ideal for K a numberfield!
Robert Bradshaw
Nov 26, 2012, 12:13:58 PM11/26/12
to sage-nt
+1 from me.
David Harvey
Nov 26, 2012, 2:49:08 PM11/26/12
to <sage-nt@googlegroups.com>
Alex Ghitza
Nov 26, 2012, 4:42:35 PM11/26/12
to sag...@googlegroups.com
Yes, please! (And thanks for working on this.)
--
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
http://aghitza.org
--
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
http://aghitza.org
Marco Streng
Nov 27, 2012, 10:09:50 AM11/27/12
to sag...@googlegroups.com
2012/11/25 David Roe <roed...@gmail.com>:
made for K.unit_group(). Both are part of the same design: when people
talk about unit groups and ideals of a number field, they always mean
unit groups and ideals of the maximal order. Changing one of these,
but not the other will add to the confusion. So whatever is done with
K.ideal should be done with K.unit_group too. But for K.unit_group, it
was decided to keep it as it is:
https://groups.google.com/d/topic/sage-nt/jbLLraOIVaA/discussion
> having fractional ideals available makes it more difficult to eventually
> implement non-maximal orders and their ideals.
I don't understand. Surely we want to have fractional ideals of the
non-maximal orders too!
Now that we only have fractional ideals, we only need to create
fractional ideals for non-maximal orders. For that, we could have for
example NumberFieldFractionalIdeal (for fractional ideals of the
maximal order) inheriting from a new class OrderFractionalIdeal (for
arbitrary orders).
If we have a separate class for actual ideals, then we have twice (or
even three times if I read below) as many classes to generalize to
non-maximal orders.
> 2. We should have a NumberFieldIdeal class that is used for more than just
> the zero ideal. Eventually this class will be used for ideals of
> non-maximal orders, but for now we can distinguish between ideals of R and
> fractional ideals.
>
> 3. If I is a fractional ideal, I.ring() should return R. This is an
> incompatible change to the current behavior, but you can recover K from R by
> taking the fraction field; once we have ideals in non-maximal orders the
> other direction is impossible.
+1
> 4. Neither NumberFieldIdeal nor NumberFieldFractionalIdeal should inherit
> from the other (rather I'm planning on having a common superclass that
> implements much of the functionality).
>
> 5. There should be parents in Sage for the monoid of integral ideals, the
> group of invertible fractional ideals and the monoid of R-submodules of K
> (satisfying aI \subset R for some a \in R), with coercions from the first
> and second to the third and a construction functor so that the product of an
> integral ideal and a fractional ideal lives in the third parent. Another
> option would be to just have the first and third parent.
-1 for not having the second parent (group of fractional ideals), as
that is the most important one mathematically. Though I'm open to
explanations of why it is better for the programming to do without it.
And shouldn't there also be coercion of all non-zero (integral) ideals
to the group of fractional ideals?
If I have a fractional ideal I and a non-zero (integral) ideal J, then
all basic ideal arithmetic I+J, I*J, I.intersection(J), I/J (also with
I and J swapped) should work and give me a fractional ideal.
So if we have the first parent (ideals), then there should also be the
intersection of the first and second parents: non-zero ideals,
equivalently integral fractional ideals.
The coercions are then ({non-zero ideals} to everything) and
(everything to third parent).
>
> Thoughts? What's the best way to make these changes in a way that doesn't
> break backward-compatibility? Do we deprecate K.ideal and I.ring and
> encourage the alternatives K.fractional_ideal and I.number_field?
> David
>
> Hi number theorists,
> Currently fractional ideals inherit from ideals, and there's a general lack
> of clarify between the two (and between the ideal monoids containing them).
> I'd like to propose the following changes for comments.
>
> Let K be a number field, R its ring of integers and a an element of K or OK.
>
> 1. We should deprecate K.ideal(a) in favor of the more explicit
> K.fractional_ideal(a) and R.ideal(a). This abuse is incompatible with
> general algorithms that rely on K.ideal yielding an actual ideal of K. Only
The same argument about incompatibility with general algorithms can be
> Currently fractional ideals inherit from ideals, and there's a general lack
> of clarify between the two (and between the ideal monoids containing them).
> I'd like to propose the following changes for comments.
>
> Let K be a number field, R its ring of integers and a an element of K or OK.
>
> 1. We should deprecate K.ideal(a) in favor of the more explicit
> K.fractional_ideal(a) and R.ideal(a). This abuse is incompatible with
> general algorithms that rely on K.ideal yielding an actual ideal of K. Only
made for K.unit_group(). Both are part of the same design: when people
talk about unit groups and ideals of a number field, they always mean
unit groups and ideals of the maximal order. Changing one of these,
but not the other will add to the confusion. So whatever is done with
K.ideal should be done with K.unit_group too. But for K.unit_group, it
was decided to keep it as it is:
https://groups.google.com/d/topic/sage-nt/jbLLraOIVaA/discussion
> having fractional ideals available makes it more difficult to eventually
> implement non-maximal orders and their ideals.
non-maximal orders too!
Now that we only have fractional ideals, we only need to create
fractional ideals for non-maximal orders. For that, we could have for
example NumberFieldFractionalIdeal (for fractional ideals of the
maximal order) inheriting from a new class OrderFractionalIdeal (for
arbitrary orders).
If we have a separate class for actual ideals, then we have twice (or
even three times if I read below) as many classes to generalize to
non-maximal orders.
> 2. We should have a NumberFieldIdeal class that is used for more than just
> the zero ideal. Eventually this class will be used for ideals of
> non-maximal orders, but for now we can distinguish between ideals of R and
> fractional ideals.
>
> 3. If I is a fractional ideal, I.ring() should return R. This is an
> incompatible change to the current behavior, but you can recover K from R by
> taking the fraction field; once we have ideals in non-maximal orders the
> other direction is impossible.
> 4. Neither NumberFieldIdeal nor NumberFieldFractionalIdeal should inherit
> from the other (rather I'm planning on having a common superclass that
> implements much of the functionality).
>
> 5. There should be parents in Sage for the monoid of integral ideals, the
> group of invertible fractional ideals and the monoid of R-submodules of K
> (satisfying aI \subset R for some a \in R), with coercions from the first
> and second to the third and a construction functor so that the product of an
> integral ideal and a fractional ideal lives in the third parent. Another
> option would be to just have the first and third parent.
that is the most important one mathematically. Though I'm open to
explanations of why it is better for the programming to do without it.
And shouldn't there also be coercion of all non-zero (integral) ideals
to the group of fractional ideals?
If I have a fractional ideal I and a non-zero (integral) ideal J, then
all basic ideal arithmetic I+J, I*J, I.intersection(J), I/J (also with
I and J swapped) should work and give me a fractional ideal.
So if we have the first parent (ideals), then there should also be the
intersection of the first and second parents: non-zero ideals,
equivalently integral fractional ideals.
The coercions are then ({non-zero ideals} to everything) and
(everything to third parent).
>
> Thoughts? What's the best way to make these changes in a way that doesn't
> break backward-compatibility? Do we deprecate K.ideal and I.ring and
> encourage the alternatives K.fractional_ideal and I.number_field?
> David
>
Jean-Pierre Flori
Nov 28, 2012, 9:27:45 AM11/28/12
to sag...@googlegroups.com
I agree strongly with that.
In fact, there must be some code rotting on my old webpage somehow forking the current classes for (fractional) ideal (of maximal orders) of number fields, to work with non-maximal orders.
I only copied-pasted the old class, renamed them, and modified enough functions to get basic arithmetic and a little more, without even caring of removing senseless functions in the general case, but that was enough for me.
Of course that was dirty, and I think this should be in a more proper way, and indeed the maximal case should be rethought, rewritten as well, even though it could break backward compatibility.
Let's mention that it was prticularly unpleasant that the existing classes were strongly mixed with things only available in the maximal case, I mean it is implemented with the maximal case only in mind, and not as a special case of the (potentially non-)maximal one.
In fact, there must be some code rotting on my old webpage somehow forking the current classes for (fractional) ideal (of maximal orders) of number fields, to work with non-maximal orders.
I only copied-pasted the old class, renamed them, and modified enough functions to get basic arithmetic and a little more, without even caring of removing senseless functions in the general case, but that was enough for me.
Of course that was dirty, and I think this should be in a more proper way, and indeed the maximal case should be rethought, rewritten as well, even though it could break backward compatibility.
Let's mention that it was prticularly unpleasant that the existing classes were strongly mixed with things only available in the maximal case, I mean it is implemented with the maximal case only in mind, and not as a special case of the (potentially non-)maximal one.
Reply all
Reply to author
Forward
0 new messages