Poly. degree check in `MultiIndexSet.from_degree()` is now more forgiving.
The type and value check for poly. degree parameter in the constructor MultiIndexSet.from_degree()
is now more forgiving as long as the provided value:
- is non-negative (>= 0) PS: Unlike spatial dimension which is strictly positive
- is a whole number
- can be compared (
< 0
) in anif
statement without ambiguity - can be converted to an
int
without ambiguity
This means values like 0.0
(a float but a whole number) or np.array([1])[0]
(i.e., the type numpy.int64
is not int
) are now a valid poly. degree value, while values like 0.5
(not a whole number) or np.array([1, 2, 3])
(the result of comparison < 0
can't be used in an if
statement without ambiguity) are invalid.
A valid value of poly. degree will eventually be converted to and stored as an int
in the attribute value of the resulting MultiIndexSet
instance.
This MR should resolve Issue #101 (closed).
Additional changes:
- A new verification function
verify_poly_degree()
is added to the moduleminterpy.core.verification
. The function checks for correctness of a given poly. degree and forces the verified value to be ofint
type. - A new test for the new functions in
minterpy.core.verification
is added to the test suite. - The test suite on
MultiIndexSet.from_degree
is extended to include testing the behavior of passing different types and values (both valid and invalid) for poly. degree. - The docstring of the constructor
MultiIndexSet.from_degree()
is added.
This MR is related to Issue #99 (closed). Along with MR !64 (merged) and !85 (merged), the three important parameters to define an instance of MultiIndexSet
(namely spatial dimension, poly. degree, and lp-degree) have been "normalized" in the sense that once they are stored in the instance, all of these parameters have the respective expected type (int
for spatial dimension and poly. degree, and float
for lp-degree). When working with the code base, we can keep this type convention in mind and avoid any unnecessary type checks.