2008/10/7 mhampton <[EMAIL PROTECTED]>: > > Linearly increasing the lift values does not work. I can find a > relatively small example (81 vertices in 4 dimensions) where your > patch fails. > > For higher dimensions I think using lrs is really the way to go, since > adding it has other advantages as well. When I have a little time I > will try to write an interface to use it for triangulation.
If it is faster, then go for it. But in the meantime I would like to have something that works in all cases. If as I kind of guessed, but hoped to be false, linear increments are not good because the may create planar situations in the extra dimension, then an exponential growth should work. I have yet another revised patch that does just that. After this one I promise to stop bothering you. Arnaud > I am putting the other improvements from your patch into another > merged patch. Can you review it? > > Cheers, > Marshall > >> On Oct 4, 7:59 pm, "Arnaud Bergeron" <[EMAIL PROTECTED]> wrote: >> >> > 2008/9/29 mhampton <[EMAIL PROTECTED]>: >> >> > > I thought I would explicitly point this one out because I had been >> > > reviewing #4164 (work by Arnaud Bergeron), but now I am also >> > > contributing code and I think the best scenario is to have someone >> > > else take a look. Mike Hansen has looked at polyhedra.py before, so >> > > he is a candidate if willing, but it would be great if someone else >> > > takes a look. Polyhedra.py (in sage/geometry) is still in its early >> > > stages; eventually I hope for it and other things in the geometry >> > > group to provide most of the functionality of polymake and other >> > > packages if they can't be made part of standard sage. Because the >> > > optimal design is far from clear to me, I want to encourage more >> > > eyeballs on it (I am an enthusiastic amateur when it comes to >> > > polytopes, not an expert). >> >> > > Marshall Hampton >> >> > About this patch I have an idea for an improvement that would make it >> > work 100% in all cases. I can't believe I didn't think of this >> > sooner. >> >> > The idea is that instead of adding a random value in the extra >> > dimension for the lifting we can only add an monotonically increasing >> > value. I tried this on the simple 4D example that was in doctest >> > before as well as the monster that crashed my code (and my hopes) >> > before and they both worked repeatedly (with a newly created >> > polyhedron, otherwise it just hits the cache). >> >> > I visualized the monster one (with ugly hacks) and the results looks >> > correct. I haven't manually inspected every surface produced though, >> > so there might be some errors. >> >> > So I turn to you (or anybody else that wants) for examples that could >> > break this before submitting final version no 42 to trac. >> >> > Use the attached patch (requires trac_4164_merge.patch from the trac >> > ticket) to try yourself or send me lists of vertices for polyhedron. >> >> > Arnaud >> >> > tentative_4164.patch >> > 1KViewDownload > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
tentative2_4164.patch
Description: Binary data
