Skip to content

Yet another rearrangement

Uwe Hernandez Acosta requested to merge dev_rearrangement into refac_tests

This request is the result of the rearrangement we agreed on in the meeting on 28-06-2021 at CASUS in Görlitz. It contains major changes and gives the minterpy package a more clean structure.

We now use mp as an abbreviation for minterpy as a module.

  1. Now we have mp.core, where all data structures (aka. ABCs) and the related general functionalities (MultiIndexSet, Grid, MultiIndexTree) are stored.

    • RENAMING: There is one major change here in the renaming: MultiIndex to MultiIndexSet. The reason was confusion with imports of submodules.
    • RENAMING: The former minterpy/multi_index_utils.py is renamed to minterpy/core/utils.py and is exposed as mp.core.utils.
    • RENAMING: The former minterpy/multi_index_tree.py is renamed to minterpy/core/tree.py and is exposed as mp.core.tree.
    • Anything in minterpy.core shall be self-contained, i.e. shall not have any dependency to other modules outside mp.core (and the install requirements, e.g. numpy). However, currently, this is not entirely fulfilled (see #34).
    • All other modules of minterpy are based on mp.core.
    • From this module, the data types MultiIndexSet and Grid are exposed to the top level of mp.core as well as mp itself.
    • All abstract base classes are now stored in mp.core.ABC, where the ABCs are exposed to the level of the submodule (i.e. minterpy.core.ABC), but not higher.
    • The submodule mp.core should be as immutable as possible.
  2. The concrete implementations of polynomials bases are stored in mp.polynomials.

    • This contains the shipped concrete implementations of canonical, Newton and Lagrange polynomial base, respectively.
    • The respective classes (CanonicalPolynomial, NewtonPolynomial, LagrangePolynomial) are exposed to mp.polynomials as well as to the top level of mp.
    • The submodule mp.polynomials.utils is empty for now, however, there is a refactoring needed, since in minterpy/utils.py there are some polynomial related functions, which shall be stored under mp.polynomials.utils.
  3. In mp.schemes the interpolation schemes shall be stored. However, for now it contains only the barycentric schemes (mp.schemes.barycentric) and the matrix operator scheme (mp.schemes.matrix_operator). In the future, it shall also contain the divided difference scheme (for now exposed as mp.dds), but first, #38 (closed) needs to be solved.

  4. In mp.transformations the transformations between each two of the polynomial bases (CanonicalPolynomial,NewtonPolynomial,LagrangePolynomial) completed with the Identity are stored.

    • RENAMING The former modules minterpy/transformation_<foo>.py are renamed to minterpy/transformations/<foo>.py.
    • RENAMING The former class names Transformation<Foo>To<Bar> are renamed to <Foo>To<Bar>.
    • RENAMING The former class name TransformationIdentity is renamed to Identity.
    • RENAMING The former module minterpy/transformation_meta.py is renamed to minterpy/transformations/interface.py.
    • all transformation classes as well as the interface functions get_transformation_class and get_transformation are exposed to mp.transformations as well as to the top level of mp itself.

The remaining modules on top level are mp.dds (see #38 (closed)), mp.jit_compiled_utils (which should be divided into the functional distinct parts), mp.utils (which should also be divided into the functional distinct parts), mp.global_settings and mp.version.

The major changes described above get some adjustments in the tests as well. However, there was no semantic change in there, but only renaming of the imports.

Last but not least, also the documentation got some adjustments, there the toctree structure adapted the new structure of the package. There are three warnings for imports of the old structure left in the documentation building process, which I could not resolve. However, the docs seem to be built correctly.

Merge request reports

Loading