Comparison of fractional ideals
Simon King
Sorry to bother you with yet another stupid question.
I wonder if the following is intended (unpatched sage-4.6):
sage: K.<i> = NumberField(x^2+1,embedding=I)
sage: L.<j> = NumberField(x^2+1)
sage: FK = K.fractional_ideal(-K.0+2)
sage: FL = L.fractional_ideal(-L.0+2)
sage: cmp(K,L)
-1
sage: cmp(FK,FL)
0
Hence, the fields are not equal (because the equality check takes the
embedding into account), but the fractional ideals are equal (because
the equality check doesn't care about the rings involved).
Do you agree that it is a bug? I.e., do you agree that FK.__cmp__
should do cmp(FK.pari_hnf(),FL.pari_hnf()) only after doing
cmp(FK.ring(),FL.ring()) ?
Cheers,
Simon
Simon King
On 30 Nov., 13:59, Simon King <simon.k...@uni-jena.de> wrote:
> sage: K.<i> = NumberField(x^2+1,embedding=I)
> sage: L.<j> = NumberField(x^2+1)
> sage: FK = K.fractional_ideal(-K.0+2)
> sage: FL = L.fractional_ideal(-L.0+2)
> sage: cmp(K,L)
> -1
> sage: cmp(FK,FL)
> 0
from K to L then testing FK==FL will first send FK to FL.parent(),
where things evaluate equal, hence, FK==FL will return "True".
Do you think "FK==FL" is False? Then we must forget about forgetful
coercion.
Do you think "FK==FL" is True? Then some changes in
ResidueField.create_key() will be necessary, for otherwise some doc
tests in ell_number_field.py will fail due to side effects of other
doc tests.
Cheers,
Simon
John Cremona
sage: ZZ(1) == QQ(1) == RR(1) == CC(1)
True
I think it would be unfortunate not to have "FK==FL" being True.
(Though not "FK is FL"). The behaviour of == in sage is already rathe
rstrange mathematically:
sage: GF(7)(1) == GF(5)(1)
False
sage: GF(7)(1) == ZZ(1) == GF(5)(1)
True
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.
>
>
Simon King
On 30 Nov., 15:42, John Cremona <john.crem...@gmail.com> wrote:
>
> I think it would be unfortunate not to have "FK==FL" being True.
And, by the way, I think it is unfortunate that we currently have
"cmp(FK,FL)==0" but "FK!=FL".
So, the next step for me would be to change the unique key of residue
fields, because with FK==FL one would have
sage: K.<i> = NumberField(x^2+1,embedding=I)
sage: FL = L.fractional_ideal(-L.0 + 2)
True
Unfortunately, there is one doc test creating ResidueField(FL) and
another one that later requests ResidueField(FK). The result is an
arithmetic error in _tate().
But that should be straight forward: Simply P.ring() should be
included into the unique key for ResidueField(P).
Cheers,
Simon
Simon King
> ...
> included into the unique key for ResidueField(P).
sage: K.<i> = NumberField(x^2+1,embedding=I)
sage: L.<i> = NumberField(x^2+1)
sage: FK = K.fractional_ideal(-K.0 + 2)
sage: FL = L.fractional_ideal(-L.0 + 2)
sage: RL = ResidueField(FL)
With the suggested changes, we have
sage: RK is RL
False
since otherwise some arithmetic occuring in elliptic curves fails.
But: If RK is not RL, would we then also want RK!=RL ? The current
implementation of comparison yields RK==RL, since RK.p==RL.p (but
RK.p.ring()!=RL.p.ring()).
Cheers,
Simon
Simon King
> implementation of comparison yields RK==RL, since RK.p==RL.p (but
> RK.p.ring()!=RL.p.ring()).
I mean, without patches, RK!=RL since RK.p!=RL.p. But with coercion
from K to L, one has RK.p==RL.p, approved by John. That would imply
RK==RL and RK is not RL with the current implementation of RK.__cmp__.
So, should RK.__cmp__(RL) include a comparison of RK.p.ring() with
RL.p.ring()?
Cheers,
Simon
John Cremona
fields since the same finite field (up to isomorphism) can occur in
many different number fields, but they are not deemed equal since they
have different defining polynomials over F_p. And even for degree 1
primes with residue field F_p I don't think we want to regard the
residue fields as the same.
But there is no way in which the residue field's identity is affected
by an embedding into CC or RR, so in your example I see no reason why
the exact same residue field could not be used for both.
(continued below)
I'm not sure I understand that.
Next point: we want this embedding stuff to also apply when it's a
p-adic field that the number field is being embedded into. For
example, in the above example but with embeddings into Q5, one can map
i to either one of the square roots of -1 in Q5. And this does effect
the residue fields at the primes above 5 (generated by 2+i and 2-i)
since in one embedding 2+i maps to 0 mod 5 and in the other it maps to
something nonzero mod 5. SO there would be a case for the residue
field of 2+i w.r.t. the first embedding being equal to that of 2-i
w.r.t. the second embedding!
My guess is that this is too complicated to work out in general.
Maybe David Roe and p-adic people can assist?
John
Simon King
I thought I had answered about two hours ago, but aparently I did not
press the "send" button.
On 30 Nov., 18:16, John Cremona <john.crem...@gmail.com> wrote:
> ...
> by an embedding into CC or RR, so in your example I see no reason why
> the exact same residue field could not be used for both.
> > implementation of comparison yields RK==RL, since RK.p==RL.p (but
> > RK.p.ring()!=RL.p.ring()).
>
> I'm not sure I understand that.
sage: K.<i> = NumberField(x^2+1,embedding=I)
sage: L.<i> = NumberField(x^2+1)
sage: FK = K.fractional_ideal(-K.0 + 2)
sage: FL = L.fractional_ideal(-L.0 + 2)
sage: RK = ResidueField(FK)
sage: RL = ResidueField(FL)
False
True
sage: RK.p==RL.p
False
sage: cmp(RK.p,RL.p)
0
Hence, the current behaviour is that the identity of the residue field
does depend on the embedding (RK is not RL), but these non-identical
fields evaluate equal because there is a difference between cmp(...)
and "==". Usually we want unique parent structures. So, the first
question is: Should this change? And if it should, how? Should we have
"RK is RL" in the situation above, or should we have "RK!=RL"?
Currently, the given fractional ideal (and some names) forms the
unique key used in the creation of ResidueField. Without my patch, we
have
sage: FK==FL
False
but if one introduces a forgetful coercion from K to L then one will
have
sage: FK==FL
True
By consequence, if one does not change the unique key of ResidueField
then one will have
sage: RK is RL
True
Do I understand correctly that you would like to have such identity?
However, that identity would create a subtle problem, namely a side-
effect in the doc tests:
1)
The first doc test creates a non-embedded number field (such as L
above) and creates the residue field RL associated with the fractional
ideal FL as above.
2)
The second doc test creates an embedded number field (such as K above)
and creates the residue field RK associated with the fractional ideal
FK as above. Since FK==FL (this is the effect of my patch), the unique
key in ResidueField is the same as for FL. Hence, RK is the same
object as RL.
3)
In particular, RK.p.ring() is L, not K. But some computation occuring
in a method "_tate()" does arithmetic between an element of
RK.p.ring().maximal_order() and an element of K. We had agreed in
previous posts that there must be no coercion in that situation, and
hence an error is to be raised.
I see two ways to overcome the problem.
(i)
In addition to what my patch already does, change the method
ResidueField.create_key_and_extra_args so that the number field (and
thus the embedding) is included in the key. By consequence, one would
still have "RK is not RL" and "RK==RL", as without my patch. I tested,
and it seems that this would make all doc tests pass.
(ii)
Do not change ResidueField.create_key_and_extra_args, since we are
happy about the new feature "RK is RL". Then, "_tate()" and probably
some other methods must be fixed, so that a conversion (not coercion)
is made from RK.p.ring().maximal_order() (which is L.maximal_order())
to K.
What would you prefer? I have no preference.
> Next point: we want this embedding stuff to also apply when it's a
> p-adic field that the number field is being embedded into. For
> example, in the above example but with embeddings into Q5, one can map
> i to either one of the square roots of -1 in Q5. And this does effect
> the residue fields at the primes above 5 (generated by 2+i and 2-i)
> since in one embedding 2+i maps to 0 mod 5 and in the other it maps to
> something nonzero mod 5. SO there would be a case for the residue
> field of 2+i w.r.t. the first embedding being equal to that of 2-i
> w.r.t. the second embedding!
embedding of a number field into account when we construct the residue
field w.r.t. some fractional ideal. Hence, better have "RK is not RL"
and "RK!=RL" in the situation above?
> My guess is that this is too complicated to work out in general.
> Maybe David Roe and p-adic people can assist?
expertise.
Best regards,
Simon
John Cremona
different embeddings will never have identical residue fields.
I would be happier of there were more opinions though -- where are
you, 100+ sage-nt subscribers? Simon is not a number theorist but is
implementing stuff which will make our work easier!!!
John
Simon King
On 30 Nov., 22:07, John Cremona <john.crem...@gmail.com> wrote:
> The safest and easiest is your solution (i), so that fields with
> different embeddings will never have identical residue fields.
The question is whether it is worth the additional effort or not.
Best regards,
Simon
Simon King
On 30 Nov., 23:22, Simon King <simon.k...@uni-jena.de> wrote:
> "Safest and easiest" aside: Solution (ii) should be doable as well.
> The question is whether it is worth the additional effort or not.
what number theorists expect.
I would thus prefer a solution which is based on answers (from sage-nt
people) how number fields should coerce, how fractional ideals should
compare, and when residue fields should be identical resp. equal.
Therefore I try to sum up the state of the discussion.
Number fields:
- EmbeddedNumberFieldMorphism should continued to be used for
cooercion; only the implementation should be improved.
- NEW: There should be a "forgetful coercion" mapping generator to
generator and disregarding the embedding, provided that the defining
polynomials compare equal.
- Not clear to me: Assume that two number fields K1,K2 are embedded,
but there is no direct coercion; should arithmetic be done in the
pushout of the codomains of the embeddings? Otherwise, there will be
no arithmetic at all between elements of K1 and K2, but perhaps that
is what people would expect/prefer. There have been different answers
so far.
Fractional ideals:
Let F1 and F2 be fractional ideals in K1, K2. Currently we have a
crucial difference between the meaning of cmp(F1,F2)==0 and F1==F2:
* "cmp" is only comparing F1.pari_hnf() with F2.pari_hnf()
* "==" first tries to find a common parent and then
compares .pari_hnf():
{{{
sage: K.<i> = NumberField(x^2+1,embedding=CDF(I))
sage: L.<i> = NumberField(x^2+1,embedding=-CDF(I))
sage: FL = L.fractional_ideal(-L.0 + 2)
False
sage: cmp(FK,FL)==0
True
}}}
Do we want that difference?
Residue fields:
Let R1, R2 be the residue fields provided by fractional ideals F1, F2,
using the same generator name. Currently, we have
"R1 is R2" <=> F1==F2
"R1==R2" <=> cmp(F1,F2)==0
Currently, that is a difference, hence, we have a violation of
uniqueness of parent structures.
Would it be a mathematically correct solution to have
"R1 is R2" <=> F1.pari_hnf()=F2.pari_hnf() ?
Then I suggest to use F1.pari_hnf() in the unique key for
ResidueField(F1) -- currently, F1 itself is used.
When these questions are settled, potential other problems (like the
one in _tate I mentioned before) will be tackled separately.
Thanks for your patience,
Simon
John Cremona
On Wed, Dec 1, 2010 at 9:48 AM, Simon King <simon...@uni-jena.de> wrote:
> Hi y'all,
>
> On 30 Nov., 23:22, Simon King <simon.k...@uni-jena.de> wrote:
>> "Safest and easiest" aside: Solution (ii) should be doable as well.
>> The question is whether it is worth the additional effort or not.
>
> I think I would not be happy with the easy solution if it violates
> what number theorists expect.
>
> I would thus prefer a solution which is based on answers (from sage-nt
> people) how number fields should coerce, how fractional ideals should
> compare, and when residue fields should be identical resp. equal.
> Therefore I try to sum up the state of the discussion.
>
> Number fields:
> - EmbeddedNumberFieldMorphism should continued to be used for
> cooercion; only the implementation should be improved.
OK
> - NEW: There should be a "forgetful coercion" mapping generator to
> generator and disregarding the embedding, provided that the defining
> polynomials compare equal.
OK
> - Not clear to me: Assume that two number fields K1,K2 are embedded,
> but there is no direct coercion; should arithmetic be done in the
> pushout of the codomains of the embeddings? Otherwise, there will be
> no arithmetic at all between elements of K1 and K2, but perhaps that
> is what people would expect/prefer. There have been different answers
> so far.
>
No. If people want to (say) add elements of K1 to elements of K2,
whether or not the fields both have embeddings somewhere, I think that
the user should construct the compositum explicitly. Sage allows for
that, and in such a way that embeddings are preserved where relevant.
I'm not sure of the definition of pushout, but it sounded to me that
you were saying that if K1, K2 both had embeddings into CC then adding
an element of
K1 to an element of K2 would give a result in CC. I cannot imagine
that being what people would want as the default behaviour.
> Fractional ideals:
> Let F1 and F2 be fractional ideals in K1, K2. Currently we have a
> crucial difference between the meaning of cmp(F1,F2)==0 and F1==F2:
> * "cmp" is only comparing F1.pari_hnf() with F2.pari_hnf()
> * "==" first tries to find a common parent and then
> compares .pari_hnf():
> {{{
> sage: K.<i> = NumberField(x^2+1,embedding=CDF(I))
> sage: L.<i> = NumberField(x^2+1,embedding=-CDF(I))
> sage: FK = K.fractional_ideal(-K.0 + 2)
> sage: FL = L.fractional_ideal(-L.0 + 2)
> sage: FK==FL
> False
> sage: cmp(FK,FL)==0
> True
> }}}
> Do we want that difference?
>
NO
> Residue fields:
> Let R1, R2 be the residue fields provided by fractional ideals F1, F2,
> using the same generator name. Currently, we have
> "R1 is R2" <=> F1==F2
> "R1==R2" <=> cmp(F1,F2)==0
> Currently, that is a difference, hence, we have a violation of
> uniqueness of parent structures.
> Would it be a mathematically correct solution to have
> "R1 is R2" <=> F1.pari_hnf()=F2.pari_hnf() ?
No.
> Then I suggest to use F1.pari_hnf() in the unique key for
> ResidueField(F1) -- currently, F1 itself is used.
>
Keep using F1.
> When these questions are settled, potential other problems (like the
> one in _tate I mentioned before) will be tackled separately.
>
OK -- keep on asking!
John
> Thanks for your patience,
> Simon
>
Simon King
On 1 Dez., 12:55, John Cremona <john.crem...@gmail.com> wrote:
> [I hope I am not the only one reading this!]
>...
> you were saying that if K1, K2 both had embeddings into CC then adding
> an element of
> K1 to an element of K2 would give a result in CC.
> I cannot imagine
> that being what people would want as the default behaviour.
http://groups.google.com/group/sage-devel/browse_thread/thread/b080f34ba3cbc015/b6457ab70dd79c41?lnk=gst&q=NumberField+EOF#b6457ab70dd79c41,
stating about L1->K, L2->K, where L1 has generator r2_1:
"""
As long as you construct L1 with a specified embedding to K, from a
user point of view you are stating "I am working on this subfield L1
of K, but I want a subfield representation in terms of powers of
r2_1". In that sense yes, K would be canónical. It would not be in L2
had not an embedding to K or an embedding to a different field.
"""
So, indeed we have two opinions.
> > {{{
> > sage: L.<i> = NumberField(x^2+1,embedding=-CDF(I))
> > sage: FK = K.fractional_ideal(-K.0 + 2)
> > sage: FL = L.fractional_ideal(-L.0 + 2)
> > sage: FK==FL
> > False
> > sage: cmp(FK,FL)==0
> > True
> > }}}
> > Do we want that difference?
>
> NO
then cmp(FK,FL) yields -1.
> > Residue fields:
> > Let R1, R2 be the residue fields provided by fractional ideals F1, F2,
> > using the same generator name. Currently, we have
> > "R1 is R2" <=> F1==F2
> > "R1==R2" <=> cmp(F1,F2)==0
> > Currently, that is a difference, hence, we have a violation of
> > uniqueness of parent structures.
> > Would it be a mathematically correct solution to have
> > "R1 is R2" <=> F1.pari_hnf()=F2.pari_hnf() ?
>
> No.
> Keep using F1.
In combination with the change of __cmp__ into _cmp_ for fractional
ideals, one would obtain "uniqueness of parents" for residue fields.
Nice.
But note one consequence: Residue fields obtained from fractional
ideals FK and FL in number fields K and L are the same if and only if
FK is equal to FL. Since equality of FK and FL depends on coercions
between K and L and since this depends on embeddings for K and L, the
identity of the residue fields would ultimately depend on the
embeddings of number fields.
In an earlier post of yours, I understood that you state that the
residue fields identity should *not* depend on an embedding, but you
also gave a p-adic example where the residue field did seem (to me) to
depend on the embedding.
I would not mind about that consequence, but perhaps you (or other
people) do.
Cheers,
Simon
John Cremona
number field is created with NumberField() the embedding is None,
*unless* it is a quadratic or cyclotomic field. In those cases it was
deemed desirable to have default embeddings into RR or CC (as
appropriate) since they are "natural", not not exactly canonical.
(For QuadraticField(-1) the generator embeds to +1.0*I; for imaginary
quadratics I think the embedded generator has positive imaginary part,
and so on). I believe that these only get set when the user
specifically uses the specially named constructor:
sage: K.<i> = NumberField(x^2+1)
sage: L.<j> = QuadraticField(-1)
sage: K is L
False
sage: K == L
False
but I do not know how to tell which of those fields has an embedding
set. (When there is an embedding, the function
._populate_coercion_lists_() is called by the constructor).
This is a different situation from one in which the user has specified
an embedding (in my opinion).
On Wed, Dec 1, 2010 at 12:40 PM, Simon King <simon...@uni-jena.de> wrote:
> Hi John,
>
> On 1 Dez., 12:55, John Cremona <john.crem...@gmail.com> wrote:
>> [I hope I am not the only one reading this!]
>
> Don't you like to be a dictator? :-)
>
>>...
>> I'm not sure of the definition of pushout, but it sounded to me that
>> you were saying that if K1, K2 both had embeddings into CC then adding
>> an element of
>> K1 to an element of K2 would give a result in CC.
>
> Yes, that was my question.
>
>> I cannot imagine
>> that being what people would want as the default behaviour.
>
> There has been at least one person, namely "luisfe" at
> http://groups.google.com/group/sage-devel/browse_thread/thread/b080f34ba3cbc015/b6457ab70dd79c41?lnk=gst&q=NumberField+EOF#b6457ab70dd79c41,
> stating about L1->K, L2->K, where L1 has generator r2_1:
> """
> As long as you construct L1 with a specified embedding to K, from a
> user point of view you are stating "I am working on this subfield L1
> of K, but I want a subfield representation in terms of powers of
> r2_1". In that sense yes, K would be canónical. It would not be in L2
> had not an embedding to K or an embedding to a different field.
> """
>
> So, indeed we have two opinions.
I don't think I agree with Luis on this point, mainly because of what
I said above, namely that for quadratic and cyclotomic fields there is
an embedding by default, but you cannot say that the user has
expressed any preference by leaving that as default.
>
>> > {{{
I seem to have changed my mind!
John
> I would not mind about that consequence, but perhaps you (or other
> people) do.
>
> Cheers,
> Simon
>
Simon King
I am afraid it won't work in the way we discussed. We had:
> > generator and disregarding the embedding, provided that the defining
> > polynomials compare equal.
>
> OK
> > - Not clear to me: Assume that two number fields K1,K2 are embedded,
> > but there is no direct coercion; should arithmetic be done in the
> > pushout of the codomains of the embeddings? Otherwise, there will be
> > no arithmetic at all between elements of K1 and K2, but perhaps that
> > is what people would expect/prefer. There have been different answers
> > so far.
>
> No.
>K3), K3 a number field without embedding, and we may assume that
there is no direct coercion between K1 and K2.
Since you advice against doing arithmetic between K1,K2 using the
common embedding into K3, we may have fractional ideals F1, F2, F3 in
K1, K2, K3, so that F1==F3 and F2==F3 (since the given embeddings are
used as coercions) but F1!=F2 (since there is no direct coercion and
since F3 will not be used as a pushout for F1 and F2).
> Keep using F1.
Hence, we would have
sage: R3 = ResidueField(F3)
sage: R2 = ResidueField(F2)
sage: R1 = ResidueField(F1)
sage: R1 is R2
True
sage: R2 is R3
True
(Reason: R3 was created first, F1==F3 and F2==F3, hence R1 is R2 is
R3)
and in a new Sage session we would have
sage: R1 = ResidueField(F1)
sage: R2 = ResidueField(F2)
sage: R3 = ResidueField(F3)
sage: R1 is R2
False
sage: (R2 is R3) or (R1 is R3)
True
(Reason: R1 was created first, F1!=F2 hence R1 is not R2; F1==F3 and
F2==F3, so, R3 will be identic with one of the previously created R1,
R2 chosen at random).
Conclusion:
It is a terrible mess, we won't like that.
Possible solutions:
1) Use both the fractional ideal AND the number field in the unique
key of residue fields. Then, R1, R2, R3 would always be pairwise
distinct.
2) Disregard the embeddings in the creation of the residue fields.
Then, R1, R2 and R3 would always be the same objects.
You wrote that pari_hnf() won't work. But this seems better:
* ResidueField.create_key_and_extra_args(F1) currently returns a
tuple formed by F1 and some names.
* Instead, it should internally construct a non-embedded version of
F1.ring() (that would be K3) and the corresponding fractional ideal in
that non-embedded field (that would be F3), and that ideal would
replace F1 in the key.
I don't know if 2) would really be a solution (isn't disregarding the
embedding potentially harmful?).
Anyway, it seems terribly complicated to me, and we really should
think it ove twice before doing a mistake.
Cheers,
Simon
John Cremona
number field; (2) embeddings into something much bigger, in
particular RR or CC or a p-adic field -- which number theorists will
need to use (embedding a field into one of its completions) but which
"feel" very different?
In case (1) I have no objection at all to doing arithmetic in the
common overfield K3; but in (2) I would object. For a start, number
fields are exact while the complete fields are not, so we should only
move to working in the inexact fields when explicitly requested.
Is it too hard on the categorical approach to make the behaviour
depend on what sort of field the embedding codomain is?
John
Simon King
> Does it help if we distinguish between (1) embeddings into some other
> number field; (2) embeddings into something much bigger, in
> particular RR or CC or a p-adic field -- which number theorists will
> need to use (embedding a field into one of its completions) but which
> "feel" very different?
>
> In case (1) I have no objection at all to doing arithmetic in the
> common overfield K3;
the pushout of K1 and K2. Hence, the residue fields R1, R2, R3 would
be the same.
> but in (2) I would object.
not a number field: If it is no number field, then (as you suggest) K3
will not be the pushout of K1 and K2, hence K1!=K2, hence R1 is not R2
-- and the point is that R3 does not exist, since K3 is no number
field!
> Is it too hard on the categorical approach to make the behaviour
> depend on what sort of field the embedding codomain is?
When computing pushout(K1,K2), the constructions of K1 and K2 are
studied. We have an AlgebraicExtensionFunctor in both cases (say, A1
and A2), applied to QQ. Since A1 and A2 have the same rank, the
pushout algorithm will test A1.merge(A2). This should return a
construction functor for the pushout of K1, K2.
Fortunately, A1 and A2 know about the given embeddings. Hence, it is
no problem to determine the codomains of the embeddings (here: K3 for
both A1 and A2).
And then, it can easily be tested if K3 is exact (or, if you prefer,
if it is actually a number field). In that case, A1.merge(A2) returns
K3.construction()[0], and pushout(K1,K2) will be K3. Otherwise,
A1.merge(A2) returns None, and pushout(K1,K2) will raise a
CoercionError.
So, I think it would be doable.
Cheers,
Simon
Simon King
I'd like to do some fine tuning in the comparison of fractional
ideals.
As ideals, they inherit a __cmp__ method of the class of ideals: It
simply compares the list of generators.
As elements (namely elements of the monoid of ideals), it would also
make sense to let them use the Element.__cmp__ comparison: One first
applies coercion, moving the two ideals into a common parent, and then
calls _cmp_.
Apparently there is a slight but important difference between the two
approaches: Two different generators may give rise to the same
fractional ideal.
Example:
sage: L.<b> = NumberField(x^8-x^4+1)
sage: F_4 = L.fractional_ideal(b^4-1)
sage: F_2 = L.fractional_ideal(b^2-1)
sage: F_4
Fractional ideal (1)
sage: F_2
Fractional ideal (1)
1. Comparison as ideals (via generators)
sage: F_4.gens()
(b^4 - 1,)
sage: F_2.gens()
(b^2 - 1,)
sage: F_4==F_2
False
2. Comparison as elements (using _cmp_, which uses pari_hnf)
sage: F_2.pari_hnf()==F_4.pari_hnf()
True
sage: F_2==F_4
True
Am I right that number theorists prefer the second way of comparison?
Cheers,
Simon
David R. Kohel
> Example:
> sage: L.<b> = NumberField(x^8-x^4+1)
> sage: F_4 = L.fractional_ideal(b^4-1)
> sage: F_2 = L.fractional_ideal(b^2-1)
> sage: F_4
> Fractional ideal (1)
> sage: F_2
> Fractional ideal (1)
...
> 1. Comparison as ideals (via generators)
> sage: F_4.gens()
> (b^4 - 1,)
> sage: F_2.gens()
> (b^2 - 1,)
> sage: F_4==F_2
> False
Argh.
> 2. Comparison as elements (using _cmp_, which uses pari_hnf)
> sage: F_2.pari_hnf()==F_4.pari_hnf()
> True
> sage: F_2==F_4
> True
>
> Am I right that number theorists prefer the second way of comparison?
Yes, and I consider the first comparison (of ideals) a bug
(the former is defaulting to "is"?).
Cheers,
David
John Cremona
John
Simon King
On 2 Dez., 10:01, "David R. Kohel" <ko...@iml.univ-mrs.fr> wrote:
> > 2. Comparison as elements (using _cmp_, which uses pari_hnf)
> > sage: F_2.pari_hnf()==F_4.pari_hnf()
> > True
> > sage: F_2==F_4
> > True
>
> > Am I right that number theorists prefer the second way of comparison?
>
> Yes, and I consider the first comparison (of ideals) a bug
> (the former is defaulting to "is"?).
rings, it makes sense to do comparison by "list of generators", since
a "real" comparison via minimal Gröbner bases is very expensive. I
guess this is why it is the default for ideals in Sage. But of course
it makes sense to overload it with a different way of comparison.
BTW, I did not mention that "F_2==F_4" is true in sage-4.6 (so, no
bug). But for reasons mentioned in this thread ("cmp" was different
from "==") I had to work on comparison, so, the question arose what
comparison we actually want: Default for ideals (No!) or default for
elements (Yes!).
Cheers,
Simon
David Harvey
On Dec 2, 2010, at 3:37 AM, Simon King wrote:
> Hi!
>
> I'd like to do some fine tuning in the comparison of fractional
> ideals.
>
> As ideals, they inherit a __cmp__ method of the class of ideals: It
> simply compares the list of generators.
Hi everyone,
I am not actually reading this thread, and I have no idea if anyone has already said what I'm about to say, but here goes:
*** Fractional ideals should not be a subclass of ideals. ***
http://trac.sagemath.org/sage_trac/ticket/3680
It's as crazy as having Rational be a subclass of Integer.
If there is any way of fixing this during the current round of tinkering....
david
David R. Kohel
I was also shocked by the same line, but forgot or omitted saying
anything. Ideals and fractional ideals should be subclasses of
projective modules (of rank 1). In particular, elements of the
ideals will coerce into the order, but this is not the case for
fractional ideals (or projective modules in general).
I say projective modules but there are ideals for non-maximal
orders which are not projective (= not invertible), so maybe the
class should be broadened to admit such ideals.
However, I think some number theorists need to look at the code
and come up with a proposal for the class hierarchy and what
functions and functionality should apply to the classes therein.
--David
Simon King
now David Harvey, and my boss is David Green...),
On 2 Dez., 13:18, David Harvey <dmhar...@cims.nyu.edu> wrote:
> I am not actually reading this thread, and I have no idea if anyone has already said what I'm about to say, but here goes:
>
> *** Fractional ideals should not be a subclass of ideals. ***
>
> http://trac.sagemath.org/sage_trac/ticket/3680
> If there is any way of fixing this during the current round of tinkering....
The discussion here originated in my work on ticket #8800, whose
simple purpose was "Full doctest coverage for sage.categories.functor
and sage.categories.pushout".
sage.categories.pushout provides so-called "construction functors":
Essentially one for any algebraic construction implemented in Sage,
but with almost no doctests. And when I tried to construct meaningful
doctests, covering all cases I could think of by looking at the code,
I found *lots* of bugs in various algebraic parts of Sage. I lost
track, but I think the patch I am now preparing fixes at least 10
independent bugs.
I think the role of ticket #8800 is to fix a lot of think *in the
realm of existing structures*. I think, given how big the patch
already is, it would not be a good idea to include a large structural
change (namely a change of inheritance).
Best regards,
Simon