Implement Polynomial Traits for Polynomial struct

[dawnandrew100]

The Polynomial struct needs to have polynomial traits implemented. This will allow it to be used in functions that have the generic <P> parameter like bisection for example:

pub fn bisection<P>(
    polynomial: &P,
    bounds: Bounds,
    error_tol: f64,
    itermax: usize,
    mode: SolveMode,
) -> Result<f64, SolverError>
where
    P: PolynomialTraits,

[dawnandrew100]

This is the current iteration of the PolynomialTraits trait

pub trait PolynomialTraits {
    fn parse(input: &str) -> Result<Self, PolynomialError>
    where
        Self: std::marker::Sized;
    fn eval_univariate<F>(&self, point: F) -> Result<f64, PolynomialError>
    where
        F: Into<f64> + std::clone::Clone + std::fmt::Debug;
    fn eval_multivariate<V, S, F>(&self, vars: &V) -> Result<f64, PolynomialError>
    where
        V: IntoIterator<Item = (S, F)> + std::fmt::Debug + Clone,
        S: AsRef<str>,
        F: Into<f64>;
    fn derivate_univariate(&self) -> Result<Self, PolynomialError>
    where
        Self: std::marker::Sized;
    fn derivate_multivariate<S>(&self, var: S) -> Self
    where
        S: AsRef<str>;
    fn indefinite_integral_univariate(&self) -> Result<Self, PolynomialError>
    where
        Self: std::marker::Sized;
    fn indefinite_integral_multivariate<S>(&self, var: S) -> Self
    where
        S: AsRef<str>;
}

When the parse function is implemented for the Polynomial struct, there should be a step after the tokens are parsed where like terms are combined (all the x^2 terms for example). 0 multiplied by any variable should simplify to 0 (eg 0x -> 0 AND 0x^2 -> 0). Anything raised to the power of 0 should simplify to 1 (eg 4x^0 -> 4 AND x^0 -> 1). Division by 0 errors should also be present to prevent needless polynomial evaluation.

For the parse function, the following steps will have to be taken:

• Tokenize input string tok_str = lexer(input)?;
• Parse token stream result = parser(tok_str)?;
• Simplify parsed polynomial with above mentioned rules

The current lexer and parser can be found here

[shri-acha]

@dawnandrew100, I would like to work on this but I need a bit of context here. I see that SimplePolynomial is used to handle simple polynomials with incremental powers(right?), while PolynomialExtended is used to handle custom variables and coefficients, and finally PolynomialAst is supposed to provide more control over the expression?

Then it would make more sense to be implementing these functions for this struct, no?

    fn parse(..);
    fn eval_univariate(..);
    fn eval_multivariate(..);
    fn derivate_univariate(..);
    fn derivate_multivariate(..);
    fn indefinite_integral_univariate(..);

[dawnandrew100]

@shri-acha
The SimplePolynomial struct is the simpliest and fastest of the structs that can deal with positive integer exponents and any integer for a coefficient. The PolynomialExtended struct can deal with fractional/decimal exponents and coefficients and can also handle multivariate polynomials.
Both the SimplePolynomial and PolynomialExtended can only deal with addition and subtraction.
The goal of the PolynomialAst struct is to effectively deal with any polynomial given to it. There will obviously be certain cases that aren't dealt with in the beginning, but they'll hopefully be added over time.

The functions you have listed are the functions present in PolynomialTraits, so implementing PolynomialTraits ensures that all of the structs can be interchangeably used in algorithms that require a parsed polynomial.
The example I initially gave was the bisection function that accepts any struct that implements the PolynomialTraits trait as a polynomial. Because of this, both the SimplePolynomial and PolynomialExtended structs can be used in this function without needing to change the implementation of that algorithm to fit the inner workings of each struct.

I would also like to add that (probably this afternoon) I'm going to add a fn indefinite_integral_multivariate(..); function to polynomial structs, so that will have to be added to all structs that implement PolynomialTraits. I will add it to simple polynomial and polynomial extended, but whoever implements the trait for the polynomial AST can take care of all the trait implementations for that.

So, to hopefully answer your question, those functions would make sense to be implemented for this struct as those are the functions that are in the PolynomialTraits trait

[shri-acha]

Makes sense @dawnandrew100 , although the name does throw me off a little bit. Is there a way to change it's name, or if you could explain your thoughts over it.

[dawnandrew100]

@shri-acha The names are pretty flexible, but which name is confusing? And any suggestions on alternatives?

[shri-acha]

PolynomialAst seems like a lower level handler as opposed to a value that can be directly used to construct a Polynomial. I'm not sure how to name it though, potentially SimplePolynomial, Polynomial and ExtendedPolynomial could be a good fit.

This would have us renaming PolynomialExtended -> Polynomial and PolynomialAst -> ExtendedPolynomial.

This would make the naming conventions a little more consistent as we'd have a prefix to Polynomial.

[dawnandrew100]

@shri-acha That can definitely work. Would you mind opening an issue specifically for this name change and working on this?

[dawnandrew100]

And we can work on this after we finish work on #70 and #72