[sage-devel] Methods for polyhedron are ring dependant?
Hi everyone, Currently, I am working on the ticket: http://trac.sagemath.org/ticket/18442 which implements a barycentric subdivision of a polytope. For this I use the containment check. In the tests, it works fine for a regular pentagon over AA but not over RDF. The problem can be seen with the following code: sage: P = polytopes.regular_polygon(5) sage: a_vertex = P.vertices()[0] sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), facet.interior_contains(a_vertex) True False True True True False True True True True sage: P = polytopes.regular_polygon(5, base_ring=RDF) sage: a_vertex = P.vertices()[0] sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), facet.interior_contains(a_vertex) True True True True True True True True True True (The first output is as expected: the vertex is not contained in the interior of exactly 2 facets. This is not the case in RDF) Right now, I have the following question in mind: Does it make sense to have polyhedron over RDF? By which I mean: it can not even deal with containment of faces properly. Reasonably, the user knows that and will use a different ring... But what if? I know that it is practical to have polyhedron defined over RDF for different reasons, but there is a fundamental change in the results (and pretty much any method doing computations) if the ring changes. I'm NOT asking to remove RDF as a possible ring. The reason I'm asking is that I have to use such containment check to implement the method barycentric subdivision for polyhedron, but then it breaks for polyhedron defined on RDF because of that. So there are methods that simply do not work when the ring is RDF. Maybe this analogy could explain my thoughts: If we compute the eigenvalues of a matrix defined over RDF, sage warns us that the results may go bad. It doesn't if the matrix is rational... Could such a warning be issued when working with RDF? And then put NotImplemented whenever it is known that RDF could cause trouble (and then fix it for that specific ring?). I could simply set the barycentric subdivision for polyhedron over RDF not to be implemented, but I feel this would not answer the problem raised anyway. Thanks! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Getting output of libsingular when it gives several objects
I heard from the author of the libSingular interface that multiple return values were not considered in the initial design. So I guess you need to revise Sage's libSingular interface first. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Methods for polyhedron are ring dependant?
In this particular case the problem can probably be resolved by being a bit stricter with the check in interior_contains: Instead of checking return self.polyhedron()._is_positive( self.eval(Vobj) ) one should have return self.polyhedron()._is_positive( self.eval(Vobj) ) and not self.polyhedron()._is_zero( self.eval(Vobj) ) Am Dienstag, 13. Oktober 2015 09:20:10 UTC+2 schrieb jplab: > > Hi everyone, > > Currently, I am working on the ticket: > > http://trac.sagemath.org/ticket/18442 > > which implements a barycentric subdivision of a polytope. For this I use > the containment check. In the tests, it works fine for a regular pentagon > over AA but not over RDF. The problem can be seen with the following code: > > sage: P = polytopes.regular_polygon(5) > sage: a_vertex = P.vertices()[0] > sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), > facet.interior_contains(a_vertex) > > True False > True True > True False > True True > True True > sage: P = polytopes.regular_polygon(5, base_ring=RDF) > sage: a_vertex = P.vertices()[0] > sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), > facet.interior_contains(a_vertex) > True True > True True > True True > True True > True True > > (The first output is as expected: the vertex is not contained in the > interior of exactly 2 facets. This is not the case in RDF) > > Right now, I have the following question in mind: Does it make sense to > have polyhedron over RDF? By which I mean: it can not even deal with > containment of faces properly. Reasonably, the user knows that and will use > a different ring... But what if? > > I know that it is practical to have polyhedron defined over RDF for > different reasons, but there is a fundamental change in the results (and > pretty much any method doing computations) if the ring changes. I'm NOT > asking to remove RDF as a possible ring. The reason I'm asking is that I > have to use such containment check to implement the method barycentric > subdivision for polyhedron, but then it breaks for polyhedron defined on > RDF because of that. So there are methods that simply do not work when the > ring is RDF. > > Maybe this analogy could explain my thoughts: > > If we compute the eigenvalues of a matrix defined over RDF, sage warns us > that the results may go bad. It doesn't if the matrix is rational... Could > such a warning be issued when working with RDF? And then put NotImplemented > whenever it is known that RDF could cause trouble (and then fix it for that > specific ring?). > > I could simply set the barycentric subdivision for polyhedron over RDF not > to be implemented, but I feel this would not answer the problem raised > anyway. > > Thanks! > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
On 13/10/15 06:48, Jan Keitel wrote: In this particular case the problem can probably be resolved by being a bit stricter with the check in interior_contains: Instead of checking return self.polyhedron()._is_positive( self.eval(Vobj) ) one should have return self.polyhedron()._is_positive( self.eval(Vobj) ) > and not self.polyhedron()._is_zero( self.eval(Vobj) ) This will not solve the problem! _is_positive(x) returns (x >= -1e-6)... which is exactly the same thing as _is_nonneg(x)... You will also get False positive and True negative, won't you? For example, you can be out of the polytope but get from _is_positive that you are inside. I would go for: - a warning for non exact rings (using the method .is_exact()) - using _is_positive for non exact rings Though, using intensively _is_positive or _is_nonneg might significantly slows down the code (it is one more Python function call). Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
Hi Vincent, that's actually not true, have you checked it? The code elif Vobj.is_vertex(): return (self.polyhedron()._is_positive( self.eval(Vobj) ) and not self.polyhedron()._is_zero( self.eval(Vobj) ) ) inside interior_contains in representations.py gives sage: P = polytopes.regular_polygon(5, base_ring=RDF) sage: sage: a_vertex = P.vertices()[0] sage: sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), facet.interior_contains(a_vertex) True True True False True True True False True True Whether this is the correct way to go is an entirely different question - all I'm saying is that _is_positive checks (with fuzziness) whether that the argument is non-negative, but not whether it is non-zero. Maybe that is what should be changed. Am Dienstag, 13. Oktober 2015 12:19:50 UTC+2 schrieb vdelecroix: > > On 13/10/15 06:48, Jan Keitel wrote: > > In this particular case the problem can probably be resolved by being > > a bit stricter with the check in interior_contains: > > > > Instead of checking > > > > return self.polyhedron()._is_positive( self.eval(Vobj) ) > > > > one should have > > > > return self.polyhedron()._is_positive( self.eval(Vobj) ) > > and not > > self.polyhedron()._is_zero( self.eval(Vobj) ) > > This will not solve the problem! _is_positive(x) returns (x >= -1e-6)... > which is exactly the same thing as _is_nonneg(x)... You will also get > False positive and True negative, won't you? For example, you can be out > of the polytope but get from _is_positive that you are inside. > > I would go for: > - a warning for non exact rings (using the method .is_exact()) > - using _is_positive for non exact rings > > Though, using intensively _is_positive or _is_nonneg might significantly > slows down the code (it is one more Python function call). > > Vincent > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
No need to check, the code is explicitely as I said: def _is_positive(self, x): return x >= 1e-6 Here is an example: sage: P = polytopes.regular_polygon(5, base_ring=RDF) sage: v0,v1,v2,v3,v4 = [v.vector() for v in P.vertices()] sage: v = (.5*v0 + .5*v1) - 1e-4*v2 sage: v in P False sage: v = (.5*v0 + .5*v1) - 1e-7*v2 sage: v in P True Everything is fine with base_ring=AA (and using exact vectors of course). Vincent On 13/10/15 08:30, Jan Keitel wrote: Hi Vincent, that's actually not true, have you checked it? The code elif Vobj.is_vertex(): return (self.polyhedron()._is_positive( self.eval(Vobj) ) and not self.polyhedron()._is_zero( self.eval(Vobj) ) ) inside interior_contains in representations.py gives sage: P = polytopes.regular_polygon(5, base_ring=RDF) sage: sage: a_vertex = P.vertices()[0] sage: sage: for facet in P.Hrepresentation(): print facet.contains(a_vertex), facet.interior_contains(a_vertex) True True True False True True True False True True Whether this is the correct way to go is an entirely different question - all I'm saying is that _is_positive checks (with fuzziness) whether that the argument is non-negative, but not whether it is non-zero. Maybe that is what should be changed. Am Dienstag, 13. Oktober 2015 12:19:50 UTC+2 schrieb vdelecroix: On 13/10/15 06:48, Jan Keitel wrote: In this particular case the problem can probably be resolved by being a bit stricter with the check in interior_contains: Instead of checking return self.polyhedron()._is_positive( self.eval(Vobj) ) one should have return self.polyhedron()._is_positive( self.eval(Vobj) ) > and not self.polyhedron()._is_zero( self.eval(Vobj) ) This will not solve the problem! _is_positive(x) returns (x >= -1e-6)... which is exactly the same thing as _is_nonneg(x)... You will also get False positive and True negative, won't you? For example, you can be out of the polytope but get from _is_positive that you are inside. I would go for: - a warning for non exact rings (using the method .is_exact()) - using _is_positive for non exact rings Though, using intensively _is_positive or _is_nonneg might significantly slows down the code (it is one more Python function call). Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
Hi Vincent, I don't know what you're checking, but the code in base_RDF.py says return x>=-1e-6 So no, it is not checking true positivity. Am Dienstag, 13. Oktober 2015 13:50:54 UTC+2 schrieb vdelecroix: > > No need to check, the code is explicitely as I said: > > > def _is_positive(self, x): > return x >= 1e-6 > > Here is an example: > > sage: P = polytopes.regular_polygon(5, base_ring=RDF) > sage: v0,v1,v2,v3,v4 = [v.vector() for v in P.vertices()] > > sage: v = (.5*v0 + .5*v1) - 1e-4*v2 > sage: v in P > False > > sage: v = (.5*v0 + .5*v1) - 1e-7*v2 > sage: v in P > True > > Everything is fine with base_ring=AA (and using exact vectors of course). > > Vincent > > On 13/10/15 08:30, Jan Keitel wrote: > > Hi Vincent, > > > > that's actually not true, have you checked it? > > The code > > > > elif Vobj.is_vertex(): > > return (self.polyhedron()._is_positive( self.eval(Vobj) ) > and > > not self.polyhedron()._is_zero( self.eval(Vobj) ) ) > > > > inside interior_contains in representations.py gives > > > > sage: P = polytopes.regular_polygon(5, base_ring=RDF) > > sage: sage: a_vertex = P.vertices()[0] > > sage: sage: for facet in P.Hrepresentation(): print > > facet.contains(a_vertex), facet.interior_contains(a_vertex) > > True True > > True False > > True True > > True False > > True True > > > > Whether this is the correct way to go is an entirely different question > - > > all I'm saying is that _is_positive checks (with fuzziness) whether that > > the argument is non-negative, but not whether it is non-zero. Maybe that > is > > what should be changed. > > > > Am Dienstag, 13. Oktober 2015 12:19:50 UTC+2 schrieb vdelecroix: > >> > >> On 13/10/15 06:48, Jan Keitel wrote: > >>> In this particular case the problem can probably be resolved by being > >>> a bit stricter with the check in interior_contains: > >>> > >>> Instead of checking > >>> > >>> return self.polyhedron()._is_positive( self.eval(Vobj) ) > >>> > >>> one should have > >>> > >>> return self.polyhedron()._is_positive( self.eval(Vobj) ) > >> > and not > >>> self.polyhedron()._is_zero( self.eval(Vobj) ) > >> > >> This will not solve the problem! _is_positive(x) returns (x >= > -1e-6)... > >> which is exactly the same thing as _is_nonneg(x)... You will also get > >> False positive and True negative, won't you? For example, you can be > out > >> of the polytope but get from _is_positive that you are inside. > >> > >> I would go for: > >>- a warning for non exact rings (using the method .is_exact()) > >>- using _is_positive for non exact rings > >> > >> Though, using intensively _is_positive or _is_nonneg might > significantly > >> slows down the code (it is one more Python function call). > >> > >> Vincent > >> > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Methods for polyhedron are ring dependant?
Hello, Instead of checking > > return self.polyhedron()._is_positive( self.eval(Vobj) ) > > one should have > > return self.polyhedron()._is_positive( self.eval(Vobj) ) and > not self.polyhedron()._is_zero( self.eval(Vobj) ) > As Vincent said, this would just be a different kind of wrong. I personally don't mind if you want to turn the old wrong answers into new wrong answers, but perhaps what we should do here is protect the users against a false kind of security. Indeed, anybody who actually plays with RDF matrices directly will soon notice that testing "==0" does not lead very far. What would you think of adding a warning in _is_zero, only when it returns *true* ? If we then write the function your way -- by calling _is_zero -- then we would show a warning whenever some decision is taken based on the output of _is_zero ? This way, all functions that call is_zero would show this warning (only once) on RDF, and ... well, perhaps add to it a suggestion to use an exact ring if results start looking weird ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
Hi, > I don't know what you're checking, but the code in base_RDF.py says The point (.5*v0 + .5*v1) - 1e-7*v2 is definitely not in the regular pentagon. But Sage answers that it is. If you start taking barycenters, this is the kind of things you can run into. >> On 13/10/15 08:30, Jan Keitel wrote: >>> that's actually not true, have you checked it? >>> The code What was actually not true in my initial statement? Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: nauty in Sage
FWIW I think that nauty has been discussed enough that IF we were to integrate it a bit more then it would certainly have passed the period to become standard. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: new mathematics plot jmol primitive
This could be worth a ticket? On Sunday, October 11, 2015 at 10:27:07 AM UTC-4, Lubomir Dechevsky wrote: > > Here is one suggestion for a general solution in SAGE to the problem about > generating arbitrary meshes of curves on surfaces in 3D or of curves and/or > surfaces in 3D-volume deformations (i.e., > (x=fx(u,v,w),y=fy(u,v,w),z=fz(u,v,w)), which includes also 3D-scalar fields > (i.e., t=f(x,y,z), t is a scalar, say, real). In this setting, the > necessary result is achieved in a simple way using the currently available > visualization classes parametric_plot3d and implicit_plot3d: > > > http://ask.sagemath.org/question/29836/plotting-families-depending-on-integer-parameters-of-curvilinear-coordinate-and-isolevel-lines-and-surfaces-resp-for-functional-and-parametric/ > > Comments, remarks, improvements and optimizations are very welcome! > > Regards, > > shao-linux :) > > On Tuesday, November 3, 2009 at 2:56:58 PM UTC+1, Jonathan wrote: >> >> Thanks, I'll try to get a look at it. This appears to be what I >> needed to find. No promises, as I'm pretty swamped, but now I have >> somewhere to start. >> >> Jonathan >> >> >> On Nov 3, 1:02 am, Jason Grout wrote: >> > Jonathan wrote: >> > > Jason, >> > > I think this is a great idea. As I use Sage a bit in my teaching, >> > > it would be nice to have a primitive with separate items for axes, >> > > axes' labels, axes scale (the numbers on the axes). Then buttons >> > > could be added to turn these on and off at the user request. If some >> > > things can be passed to Jmol as functions, they will render well at >> > > any zoom level. It would also be easier to use the slab function for >> > > slicing 3-D objects. >> > > That said there are some serious problems with how the notebook/ >> > > plot3D uses Jmol presently, that have little to do with whether a >> > > primitive exists or not. I'm willing to help fix them, but need to >> > > understand where in the code the html and javascript for Jmol is >> > > generated. The way it is presently done the following things are a >> > > problem: >> > >> > > 1) It does not work in Firefox on Macs. Since I never have trouble >> > > with this, I'm assuming something abnormal is being done with the >> > > javascript that controls Jmol. Again, I bet I can help with this, >> but >> > > I could not easily find where the code was generated. All I can do >> is >> > > look at a web page. >> > > 2) Since people are running into memory problems, I suggest that only >> > > a limited number of live Jmols (present default JavaVM configurations >> > > support about 8 - 10 per page) be allowed in any given notebook. I >> > > provided some example code that does not require any server >> > > intervention that does this. I could help fold this in, if I could >> > > figure out how you are generating the javascript to control Jmol. >> > > 3) Since there is room next to Jmol in the notebook, I suggest that >> > > simple instructions on what Jmol can do and how to access the pop-up >> > > be added and maybe a link to more extensive documentation (the Jmol >> > > Site?). I'm an expert with Jmol and found it difficult to do >> anything >> > > but rotate the image without significant experimentation. >> > > 4) It also might be worth loading only a static image first with a >> > > link to make live. This saves a lot of bandwidth and will decrease >> > > the time users have to wait to see their plots. >> > > 5) It would probably be a good idea to upgrade Jmol to the latest >> > > stable release 11.8. I will try slipping that into a copy of 4.2 I >> > > just downloaded. >> > >> > > These are just some thoughts. The key thing is I think I could help, >> > > but do not have time to wade through the code to figure out how >> > > everything is connected. Can someone just tell me were to look? >> > >> > Here's what I found by poking around for a bit. Everything has changed >> > since the new notebook, so someone that knows, *please* correct me if >> > I'm wrong. >> > >> > In Sage 4.2, it looks like the jmol-invoking javascript code is in: >> > >> > local/lib/python2.6/site-packages/sagenb/data/sage/js/jmol_lib.js >> > >> > That appears to be the code that actually sets up a jmol applet and >> > makes the "Get Image" link. >> > >> > That file is loaded in >> > local/lib/python2.6/site-packages/sagenb/data/sage/js/notebook_lib.js >> > >> > Jmol is initialized at the bottom of the template file: >> > >> > >> local/lib/python2.6/site-packages/sagenb/data/sage/html/notebook/head.tmpl >> > >> > The actual jmol application is in: >> > >> > local/lib/python2.6/site-packages/sagenb/data/jmol >> > >> > The jmol code gets invoked when a ".jmol" file is created by a 3d plot. >> > The notebook then comes by, sees the .jmol file, and creates the jmol >> > applet. The code that does this is in >> > local/lib/python2.6/site-packages/sagenb/notebook/cell.py
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
Hi Vincent, you were missing the crucial minus in the code: Instead of checking that x>1e-6, it is checking whether x>-1e-6. Am Dienstag, 13. Oktober 2015 15:07:04 UTC+2 schrieb vdelecroix: > > Hi, > > > I don't know what you're checking, but the code in base_RDF.py says > > The point > > (.5*v0 + .5*v1) - 1e-7*v2 > > is definitely not in the regular pentagon. But Sage answers that it is. > > If you start taking barycenters, this is the kind of things you can run > into. > > >> On 13/10/15 08:30, Jan Keitel wrote: > >>> that's actually not true, have you checked it? > >>> The code > > What was actually not true in my initial statement? > > Vincent > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
I did not miss it (but forgot it when I copied it in my e-mail). You have cancellations in approximate rings: sage: (1e60 - 1) - 1e60 0.000 sage: _.is_zero() True And you can check that this number is larger than -1e-6 if you wish. It will still be wrong. Vincent On 13/10/15 10:30, Jan Keitel wrote: Hi Vincent, you were missing the crucial minus in the code: Instead of checking that x>1e-6, it is checking whether x>-1e-6. Am Dienstag, 13. Oktober 2015 15:07:04 UTC+2 schrieb vdelecroix: Hi, > I don't know what you're checking, but the code in base_RDF.py says The point (.5*v0 + .5*v1) - 1e-7*v2 is definitely not in the regular pentagon. But Sage answers that it is. If you start taking barycenters, this is the kind of things you can run into. >> On 13/10/15 08:30, Jan Keitel wrote: >>> that's actually not true, have you checked it? >>> The code What was actually not true in my initial statement? Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
BTW the 1e-6 fuzzy zero is because that is used in cdd, the backend for RDF polyhedra. You can't really distinguish positive from non-negative in the nonexact case, so I'm fine with just providing it "as is". On Tuesday, October 13, 2015 at 3:30:24 PM UTC+2, Jan Keitel wrote: > > Hi Vincent, > > you were missing the crucial minus in the code: Instead of checking that > x>1e-6, it is checking whether x>-1e-6. > > Am Dienstag, 13. Oktober 2015 15:07:04 UTC+2 schrieb vdelecroix: >> >> Hi, >> >> > I don't know what you're checking, but the code in base_RDF.py says >> >> The point >> >> (.5*v0 + .5*v1) - 1e-7*v2 >> >> is definitely not in the regular pentagon. But Sage answers that it is. >> >> If you start taking barycenters, this is the kind of things you can run >> into. >> >> >> On 13/10/15 08:30, Jan Keitel wrote: >> >>> that's actually not true, have you checked it? >> >>> The code >> >> What was actually not true in my initial statement? >> >> Vincent >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Methods for polyhedron are ring dependant?
Hi everyone, Out of the discussion I could conclude the following: -it would be a good idea to warn the user if some results may be wrong due to the used ring. Perhaps this deserves a ticket on its own. -use is_positive for non exact ring and I suggest: -Perhaps containment should be done combinatorially in the case of an inexact ring (looking at the incidence matrix) and using the canonical ordering of vertices and facets? Would that make sense? I'm also fine with providing RDF polyhedra as they are, but for some methods I realized that it makes a difference in the way to implement them, which is good to know. In the case of barycentric subdivision it makes a huge difference in the computation time, the algorithmic method, and the truth of the results... JP -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
