Opened 17 months ago
Last modified 2 months ago
#22982 needs_work enhancement
Global function fields
Reported by:  klee  Owned by:  klee 

Priority:  major  Milestone:  sageduplicate/invalid/wontfix 
Component:  algebra  Keywords:  global function field, algebraic geometry code 
Cc:  jsrn, danielaugot, ghBrentBaccala  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)
Some notes:
 A pdf for a short introduction to global function fields in Sage is attached.
 A branch merged with Sage 8.3 is available at
u/klee/22982_stable
.
Now a longterm process is going on to merge the global function field machinery to Sage. This ticket will play the role of metaticket that tracks the multistep 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  Add places.  
3  Add divisors.  
4  Add differentials. 
The author was supported by Chosun University 2016 and by NRF of Korea 2017, 2018
Attachments (1)
Change History (90)
comment:1 Changed 17 months ago by
 Branch set to u/klee/22982
comment:2 Changed 17 months ago by
 Commit set to 269da475d09e3fe53987084de2a22c662097b464
comment:3 Changed 17 months ago by
 Description modified (diff)
comment:4 Changed 17 months 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 17 months ago by
 Commit changed from 6fa87ce3b5a5f9e0cd1e57a868f3b16a0e9eaf5e to 7ef1becb310eddffae5d26b95d1a9032f0df203f
comment:6 Changed 17 months ago by
 Description modified (diff)
comment:7 Changed 17 months ago by
 Description modified (diff)
comment:8 Changed 17 months ago by
 Description modified (diff)
comment:9 Changed 17 months ago by
 Description modified (diff)
comment:10 Changed 17 months ago by
 Dependencies set to #22841
 Owner changed from (none) to klee
comment:11 Changed 17 months 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 17 months 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 17 months ago by
 Keywords global function field algebraic geometry code added
comment:14 Changed 16 months 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 16 months ago by
 Dependencies #22841 deleted
 Description modified (diff)
comment:16 Changed 16 months 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 16 months 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 16 months ago by
 Commit changed from 40af34a8bff9cb0d42cf0d008b5c71f2181c35d2 to 5ae6dc4634455d0c1bc05c81f0e3f278e9154732
comment:19 Changed 16 months ago by
 Description modified (diff)
comment:20 Changed 16 months ago by
 Description modified (diff)
comment:21 followup: ↓ 23 Changed 16 months 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 16 months 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 16 months 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 16 months ago by
 Status changed from new to needs_info
comment:25 Changed 16 months ago by
 Status changed from needs_info to needs_work
Some docstrings are not in good style.
comment:26 Changed 16 months 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 followup: ↓ 31 Changed 16 months 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 16 months ago by
 Commit changed from f0a1e0e3b3534b94ffe5c8338cf75e831d6dcba4 to fc92062e1d9e2b89ea1c2c32e04429b6d3804fd9
comment:29 Changed 15 months ago by
 Description modified (diff)
comment:30 Changed 15 months ago by
There remains a call to cmp, not compatible with python3 (see patchbot report)
comment:31 in reply to: ↑ 27 ; followup: ↓ 33 Changed 15 months 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 15 months ago by
 Commit changed from fc92062e1d9e2b89ea1c2c32e04429b6d3804fd9 to f6ef7cb382288f6a92087e67f6b3ee04ff48ddc2
comment:33 in reply to: ↑ 31 Changed 15 months 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 14 months 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 14 months 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 13 months 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 13 months ago by
 Description modified (diff)
comment:38 Changed 12 months ago by
 Commit changed from d6b906019a63bee1f71a27f06d93dcd3eaac18de to 8b590ab47a9a6f6c10035f57d1db50c9964e13ee
comment:39 Changed 12 months 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 12 months 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 11 months 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 11 months ago by
 Dependencies set to #24170,#24195
comment:43 Changed 10 months ago by
 Commit changed from 1a4999c218ba863a43cd5e76a6e37b990e7eabad to 015a0becb01dcbe352ad511c8768c6bbbe44fa67
comment:44 Changed 10 months ago by
 Milestone changed from sagefeature to sage8.2
 Status changed from needs_work to needs_review
comment:45 Changed 10 months 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 10 months 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 10 months ago by
 Dependencies #24170,#24195 deleted
comment:48 Changed 10 months ago by
 Commit changed from a1d8ae919c63a825df769b2ca1feef395f89b18b to 0e4c2a1a159b91b88329b08864b54feab39939d3
comment:49 followup: ↓ 50 Changed 10 months 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 ; followup: ↓ 51 Changed 10 months 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 10 months 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 10 months ago by
 Status changed from needs_review to needs_work
comment:53 followup: ↓ 54 Changed 10 months 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 10 months 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 9 months ago by
 Commit changed from 0e4c2a1a159b91b88329b08864b54feab39939d3 to 3b373398ecc63a9484cdb49bc047133a491e0e94
comment:56 Changed 9 months ago by
 Description modified (diff)
comment:57 Changed 9 months ago by
 Description modified (diff)
comment:58 Changed 9 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 8 months ago by
 Branch u/klee/22982 deleted
 Commit 8c797ac61409f81a73cea8ad1e0ecd7f63db760a deleted
 Milestone changed from sage8.2 to sageduplicate/invalid/wontfix
comment:60 Changed 8 months ago by
 Description modified (diff)
comment:61 followup: ↓ 63 Changed 5 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 5 months ago by
 Description modified (diff)
comment:63 in reply to: ↑ 61 ; followups: ↓ 64 ↓ 66 Changed 5 months ago by
Replying to ghBrentBaccala:
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 ; followup: ↓ 65 Changed 5 months ago by
Replying to klee:
Replying to ghBrentBaccala:
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 5 months ago by
Replying to ghBrentBaccala:
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 ; followups: ↓ 67 ↓ 68 Changed 5 months ago by
Replying to klee:
The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.
I suggest doublechecking that. There's a lot of diffs between u/klee/22982_stable
and 8.2
.
comment:67 in reply to: ↑ 66 Changed 5 months ago by
Replying to ghBrentBaccala:
Replying to klee:
The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.I suggest doublechecking that. There's a lot of diffs between
u/klee/22982_stable
and8.2
.
Thanks!
comment:68 in reply to: ↑ 66 ; followup: ↓ 69 Changed 5 months ago by
Replying to ghBrentBaccala:
Replying to klee:
The whole patch working with the latest stable Sage is available as
u/klee/22982_stable
.I suggest doublechecking that. There's a lot of diffs between
u/klee/22982_stable
and8.2
.
Now corrected.
comment:69 in reply to: ↑ 68 ; followup: ↓ 70 Changed 5 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^2x^31) sage: FunctionFieldPlace(R*(x2,y3))
or more sensibly this:
sage: R.<x,y,z> = QQ[] sage: C = Curve((y^2x^31).homogenize(z)) sage: FunctionFieldPlace(R*(x2,y3).homogenize(z))
Also, is there a way to construct a FunctionField
from a Curve
?
comment:70 in reply to: ↑ 69 ; followup: ↓ 71 Changed 5 months ago by
Replying to ghBrentBaccala:
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^2x^31) sage: FunctionFieldPlace(R*(x2,y3))
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^2x^31).homogenize(z)) sage: FunctionFieldPlace(R*(x2,y3).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 ; followup: ↓ 72 Changed 5 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 ; followup: ↓ 77 Changed 5 months ago by
Replying to ghBrentBaccala:
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 5 months ago by
 Description modified (diff)
comment:74 Changed 5 months ago by
 Description modified (diff)
comment:75 Changed 5 months ago by
 Cc ghBrentBaccala added
comment:76 followup: ↓ 78 Changed 5 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 ; followup: ↓ 79 Changed 5 months ago by
Replying to klee:
Replying to ghBrentBaccala:
 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 5 months ago by
Replying to ghBrentBaccala:
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 longterm 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 5 months ago by
Replying to ghBrentBaccala:
Replying to klee:
Replying to ghBrentBaccala:
 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 followup: ↓ 83 Changed 4 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 RiemannRoch 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, y1) 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 followup: ↓ 85 Changed 4 months ago by
comment:82 followup: ↓ 84 Changed 4 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 ; followup: ↓ 86 Changed 4 months ago by
Replying to ghBrentBaccala:
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 4 months ago by
Replying to ghBrentBaccala:
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 4 months ago by
Replying to ghBrentBaccala:
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 4 months ago by
Replying to klee:
Replying to ghBrentBaccala:
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 followup: ↓ 88 Changed 3 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 3 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 2 months ago by
 Description modified (diff)
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