#6046: [with patch, needs review] Implement local and global heights for number
field elements
---------------------------+------------------------------------------------
Reporter: cremona | Owner: was
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.0.1
Component: number theory | Keywords: number field height
---------------------------+------------------------------------------------
Comment(by fwclarke):
== Four Comments ==
1. I had a doctest failure (after applying both patches to 3.4.2 on OS X
10.5.7).
{{{
File "/Users/mafwc/sage-3.4.2/devel/sage-
cremona/sage/rings/number_field/number_field_element.pyx", line 2138:
sage: [a.local_height_arch(i, weighted=True) for i in range(4)]
Expected:
[0.530192454572, 1.77282843491, 1.77282843491, 1.06038490914]
Got:
[1.06038490914, 1.77282843491, 1.77282843491, 0.530192454572]
}}}
But I get the "right" answer when doing the same interactively. No doubt
this is down
to pari's unpredictability.
2. Your test in `local_height_arch` for whether embeddings are real can
easily fail:
{{{
sage: K.<a> = NumberField(x^4+3*x^2-17)
sage: [f(a).imag().is_zero() for f in K.complex_embeddings()]
[False, False, False, True]
}}}
would be telling us that there are 3 complex embeddings and 1 real one!
In fact
{{{
sage: K.signature()
(2, 1)
}}}
It's a rounding problem, of course,
{{{
sage: [f(a).imag() for f in K.complex_embeddings()]
[4.33954243808e-16, 2.42641344245, -2.42641344245, 0.0]
}}}
It would be possible to use something corresponding to Mathematica's
`Chop`,
but this would have to be done carefully.
On the other hand the following from the pari manual entry for `nfint`
could
be helpful:
"`nf [6]` is the vector containing the `r1 + r2` roots (`nf .roots`) of
`nf [1]`
corresponding to the `r1 + r2` embeddings of the number field into `C`
(the first `r1` components are real, the next `r2` have positive imaginary
part)."
But this approach wouldn't allow the precision to be varied.
3. Trying your new functions on elements in relative number fields has
exposed
a problem with `x.valuation()` when `x` is such an element. It's easily
solved by
a change to `is_prime` for relative ideals. I've attached a new patch
which makes
this change, as well as a few tweaks, and some doctests, so that all your
functions
(with the exception of `local_height_arch` and those that depend on it)
work in
the relative case.
4. `denominator_ideal` and `numerator_ideal` are surely better defined
using
the `denominator` and `numerator` of the ideal generated by the element,
as
already defined in `number_field_ideal.py`. I've incorporated the changes
in the
patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6046#comment:1>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
