Added
- Important functions to sageopt's ``__init__.py`` file.
For example, you can now call ``sageopt.standard_sig_monomials(n)`` and
``sageopt.sig_constrained_primal(....)`` without following a chain of
subpackages.
- Added a function ``local_refine_polys_from_sigs``, which performs local refinement
as though given signomial problem data actually defined polynomials. This
is to help people who only use signomials as a modeling tool for polynomial
optimization problems where decision variables must be nonnegative.
- Track the constraint functions which generate the set ``X`` in conditional SAGE
relaxations. By keeping track of these functions, we can check membership in ``X``
just be evaluating functions, rather than by solving an optimization-based
feasibility problem. This is especially useful for polynomial problems.
- Added a ``as_signomial`` function to Polynomial objects. There isn't a specific
use-case for this in sageopt's codebase, but it makes the Polynomial API closer
to the Signomial API, and that's desirable in its own right.
- Added a ``log_domain_converter`` to ``sage_polys.py``. The purpose of this new function
is to allow arguments to be passed in log-domain, but evaluated as though they
were in the original function's domain. This mimics the functionality of a user
calling ``f_sig = f.as_signomial()`` and subsequently evaluating ``f_sig(x)``,
however ``log_domain_converter`` does not require inputs to be Polynomial objects.
Changed
- Removed the local_refine implementation for polynomials; replaced
it by a generic implementation which works for polynomials and signomials
- Changed references to "X" and "logAbK" in user-facing functions to "X".
This is both out of consistency with the paper, and to reflect the fact that
the set X carries more information than just a conic representation.
Removed
- Removed the ability to call signomials in geometric format.
Remarks
- Plan to release this version as "0.3.0". This is done so that if bugs
are found in 0.2.0, we can release 0.2.x which still follows the 0.2.0 API.
The desire to have minimal support for the 0.2.0 API stems from the fact that
I have a massive collection of experiment / simulation code that I'd rather
not rewrite, and that I may have to run again before the paper is published.