#18454: New `random_cone()` function
-------------------------------------+-------------------------------------
Reporter: mjo | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.8
Component: geometry | Resolution:
Keywords: | Merged in:
Authors: Michael Orlitzky | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/mjo/ticket/18454 | 55da704f2f101cfdc25ba1c0b35f38072cb0e7f3
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by mjo):
Replying to [comment:5 novoselt]:
> Well, it would be helpful to know in what sense the cone is "random". If
it is a cone on a random set of rays, then dimension+1 is the only
sensible upper bound to me - such a cone always can be constructed.
In any dimension you can do better, up to 2*dimension -- just take the
standard basis and add negative multiples of them. The resulting come will
have 2*dimension generating rays and be equal to the entire space.
[[BR]]
> In R^2^ it may be possible to force construction of cones with more than
4 rays - given that the code can handle 4 instead of 3 for the whole
space, probably it can live with 100.
Can you really get more than four in R^2^? I haven't tried to prove it but
geometrically, once you have four and try to add one more, the fifth one
should either be contained in the cone already (obsoleting the new one),
or be above/below some other generator (obsoleting the old one).
> But if we are talking about the minimal number of extremal rays, then
for R^1,2^ maximum is the dimension and for all others we can do anything
- generate a random n-gon in a plane and lift it.
Right, so here you definitely wouldn't want to limit the number of rays to
dimension+1.
> In most cases I think you would want a strictly convex cone, so that's
exactly what you want with bonus points if primitive generators are not
necessarily in the same hyperplane. Algorithm: generate random vectors
with positive last component. There may be an extra switch to allow linear
subspaces in cones.
When I started working on this, I thought I was interested in proper
(strictly convex, nonempty interior) cones. But the stuff I'm doing
appears to generalize, and none of my test cases require this (nor do the
test cases I added in commit 1bbb2d1). But I agree it would be useful.
I'll try to add a `strictly_convex = None/True/False` parameter. Likewise
for `solid = None/True/False` if it doesn't look too hard.
--
Ticket URL: <http://trac.sagemath.org/ticket/18454#comment:6>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
