-
-
Notifications
You must be signed in to change notification settings - Fork 481
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
adding the ring of quantum-valued polynomials #38952
base: develop
Are you sure you want to change the base?
Conversation
Documentation preview for this PR (built with commit 8efd47b; changes) is ready! 🎉 |
|
||
INPUT: | ||
|
||
- ``R`` -- commutative ring |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to have q
be included as an argument, subsequently it would be a part of the ground ring. Now you can have an option like if the input is :
- Only
R
, then appendq
as currently implemented. - Both
(R, q)
, then doq = R(q)
. - Just
q
and getR = q.parent()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I would rather not allow a custom q. The ring R is not there to provide q, in my mind. I have added a sentence about that in the doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don’t expect anyone to want to specialize q
? It also feels slightly off mathematically to not have q
in the base ring, but perhaps that is just from my experience with Hecke algebras and quantum groups...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure. For my own usage, I have a base ring of coefficients, almost always QQ, and the variable q on top of that. For this algebra of quantum-valued polynomials, I can see no interest to have q a complex number. Of course, one can evaluate to polynomials and then evaluate q if one will.
j = ZZ(n2) | ||
if j < i: | ||
j, i = i, j | ||
q = self.base_ring().gen() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than getting this every time, I think it would be better to store self._q = self.base_ring().gen()
in the __init__
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new attribute "_q" is not inherited by the Bases. So I have made a method ".q" there. If you have a better way, please tell me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either have an ABC for the basis or just have both of them provide it.
Nevertheless, having a method q()
is a good idea.
This is a q-analogue of the ring of integer-valued polynomials. The elements are polynomials in x such that their evaluation at every q-integer is a polynomial in q.
📝 Checklist