The fuzzy zero bound for polyhedra over RDF is 10^-6 (not: 10^-10) which
matches the cdd sources.
On Wednesday, July 1, 2015 at 5:50:15 PM UTC+2, Dima Pasechnik wrote:
>
>
>
> On Wednesday, 1 July 2015 14:59:20 UTC+1, Volker Braun wrote:
>>
>> cdd does not correctly handle floating point precision issues. It works
>> for non-degenerate input, for everything else there are no guarantees.
>>
>
> the input in question is randomly generated...
>
> Is there any rationale for _is_zero() for cdd to me 10^{-10} ?
>
>
>>
>>
>>
>> On Wednesday, July 1, 2015 at 12:27:09 PM UTC+2, Dima Pasechnik wrote:
>>>
>>> While working on http://trac.sagemath.org/ticket/10276, we had trouble
>>> running Polyhedron with RDF precision.
>>> An explicit example showing the issue is in
>>> http://trac.sagemath.org/raw-attachment/ticket/10276/x.sage
>>>
>>> What happens is that Polyhedron() finishes normally, but it creates
>>> something that looks like inconsistent data
>>> (a closer inspection reveals that one of the 136 facets of this polytope
>>> does not "contain any vertices", in the
>>> sense that the corresponding inequality is not satisfied with equality
>>> (within the meaningful precision)).
>>> At least this data is not good enough to compute the face lattice of it.
>>>
>>> Without a better knowledge of Polyhedron() code it is hard for me to
>>> decide whether this is a bug.
>>>
>>> Any comments?
>>> Thanks,
>>> Dima
>>>
>>> PS. if I use non-default 'field' backend I also get some weird error on
>>> this data, but it works fine if I use
>>> QQ as the base_ring.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"sage-support" 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-support.
For more options, visit https://groups.google.com/d/optout.
