Opened 3 years ago
Closed 7 months ago
#22982 closed enhancement (fixed)
Global function fields
Reported by: | klee | Owned by: | klee |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | algebra | Keywords: | global function field, algebraic geometry code |
Cc: | jsrn, danielaugot, gh-BrentBaccala | Merged in: | |
Authors: | Kwankyu Lee | Reviewers: | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Function fields part of Sage has long been neglected and has little significant functionality besides basic arithmetic and frameworks. This ticket improves the situation by two tasks:
- Add global function fields (with complete functionality for the theory of AG codes)
- Clean existing code (mostly revising docstrings)
A pdf for a short introduction to global function fields in Sage is attached.
Now the long-term process to merge the global function field machinery to Sage has finished. This ticket played the role of meta-ticket that tracks the multi-step process:
Step | Ticket | Comments |
0 | #24591 | Trim the existing code. Add several classes that are now just stubs. |
1 | #25435 | Add orders and ideals. |
2 | #26616 | Add places. |
3 | #27121 | Add divisors. |
4 | #27370 | Add differentials. |
5 | #27418 | Add completions. |
6 | #27558 | Last fixes and additions. |
The author was supported by Chosun University 2016 and by NRF of Korea 2017, 2018, 2019
Attachments (1)
Change History (101)
comment:1 Changed 3 years ago by
- Branch set to u/klee/22982
comment:2 Changed 3 years ago by
- Commit set to 269da475d09e3fe53987084de2a22c662097b464
comment:3 Changed 3 years ago by
- Description modified (diff)
comment:4 Changed 3 years ago by
- Commit changed from 269da475d09e3fe53987084de2a22c662097b464 to 6fa87ce3b5a5f9e0cd1e57a868f3b16a0e9eaf5e
Branch pushed to git repo; I updated commit sha1. New commits:
6fa87ce | Remove redundant a or an
|
comment:5 Changed 3 years ago by
- Commit changed from 6fa87ce3b5a5f9e0cd1e57a868f3b16a0e9eaf5e to 7ef1becb310eddffae5d26b95d1a9032f0df203f
comment:6 Changed 3 years ago by
- Description modified (diff)
comment:7 Changed 3 years ago by
- Description modified (diff)
comment:8 Changed 3 years ago by
- Description modified (diff)
comment:9 Changed 3 years ago by
- Description modified (diff)
comment:10 Changed 3 years ago by
- Dependencies set to #22841
- Owner changed from (none) to klee
comment:11 Changed 3 years ago by
- Commit changed from 7ef1becb310eddffae5d26b95d1a9032f0df203f to 1034aacce3f14206dc0668cc6e85ce4da9e0989a
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
b292fb2 | Use reverse_rows_and_columns
|
df8ce31 | Fixes in docstrings and code
|
0e57cc1 | Improve docstrings
|
ad9a8c4 | Fix a bug in include_zero_rows
|
1894770 | Relocate _hermite_form_euclidean
|
bf6b339 | Fix a bug; add an example for ZZ
|
464f6de | Fix a docstring failure
|
734c862 | Merge branch 'develop' into hermite_trac22841
|
268f049 | Compute U also by low level operations
|
1034aac | Merge branch 'hermite_trac22841' into function_fields_trac22982
|
comment:12 Changed 3 years ago by
- Commit changed from 1034aacce3f14206dc0668cc6e85ce4da9e0989a to a5ceb84d852397d8430a22049368e1885e65f90b
Branch pushed to git repo; I updated commit sha1. New commits:
a5ceb84 | Merge branch 'develop' into function_fields_trac22982
|
comment:13 Changed 3 years ago by
- Keywords global function field algebraic geometry code added
comment:14 Changed 3 years ago by
- Commit changed from a5ceb84d852397d8430a22049368e1885e65f90b to ae89ab2d89986c3496871992f188851e4caa78a0
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
4cd0abc | Merge branch 'develop' into hermite_trac22841
|
a96c3be | Remove reversed hermite form methods
|
f1c8202 | Set hermite form immutable consistently
|
9c8408f | More static typing and setting immutable
|
3d7fd03 | Fix EXAMPLE to EXAMPLES
|
ff0b73e | Improve normalization
|
bc890de | Merge branch 'hermite_trac22841' into function_fields_trac22982
|
1b4881b | Fix reverse hermite form code
|
e59bd0d | Merge branch 'develop' into function_fields_trac22982
|
ae89ab2 | Fix richcmp deprecation warnings
|
comment:15 Changed 2 years ago by
- Dependencies #22841 deleted
- Description modified (diff)
comment:16 Changed 2 years ago by
- Commit changed from ae89ab2d89986c3496871992f188851e4caa78a0 to 8143ac6857cbd161575d08422e7be6b8f36a6deb
Branch pushed to git repo; I updated commit sha1. New commits:
d893d55 | Merge branch 'develop' into function_fields_trac22982
|
d12fd77 | Merge branch 'develop' into hermite_trac22841
|
dd0d065 | Add an example using normalization argument
|
7933860 | Merge branch 'develop' into hermite_trac22841
|
032ee67 | Merge branch 'hermite_trac22841' into function_fields_trac22982
|
8143ac6 | Fix a doctest failure
|
comment:17 Changed 2 years ago by
- Commit changed from 8143ac6857cbd161575d08422e7be6b8f36a6deb to 40af34a8bff9cb0d42cf0d008b5c71f2181c35d2
Branch pushed to git repo; I updated commit sha1. New commits:
40af34a | Fix a doctest that takes too long
|
comment:18 Changed 2 years ago by
- Commit changed from 40af34a8bff9cb0d42cf0d008b5c71f2181c35d2 to 5ae6dc4634455d0c1bc05c81f0e3f278e9154732
comment:19 Changed 2 years ago by
- Description modified (diff)
comment:20 Changed 2 years ago by
- Description modified (diff)
comment:21 follow-up: ↓ 23 Changed 2 years ago by
It's great to see progress in the function field code. What are your plans for this branch? Are you in contact with the people who were working on divisors recently at Sage Days 86.5?
comment:22 Changed 2 years ago by
- Commit changed from 5ae6dc4634455d0c1bc05c81f0e3f278e9154732 to 27b68b2c5f7c3ee74c7bbe707fe80e69a47c9a54
Branch pushed to git repo; I updated commit sha1. New commits:
27b68b2 | Fix an EXAMPLE block
|
comment:23 in reply to: ↑ 21 Changed 2 years ago by
Replying to saraedum:
What are your plans for this branch?
The branch is essentially a patch bomb, and is not suitable for a regular review yet. But I see no way to split the code as it consists of several parts dependent on one another. My plan is to have people to play with it for some time, and I do bug fixes and improve documentation until there appears someone who can review the whole code. I don't know how long this procedure would take. Though I want it to be merged to Sage as soon as possible from my heart :-)
I have done this task during my sabbatical year, which is going to end soon. After that, I will not have much time but to maintain the code just not to be bitrotting.
Are you in contact with the people who were working on divisors recently at Sage Days 86.5?
No. I won't have time to cooperate with other people.
I looked at their wiki page. It seems that his(?) task in "basic arithmetic in function fields" may overlap with what I did here. I implemented fractional ideals in the classical way using hermite normal form while he uses OM representation, about which I know nothing. Practically he may use my branch as a tool/base to experiment and build his system. It seems his approach is more suitable for global function fields defined by more complicated equations. Thus it could be the case that the classical approach and the OM representation approach complement each other.
comment:24 Changed 2 years ago by
- Status changed from new to needs_info
comment:25 Changed 2 years ago by
- Status changed from needs_info to needs_work
Some docstrings are not in good style.
comment:26 Changed 2 years ago by
- Commit changed from 27b68b2c5f7c3ee74c7bbe707fe80e69a47c9a54 to f0a1e0e3b3534b94ffe5c8338cf75e831d6dcba4
Branch pushed to git repo; I updated commit sha1. New commits:
f0a1e0e | Merge branch 'develop' into function_fields_trac22982
|
comment:27 follow-up: ↓ 31 Changed 2 years ago by
- Cc jsrn danielaugot added
Great that you are working on this! This is something I also really want in Sage - I will try to play around with your implementation and provide feedback when I can.
comment:28 Changed 2 years ago by
- Commit changed from f0a1e0e3b3534b94ffe5c8338cf75e831d6dcba4 to fc92062e1d9e2b89ea1c2c32e04429b6d3804fd9
comment:29 Changed 2 years ago by
- Description modified (diff)
comment:30 Changed 2 years ago by
There remains a call to cmp, not compatible with python3 (see patchbot report)
comment:31 in reply to: ↑ 27 ; follow-up: ↓ 33 Changed 2 years ago by
Replying to jsrn:
Great that you are working on this! This is something I also really want in Sage - I will try to play around with your implementation and provide feedback when I can.
Yes this is great ! Thank you for this. I will try this and tell the news to colleagues. If it is good, it should be integrated in Sage, even if reviewing the ticket takes time.
comment:32 Changed 2 years ago by
- Commit changed from fc92062e1d9e2b89ea1c2c32e04429b6d3804fd9 to f6ef7cb382288f6a92087e67f6b3ee04ff48ddc2
comment:33 in reply to: ↑ 31 Changed 2 years ago by
Replying to danielaugot:
If it is good, it should be integrated in Sage, even if reviewing the ticket takes time.
Compared with Magma, the biggest problem is speed. I worked hard to improve this, but I guess there is still wide room for improvement, though certainly there is a limit somewhere due to Python vs C.
comment:34 Changed 2 years ago by
- Commit changed from f6ef7cb382288f6a92087e67f6b3ee04ff48ddc2 to 4aae96066f53cb211078e3e61949a987359226e1
Branch pushed to git repo; I updated commit sha1. New commits:
4aae960 | Remove redundant code in ideal.py
|
comment:35 Changed 2 years ago by
- Commit changed from 4aae96066f53cb211078e3e61949a987359226e1 to f6f29d411d82a7f67cff2a4e5fb2ac1f7683268b
Branch pushed to git repo; I updated commit sha1. New commits:
f6f29d4 | Merge branch 'develop' into function_fields_trac22982
|
comment:36 Changed 2 years ago by
- Commit changed from f6f29d411d82a7f67cff2a4e5fb2ac1f7683268b to d6b906019a63bee1f71a27f06d93dcd3eaac18de
Branch pushed to git repo; I updated commit sha1. New commits:
d6b9060 | Merge branch 'develop' into function_fields_trac22982
|
comment:37 Changed 2 years ago by
- Description modified (diff)
comment:38 Changed 2 years ago by
- Commit changed from d6b906019a63bee1f71a27f06d93dcd3eaac18de to 8b590ab47a9a6f6c10035f57d1db50c9964e13ee
comment:39 Changed 2 years ago by
- Commit changed from 8b590ab47a9a6f6c10035f57d1db50c9964e13ee to 18bd03cffbfcac9b9794791d026ee25a329d11f2
Branch pushed to git repo; I updated commit sha1. New commits:
18bd03c | Merge branch 'function_fields_trac22982' into function_fields_trac22982_dev
|
comment:40 Changed 2 years ago by
- Commit changed from 18bd03cffbfcac9b9794791d026ee25a329d11f2 to 4e252a14a5d8736d929c0354018b4068ce4f1997
Branch pushed to git repo; I updated commit sha1. New commits:
4e252a1 | Merge branch 'function_fields_trac22982' into function_fields_trac22982_dev
|
comment:41 Changed 2 years ago by
- Commit changed from 4e252a14a5d8736d929c0354018b4068ce4f1997 to 1a4999c218ba863a43cd5e76a6e37b990e7eabad
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
0361682 | 24170: extend vector_space method of finite fields
|
2d3ec2c | 24170: implement _call_ instead of local functions
|
6024257 | Allow morphism as subfield and add inclusion_map
|
cef982d | Merge branch 'finite_field_vector_space_trac24170' into function_fields_trac22982_dev
|
e9dcfeb | Merge develop
|
6e5577b | Use vector_space
|
f468265 | Improve residue_field() methods
|
02b6c3e | Merge develop
|
d205018 | Set C and Cinv immutable
|
1a4999c | Merge trac24170
|
comment:42 Changed 2 years ago by
- Dependencies set to #24170,#24195
comment:43 Changed 2 years ago by
- Commit changed from 1a4999c218ba863a43cd5e76a6e37b990e7eabad to 015a0becb01dcbe352ad511c8768c6bbbe44fa67
comment:44 Changed 2 years ago by
- Milestone changed from sage-feature to sage-8.2
- Status changed from needs_work to needs_review
comment:45 Changed 2 years ago by
- Commit changed from 015a0becb01dcbe352ad511c8768c6bbbe44fa67 to c64bd0fdba125b2bf165ced247ce706af14b7609
Branch pushed to git repo; I updated commit sha1. New commits:
c64bd0f | Fix Isomorphism morphism to Isomorphism
|
comment:46 Changed 2 years ago by
- Commit changed from c64bd0fdba125b2bf165ced247ce706af14b7609 to a1d8ae919c63a825df769b2ca1feef395f89b18b
Branch pushed to git repo; I updated commit sha1. New commits:
a1d8ae9 | Merge develop
|
comment:47 Changed 2 years ago by
- Dependencies #24170,#24195 deleted
comment:48 Changed 2 years ago by
- Commit changed from a1d8ae919c63a825df769b2ca1feef395f89b18b to 0e4c2a1a159b91b88329b08864b54feab39939d3
comment:49 follow-up: ↓ 50 Changed 2 years ago by
Perhaps it would be a good thing to quickly merge this branch to Sage, so that more people try it and we have more chances to fix and improve this part of Sage...
comment:50 in reply to: ↑ 49 ; follow-up: ↓ 51 Changed 2 years ago by
Replying to klee:
Perhaps it would be a good thing to quickly merge this branch to Sage, so that more people try it and we have more chances to fix and improve this part of Sage...
Hi Kwankyu, I really appreciate your massive effort here, but I don't think it is realistic that this patch bomb will get quickly merged. Bugs are much better fixed before being introduced into Sage. Why is it not possible to break this ticket into a number of smaller ones? Each one can then be reviewed with the proper care. Some tickets could basically contain just the class structure of some object, while complicated algorithms for a specific task could be tickets by themselves. Possibly keeping this ticket as a wontfix reference ticket, reviewers of the smaller ones can see what your aim is. You could give an overview of the set of tickets on a dedicated subpage on the wiki.
I want to help out with testing and reviewing, but I don't see any time that I could take out 2 weeks straight to review this beast...
Best, Johan
comment:51 in reply to: ↑ 50 Changed 2 years ago by
Replying to jsrn:
Replying to klee:
Perhaps it would be a good thing to quickly merge this branch to Sage, so that more people try it and we have more chances to fix and improve this part of Sage...
Hi Kwankyu, I really appreciate your massive effort here, but I don't think it is realistic that this patch bomb will get quickly merged. Bugs are much better fixed before being introduced into Sage. Why is it not possible to break this ticket into a number of smaller ones? Each one can then be reviewed with the proper care. Some tickets could basically contain just the class structure of some object, while complicated algorithms for a specific task could be tickets by themselves. Possibly keeping this ticket as a wontfix reference ticket, reviewers of the smaller ones can see what your aim is. You could give an overview of the set of tickets on a dedicated subpage on the wiki.
Thanks for the comments, Johan. You are right. That is what should happen, as no reviewer wants to swallow a patch bomb.
I really had no idea about how to spend a pleasant time splitting the big code, which seems an organic whole, into smaller chunks, even with my humble git skill.
So while having dinner, I thought about this problem. And now I think I can do something about it. It seems I have to plan carefully before making tickets.
I want to help out with testing and reviewing, but I don't see any time that I could take out 2 weeks straight to review this beast...
Let me spend some days to plan this out, so that you won't be deprived of 2 weeks straight :-)
comment:52 Changed 2 years ago by
- Status changed from needs_review to needs_work
comment:53 follow-up: ↓ 54 Changed 2 years ago by
That sounds great :-) Realistically, I won't have much time in most of January (important conference deadlines), but I hope to have some time for smaller tickets in February. You should probably expect that getting all of the functionality of this ticket into Sage will take quite a while, though.
Some tips from my experience with implementing coding theory during the "ACTIS project": expect that the review process will cause the design to change, and later tickets can be lightly or massively impacted. If you cut this ticket into, say 10 tickets, then consider not setting up all 10 tickets at once with full dependency lattice. The later tickets won't be looked at before the early ones, and each single change to an early ticket would have to propagate down, causing lots of extra work and headache.
Best, Johan
comment:54 in reply to: ↑ 53 Changed 2 years ago by
Replying to jsrn:
That sounds great :-) Realistically, I won't have much time in most of January (important conference deadlines), but I hope to have some time for smaller tickets in February. You should probably expect that getting all of the functionality of this ticket into Sage will take quite a while, though.
I don't intend to rush. Don't worry.
Some tips from my experience with implementing coding theory during the "ACTIS project": expect that the review process will cause the design to change, and later tickets can be lightly or massively impacted. If you cut this ticket into, say 10 tickets, then consider not setting up all 10 tickets at once with full dependency lattice. The later tickets won't be looked at before the early ones, and each single change to an early ticket would have to propagate down, causing lots of extra work and headache.
Right. Thanks for the tips. Let's see :-)
comment:55 Changed 23 months ago by
- Commit changed from 0e4c2a1a159b91b88329b08864b54feab39939d3 to 3b373398ecc63a9484cdb49bc047133a491e0e94
comment:56 Changed 23 months ago by
- Description modified (diff)
comment:57 Changed 23 months ago by
- Description modified (diff)
comment:58 Changed 23 months ago by
- Commit changed from 3b373398ecc63a9484cdb49bc047133a491e0e94 to 8c797ac61409f81a73cea8ad1e0ecd7f63db760a
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
50efcbb | Rename ideal order element modules
|
8588d76 | Revert "Rename ideal order element modules"
|
ec33bf8 | Merge develop
|
3c46c03 | Remove orders code
|
52a39af | Revert "Remove orders code"
|
b06bdec | Merge branch 'function_fields_trac22982_5'
|
6f23de4 | Merge branch 'function_fields_trac22982_4'
|
e281202 | Merge branch 'function_fields_trac22982_3'
|
0642c14 | Merge branch 'function_fields_trac22982_2'
|
8c797ac | Merge branch 'function_fields_trac22982_1'
|
comment:59 Changed 23 months ago by
- Branch u/klee/22982 deleted
- Commit 8c797ac61409f81a73cea8ad1e0ecd7f63db760a deleted
- Milestone changed from sage-8.2 to sage-duplicate/invalid/wontfix
comment:60 Changed 23 months ago by
- Description modified (diff)
comment:61 follow-up: ↓ 63 Changed 20 months ago by
Is there a current branch for this ticket? u/klee/22982
seems to have been deleted and then recreated.
comment:62 Changed 20 months ago by
- Description modified (diff)
comment:63 in reply to: ↑ 61 ; follow-ups: ↓ 64 ↓ 66 Changed 20 months ago by
Replying to gh-BrentBaccala:
Is there a current branch for this ticket?
u/klee/22982
seems to have been deleted and then recreated.
It was deleted as it would be broken into several small patches to facilitate easy review. The whole patch working with the latest stable Sage is available as u/klee/22982_stable
.
comment:64 in reply to: ↑ 63 ; follow-up: ↓ 65 Changed 20 months ago by
Replying to klee:
Replying to gh-BrentBaccala:
Is there a current branch for this ticket?
u/klee/22982
seems to have been deleted and then recreated.It was deleted as it would be broken into several small patches to facilitate easy review. The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.
I'd like to get the divisor basis code (the Hess algorithm) working with function fields over QQ (and QQbar), but I'll wait until this patch gets incorporated into the main branch before trying to add to it.
comment:65 in reply to: ↑ 64 Changed 20 months ago by
Replying to gh-BrentBaccala:
I'd like to get the divisor basis code (the Hess algorithm) working with function fields over QQ (and QQbar), but I'll wait until this patch gets incorporated into the main branch before trying to add to it.
That would be great. I guess that a crucial step for your aim is to compute the (finite) maximal order, and perhaps also to factor ideals in the order. After that, most of the code in this patch would just carry over. In particular, the Hess algorithm code in this patch would work over Q.
The current pace of merging this patch to Sage is very slow though. I will think about a least painful way to provide this patch so that you can base your code on this patch.
comment:66 in reply to: ↑ 63 ; follow-ups: ↓ 67 ↓ 68 Changed 19 months ago by
Replying to klee:
The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.
I suggest double-checking that. There's a lot of diffs between u/klee/22982_stable
and 8.2
.
comment:67 in reply to: ↑ 66 Changed 19 months ago by
Replying to gh-BrentBaccala:
Replying to klee:
The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.I suggest double-checking that. There's a lot of diffs between
u/klee/22982_stable
and8.2
.
Thanks!
comment:68 in reply to: ↑ 66 ; follow-up: ↓ 69 Changed 19 months ago by
Replying to gh-BrentBaccala:
Replying to klee:
The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.I suggest double-checking that. There's a lot of diffs between
u/klee/22982_stable
and8.2
.
Now corrected.
comment:69 in reply to: ↑ 68 ; follow-up: ↓ 70 Changed 19 months ago by
Replying to klee:
Now corrected.
Looks good!
Suggestion:
In the documentation for class FunctionFieldPlace
, prime
is defined as "prime ideal associated with the place". I assume this means a prime ideal of an order (as opposed to an ideal of the coordinate ring). I suggest documenting that more clearly, and perhaps checking when an instance is created if it's the right kind of ideal and throwing an exception otherwise.
I can see someone trying to do this:
sage: R.<x,y> = QQ[] sage: C = Curve(y^2-x^3-1) sage: FunctionFieldPlace(R*(x-2,y-3))
or more sensibly this:
sage: R.<x,y,z> = QQ[] sage: C = Curve((y^2-x^3-1).homogenize(z)) sage: FunctionFieldPlace(R*(x-2,y-3).homogenize(z))
Also, is there a way to construct a FunctionField
from a Curve
?
comment:70 in reply to: ↑ 69 ; follow-up: ↓ 71 Changed 19 months ago by
Replying to gh-BrentBaccala:
Replying to klee:
Now corrected.
Looks good!
Suggestion:
In the documentation for class
FunctionFieldPlace
,prime
is defined as "prime ideal associated with the place". I assume this means a prime ideal of an order (as opposed to an ideal of the coordinate ring). I suggest documenting that more clearly, and perhaps checking when an instance is created if it's the right kind of ideal and throwing an exception otherwise.I can see someone trying to do this:
sage: R.<x,y> = QQ[] sage: C = Curve(y^2-x^3-1) sage: FunctionFieldPlace(R*(x-2,y-3))
For a function field, there is no coordinate ring, and you are not supposed to use the class FunctionFieldPlace
directly, just like you use the constructor Curve
rather than a curve class.
or more sensibly this:
sage: R.<x,y,z> = QQ[] sage: C = Curve((y^2-x^3-1).homogenize(z)) sage: FunctionFieldPlace(R*(x-2,y-3).homogenize(z))Also, is there a way to construct a
FunctionField
from aCurve
?
The function field code is not yet integrated with the curve code. This is something to be done later.
comment:71 in reply to: ↑ 70 ; follow-up: ↓ 72 Changed 19 months ago by
Replying to klee:
The function field code is not yet integrated with the curve code. This is something to be done later.
Could we discuss that a bit, since that's a major use case and might affect how the code is designed?
There's two common things to do with a place on a curve that don't seem very easy with the current code:
- get the coordinates of the point under the place
We've got
place_below
inFFP_Global
, that I think should get us to a prime ideal in the coordinate ring, and from there we can get to coordinates of the point, but I don't see anything more straightforward than that
- compute a series expansion of a function in terms of a uniformizing variable
We got
local_uniformizer
inFFP_Rational
, that returns a uniformizing variable, but I don't think there's a method to do a series expansion
Also, what's the difference between a global place and a rational place?
comment:72 in reply to: ↑ 71 ; follow-up: ↓ 77 Changed 19 months ago by
Replying to gh-BrentBaccala:
Replying to klee:
The function field code is not yet integrated with the curve code. This is something to be done later.
Could we discuss that a bit, since that's a major use case and might affect how the code is designed?
There's two common things to do with a place on a curve that don't seem very easy with the current code:
- get the coordinates of the point under the place
This would be part of the code integrating a curve with its function field.
We've got
place_below
inFFP_Global
, that I think should get us to a prime ideal in the coordinate ring, and from there we can get to coordinates of the point, but I don't see anything more straightforward than that.
No. place_below
is nothing to do with the coordinate ring. A function field is an extension of a rational function field. place below
return the place of the rational function field below a place of the function field.
- compute a series expansion of a function in terms of a uniformizing variable
We got
local_uniformizer
inFFP_Rational
, that returns a uniformizing variable, but I don't think there's a method to do a series expansion
I recommend you to read the attached pdf for short introduction to the function field code. Yes, there is a method for series expansion of functions at a place.
Also, what's the difference between a global place and a rational place?
You seem to mean places of global function fields and places of rational function fields.
If you consult Stichtenoth's book Algebraic Function Fields and Codes, then you would be better prepared to understand and use the function field code of this ticket. That book also explains how curve and function field are related.
comment:73 Changed 19 months ago by
- Description modified (diff)
comment:74 Changed 19 months ago by
- Description modified (diff)
comment:75 Changed 19 months ago by
- Cc gh-BrentBaccala added
comment:76 follow-up: ↓ 78 Changed 19 months ago by
There are some changes that I'm considering making here:
- some doctest failures, due mostly to packages being renamed
- a Kash interface to implement a lot of these functions (probably selected with
implementation='kash'
)
Should I make those changes to this ticket? Change this git branch to be public? Or is there something else you'd suggest?
comment:77 in reply to: ↑ 72 ; follow-up: ↓ 79 Changed 19 months ago by
Replying to klee:
Replying to gh-BrentBaccala:
- compute a series expansion of a function in terms of a uniformizing variable
We got
local_uniformizer
inFFP_Rational
, that returns a uniformizing variable, but I don't think there's a method to do a series expansionI recommend you to read the attached pdf for short introduction to the function field code. Yes, there is a method for series expansion of functions at a place.
I read through the PDF, and I'm sorry, I don't see the method for series expansion. Could you please point it out to me?
comment:78 in reply to: ↑ 76 Changed 19 months ago by
Replying to gh-BrentBaccala:
There are some changes that I'm considering making here:
- some doctest failures, due mostly to packages being renamed
I guess you mean doctest failures in the stable branch of this ticket. The branch is provided for those who may want to try the global function field code before a full merge of the code to Sage, which would take quite some time. You should expect that it is not completely "stable", though I put some efforts to make it so.
Actual long-term merge process is going on through the child tickets as described in the ticket description. So all necessary fixes would go to the branches in the child tickets.
- a Kash interface to implement a lot of these functions (probably selected with
implementation='kash'
)
The proper parameter name for that is "algorithm" in Sage.
Should I make those changes to this ticket? Change this git branch to be public?
No. Sage development occurs incrementally. You should base your code on either the Sage develop branch or possibly a branch of other ticket. For that, you create your own ticket. It is possible that you make your branch from a branch of some child ticket of the present ticket. In that case, you have to fill the dependencies field of your ticket.
comment:79 in reply to: ↑ 77 Changed 19 months ago by
Replying to gh-BrentBaccala:
Replying to klee:
Replying to gh-BrentBaccala:
- compute a series expansion of a function in terms of a uniformizing variable
We got
local_uniformizer
inFFP_Rational
, that returns a uniformizing variable, but I don't think there's a method to do a series expansionI recommend you to read the attached pdf for short introduction to the function field code. Yes, there is a method for series expansion of functions at a place.
I read through the PDF, and I'm sorry, I don't see the method for series expansion. Could you please point it out to me?
The pdf is for a general introduction. For documentation, you should consult the Sage reference manual. Check out the "completion" method of function fields.
comment:80 follow-up: ↓ 83 Changed 18 months ago by
I've created a new ticket #25494 that (partially) implements function fields using kash
. Both prime finite fields and QQ are supported as the underlying constant field (no algebraic extensions of them, though). A lot of the methods aren't implemented, but enough are done to allow Riemann-Roch basis calculations:
sage: F.<x> = FunctionField(QQ, implementation='kash') sage: R.<Y> = F[] sage: L.<y> = F.extension(Y^2 - x^8 - 1) sage: O = L.maximal_order() sage: I = O.ideal(x, y-1) sage: P = I.place() sage: D = P.divisor() sage: D.basis_function_space() [1] sage: (4*D).basis_function_space() [1, 1/x^4*y + 1/x^4]
It actually uses Kwankyu Lee's Sage implementation of the Hess algorithm. Although kash implements the Hess algorithm, it turns out that klee's code works fine; all that kash is needed for is constructing and manipulating orders and ideals.
Since kash
is closed source, and doesn't support anything like QQbar
(a major need for my application), this code is probably only useful to verify our results. We still need a native Sage implementation.
Would you like to add a link to #25494 on this ticket's description?
comment:81 follow-up: ↓ 85 Changed 18 months ago by
comment:82 follow-up: ↓ 84 Changed 18 months ago by
Also, what is the gens
method supposed to do for ideals? Looking at the test cases in ideal.py
, it seems like it returns some kind of basis. My version just returns the generators used to create the ideal, and basis
needs to be called for an actual basis. Which is correct?
comment:83 in reply to: ↑ 80 ; follow-up: ↓ 86 Changed 18 months ago by
Replying to gh-BrentBaccala:
Would you like to add a link to #25494 on this ticket's description?
No, it should be the other way around. I mean that #25494 should contain a link to this ticket if it depends on this ticket.
comment:84 in reply to: ↑ 82 Changed 18 months ago by
Replying to gh-BrentBaccala:
Also, what is the
gens
method supposed to do for ideals? Looking at the test cases inideal.py
, it seems like it returns some kind of basis. My version just returns the generators used to create the ideal, andbasis
needs to be called for an actual basis. Which is correct?
This comment should be addressed to #25435. Also you could be more specific in your question; gens
method of what class do you mean?
comment:85 in reply to: ↑ 81 Changed 18 months ago by
Replying to gh-BrentBaccala:
Some of #25494's code should probably be merged into #22982. The commit labeled "refactor divisor methods" moves the
divisor
,divisor_of_zeros
, anddivisor_of_poles
methods into superclasses. Is there a reason not to do this? It avoids some code duplication.
As you see, this ticket is just a meta ticket. You comment should be addressed to a (not yet created) sub ticket of this ticket, merging divisor part of the code. I am still waiting for a review of the ticket #25435 dealing with orders and ideals before I create a ticket for divisors.
comment:86 in reply to: ↑ 83 Changed 18 months ago by
Replying to klee:
Replying to gh-BrentBaccala:
Would you like to add a link to #25494 on this ticket's description?
No, it should be the other way around. I mean that #25494 should contain a link to this ticket if it depends on this ticket.
#25494 does contain a link to #22982 in its "dependencies".
I suggest putting a link in this ticket (just like you have links to the sub tickets) so that people will know that we've got a version of this code that works over QQ
.
comment:87 follow-up: ↓ 88 Changed 17 months ago by
I don't think working on kash
makes sense - it's basically dead, it seems.
The last release was 10 years ago, and it's binary only!
comment:88 in reply to: ↑ 87 Changed 17 months ago by
Replying to dimpase:
I don't think working on
kash
makes sense - it's basically dead, it seems. The last release was 10 years ago, and it's binary only!
You read wrong some previous comments. This ticket is not about kash at all!
comment:89 Changed 17 months ago by
- Description modified (diff)
comment:90 Changed 14 months ago by
- Description modified (diff)
comment:91 Changed 14 months ago by
- Description modified (diff)
comment:92 Changed 14 months ago by
- Milestone changed from sage-duplicate/invalid/wontfix to sage-pending
comment:93 Changed 11 months ago by
- Description modified (diff)
comment:94 Changed 10 months ago by
- Description modified (diff)
comment:95 Changed 10 months ago by
- Description modified (diff)
comment:96 Changed 9 months ago by
- Description modified (diff)
comment:97 Changed 7 months ago by
- Description modified (diff)
- Milestone changed from sage-pending to sage-duplicate/invalid/wontfix
- Status changed from needs_work to needs_review
comment:98 Changed 7 months ago by
- Description modified (diff)
comment:99 Changed 7 months ago by
- Status changed from needs_review to positive_review
comment:100 Changed 7 months ago by
- Resolution set to fixed
- Status changed from positive_review to closed
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
Improve docstrings
Trim code and docstrings
Refine docstrings
Merge branch 'derivations_trac16561'
Improve docstrings
Merge branch 'develop'
Add new features and revise docstrings
Merge branch 'develop'
Raise doctest coverage by adding lots of them
Add more maps