#14900: mistake in docstring for modular_symbols
-----------------------------------+-----------------------------
Reporter: was | Owner: cremona
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-5.12
Component: elliptic curves | Resolution:
Keywords: | Merged in:
Authors: Chris Wuthrich | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Dependencies:
Stopgaps: |
-----------------------------------+-----------------------------
Changes (by {'newvalue': u'Chris Wuthrich', 'oldvalue': ''}):
* status: new => needs_review
* author: => Chris Wuthrich
Old description:
> The docstring for {{{E.modular_symbol}}} accidentally includes
> "normalize" twice. I think the *first* instance, which a user might read
> first, is wrong and should be deleted (it must have been accidentally
> left there).
>
> {{{
> sage: E = EllipticCurve('11a')
> sage: E.modular_symbol?
> ...
> - ``normalize`` - (default: True); if True, the
> modular symbol is correctly normalized (up to possibly a
> factor of
> -1 or 2). If False, the modular symbol is almost certainly not
> correctly normalized, i.e., all values will be a fixed scalar
> multiple of what they should be. But the initial computation
> of the
> modular symbol is much faster, though evaluation of it after
> computing it won't be any faster.
>
> - ``use_eclib`` - (default: False); if True the computation is
> done with John Cremona's implementation of modular
> symbols in ``eclib``
>
> - ``normalize`` - (default: 'L_ratio'); either 'L_ratio',
> 'period', or 'none';
> For 'L_ratio', the modular symbol is correctly normalized
> as explained above by comparing it to ``L_ratio`` for the
> curve and some small twists.
> The normalization 'period' is only available if
> ...
> }}}
New description:
The docstring for {{{E.modular_symbol}}} accidentally includes "normalize"
twice. I think the *first* instance, which a user might read first, is
wrong and should be deleted (it must have been accidentally left there).
{{{
sage: E = EllipticCurve('11a')
sage: E.modular_symbol?
...
- ``normalize`` - (default: True); if True, the
modular symbol is correctly normalized (up to possibly a factor
of
-1 or 2). If False, the modular symbol is almost certainly not
correctly normalized, i.e., all values will be a fixed scalar
multiple of what they should be. But the initial computation of
the
modular symbol is much faster, though evaluation of it after
computing it won't be any faster.
- ``use_eclib`` - (default: False); if True the computation is
done with John Cremona's implementation of modular
symbols in ``eclib``
- ``normalize`` - (default: 'L_ratio'); either 'L_ratio',
'period', or 'none';
For 'L_ratio', the modular symbol is correctly normalized
as explained above by comparing it to ``L_ratio`` for the
curve and some small twists.
The normalization 'period' is only available if
...
}}}
Apply the patch "trac_14900_modsymdoc.patch".
--
Comment:
Yes, that is what happened an I am sorry. I submit a quick patch here that
fixes this and a small other issue with this normalisation. If L_ratio
fails it now falls back to period. The cases where this makes a real
difference, like 1369b1 are too long to be included as a doctest.
In any case, I am writing on a new implementation of modular symbols which
will change this normalisation business radically anyway.
--
Ticket URL: <http://trac.sagemath.org/ticket/14900#comment:2>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
