#10529: dimension() and is_smooth() for algebraic subschemes of toric varieties
----------------------------------+-----------------------------------------
Reporter: vbraun | Owner: AlexGhitza
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.7
Component: algebraic geometry | Keywords:
Author: Volker Braun | Upstream: N/A
Reviewer: Andrey Novoseltsev | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Changes (by novoselt):
* status: needs_review => needs_work
Comment:
Replying to [comment:20 vbraun]:
> I think the calling quotient rings stuff is actually not used because I
later switched the maps between affine algebraic schemes to be defined by
actual polynomials instead of quotient rings.
So you want to just drop this patch? I think that the functionality you
have added is neat and useful even without relation to this ticket, just
don't want it to be dangerous ;-)
Comments on the last patch:
1. How about renaming `Jacobian` to `Jacobian_ideal`? I associate
`Jacobian` with a single determinant of a square matrix...
1. It seems to me also that it should NOT include the original
polynomials. I am having difficulties with finding a definition of the
Jacobian ideal, but at least in the case of one polynomial Singular does
not add it in this function http://www.singular.uni-
kl.de/Manual/3-0-4/sing_986.htm and its Milnor number routine takes into
account all critical points of a function and not just critical points in
the zero set http://www.singular.uni-
kl.de/Manual/latest/sing_718.htm#SEC770. Another argument against mixing
in the defining ideal is that it is easier to combine ideals than to split
one apart. So I propose to have `Jacobian_ideal` for the ideal generated
by partial derivatives or their minors and some other function or an
optional parameter for combining it with the defining ideal.
1. Wouldn't it be faster to check the rank of the Jacobian matrix rather
than to compute all maximal minors?
1. If there are obstructions to it, probably the Jacobian ideal should be
cached.
1. Can the documentation of `_best_affine_patch` be extended a little
with the explanation you gave earlier?
1. I have a number of issues with `affine_neighbourhood`
1. Its purpose is not quite clear from the name: since projective spaces
and toric varieties have "natural" affine covers, I would expect to get
one of the standard patches as an affine neighbourhood. How about changing
it to `centered_neigbourhood`?
1. I think it actually can be nice to get one of those standard ones as
well. How about `affine_neigbourhood(point)` returning a patch which
contains `point`?
1. This is, of course, close to what `_best_affine_patch` does. I think
it would be nice to expose its functionality to the user, but make it a
bit more clear that it returns a number. So I guess I propose three
functions:
* `containing_patch_index(point)` - does what is now done by
`_best_affine_patch(point)` (I think that access to the index can be
convenient e.g. if a user wants to consider the same points on several
subschemes.);
* `affine_neighbourhood(point)` - a shortcut for
`X.affine_patch(X.containing_patch_index(point))`;
* `centered_neigbourhood(point)` - does what is now done by
`affine_neigbourhood`.
1. I think that returned neighbourhoods should be affine schemes with a
determined embedding, not just the embedding morphism (I know that it is
possible to get domain/codomain from a morphism, but I think that most
people think of neighbourhoods as open subsets, plus it is more consistent
with the current `affine_patch`.)
1. I don't see any point storing `point_preimage` since it is the
origin. Plus having plain public attributes is not in the style of Sage.
1. Why do you say that it returns a local isomorphism? A neighbourhood
should be isomorphic to its image under the inclusion morphism, and I
don't think that it needs any clarification. A local isomorphism, on the
other hand, means to me that every point in the domain has a neighbourhood
which is isomorphic to its image. That is clearly a weaker statement in
general, so it seems confusing to me here.
1. For toric varieties `_best_affine_patch` can be written a bit more
efficiently (for fans with many rays it may give a considerable speed-up):
{{{
point = list(point)
zeros = set(i for i, coord in enumerate(point) if coord == 0)
for cone_idx, cone in
enumerate(self.ambient_space().fan().generating_cones()):
if zeros.issubset(cone.ambient_ray_indices()):
return cone_idx
assert False, 'The point must not have been a point of the toric variety.'
}}}
Here we work sets of zeros in the point and indices of the cone rather
than their completements, which can be much bigger. Also this isn't "the
best" patch, it is "just a patch" so I think that `containing_patch_index`
is a better name and when possible it can try to return the best option.
1. Now I see that for toric varieties `affine_neighbourhood` is not
centered. Then I think that for sure the method of projective varieties
should be renamed to `centered_neighbourhood`. Other comments still apply.
And I still don't like `point_preimage` even though now it is non-trivial.
I think that if it is exposed to users it should be a function with
documentation and have a bit more meaningful name. (`center_preimage`
comes to mind, although I am not sure if that's clear/standard.) Or,
perhaps, we still can return an honest centered neighbourhood realized as
a plain affine scheme (with an appropriate embedding map)? That actually
would be very handy, as so far I was doing such shifts manually whenever I
had to put my special points to the origin.
1. Would be nice to add a message to `NoteImplementedError` in
`is_smooth` of affine toric subschemes.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10529#comment:21>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
