-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2F4
seems to be broken
#117
Comments
Well, if in doubt we could always ask @frankluebeck to check these norms in the tables -- he should have no problem running the CHEVIE Maple code, and can then tell us whether the norms work there, and what they are, so that we can cross-check. (Not sure if he will get this GitHub notification, though -- we could also email him later this week) |
@SoongNoonien did not specify how |
Yes, exactly. The errors are the same for both. |
I guess that you mean with In For the moment I would ignore this problem. The most important characters for these groups are those with numbers 1 to 21 (unipotent characters), and for those the Maple table seems fine. |
Yes, exactly. Currently those are two separate tables. Hopefully we will be able to unify them without the need for a global variable. (I can think of a generic cyclotomic which evaluates to 1 if
This is reassuring, so I didn't mess up the tables completely.
Ok, the character 1 to 21 should be fine here as well. |
Perhaps we should add a warning about this to the documentation. Perhaps add a new section "Available tables" or so which discusses a bit which tables are available (not necessarily a full list, but the commands that one can use to get the list), and which could also contain hints about issues with specific tables, like this one. |
As mentioned in #97 the norms of the
2F4
tables are broken. Specifically the computation of the norm of the characters 29, 30 and 31 fail with this error:Before rationalizing this also happened for 35 and 36 but somehow this got fixed so I think the remaining three character types should be fixable as well. Characters 32, 33 and 38 don't fail but their norm looks unequal to 1:
I don't know how this behaved in the original implementation. I tried to test this earlier today but I'm having troubles with the license for Maple. It's always the same with proprietary software... I hope I can get it to work again.
The text was updated successfully, but these errors were encountered: