Opened 7 years ago
Closed 7 years ago
#15224 closed enhancement (fixed)
Iterate over the points of a toric variety
Reported by: | vbraun | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.1 |
Component: | algebraic geometry | Keywords: | sd53 |
Cc: | novoselt | Merged in: | |
Authors: | Volker Braun | Reviewers: | Ursula Whitcher |
Report Upstream: | N/A | Work issues: | |
Branch: | u/vbraun/toric_variety_points (Commits) | Commit: | f00af8f68c632d42463835d97c9b58e33b6aaf59 |
Dependencies: | Stopgaps: |
Description (last modified by )
This ticket makes the point homset iterable. This is useful to access the set of points on a toric variety over a finite field
sage: P123 = toric_varieties.P2_123(base_ring=GF(3)) sage: list(P123.point_set()) [[0 : 0 : 1], [1 : 0 : 0], [2 : 0 : 0], [0 : 1 : 0], [0 : 1 : 1], [0 : 1 : 2], [1 : 0 : 1], [2 : 0 : 1], [1 : 1 : 0], [2 : 1 : 0], [1 : 1 : 1], [1 : 1 : 2], [2 : 1 : 1], [2 : 1 : 2]]
Change History (30)
comment:1 Changed 7 years ago by
- Branch set to u/vbraun/toric_variety_points
- Description modified (diff)
comment:2 Changed 7 years ago by
- Commit set to 230127e7b85dd552c1347d72e497f41930cd0948
comment:3 Changed 7 years ago by
- Commit changed from 230127e7b85dd552c1347d72e497f41930cd0948 to f792e1216ed79b23e7a2da7ca123979ee76e1009
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:f792e12] | separate scheme point sets for subschemes of toric varieties |
comment:4 Changed 7 years ago by
- Commit changed from f792e1216ed79b23e7a2da7ca123979ee76e1009 to 5feea0d1000f0d34fb8dfdba3f41fc183749c8b7
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:5feea0d] | points for subvarieties of toric varieties works |
comment:5 Changed 7 years ago by
- Commit changed from 5feea0d1000f0d34fb8dfdba3f41fc183749c8b7 to f33dc0bb9c0fdf6221956033e0d697fcdb59becb
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:f33dc0b] | code cleanups |
comment:6 Changed 7 years ago by
- Cc novoselt added
comment:7 Changed 7 years ago by
- Commit changed from f33dc0bb9c0fdf6221956033e0d697fcdb59becb to ddd665f8b2c3b4743745f11d6013adf62457a87d
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:ddd665f] | final code cleanups |
comment:8 Changed 7 years ago by
I successfully applied this patch.
I think you need to throw an error, or at least produce a warning message, if someone tries to create an iterator over the points in a variety with an infinite base ring.
comment:9 Changed 7 years ago by
There are infinite iterators in Sage:
sage: iter(ZZ).next() 0
use case - try to find an element that satisfies certain property, at which point you stop.
comment:10 Changed 7 years ago by
Though the iterator over the points doesn't handle the infinite case right, it'll just forever hang at creating the list of all rescalings.
comment:11 Changed 7 years ago by
- Commit changed from ddd665f8b2c3b4743745f11d6013adf62457a87d to 0dc5e0b9a5c9fb1ff3ee3a18e48acd487bfdaae5
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:0dc5e0b] | also allow iterating over points for a toric variety over an infinite ring |
comment:12 Changed 7 years ago by
There are some subtleties involving singular varieties that this code does not take into account. For example, if you take the normal fan to the standard 2-dimensional simplex (ReflexivePolytope?(2,0)), you get a quotient of the projective plane by a diagonal action of a group of order 3. When the base ring is GF(7), 2 is a 3rd root of unity and [1:2:4] generates the diagonal action, so [1:1:1] and [1:2:4] should be identified. But they are listed as different points by this iterator!
The obvious fix is to restrict to the case of nonsingular varieties; this behavior would match the existing function for counting points on a toric variety.
comment:13 Changed 7 years ago by
- Commit changed from 0dc5e0b9a5c9fb1ff3ee3a18e48acd487bfdaae5 to 88da46e2f72d4528b0620fb9f4ce0294ae22656e
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:88da46e] | also divide out relations coming from the torsion in the Chow group |
comment:14 Changed 7 years ago by
I think when you included the torsion relations, you lost the non-torsion relations? The list I get of points in the normal fan to the standard 2-dimensional simplex example now includes [1:1:1], [2:2:2], [3:3:3], etc.
comment:15 Changed 7 years ago by
- Commit changed from 88da46e2f72d4528b0620fb9f4ce0294ae22656e to e9f9710bd26adeb8ffaf7205343cbd9f78bbac0a
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:e9f9710] | forgot to divide by the free part of the Chow group if there is torsion |
comment:16 Changed 7 years ago by
Now works as advertised for toric varieties obtained from complete fans! Does this patch apply to affine fans as well? (I tried the example of a fan obtained from the first quadrant in the plane, and got an accurate list of points, though the use of colons in that setting is weird.)
We could use this to update #14891, which was only implemented for non-singular toric varieties.
comment:17 Changed 7 years ago by
Its supposed to give the correct answer for all fans. If it doesn't then its a bug.
I already incorporated it with #14891, for example X.point_set().cardinality()
will use the formula if the variety is smooth and enumerate the points otherwise.
comment:18 Changed 7 years ago by
We should add a documentation example where the fan is not complete. The blowup of a point, where the fan has two cones, one from [(1,0),(1,1)] and one from [(0,1),(1,1)] would be a nice choice: in that setting, you can see a projective line when the coordinate corresponding to (1,1) is 0.
This code throws errors when the toric variety has torus factors (that is, when the rays of the fan do not span the vector space associated with N). For example:
V = ToricVariety?(Fan([Cone([(1,0)])]))
VF = V.change_ring(GF(3))
list(VF.point_set())
yields:
ValueError?: there must be 2 coordinates! Got only 1: (0,)
This behaviour does not really surprise me. When a toric variety has torus factors, the choice of homogeneous coordinates is non-canonical. I assume homogeneous coordinates are not implemented in Sage for such a variety.
comment:19 Changed 7 years ago by
We have the "virtual rays" of the fan to keep track of an arbitrary (but fixed) choice of coordinates on the torus factor. Its just a matter of hooking them up correctly.
Adding another example is fine with me, can do that tomorrow.
comment:20 Changed 7 years ago by
- Commit changed from e9f9710bd26adeb8ffaf7205343cbd9f78bbac0a to be92dbe2685934031ce875bc50586507d4a0f75e
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:be92dbe] | added non-compact example for the toric point_set, allow base_ring argument to ToricVariety? |
comment:21 Changed 7 years ago by
- Commit changed from be92dbe2685934031ce875bc50586507d4a0f75e to f00af8f68c632d42463835d97c9b58e33b6aaf59
Branch pushed to git repo; I updated commit sha1. New commits:
[changeset:f00af8f] | fix point counting on toric varieties with torus factors |
comment:22 Changed 7 years ago by
This works now:
sage: T2 = toric_varieties.torus(2, base_ring=GF(3)) sage: T2.point_set().list() ([1 : 1], [1 : 2], [2 : 1], [2 : 2])
comment:23 Changed 7 years ago by
Nice!
I support approving this patch.
comment:24 Changed 7 years ago by
You can press the "positive review" button and put your full name in the "Reviewer:" field if you want ;-)
comment:25 Changed 7 years ago by
- Status changed from new to needs_review
comment:26 Changed 7 years ago by
- Status changed from needs_review to positive_review
comment:27 Changed 7 years ago by
- Reviewers set to Ursula Whitcher
comment:28 Changed 7 years ago by
- Milestone changed from sage-5.13 to sage-6.0
comment:29 Changed 7 years ago by
- Milestone changed from sage-6.0 to sage-6.1
comment:30 Changed 7 years ago by
- Resolution set to fixed
- Status changed from positive_review to closed
Branch pushed to git repo; I updated commit sha1. New commits: