carl
24.04
Computer ARithmetic Library
|
The classes used to build polynomials are (almost) fully compatible with respect to the following operators, that means that any two objects of these types can be combined if there is a directed path between them within the class hierarchy. The exception are shown and explained below. All the operators have the usual meaning.
operator==(lhs, rhs)
operator!=(lhs, rhs)
operator<(lhs, rhs)
operator<=(lhs, rhs)
operator>(lhs, rhs)
operator>=(lhs, rhs)
operator+(lhs, rhs)
operator+=(lhs, rhs)
operator-(lhs, rhs)
operator-(rhs)
operator-=(lhs, rhs)
operator*(lhs, rhs)
operator*=(lhs, rhs)
All of these operators are defined for all combination of types. We use the following ordering:
x
and y
, x < y
if the id of x
is smaller then the id of y
. The id is generated automatically by the VariablePool.a
and b
, we use a lexicographical ordering with total degree, that is a < b
ifa
is smaller than the total degree of b
, orv
in a
is greater than in b
andv
are the same in a
and in b
.a
and b
, a < b
ifa
is smaller than the monomial of b
, ora
and b
are the same and the coefficient of a
is smaller than the coefficient of b
.a
and b
, we use a lexicographical ordering, that is a < b
ifterm(a,i) < term(b,i)
andterm(a,j) = term(b,j)
for all j=0, ..., i-1
, where term(a,0)
is the leading term of a
, that is the largest term with respect to the term ordering.We now give a table for all (classes of) operators with the result type or a reason why it is not implemented for any combination of these types.
+ | C | V | M | T | MP |
---|---|---|---|---|---|
C | C | MP | MP | MP | MP |
V | MP | 1) | 1) | MP | MP |
M | MP | 1) | 1) | MP | MP |
T | MP | MP | MP | MP | MP |
MP | MP | MP | MP | MP | MP |
- | C | V | M | T | MP |
---|---|---|---|---|---|
- | C | 1) | 1) | T | MP |
* | C | V | M | T | MP |
---|---|---|---|---|---|
C | C | T | T | T | MP |
V | T | M | M | T | MP |
M | T | M | M | T | MP |
T | T | T | T | T | MP |
MP | MP | MP | MP | MP | MP |
+= | C | V | M | T | MP |
---|---|---|---|---|---|
C | C | 2) | 2) | 2) | 2) |
V | 2) | 2) | 2) | 2) | 2) |
M | 2) | 2) | 2) | 2) | 2) |
T | 2) | 2) | 2) | 2) | 2) |
MP | MP | MP | MP | MP | MP |
*= | C | V | M | T | MP |
---|---|---|---|---|---|
C | C | 3) | 3) | 3) | 3) |
V | 3) | 3) | 3) | 3) | 3) |
M | 3) | M | M | 3) | 3) |
T | T | T | T | T | 3) |
MP | MP | MP | MP | MP | MP |
We follow a few rules when implementing these operators:
operator==
and operator<
contain a real implementation. The others are implemented like this:operator!=(lhs, rhs)
: !(lhs == rhs)
operator<=(lhs, rhs)
: !(rhs < lhs)
operator>(lhs, rhs)
: rhs < lhs
operator>=(lhs, rhs)
: rhs <= lhs
operator==
, only those where lhs
is the most general type contain a real implementation. The others are implemented like this:operator==(lhs, rhs)
: rhs == lhs
operator+(Term, Term) -> MultivariatePolynomial
next to the MultivariatePolynomial, this will not work. If a friend declaration is necessary, it will be done as a forward declaration.operator(Term,Term)
operator(Term,Monomial)
operator(Term,Variable)
operator(Term,Coefficient)
operator(Monomial,Term)
operator(Variable,Term)
operator(Coefficient,Term)
There are two stages for testing these operators: a syntactical check that these operators exist and have the correct signature and a semantical check that they actually work as expected.
The syntactical check for all operators specified here is done in tests/core/Test_Operators.cpp
. We use boost::concept_check
to check the existence of the operators. There are the following concepts:
Comparison
: Checks for all comparison operators. (==
, !=
, <
, <=
, >
, >=
)Addition
: Checks for out-of-place addition operators. (+
, -
)UnaryMinus
: Checks for unary minus operators. (-
)Multiplication
: Checks for out-of-place multiplication operators. (*
)InplaceAddition
: Checks for all in-place addition operators. (+=
, -=
)InplaceMultiplication
: Checks for all in-place multiplication operators. (*=
)Semantical checking is done within the test for each class.