@isuruf What does
codecov/changes measure? and what does codecov/project?
codecov/changes is supposed to measure the changes in the PR. codecov is not working properly right no
Why has the operator+ been declared as an external friend function,
friend UnivariateExprPolynomial operator+(a, b) instead of UnivariateExprPolynomial &operator+(a) ?
Like we usually do?
For
a + b to work where a is of a type implicitly converted to a UnivariateExprPolynomial and b is a UnivariateExprPolynomial
Didn't understand you
What's the problem with just
UnivariateExprPolynomial &operator+(const UnivariateExprPolynomial &other)?
Let
b be a polynomial. What is the function that gives 1 + b?
Oh! Ok thanks!
One more question, how will
b + 1 be handled?
Both
b + 1 and 1 + b are handled in friend UnivariateExprPolynomial operator+(a, b)
So, if any of the arguments can be automatically 'casted' (or are already of) typeA, then
operator+(typeA a, typeA b)will be called?
yes
And this is possible, because
UnivariateExprPolynomial a = 1 works and has been defined by us, right?
Also, how does the compiler decide which function to call on say
1+1. There's both operator+(typeA a, typeA b) and operator+(int a, int b)?
See the order described in section, "Call to an overloaded operator"
@isuruf Should I start with implementing overloads for
UnivariateIntPolynomial?
Should I?
@irislq Why wasn't operator overloading done at the (current)
UnivariatePolynomial level, and instead done at UnivariateExprPolynomial level?
In theory, we could have just written the same (overloading) functions in the outer class, right?
@srajangarg I think it's because
UnivariateExprPolynomial is also used in UnivariateSeries, and UnivariateSeries already has some of the information that's in UnivariatePolynomial.
In theory, I also think (high level wise), it can be done, but just having overloaded operators for the dictionary things faster/lighter