Merge `NonMixed` and `Mixed` AND separate `SecondOrder` from `FirstOrder`

[MaxvdKolk]

In addition to #7, we might collapse the Mixed and NonMixed directories if we update the template as well. The separation might not be needed.

@artofscience you had some thoughts on this?

[artofscience]

A mixed scheme with 1 variable group and 1 response group is a nonmixed scheme, thus the nonmixed scheme is a form of a mixed scheme :) So either fully remove nonmixed, or inherit from mixed

[Giannis1993]

Aight, I'll try to fully merge them. Just be aware that the resulting non-mixed schemes (e.g. MMA) will become more complicated. In addition, I remember you saying that the 1st-order and 2nd-order must be separated to avoid the if approx.so statements. I shall also separate the 1st-order from the 2nd-order approximations. Do we all agree on the following format? @MaxvdKolk @artofscience

class ApproximationFirstOrder:
    ... (the most abstract approximation class)

class ApproximationSecondOrder:
    ... (override 1st-order methods)

class MMA(ApproximationFirstOrder):
    ...

class MixedFirstOrder(ApproximationFirstOrder):
    ...

class MMASecondOrder(ApproximationSecondOrder):
    ....

class MixedSecondOrder(ApproximatioSecondOrder):
    ....

[MaxvdKolk]

I wonder if it would make sense to define an abstract base class for just the approximation?

class Approximation(ABC)
class FirstOrder(Approximation)
class SecondOrder(Approximation)

I guess this only helps if there is a set of common functions that can be placed in Approximation and unique functions between first/second order that can be specified in FirstOrder/SecondOrder. I will take a more detailed look once some of the classes are available in the code :)

[artofscience]

I wonder if it would make sense to define an abstract base class for just the approximation?

class Approximation(ABC)
class FirstOrder(Approximation)
class SecondOrder(Approximation)

I guess this only helps if there is a set of common functions that can be placed in Approximation and unique functions between first/second order that can be specified in FirstOrder/SecondOrder. I will take a more detailed look once some of the classes are available in the code :)

Yes this makes sense imo.

Imo you might want class Approximation(ABC) class TaylorApproximation(Approximation) class FirstOrder(TaylorApproximation) class SecondOrder(FirstOrder)

Considering the differences in opinions here, we should discuss this.

Just to clarify: Taylor approx gapprox = P y[x] + 0.5 P y[x]^2 + ... hot First order gapprox = P y[x] Second order gapprox = P y[x] + 0.5 P * y[x]^2

There to since we can implement many approximation by simply providing y[x], I dont see any reason to create separate MMAfirstorder and MMAsecondorder. I am still in doubt whether providing y[x] is what we want. Since the type of function is often "only" part of the full approximation. E.g. where do the asymptote updates, move limits etc come into play?

To clarify why TaylorApprox(approx) might be needed. Some approximation use other techniques to approximate a function, e.g. a fit to previous points (many variations, e.g. fit function value, sensitivities or both)

[Giannis1993]

@artofscience A relevant thing I was thinking while separating 2nd-order from 1st-order approximations: how do you combine in a mixed scheme 1st-order and 2nd-order approximations? The most obvious choice is to combine them on the basis of 2nd-order approximations, with approx.Q=0 for the 1st-order. But then you need to have an approx.Q even for 1st-order approximations.

[Giannis1993]

New structure covers that