polymake: Resolve clashes between global polymake user functions, polymake methods, Sage methods

[mkoeppe]

Examples for current failures:

    sage: polymake.application("tropical")
    sage: p = polymake.cartesian_product(polymake("uniform_linear_space<Max>(3,2)"),
    ....:                                polymake("uniform_linear_space<Max>(3,1)"))

Fails because cartesian_product is a Sage method already.

    sage: polymake.application("polytope")
    sage: c = polymake.cube(3)
    sage: c.save("cube3.poly")

Fails because save is a Sage method already.

    sage: polymake.application("tropical")
    sage: l = polymake("uniform_linear_space<Min>(3,2)")
    sage: l.bounding_box(1)                    

Clashes with the polymake global function of the same name.

Depends on #24905

CC: @simon-king-jena @jplab @dimpase

Component: interfaces

Keywords: days84

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

[mkoeppe]

Dependencies: #24905

[mkoeppe]

comment:2

These functions are made available in #24905 .... but save is still not accessible - that's shadowed by the Sage method of the same name.

[embray]

comment:4

As the Sage-8.8 release milestone is pending, we should delete the sage-8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage-8.9).

[mkoeppe]

comment:5

Docstring of PolymakeFunctionElement::__call__:

        We consider both member functions of an element and global functions
        bound to an element::

            sage: p = polymake.rand_sphere(3, 13, seed=12)      # optional - polymake
            sage: p.get_schedule('"VERTICES"')                    # optional - polymake  # random
            sensitivity check for VertexPerm
            cdd.convex_hull.canon: POINTED, RAYS, LINEALITY_SPACE : INPUT_RAYS
            sage: p.minkowski_sum_fukuda(p).F_VECTOR            # optional - polymake
            13 33 22

Is this useful at all? This seems to cause the bounding_box clash.

[mkoeppe]

comment:6

A workaround is to use

l.get_member_function("bounding_box")(1) 

[mkoeppe]

comment:7

Replying to @mkoeppe:

        We consider both member functions of an element and global functions
        bound to an element::

Is this useful at all? This seems to cause the bounding_box clash.

Ticket to remove this: #28281

[mkoeppe]

comment:8

Moving some tickets to 9.2. This is not a promise that I will be working on them.

[mkoeppe]

comment:10

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.