Missing deriv method

[RagibHasin]

It should be possible to deriv() a Polynomial to get its derivative.

[saona-raimundo]

Hi @RagibHasin :)

It should be fairly easy to implement, I can do a pull request for that.

I would like first to think about the trait bound on , since one would need to multiply by the power that comes out of the derivative. Would

T: std::ops::Mul<usize>,

The subtle thing I see is that the resulting coefficient will be of type <T as std::ops::Mul<usize>>::Output.

One option is to ask for an even more restricting trait bound like

T: std::ops::Mul<usize>,
<T as std::ops::Mul<usize>>::Output: Into<T>,

What do you think?

[RagibHasin]

I don't think that would be possible. As most the useful types like i32, f32, f64 etc don't implement Mul<usize>.

And also polynomials of 2D and 3D vectors should be considered.

Actually my use case involves 2D vectors, and I hard-coded the deriv function for it. But a generic solution seems to require multiple generic overloads which is not supported to my knowledge.

[saona-raimundo]

Another option would be to ask for

T: std::ops::Add<T>,
<T as std::ops::Add<T>>::Output: Into<T>,

I am thinking of replacing the multiplication by usize for summing up the corresponding number of times.
Would this work for you?

I have not thought if there would be cases where one would not obtain the expected result.

[RagibHasin]

Is there any reason you don't want to use num_traits even without std or libm?

And I think repeated addition would cause a performance penalty which is not needed.

[saona-raimundo]

I have no problem with using num_traits. Actually, I think it is a good idea. Although, I do not see how it solves our problem here.

About libm, I am all in too. But again, I do not see how it helps here.

I have noticed that in some parts of the code, there is x - x, to represent the zero. Of course, I would prefer T: Zero and call T.zero(), but there are many instances where Zero is not implemented, e.g. ndarray does not implement this trait because it only remembers number of dimensions, not the exact shape.

If you have an idea to use num_traits here, please share it :)

Lastly, about the performance, I agree. We should try to come up with the best trait bounds that are both:
(a) generic enough to cover usual cases; and
(b) fast enough.
But, at the end, working with generic will eventually mean that performance will have to be compromised a bit.
There is another option which is to transform the whole crate into (derivable) traits so that people can define their own version of polynomials and then specify implementation for their own types. But this is a major change and one would have to ask if this is the intended use of the crate to @cargodog.

Disclaimer: I am not part of the project, but I think this crate is a good idea.

[RagibHasin]

Disclaimer: I am not part of the project, but I think this crate is a good idea.

😄 I thought @cargodog is a namespace of these projects from you @rasa200.

Nevertheless, I think current situation is fine most of the time. But derivation won't work efficiently if implemented as a member function. So I think we can have a trait for derivation that is specialized for different types efficiently. You can get an example of this approach in linebender/kurbo.

[saona-raimundo]

😄 I thought @cargodog is a namespace of these projects from you @rasa200.

No worries, I hope @cargodog comes in soon.

I think the trait idea is good: it would cover the most common cases and help those who want to implement their own version.
A draft of this would be the following (feel free to correct or change all you want).

pub trait Differentiable {
    fn diff(&mut self);
}

impl Differentiable for Polynomial<f64> {
    fn diff(&mut self) {
        let lenght = self.0.len();
        for i in 0..lenght - 1 {
            self.0[i] = (i as f64) * self.0[i + 1]
        }
        self.0[lenght - 1] = 0.0;
    }
}

Something we could think about is the signature of the method diff:
Would you rather prefer fn diff(self) -> Self?

[cargodog]

I hope @cargodog comes in soon.

👋 Thanks for the interest guys! Sorry, I have been distracted for a few days and missed this thread. I am catching up now.

It should be possible to deriv() a Polynomial to get its derivative.

This is a great idea. I also agree with the idea of adding it as a trait, instead of a method. If either of you wants to throw up a PR, I will happily approve.

I have noticed that in some parts of the code, there is x - x, to represent the zero. Of course, I would prefer T: Zero and call T.zero(), but there are many instances where Zero is not implemented

Exactly. I would have preferred to use T: Zero, but its not implemented widely enough. Specifically in some big integer math libs. I am open to suggestions to improve this, though, if you have any ideas.

Is there any reason you don't want to use num_traits even without std or libm?

This is a good suggestion. I should be using num_traits. I will add that as a separate issue to get around to when I get some time.

[cargodog]

smile I thought @cargodog is a namespace of these projects from you @rasa200.

No worries, I hope @cargodog comes in soon.

I think the trait idea is good: it would cover the most common cases and help those who want to implement their own version.
A draft of this would be the following (feel free to correct or change all you want).

pub trait Differentiable {
    fn diff(&mut self);
}

impl Differentiable for Polynomial<f64> {
    fn diff(&mut self) {
        let lenght = self.0.len();
        for i in 0..lenght - 1 {
            self.0[i] = (i as f64) * self.0[i + 1]
        }
        self.0[lenght - 1] = 0.0;
    }
}

Something we could think about is the signature of the method diff:
Would you rather prefer fn diff(self) -> Self?

This is a good implementation for an f64, but I think this needs to account for the edge case when self.0.len() is 0. Otherwise, self[length - 1] will result in a panic.

Also, I think this should be provided as a trait with a generic default implementation, rather than specifically implementing the trait for each type. Users can always override the default implementation, if it doesn't meet their needs.

[saona-raimundo]

This is a good implementation for an f64, but I think this needs to account for the edge case when self.0.len() is 0. Otherwise, self[length - 1] will result in a panic.

Yeah! Sorry, my mistake!

Also, I think this should be provided as a trait with a generic default implementation, rather than specifically implementing the trait for each type. Users can always override the default implementation, if it doesn't meet their needs.

Giving a default implementation is a good idea! If for some types we can give a better implementation, then that can be added to the crate too. With this default iplementation, if the user has an easy but not typical instance, they would simply have to type:

impl Differentiable for Polynomial<MyType>;

To write the default implementation one would need to put trait bounds on the trait Differentiable (please correct me if I am wrong). What are the trait bounds we would need? (It has to be something that is implemented by Polynomial<T>, of course)

[cargodog]

To write the default implementation one would need to put trait bounds on the trait Differentiable (please correct me if I am wrong). What are the trait bounds we would need? (It has to be something that is implemented by Polynomial, of course)

I believe you are correct. I would need to think on it a bit, but I believe the trait bounds would just need to match those required by the degree() and eval() methods (Add, Sub, Mul, MulAssign, Eq, Clone, Copy). This wouldn't satisfy the bounds for every trait implementation, but it would satisfy the core methods. I have mixed feelings about how strict the trait bounds should be.

As I look at this, I am realizing that I should clean up my usage of trait bounds throughout this crate. e.g. think it may be better to only use AddAssign instead of Add (same with Sub, Mul, etc) everywhere to reduce the number of trait bounds to satisfy. I will think on this some too. Lots of food for thought.

[saona-raimundo]

Hey! Great! Thank you @cargodog!

Just one comment as you go through the "trait cleaning process". The method degree is good, but needs T: Eq. This is not the case for f64. Of course that non-real numbers do not make sense as coefficients for the polynomials, but, well... floating points. I am happy that degree has this trait bound separated.

I think, Differentiable should not have the trait bound T: Eq either. That is all.

[cargodog]

Thats a good point. I agree it can probably be removed. I will add that to my list. Thanks!

[philippeitis]

Hi - I actually also produced a crate for operating on polynomials, and I created a flexible implementation producing derivatives with any numeric type (eg. u8 to f64). To convert usize to various numeric types, I provided a trait impl and implemented it, and then used the bounds to implement it here.

This may be helpful for your own implementation.

[saona-raimundo]

Hi!! Thanks for posting it here!
I looked at it and I have one question: what is the difference with TryFrom<usize> (other than the Sized trait bound)?
Maybe I just looked at it too quickly.