Repository: LMFDB/lmfdb

Issue:
Wrong q-expansions in search results 
Looking at 37.2.b.a on http://lmfdb.xyz/ModularForm/GL2/Q/holomorphic/?level=37&weight=2&search_type=List we see q-expansion `q + iq^2 + ...` but when we click through to http://lmfdb.xyz/ModularForm/GL2/Q/holomorphic/37/2/b/a/ instead it says `q+2iq^2 + ... `.


Discussion:
This seems to be data issue:
https://beta.lmfdb.org/api/mf_newforms/?label=37.2.b.a&_fields=qexp_display

On Mon, Oct 4, 2021 at 11:02 AM Alex J Best ***@***.***>
wrote:

> Looking at 37.2.b.a on
> http://lmfdb.xyz/ModularForm/GL2/Q/holomorphic/?level=37&weight=2&search_type=List
> we see q-expansion q + iq^2 + ... but when we click through to
> http://lmfdb.xyz/ModularForm/GL2/Q/holomorphic/37/2/b/a/ instead it says q+2iq^2
> + ... .
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/LMFDB/lmfdb/issues/4787>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AACO2BWRYBAGPVJ52EYKR5DUFG6ULANCNFSM5FJSS7CA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>

I'll take a look at this on Friday, I'm not sure how this could have happened and want to see if the same issue occurs elsewhere (if anyone notices any other instances of this problem, please post them here).
Any updates here, just saw this one again in the wild!
The qexp display column needs to be recomputed.  I was planning to address this at the same time as when I add the new data from Alex Cowan's computations (which has been slowed down because I first want to make some changes to the Dirichlet character database to switch over to the new char_orbits table which goes out to modulus 100,000).  I'm planning to get this done during the winter break, but it likely won't happen until mid to late January (if it is not done before the LMFDB coding sprint scheduled for Jan 21-22 I will do it then).

Can you tell me the label of the other example you found?
It was the same example, we just got confused by it again before I
remembered this issue!
Sounds good, thanks 😊

On Mon, 20 Dec 2021, 17:21 Andrew Sutherland, ***@***.***>
wrote:

> The qexp display column needs to be recomputed. I was planning to address
> this at the same time as when I add the new data from Alex Cowan's
> computations (which has been slowed down because I first want to make some
> changes to the Dirichlet character database to switch over to the new
> char_orbits table which goes out to modulus 100,000). I'm planning to get
> this done during the winter break, but it likely won't happen until mid to
> late January (if it is not done before the LMFDB coding sprint scheduled
> for Jan 21-22 I will do it then).
>
> Can you tell me the label of the other example you found?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/LMFDB/lmfdb/issues/4787#issuecomment-998075617>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAM4HVLJSXETFPFWNAOP573UR5JXVANCNFSM5FJSS7CA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>

Another example from #5092 
> https://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/?hst=List&level_type=divides&level=64&weight=4&char_order=2&search_type=List
> the q-expansion of 64.4.b.b is wrong, as can be seen when opening its page, i.e. compare
> https://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/64/4/b/b/


Resolving patch:
diff --git a/lmfdb/classical_modular_forms/web_newform.py b/lmfdb/classical_modular_forms/web_newform.py
--- a/lmfdb/classical_modular_forms/web_newform.py
+++ b/lmfdb/classical_modular_forms/web_newform.py
@@ -814,9 +814,9 @@ def order_basis(self):
             return html % ("", self._order_basis_forward(), self._nu_latex, " nodisplay", self._order_basis_inverse(), self._nu_latex)
 
     def order_gen(self):
-        if self.field_poly_root_of_unity == 4:
-            return r'\(i = \sqrt{-1}\)'
-        elif (self.hecke_ring_power_basis or self.qexp_converted) and self.field_poly_is_cyclotomic:
+        if (self.hecke_ring_power_basis or self.qexp_converted) and self.field_poly_is_cyclotomic:
+            if self.field_poly_root_of_unity == 4:
+                return r'\(i = \sqrt{-1}\)'
             return r'a primitive root of unity \(\zeta_{%s}\)' % self.field_poly_root_of_unity
         elif self.dim == 2:
             c, b, a = map(ZZ, self.field_poly)
@@ -872,10 +872,10 @@ def _PrintRing(self):
         # univariate polynomial rings don't support order,
         # we work around it by introducing a dummy variable
         """
-        if self.field_poly_root_of_unity == 4:
-            return PolynomialRing(QQ, 'i')
         m = self.hecke_ring_cyclotomic_generator
         if m is not None and m != 0:
+            if m == 4:
+                return PolynomialRing(QQ, 'i')
             return PolynomialRing(QQ, [self._zeta_print, 'dummy'], order='negdeglex')
         if self.single_generator:
             if (self.hecke_ring_power_basis or self.qexp_converted) and self.field_poly_is_cyclotomic:


Test patch: