Opened 3 years ago
Closed 3 years ago
#27370 closed enhancement (fixed)
Global function fields: differentials
Reported by:  klee  Owned by:  

Priority:  major  Milestone:  sage8.7 
Component:  algebra  Keywords:  
Cc:  Merged in:  
Authors:  Kwankyu Lee  Reviewers:  Travis Scrimshaw 
Report Upstream:  N/A  Work issues:  
Branch:  0c1b37d (Commits, GitHub, GitLab)  Commit:  0c1b37d87a6df99b5af4048d39b69895c8e6a9f3 
Dependencies:  Stopgaps: 
Description
This is part of the metaticket #22982.
The goal of the present ticket is to add code for computing with differentials of global function fields.
Change History (20)
comment:1 Changed 3 years ago by
 Branch set to u/klee/27370
comment:2 Changed 3 years ago by
 Commit set to 3b4fcb889e5d2088caef50568fbd6cc90994c323
comment:3 Changed 3 years ago by
 Status changed from new to needs_review
comment:4 followup: ↓ 6 Changed 3 years ago by
I would move the doc from FunctionFieldDifferential_global.__init__
to the class level (FunctionFieldDifferential_global
) and instead put a test in the __init__
to do a TestSuite(foo).run()
.
I think you are better off cached _differential_space()
than differential_space()
as all of the other parts of the construction are essentially trivial and that way basis_differential_space()
also will benefit from the caching.
I am not sure that the _element_constructor_
raising an NotImplementedError
is the best behavior. It suggests that any other input should be handled. The typical thing done here is to instead raise a ValueError
.
Does the differential space have the structure of a Lie algebra, where [X, Y] = XY  YX
is also in the space?
Do you want to add a _latex_
for the differentials? Same question for ascii/unicode art.
comment:5 Changed 3 years ago by
 Commit changed from 3b4fcb889e5d2088caef50568fbd6cc90994c323 to 2d1de0f256f7e3cc0272f10fffc5a3a277794a77
Branch pushed to git repo; I updated commit sha1. New commits:
2d1de0f  Fixes for reviewer comments

comment:6 in reply to: ↑ 4 ; followup: ↓ 7 Changed 3 years ago by
Replying to tscrim:
I would move the doc from
FunctionFieldDifferential_global.__init__
to the class level (FunctionFieldDifferential_global
) and instead put a test in the__init__
to do aTestSuite(foo).run()
.
I missed that. Thanks. Done.
I think you are better off cached
_differential_space()
thandifferential_space()
as all of the other parts of the construction are essentially trivial and that waybasis_differential_space()
also will benefit from the caching.
Right. Done.
I am not sure that the
_element_constructor_
raising anNotImplementedError
is the best behavior. It suggests that any other input should be handled. The typical thing done here is to instead raise aValueError
.
Done.
Does the differential space have the structure of a Lie algebra, where
[X, Y] = XY  YX
is also in the space?
No. The space of derivations is closed under commutator operation though, but I don't know even the definition of product of differentials...
Do you want to add a
_latex_
for the differentials? Same question for ascii/unicode art.
Yes for _latex_
. Done.
comment:7 in reply to: ↑ 6 ; followup: ↓ 10 Changed 3 years ago by
Thank you.
Replying to klee:
Replying to tscrim:
Does the differential space have the structure of a Lie algebra, where
[X, Y] = XY  YX
is also in the space?No. The space of derivations is closed under commutator operation though, but I don't know even the definition of product of differentials...
Ah, right. They are not the same. Another naïve question, do the differentials d(x)
satisfy some commutation relation like in the Weyl algebra:
[dx, x] = 1 <=> dx x = x dx + 1
sage: W.<x> = algebras.DifferentialWeyl(QQ) sage: dx = W.differentials()['dx'] sage: x * dx x*dx sage: dx*x  x*dx 1
One other question: Can you say anything more about the space of differentials? Is it 1 dimensional (over its base ring)? If so, I can make the necessary implementations to get it into the correct category.
Finally, one more nitpick on output:
sage: S(1) (0) d(x)
looks strange. It would also be nice to have the special output cases as doctests to show the indent.
comment:8 followup: ↓ 11 Changed 3 years ago by
I want to clarify one thing, the Weyl algebra could possibly be a separate implementation that could be a bigger space (and a separate ticket). There is a question of would it be the more natural object or would we want to have 2 objects with a natural coercion when performing multiplication (I implemented this for Lie algebras going to their universal enveloping algebras, so I could port that over).
comment:9 Changed 3 years ago by
 Commit changed from 2d1de0f256f7e3cc0272f10fffc5a3a277794a77 to d9469d6f20f257f0535c46c90f9cdca086df9a3e
Branch pushed to git repo; I updated commit sha1. New commits:
d9469d6  Zero differential is printed as zero

comment:10 in reply to: ↑ 7 Changed 3 years ago by
do the differentials
d(x)
satisfy some commutation relation like in the Weyl algebra:[dx, x] = 1 <=> dx x = x dx + 1sage: W.<x> = algebras.DifferentialWeyl(QQ) sage: dx = W.differentials()['dx'] sage: x * dx x*dx sage: dx*x  x*dx 1
I am not familiar with Weyl algebra. But the things above would make sense if you regard dx
as derivations, usually denoted d_x
(taking derivative with respect to x).
One other question: Can you say anything more about the space of differentials? Is it 1 dimensional (over its base ring)? If so, I can make the necessary implementations to get it into the correct category.
The space of differentials is 1 dimensional over the function field F. Therefore differentials are of the form fdx with an element f and a separable element x in F.
Finally, one more nitpick on output:
sage: S(1) (0) d(x)looks strange. It would also be nice to have the special output cases as doctests to show the indent(intent ?).
Done. Now print 0
.
comment:11 in reply to: ↑ 8 Changed 3 years ago by
Replying to tscrim:
I want to clarify one thing, the Weyl algebra could possibly be a separate implementation that could be a bigger space (and a separate ticket). There is a question of would it be the more natural object or would we want to have 2 objects with a natural coercion when performing multiplication (I implemented this for Lie algebras going to their universal enveloping algebras, so I could port that over).
This is a territory, mostly unknown to me. I don't know if the space of differentials on a function field belongs to the category of Weyl algebras. I guess not. But if somehow can be related, it would be good to have natural coercion between it and the bigger Weyl algebra, of course.
comment:12 followup: ↓ 13 Changed 3 years ago by
 Branch changed from u/klee/27370 to public/algebras/global_function_fields_differentials27370
 Commit changed from d9469d6f20f257f0535c46c90f9cdca086df9a3e to 71857af5413bc2f655459799acc4ad6bdfa79695
 Reviewers set to Travis Scrimshaw
Well, I guess the definition does not straight lift since a Weyl algebra is defined over a polynomial ring. Maybe we could define it under this class of generalized Weyl algebras due to Bavula (https://arxiv.org/abs/1612.08941)? Anyways, just something to ponder and I was curious about (seeing if we could form a natural ring in an analogous way).
Here are the promised changes making it into a finitedimensional module with basis. If my changes are good, then positive review.
New commits:
f72c988  Merge branch 'u/klee/27370' of git://trac.sagemath.org/sage into public/algebras/global_function_fields_differentials27370

71857af  Making differentials know they form a finitedimensional module with basis.

comment:13 in reply to: ↑ 12 Changed 3 years ago by
Here are the promised changes making it into a finitedimensional module with basis.
Looks good to me. Just one question: Why do you have copy=False
, that is not used anywhere in monomial_coefficients
method?
comment:14 followup: ↓ 15 Changed 3 years ago by
This is part of the API of the method, for those elements that are implemented using dicts as a way to improve the speed by avoiding copying when, e.g., iterating over it.
comment:15 in reply to: ↑ 14 Changed 3 years ago by
Replying to tscrim:
This is part of the API of the method, for those elements that are implemented using dicts as a way to improve the speed by avoiding copying when, e.g., iterating over it.
I now see the intent. Then for our case, a new dictionary is returned each time. Hence the default behaviour is for copy=True
(and copy=False
is ignored). No?
comment:16 Changed 3 years ago by
 Commit changed from 71857af5413bc2f655459799acc4ad6bdfa79695 to 0c1b37d87a6df99b5af4048d39b69895c8e6a9f3
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
0c1b37d  Making differentials know they form a finitedimensional module with basis.

comment:17 followup: ↓ 18 Changed 3 years ago by
The parameter is ignored in either case, but I changed the default to copy=True
to reflect the behavior better.
comment:18 in reply to: ↑ 17 Changed 3 years ago by
 Status changed from needs_review to positive_review
Replying to tscrim:
The parameter is ignored in either case, but I changed the default to
copy=True
to reflect the behavior better.
Positive review on your addition. Thanks!
comment:19 Changed 3 years ago by
No problem. Thank you.
comment:20 Changed 3 years ago by
 Branch changed from public/algebras/global_function_fields_differentials27370 to 0c1b37d87a6df99b5af4048d39b69895c8e6a9f3
 Resolution set to fixed
 Status changed from positive_review to closed
Branch pushed to git repo; I updated commit sha1. New commits:
Add differentials