Polyhedron class mistreats empty inputs

[darijgr]

sage: Polyhedron(ambient_dim=0, ieqs=[], eqns=[], base_ring=QQ)
The empty polyhedron in QQ^0

This should be a one-point polyhedron.

sage: Polyhedron(ambient_dim=2, ieqs=[], eqns=[], base_ring=QQ)
The empty polyhedron in QQ^2

This should be the whole QQ^2.

sage: Polyhedron(ambient_dim=2, vertices=[], rays=[], lines=[], base_ring=QQ)
The empty polyhedron in QQ^2

This is correct, but only because the code misunderstands the empty V-representation as no V-representation given at all.

CC: @vbraun @mkoeppe @tscrim

Component: geometry

Author: Darij Grinberg, Jonathan Kliem

Branch/Commit: c5bf041

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/17339

[vbraun]

comment:1

For the case with rays but no vertex we follow cdd in implicitly adding the origin as vertex. This is also spelled out in the docs.

[darijgr]

comment:2

There is a difference between vertices=[] and vertices=None. In the latter case, we should follow the cdd convention. In the former, we should not; this kind of exception conflicts with regular usage and forces writers of methods to special-case empty vertex sets. Currently the constructor loses the difference between [] and None at one of its first steps (the _make_listlist call); this is what I think needs to be fixed.

[vbraun]

comment:3

I don't really like to make a distinction between None and [], Python generally treats them as similar. Both are not __nonzero__. Its a bad UI to assign meaning to one over the other.

[darijgr]

comment:4

What we have right now is way worse. Say I write some code which constructs a ton of polytopes from their Vreps (e.g., I have a polygon and I construct all subpolygons from some of its vertices). A few of them have empty vertices lists. Why should they be understood differently from the rest?

[vbraun]

comment:5

The design choice is: nothing specified = empty polyhedron.

This is fine with your example, empty vertex list = empty polygon. Unless you mean a non-compact 2-d polyhedron.

I agree that there is perhaps too much DWIM but its also very convenient for interactive use. If you just specify a bunch of rays then in 99% of the cases you want a cone, not some rule thumping about missing a vertex.

How about separate Polyhedron.from_Vrep(vertices, rays, lines) and similarly from_Hrep with positional arguments and strict rules?

[darijgr]

comment:6

Very good idea about the from_Vrep and from_Hrep methods. Should the usual __init__ then dispatch to them?

[vbraun]

comment:7

Replying to @darijgr:

Should the usual __init__ then dispatch to them?

Haven't really thought about it, whatever is convenient for the implementation.

[mkoeppe]

comment:9

Even if it's not good style to distinguish between None and [], I think it is fine to distinguish between a provided keyword argument and a not-provided keyword argument.

So perhaps we should just change the default value of eqns from None to some unique value such as "not_given".

Then users who want to explicitly pass an empty list of eqns could either pass eqns=None or eqns=[].

[tscrim]

comment:11

I think Python quite often distinguishes between [] and None:

sage: list([])
[]
sage: list(None)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-1-f23beda2b661> in <module>()
----> 1 list(None)

TypeError: 'NoneType' object is not iterable

sage: for x in []:
....:     print("hi")
sage: for x in None:
....:     print("hi")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-b89ce2509dd6> in <module>()
----> 1 for x in None:
      2     print("hi")

TypeError: 'NoneType' object is not iterable

They are completely different objects in Python. Other languages behave in the same way for their list-like objects and equivalent of NULL.

I agree that it can be useful to have [] and None behave the same way, but it is not good practice to say we should not distinguish between the two. None is also faster, easier, and safer to work with than some other (essentially equally) generic input.

[kliem]

Author: ​Darij Grinberg, Jonathan Kliem

[kliem]

Changed commit from f7642d6 to f3c0bfb