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 comb
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 Vincen
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:
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
>
>
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 deformatio
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 st
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 K
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 pers
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,
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
Fal
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:
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( se
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.polyhedr
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 unsu
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 th
15 matches
Mail list logo
