Opened 14 months ago

Last modified 7 days ago

#22982 needs_work enhancement

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 klee)

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:

  1. Add global function fields (with complete functionality for the theory of AG codes)
  1. 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.2 is available at u/klee/22982_stable.

Now a long-term process is going on to merge the global function field machinery to Sage. This ticket will play 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 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)

urv60minutes.pdf (335.7 KB) - added by klee 13 months ago.
A short introduction to global function fields in Sage

Download all attachments as: .zip

Change History (89)

comment:1 Changed 14 months ago by klee

  • Branch set to u/klee/22982

comment:2 Changed 14 months ago by git

  • Commit set to 269da475d09e3fe53987084de2a22c662097b464

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

4bb538eImprove docstrings
2847da0Trim code and docstrings
939fda6Refine docstrings
2ee70bdMerge branch 'derivations_trac16561'
a910bfaImprove docstrings
931c72cMerge branch 'develop'
665f508Add new features and revise docstrings
b1d1efdMerge branch 'develop'
4b5d8aaRaise doctest coverage by adding lots of them
269da47Add more maps

comment:3 Changed 14 months ago by klee

  • Description modified (diff)

comment:4 Changed 14 months ago by git

  • Commit changed from 269da475d09e3fe53987084de2a22c662097b464 to 6fa87ce3b5a5f9e0cd1e57a868f3b16a0e9eaf5e

Branch pushed to git repo; I updated commit sha1. New commits:

6fa87ceRemove redundant a or an

comment:5 Changed 14 months ago by git

  • Commit changed from 6fa87ce3b5a5f9e0cd1e57a868f3b16a0e9eaf5e to 7ef1becb310eddffae5d26b95d1a9032f0df203f

Branch pushed to git repo; I updated commit sha1. New commits:

1a0414cMerge branch 'develop'
da7cb4dImprove _test_derivative test
7ef1becMerge branch 'trac16561'

comment:6 Changed 14 months ago by klee

  • Description modified (diff)

comment:7 Changed 14 months ago by klee

  • Description modified (diff)

comment:8 Changed 14 months ago by klee

  • Description modified (diff)

comment:9 Changed 14 months ago by klee

  • Description modified (diff)

comment:10 Changed 14 months ago by klee

  • Dependencies set to #22841
  • Owner changed from (none) to klee

comment:11 Changed 14 months ago by git

  • Commit changed from 7ef1becb310eddffae5d26b95d1a9032f0df203f to 1034aacce3f14206dc0668cc6e85ce4da9e0989a

Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:

b292fb2Use reverse_rows_and_columns
df8ce31Fixes in docstrings and code
0e57cc1Improve docstrings
ad9a8c4Fix a bug in include_zero_rows
1894770Relocate _hermite_form_euclidean
bf6b339Fix a bug; add an example for ZZ
464f6deFix a docstring failure
734c862Merge branch 'develop' into hermite_trac22841
268f049Compute U also by low level operations
1034aacMerge branch 'hermite_trac22841' into function_fields_trac22982

comment:12 Changed 14 months ago by git

  • Commit changed from 1034aacce3f14206dc0668cc6e85ce4da9e0989a to a5ceb84d852397d8430a22049368e1885e65f90b

Branch pushed to git repo; I updated commit sha1. New commits:

a5ceb84Merge branch 'develop' into function_fields_trac22982

comment:13 Changed 14 months ago by klee

  • Keywords global function field algebraic geometry code added

comment:14 Changed 13 months ago by git

  • Commit changed from a5ceb84d852397d8430a22049368e1885e65f90b to ae89ab2d89986c3496871992f188851e4caa78a0

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

4cd0abcMerge branch 'develop' into hermite_trac22841
a96c3beRemove reversed hermite form methods
f1c8202Set hermite form immutable consistently
9c8408fMore static typing and setting immutable
3d7fd03Fix EXAMPLE to EXAMPLES
ff0b73eImprove normalization
bc890deMerge branch 'hermite_trac22841' into function_fields_trac22982
1b4881bFix reverse hermite form code
e59bd0dMerge branch 'develop' into function_fields_trac22982
ae89ab2Fix richcmp deprecation warnings

comment:15 Changed 13 months ago by klee

  • Dependencies #22841 deleted
  • Description modified (diff)

comment:16 Changed 13 months ago by git

  • Commit changed from ae89ab2d89986c3496871992f188851e4caa78a0 to 8143ac6857cbd161575d08422e7be6b8f36a6deb

Branch pushed to git repo; I updated commit sha1. New commits:

d893d55Merge branch 'develop' into function_fields_trac22982
d12fd77Merge branch 'develop' into hermite_trac22841
dd0d065Add an example using normalization argument
7933860Merge branch 'develop' into hermite_trac22841
032ee67Merge branch 'hermite_trac22841' into function_fields_trac22982
8143ac6Fix a doctest failure

comment:17 Changed 13 months ago by git

  • Commit changed from 8143ac6857cbd161575d08422e7be6b8f36a6deb to 40af34a8bff9cb0d42cf0d008b5c71f2181c35d2

Branch pushed to git repo; I updated commit sha1. New commits:

40af34aFix a doctest that takes too long

comment:18 Changed 13 months ago by git

  • Commit changed from 40af34a8bff9cb0d42cf0d008b5c71f2181c35d2 to 5ae6dc4634455d0c1bc05c81f0e3f278e9154732

Branch pushed to git repo; I updated commit sha1. New commits:

7c1505dRemove __nonzero__ for compatibility with python3
5ae6dc4Fix blocks

Changed 13 months ago by klee

A short introduction to global function fields in Sage

comment:19 Changed 13 months ago by klee

  • Description modified (diff)

comment:20 Changed 13 months ago by klee

  • Description modified (diff)

comment:21 follow-up: Changed 13 months ago by saraedum

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 13 months ago by git

  • Commit changed from 5ae6dc4634455d0c1bc05c81f0e3f278e9154732 to 27b68b2c5f7c3ee74c7bbe707fe80e69a47c9a54

Branch pushed to git repo; I updated commit sha1. New commits:

27b68b2Fix an EXAMPLE block

comment:23 in reply to: ↑ 21 Changed 13 months ago by klee

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 13 months ago by klee

  • Status changed from new to needs_info

comment:25 Changed 13 months ago by klee

  • Status changed from needs_info to needs_work

Some docstrings are not in good style.

comment:26 Changed 13 months ago by git

  • Commit changed from 27b68b2c5f7c3ee74c7bbe707fe80e69a47c9a54 to f0a1e0e3b3534b94ffe5c8338cf75e831d6dcba4

Branch pushed to git repo; I updated commit sha1. New commits:

f0a1e0eMerge branch 'develop' into function_fields_trac22982

comment:27 follow-up: Changed 13 months ago by jsrn

  • 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 13 months ago by git

  • Commit changed from f0a1e0e3b3534b94ffe5c8338cf75e831d6dcba4 to fc92062e1d9e2b89ea1c2c32e04429b6d3804fd9

Branch pushed to git repo; I updated commit sha1. New commits:

7543316Format True, False, and None
fc92062Merge branch 'develop' into function_fields_trac22982

comment:29 Changed 12 months ago by klee

  • Description modified (diff)

comment:30 Changed 12 months ago by chapoton

There remains a call to cmp, not compatible with python3 (see patchbot report)

comment:31 in reply to: ↑ 27 ; follow-up: Changed 12 months ago by danielaugot

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 12 months ago by git

  • Commit changed from fc92062e1d9e2b89ea1c2c32e04429b6d3804fd9 to f6ef7cb382288f6a92087e67f6b3ee04ff48ddc2

Branch pushed to git repo; I updated commit sha1. New commits:

7336f26Remove cmp from ideal.py
f6ef7cbMerge branch 'develop' into function_fields_trac22982

comment:33 in reply to: ↑ 31 Changed 12 months ago by klee

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 11 months ago by git

  • Commit changed from f6ef7cb382288f6a92087e67f6b3ee04ff48ddc2 to 4aae96066f53cb211078e3e61949a987359226e1

Branch pushed to git repo; I updated commit sha1. New commits:

4aae960Remove redundant code in ideal.py

comment:35 Changed 10 months ago by git

  • Commit changed from 4aae96066f53cb211078e3e61949a987359226e1 to f6f29d411d82a7f67cff2a4e5fb2ac1f7683268b

Branch pushed to git repo; I updated commit sha1. New commits:

f6f29d4Merge branch 'develop' into function_fields_trac22982

comment:36 Changed 10 months ago by git

  • Commit changed from f6f29d411d82a7f67cff2a4e5fb2ac1f7683268b to d6b906019a63bee1f71a27f06d93dcd3eaac18de

Branch pushed to git repo; I updated commit sha1. New commits:

d6b9060Merge branch 'develop' into function_fields_trac22982

comment:37 Changed 10 months ago by klee

  • Description modified (diff)

comment:38 Changed 9 months ago by git

  • Commit changed from d6b906019a63bee1f71a27f06d93dcd3eaac18de to 8b590ab47a9a6f6c10035f57d1db50c9964e13ee

Branch pushed to git repo; I updated commit sha1. New commits:

9bf1a41Merge branch 'function_fields_trac22982' into function_fields_trac22982_dev
7b7b31fMerge branch 'function_fields_trac22982'
8b590abResolve conflicts

comment:39 Changed 9 months ago by git

  • Commit changed from 8b590ab47a9a6f6c10035f57d1db50c9964e13ee to 18bd03cffbfcac9b9794791d026ee25a329d11f2

Branch pushed to git repo; I updated commit sha1. New commits:

18bd03cMerge branch 'function_fields_trac22982' into function_fields_trac22982_dev

comment:40 Changed 9 months ago by git

  • Commit changed from 18bd03cffbfcac9b9794791d026ee25a329d11f2 to 4e252a14a5d8736d929c0354018b4068ce4f1997

Branch pushed to git repo; I updated commit sha1. New commits:

4e252a1Merge branch 'function_fields_trac22982' into function_fields_trac22982_dev

comment:41 Changed 8 months ago by git

  • Commit changed from 4e252a14a5d8736d929c0354018b4068ce4f1997 to 1a4999c218ba863a43cd5e76a6e37b990e7eabad

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

036168224170: extend vector_space method of finite fields
2d3ec2c24170: implement _call_ instead of local functions
6024257Allow morphism as subfield and add inclusion_map
cef982dMerge branch 'finite_field_vector_space_trac24170' into function_fields_trac22982_dev
e9dcfebMerge develop
6e5577bUse vector_space
f468265Improve residue_field() methods
02b6c3eMerge develop
d205018Set C and Cinv immutable
1a4999cMerge trac24170

comment:42 Changed 8 months ago by klee

  • Dependencies set to #24170,#24195

comment:43 Changed 7 months ago by git

  • Commit changed from 1a4999c218ba863a43cd5e76a6e37b990e7eabad to 015a0becb01dcbe352ad511c8768c6bbbe44fa67

Branch pushed to git repo; I updated commit sha1. New commits:

557f689Merge develop
3bc8422Change hasse to higher
0159b20Add VectorSpace to FunctionFieldIsomorphism
015a0beChange Isomorphism morphism to Isomorphism

comment:44 Changed 7 months ago by klee

  • Milestone changed from sage-feature to sage-8.2
  • Status changed from needs_work to needs_review

comment:45 Changed 7 months ago by git

  • Commit changed from 015a0becb01dcbe352ad511c8768c6bbbe44fa67 to c64bd0fdba125b2bf165ced247ce706af14b7609

Branch pushed to git repo; I updated commit sha1. New commits:

c64bd0fFix Isomorphism morphism to Isomorphism

comment:46 Changed 7 months ago by git

  • Commit changed from c64bd0fdba125b2bf165ced247ce706af14b7609 to a1d8ae919c63a825df769b2ca1feef395f89b18b

Branch pushed to git repo; I updated commit sha1. New commits:

a1d8ae9Merge develop

comment:47 Changed 7 months ago by klee

  • Dependencies #24170,#24195 deleted

comment:48 Changed 6 months ago by git

  • Commit changed from a1d8ae919c63a825df769b2ca1feef395f89b18b to 0e4c2a1a159b91b88329b08864b54feab39939d3

Branch pushed to git repo; I updated commit sha1. New commits:

8cb06e0Merge develop
0e4c2a1Fix a doctest failure

comment:49 follow-up: Changed 6 months ago by 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...

comment:50 in reply to: ↑ 49 ; follow-up: Changed 6 months ago by 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.

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 6 months ago by klee

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 6 months ago by klee

  • Status changed from needs_review to needs_work

comment:53 follow-up: Changed 6 months ago by 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.

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 6 months ago by klee

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 6 months ago by git

  • Commit changed from 0e4c2a1a159b91b88329b08864b54feab39939d3 to 3b373398ecc63a9484cdb49bc047133a491e0e94

Branch pushed to git repo; I updated commit sha1. New commits:

8250e96Merge develop
3b37339Add back proof=True to _factor method

comment:56 Changed 6 months ago by klee

  • Description modified (diff)

comment:57 Changed 6 months ago by klee

  • Description modified (diff)

comment:58 Changed 6 months ago by git

  • Commit changed from 3b373398ecc63a9484cdb49bc047133a491e0e94 to 8c797ac61409f81a73cea8ad1e0ecd7f63db760a

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

50efcbbRename ideal order element modules
8588d76Revert "Rename ideal order element modules"
ec33bf8Merge develop
3c46c03Remove orders code
52a39afRevert "Remove orders code"
b06bdecMerge branch 'function_fields_trac22982_5'
6f23de4Merge branch 'function_fields_trac22982_4'
e281202Merge branch 'function_fields_trac22982_3'
0642c14Merge branch 'function_fields_trac22982_2'
8c797acMerge branch 'function_fields_trac22982_1'

comment:59 Changed 5 months ago by klee

  • Branch u/klee/22982 deleted
  • Commit 8c797ac61409f81a73cea8ad1e0ecd7f63db760a deleted
  • Milestone changed from sage-8.2 to sage-duplicate/invalid/wontfix

comment:60 Changed 5 months ago by klee

  • Description modified (diff)

comment:61 follow-up: Changed 2 months ago by gh-BrentBaccala

Is there a current branch for this ticket? u/klee/22982 seems to have been deleted and then recreated.

comment:62 Changed 2 months ago by klee

  • Description modified (diff)

comment:63 in reply to: ↑ 61 ; follow-ups: Changed 2 months ago by 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.

comment:64 in reply to: ↑ 63 ; follow-up: Changed 2 months ago by gh-BrentBaccala

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 2 months ago by klee

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: Changed 2 months ago by 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 and 8.2.

comment:67 in reply to: ↑ 66 Changed 2 months ago by klee

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 and 8.2.

Thanks!

comment:68 in reply to: ↑ 66 ; follow-up: Changed 2 months ago by klee

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 and 8.2.

Now corrected.

comment:69 in reply to: ↑ 68 ; follow-up: Changed 2 months ago by 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))

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?

Last edited 2 months ago by gh-BrentBaccala (previous) (diff)

comment:70 in reply to: ↑ 69 ; follow-up: Changed 2 months ago by klee

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 a Curve?

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: Changed 2 months ago by 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:

  1. get the coordinates of the point under the place

We've got place_below in FFP_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

  1. compute a series expansion of a function in terms of a uniformizing variable

We got local_uniformizer in FFP_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: Changed 2 months ago by klee

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:

  1. 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 in FFP_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.

  1. compute a series expansion of a function in terms of a uniformizing variable

We got local_uniformizer in FFP_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 8 weeks ago by klee

  • Description modified (diff)

comment:74 Changed 8 weeks ago by klee

  • Description modified (diff)

comment:75 Changed 7 weeks ago by gh-BrentBaccala

  • Cc gh-BrentBaccala added

comment:76 follow-up: Changed 7 weeks ago by gh-BrentBaccala

There are some changes that I'm considering making here:

  1. some doctest failures, due mostly to packages being renamed
  1. 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: Changed 7 weeks ago by gh-BrentBaccala

Replying to klee:

Replying to gh-BrentBaccala:

  1. compute a series expansion of a function in terms of a uniformizing variable

We got local_uniformizer in FFP_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.

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 7 weeks ago by klee

Replying to gh-BrentBaccala:

There are some changes that I'm considering making here:

  1. 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.

  1. 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 7 weeks ago by klee

Replying to gh-BrentBaccala:

Replying to klee:

Replying to gh-BrentBaccala:

  1. compute a series expansion of a function in terms of a uniformizing variable

We got local_uniformizer in FFP_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.

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: Changed 4 weeks ago by gh-BrentBaccala

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: Changed 4 weeks ago by 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, and divisor_of_poles methods into superclasses. Is there a reason not to do this? It avoids some code duplication.

comment:82 follow-up: Changed 4 weeks ago by gh-BrentBaccala

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: Changed 4 weeks ago by 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.

comment:84 in reply to: ↑ 82 Changed 4 weeks ago by klee

Replying to gh-BrentBaccala:

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?

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 weeks ago by klee

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, and divisor_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 3 weeks ago by gh-BrentBaccala

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: Changed 8 days ago by 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!

comment:88 in reply to: ↑ 87 Changed 7 days ago by klee

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!

Note: See TracTickets for help on using tickets.