#8987: Add support for rational polyhedral fans
----------------------------------+-----------------------------------------
Reporter: novoselt | Owner: mhampton
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.4.4
Component: geometry | Keywords:
Author: Andrey Novoseltsev | Upstream: N/A
Reviewer: Volker Braun | Merged:
Work_issues: |
----------------------------------+-----------------------------------------
Comment(by vbraun):
Replying to [comment:11 novoselt]:
> There was no sorting, rays were determined first as a set (union of ray
sets of all cones) and then converted to a tuple.
I think the integer vectors get sorted lexicographically by their entries,
and I think the rays inherit that. So the result should be deterministic
:-)
> In general, I agree, but it may potentially lead to `cone1 == cone2`
while `Fan([cone1]) != Fan([cone2])`. Are you OK with this?
I think that right now `Fan( cone_list_1 ) == Fan( cone_list_2 )` as long
as the cones are in the same order even if the order of the rays in each
cone is different. I think that would be good enough :-). If somebody by
hand specifies different orders of the rays of the fan then its only fair
to treat the fans as different.
The "mathematical" comparison of the cones is only slow if they are not
strictly convex, so I don't think that would be a big problem. Also, in
the non-strict case one could work with facet normals which might be
cached already... I'm not necessarily insisting that we do it that way,
but just throwing out some options.
2) I think the warning would be the fine, too.
3) I only want to traverse the face lattice with those methods. By "star",
I mean without quotient (in the triangulation sense, not how star is used
for fans usually). I'm open to other names :) And adjacent works in the
same way as "adjacency matrix", but I don't have a reference at hand right
now that uses that.
> I was tempted to say that
> {{{
> sage: fan(1)[i]
> }}}
> will do exactly this, but it will not since `fan(1)` purposefully
returns the list of rays, rather than one-dimensional cones... Did you
notice this convention? What do you think of it?
Oww I didn't notice that... Can we have it return the 1-cones in the same
order as the rays of the fan?
> > * `smallest_cone_containing(*Nlist)`: the smallest cone containing
all points (which can be specified by a ray index or as a N-lattice
element).
>
> Can I remove `smallest_`?
Fine by me!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8987#comment:13>
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.
