DirichletGroup(1).list() returns the zero character

[fstromberg]

The Dirichlet group of modulus 1 should consist of the trivial character. Something in the .list() generator seems to be broken in this case and it returns a character which takes the value 0 instead of 1. However, note that list(D) works as expected and allegedly list(D)[0] is equal to D.list()[0].

sage: D=DirichletGroup(1)
sage: D.list()[0](1)
0
sage: list(D)[0](1)
1
sage: D.list()[0]==list(D)[0]
True

[kcrisman]

I don't get this in Sage 5.7 or Sage 5.9.beta1. What is your platform, what version of Sage are you using, etc? Can you reproduce it from a new session, or does it only happen after other definitions perhaps do something weird?

That said, this would definitely be a bug!

[fstromberg]

I actually forgot to check reproducibility. And in fact I seem to only be able to reproduce this in Sage 5.8 (compiled from source, on Fedora 17 with kernel 3.7.9-104) in my office after running (or at least initializing) some of my psage code. It works as it should on Sage 5.8 on my laptop (also from source on ubuntu 12.04 with kernel 3.2.0-39).

I guess it was just a fluke. I will recompile everything (including sage) and see if I still have the problem. Otherwise I should probably just close the ticket.

[kcrisman]

Well, I think that it's conceivable that there is a psage interaction, that's true. So let's not close this until we know the precise reason it happened.

[fstromberg]

Hmm, I was apparently a bit stressed or something yesterday. Now I can confirm the bug on all systems I tried, including Sage 4.4.4, 5.3, 5.6 and 5.8. For example, on mod.math.washington.edu with Sage 5.8 (the standard install in /usr/local/bin/) I get:

sage: DirichletGroup?(1).list()[0].values()
[0]
sage: Can someone log on to mod or boxen and see if you can confirm it?

[kcrisman]

Yes, I can confirm this on a Mac 10.7. But it gets weirder (here on boxen):

kcrisman@boxen:~$ sage
----------------------------------------------------------------------
| Sage Version 5.8, Release Date: 2013-03-15                         |
| Type "notebook()" for the browser-based notebook interface.        |
| Type "help()" for help.                                            |
----------------------------------------------------------------------
sage: DirichletGroup(1).list()[0](1)
1
sage: DirichletGroup(1).list()[0].values()
[1]
sage: 
Exiting Sage (CPU time 0m0.20s, Wall time 0m7.94s).
kcrisman@boxen:~$ sage
----------------------------------------------------------------------
| Sage Version 5.8, Release Date: 2013-03-15                         |
| Type "notebook()" for the browser-based notebook interface.        |
| Type "help()" for help.                                            |
----------------------------------------------------------------------
sage: DirichletGroup(1).list()[0].values()
[0]
sage: DirichletGroup(1).list()[0](1)      
0

There is something wrong with caching, perhaps. One order causes the problem, the other doesn't.

[nasqret]

The new file patch1d.patch should fix the problem with wrong character when using DirichletGroup?(1) command.

[davidloeffler]

The patch needs to include a doctest to show that it's fixed, to prevent the bug occurring again.

[jdemeyer]

The patch should be rebased to sage-5.12.beta1 such that it applies without fuzz:

applying patch1d.patch
patching file sage/modular/dirichlet.py
Hunk #1 succeeded at 301 with fuzz 2 (offset 0 lines).

[davidloeffler]

Rebased to 5.12.beta1

[davidloeffler]

I rebased the patch. The fuzz was of the most trivial possible kind (changes in the whitespace on empty lines).

Apply trac_14368-rebased.patch