to create a constant, there are now always the three functions
Opm::constant<Eval>(value);
Opm::constant<Eval>(numDeriv, value);
Opm::constant<Eval>(x, value); // with 'x' being the 'template' of the returned value
If a given call does not make sense, an exception is thrown:
- Plain floating point objects like `float`, `double` or `quad`
complain if the specified number of derivatives is not zero.
- Statically sized evaluations throw if the specified number of
derivatives of passed to the function is not equal to their static
size.
- Dynamically sized evaluations complain if the number of derivatives
cannot be determined.
The third variant of `Opm::constant()` works unconditionally. The
`Opm::variable()` helpers are modified analogously.
this creates an uninitialized "compatible" evaluation that is
compatible with its argument. For primitive floating point types and
statically-sized Evaluations, this is identical to calling the default
constructor, for dynamically sized ones, it creates an uninitialized
Evaluation object of identical size as the argument.
thanks to [at]GitPaen for the heads up.
this works by passing -1 as the template argument for the number of
derivatives. most of the code is identical, but creation of such
objects requires the number of derivatives passed to the constructor
or the copy constructor must be used.
Finally `DynamicEvaluation<Scalar>` is provided as a more expressive
alias for `Evaluation<Scalar, -1>`.
e.g., looping over the wrong range or an infinite loop. also, the
dense-AD unit test is shortend to test one specialization and the
unspecialized class.
older compilers (-> GCC < 5) seem to have trouble with inlining here
which leads to sub-optimal performance. since it is not a big problem
to also generate the unspecialized Evaluation class, let's do that
instead. (for hand-written code, this would be a huge
consistency/maintainance problem, though.)
