number field places
John Cremona
which returns the set of (infinite) places with various precision
options (see discussion at
http://trac.sagemath.org/sage_trac/ticket/6046).
My first question is, has anyone actually used this function? I found
nothing cia search_src(), and I myself have only ever used the
(inferior) complex_embeddings() -- inferior since it returns both
complex conjugates and gives no good way of separating the real from
the non-real.
Second question: places() does not actually do what it says when
prec=None: the docstring says that it returns maps to RIF or CIF, but
although the computation of roots is done in those fields, the homs
are constructed using r.center() for each root, so have codomains
which are Real or Complex Fields but not Interval fields. So the
question is, was that done for a reason? Or was it a slip? And
should I change the code to d owhat the docstring says, or change the
docstring to do what the code does?
John
Craig Citro
> My first question is, has anyone actually used this function? I found
> nothing cia search_src(), and I myself have only ever used the
> (inferior) complex_embeddings() -- inferior since it returns both
> complex conjugates and gives no good way of separating the real from
> the non-real.
>
I wrote this function, and amusingly, I've never really used it for
much. :) I wrote it when I wanted to do something with embeddings
(related to John Voight's totally real fields enumeration code), but I
don't think I ended up using it.
> Second question: places() does not actually do what it says when
> prec=None: the docstring says that it returns maps to RIF or CIF, but
> although the computation of roots is done in those fields, the homs
> are constructed using r.center() for each root, so have codomains
> which are Real or Complex Fields but not Interval fields. So the
> question is, was that done for a reason? Or was it a slip? And
> should I change the code to d owhat the docstring says, or change the
> docstring to do what the code does?
>
No, it wasn't done for a reason -- I probably wrote the docstring
before I wrote the code. I would be fine with either behavior -- it
might be more natural to return the actual interval, because it's easy
for the user to then use .center() if they'd like. Maybe an example of
doing this could be in the docstring, so people see how it works?
-cc
Nick Alexander
I think this function is useful (although I rarely need all places)
and would prefer that it be like embeddings (i.e. taking the field,
not the precision). So K.places(CIF) instead of K.places(None). Then
there's no confusion.
Nick
Craig Citro
> and would prefer that it be like embeddings (i.e. taking the field,
> not the precision). So K.places(CIF) instead of K.places(None). Then
> there's no confusion.
>
+1. This is clearer, especially since this is how several other things
(embeddings, roots, etc) all work. Would you want it to take an
arbitrary field, or just something that models the reals or complexes?
(My first impression is to go with the latter, but I could be
convinced otherwise.)
-cc
Nick Alexander
I don't know what K.places(L) means, even when L is an extension of K.
Nick
Craig Citro
>
Me either.
Interestingly, it seems like real fields generally have a
complex_field() method -- given a complex field, is there an obvious
way to get back the real field? The best I came up with was
C.zero_element().real().parent() ...
-cc
John Cremona
>
> On 17-May-09, at 11:02 AM, Craig Citro wrote:
>
>>
>>> I think this function is useful (although I rarely need all places)
>>> and would prefer that it be like embeddings (i.e. taking the field,
>>> not the precision). So K.places(CIF) instead of K.places(None).
>>> Then
>>> there's no confusion.
>>>
>>
>> +1. This is clearer, especially since this is how several other things
field, so (mathematically) there are only two possibilities, R and C.
So in fact it makes a lot of sense to specify the precision and let
the function work out how many of the places are real and how many are
not. That is what I really like about it -- unlike
K.complex_embeddings() which maps to the complexes even for real
places!
So I think it is just fine as it is (after the RIF/CIF is sorted).
For arbitrary extension fields one can still us the embeddings()
function, which I do not propose to change at all. The extra thing
needed one day would be to have p-adic places, as maps to appropriate
extensions of Q_p, where one should define either K.place(P,prec) for
P a prime ideal, or K.places(p,prec), where p is a rational prime and
it returns a list of all the embeddings. However, we do not have a
p-adic analog of R or C so the image would have to be an actual p-adic
field.
I don't need this so will not be doing it! But I much prefer the
places() to embeddings() -- so thanks, Craig! -- and will probably
convert the various elliptic curve functions which use real/complex
embeddings to use the places instead.
Meanwhile, #6021 (which still uses embeddings) needs a review, as does
#6046 (which now uses places).
John
David Roe
For arbitrary extension fields one can still us the embeddings()
function, which I do not propose to change at all. The extra thing
needed one day would be to have p-adic places, as maps to appropriate
extensions of Q_p, where one should define either K.place(P,prec) for
P a prime ideal, or K.places(p,prec), where p is a rational prime and
it returns a list of all the embeddings. However, we do not have a
p-adic analog of R or C so the image would have to be an actual p-adic
field.
One day.... ;-)
Should it just return the embedding into the completion at that prime (until I get around to implementing Cp)?
David
John Cremona
for the infinite places is to extend the current places() function to
allow a parameter which, if 0 or Infinity, does what the current
function does, and if p (a prime number) gives all the embeddings into
completions which extend Q_p (so, a list of at most deg(K)
embeddings). In that case the precision parameter would be
interprested as a p-adic precision. I don't think we need C_p to do
this: just factor the field's defining poly over Q_p and use the
fators to construct the appropriate extensions of Q_p into which the
field is to be embedded.
As I said, I'm in no hurry for this.
John
> David
>
>
> >
>
David R. Kohel
How about?:
K.places(prime,ring,prec)
K.infinite_places(ring,prec)
Returns the list of places over a given prime
(a rational prime for an absolute field K or a
prime
Notes:
prime : required and may be Infinity(), i.e. can
represent any place of the base number field
ring : optional, may be determined by the prime
prec : optional, may be determined by the ring
I prefer that prime does not default to Infinity();
one should use infinite_places.
Abuse of input: one might allow the user to input
prime=<some complete field> which would set the
prime to infinity and ring to the complete field.
This would allow K.places(CIF).
Possibly "ring" could be changed to "field".
Question: If the ring is given then should only the
places which split over that ring should be returned?
E.g. only the real places or if QQ_p is given, then
only the degree one places. If so, then this should
be clearly documented as a feature. An objection to
this is that places
Question: what definition do we want for a place?
It is an equivalence class of:
(1) an embedding of K into a complete field;
(2) an absolute value |x|_v on K;
(3) a valuation on K^* (log|x|_v in the infinite case);
(4) [in the finite case only] a prime ideal.
Do we want to represent them by (1) -- the current
definition? Or do we want a class for which we can
ask for the various associated data?
Objections to my syntax: K.places() should not replace
the set of all places, maybe K.places_set()? There was
some syntax for the set of all primes of ZZ (or QQ),
which this should also follow? William created this
with an iteration operator, as I remember, and there
was some discussion its use or utility.
> > For arbitrary extension fields one can still us the embeddings()
> > function, which I do not propose to change at all. The extra thing
> > needed one day would be to have p-adic places, as maps to appropriate
> > extensions of Q_p, where one should define either K.place(P,prec) for
> > P a prime ideal, or K.places(p,prec), where p is a rational prime and
> > it returns a list of all the embeddings. However, we do not have a
> > p-adic analog of R or C so the image would have to be an actual p-adic
> > field.
> >
>
> One day.... ;-)
Excellent turn-around! Thanks for the speedy effort!
> Should it just return the embedding into the completion at that prime (until
> I get around to implementing Cp)?
I think the above syntax covers the possible inputs.
What the desired output object should be is still
open to debate.
Cheers,
David
John Cremona
But -1 for the fact that I want the infinite places to be a list of
embeddings into either R or C -- in such a way that I can tell which
are the real ones, i.e. I want the codomains to not all be the same.
Your proposal made it look as if all the codomains would be the given
ring (or at least the same ring if none were given).
I would say -- add the functionality first and worry about defining
new classes later. but I think David (K) will disagree with that ;)
John
2009/5/18 David R. Kohel <ko...@iml.univ-mrs.fr>:
David Kohel
> embeddings into either R or C -- in such a way that I can tell which
> are the real ones, i.e. I want the codomains to not all be the same.
> Your proposal made it look as if all the codomains would be the given
> ring (or at least the same ring if none were given).
>
> I would say -- add the functionality first and worry about defining
> new classes later. but I think David (K) will disagree with that ;)
should be, and what uses one wants from them. How much of this
functionality would we like?
K.<t> = NumberField(x^6+x^2+3)
plcs = K.places(3)
[ t.valuation(p) for p in plcs ]
[ t.absolute_value(p) for p in plcs ]
[ p.evaluate(t) for p in plcs ]
[ p.residue_field() for p in plcs ]
[ p.completion() for p in plcs ] # or p.codomain() as morphism?
[ p.degree() for p in plcs ] # or p.inertial_degree()
[ p.ramification_index() for p in plcs ]
len(plcs) # 3
And if we want a ring specified:
plcs = K.places(3,pAdicField(3))
len(plcs) # 0 unramified degree one places
Q = pAdicField(3)
L.<i> = Q.extension(x^2+1)
plcs = K.places(3,Q)
len(plcs) # 0 unramified degree one places
plcs = K.places(3,L)
len(plcs) # 2 degree two unramified places
If K.places(Q) is a short-hand for K.places(3,ring=Q),
then it should be clearly documented that this is
asking for the subset of places with embedding in Q,
rather than places over 3 whose residue field is a
Q-algebra. This potential ambiguity leaves some
concern over the correct design.
However, I don't see how to avoid the need to
give some input hint about which implementation
of p-adic or real/complex ring is to be used.
In general I agree that the the different places
should have different completions.
plcs = K.places(Infinity())
[ p.is_real() for p in plcs ]
plcs = K.places(RealField(32))
etc.
Note that there are different conventions about
the ramification and inertial degree of CC/RR.
I think these operations make sense for places but
are absurd for morphisms?
One can also ask whether two places are equal.
The answer is different for places and morphisms.
Once a design decision is made, and the functions
used, it is often difficult to change code later.
--David
N. Bruin
I agree with David that it is worth trying to get the design of places
right. My input below.
> Question: what definition do we want for a place?
> It is an equivalence class of:
>
> (1) an embedding of K into a complete field;
would take a set of places as input. To compute an s-unit group, one
doesn't really need the completions. This suggest that a "place"
should be a little lighter weight than a morphism which can be
relatively expensive to compute.
A problem with K.places(RING): How are you going to generalize to
relative extensions?
How about
K.places_above() rather than K.places() ?
The input could then be Infinity(), a rational prime, or a place from
a (proper) subfield.
John Cremona's problem could then be solved by having is_real(),
is_complex(), is_archimedean() predicates on the place,
or even real_places() and complex_places() of the field if that can be
done much more efficiently.
This would require a separate class for places. Keep in mind function
fields when thinking about places. They can share a lot of
infrastructure.
Nils
John Cremona
"places" as a synonym for "certain embeddings into R or C" is not good
mathematically; I just liked that (never before used) function since
it at least made the effort to separate real and non-real embeddings.
So, we need a class Place (or perhaps GlobalFieldPlace with derived
class NumberFieldPlace) which includes finite and infinite places (and
allows for future function field support, which I agree is necessary).
For the moment I suggest that we open a ticket with this proposal; if
someone has the energy to paste in this discussion, or at least give a
link to this thread, that would be good.
John
> Nils
> >
>