#8133: changing the string representation of Dirichlet charachters
-----------------------------+----------------------------------------------
Reporter: wuthrich | Owner: craigcitro
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.3.2
Component: modular forms | Keywords: dirichlet characters
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-----------------------------+----------------------------------------------
Comment(by wuthrich):
Thanks a lot for the valuable comments. Sorry to insist a bit more on this
change. I have been using Dirichlet characters quite a lot recently for
p-adic L-functions (of elliptic curves and for zeta functions) and I
thought the current printing was not useful.
Replying to [comment:6 was]:
> 1. First, you can easily get the generators of the Dirichlet group. I
do not think they have to be given explicitly in the print representation
(just like the basis for a vector space doesn't have to be given in a
matrix). See below -- just use the {{{unit_gens()}}} method to find out
the gens that are being mapped.
I almost agree with you, only with a few minor points :
* The group (Z/N)* is not a vector space, for instance for N=16, we have
Z/2 + Z/4 and so the two generators have different order and it would be
great to recognise that immediately in the string representation.
* Usually, in a vector space the elements do not have canonical names as
the residue classes in Z/N have.
* There is no need to have it, of course; but I think it would improve
the user-friendliness of sage. It is completely counter-intuitive for a
new user to ask for a Dirichlet character, which is a map from ZZ to R,
and to be given back a list of values in R.
* There is no place in sage where a Dirichlet character is treated as a
list of values, apart from the _repr_. So I do not see the advantage of
the list representation.
* I think it is advantage when the _repr_ tells what sort of type we are
dealing with. Seeing a list, one is tempted to do things like
{{{chi[0]}}}.
> 2. There are potential issues with your suggested change:
> [...]
> The problem is that it literally makes no sense to read it. The
generators don't get mapped to a Python dictionary. It's like a mixed
metaphor. Moreover, if you use Python dictionary notation, maybe you
really have a dictionary there, so the keys can come in random order,
which is bad.
Totally agree with you on this one. My English is bad and it should read
"mapping 5 |--> 1, 7 |--> -1" instead. Yes I did put a dictionary there
and I agree that it is not good, exactly because of what I said earlier.
> 3. If we're going to make some big change, it would be better to make it
consistent with ring homomorphisms, [...]
> However, this notation is definitely too heavy as is for Dirichlet
characters.
Yes, I agree with both. So as a second attempt I would propose a long
representation of the form
{{{
sage: chi
Dirichlet character modulo 12 of conductor 4 mapping 5 |--> 1, 7 |--> -1
}}}
or maybe one could print the order, too.
And a short representation as in
{{{
sage: ModularForms(chi,7)
Modular Forms space of dimension 14, character 5 |--> 1, 7 |--> -1 and
weight 7 over Rational Field
}}}
or maybe with () around it. Or we could leave it there as
values_on_gens().
> I'm not going to suggest a change, since I actually like how Dirichlet
characters are currently printed.
... this is of course a valid poitn of taste about which I won't argue
about at all.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8133#comment:7>
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 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.
