@MDD I think this covers all the cases. Only x is treated as a variable in the non-derivative terms. Note that e*(x-1) gives two terms because it is the same as e*x-e.

Download dcoeffs4.mw

@dharr works at least for your last example

dcoeffs3.mw

@MDD So I had to guess at what you wanted for the part that doesn't contain y(x).

What do you want for a*sin(x)+b*x+c? (a*sin(x)+b*x)*A4+c or a*sin(x)*A4+b*x*A5 +c? Is the function of x always a polynomial?

@MDD Oops, I uploaded the wrong file. dcoeffs2 above should work.

@MDD Sorry, this should work in your version of Maple.

dcoeffs2.mw

@Zeineb 

sol := {solve(HurwitzConditions,useassumptions)}:

Download ploterror.mw

@delvin For the 4th time - you need a modulus! I chose l=1, but you might need some other value or maybe just symbolic.  I put sum back to add as I told you originally.

Eq1 is now found without errors. simplification is slow and I didn't wait. Of course in the next step you can't solve one equation for 13 variables. I've fixed the Maple, but it is up to you to take it to the next step.

 Jaco02.mw

@delvin You did not upload your revised version - just insert the link

@delvin JacobiDN (Not Jacoby). You need a modulus.

@delvin As I said before, jacobi has to be changed to Jacobi, and these functions need a modulus as second argument (I don't know what that would be for your application.)

I haven't given much thought to your main question. But you spend a lot of calculation time figuring out the arcs of circles, especially start and end angles. If you just plot full circles and hide the bits outside the unit circle, then this can be done faster. (Though if you want to ultimately color in the regions, I'm not certain this is a good approach.)

PoincareIdeas.mw

@MaPal93 I gave some more thought to the structure of the betas in terms of the lambdas, and found some interesting things. In the expression for lambda__1:

there are no lambda__1's except in the determinant of Q. So if one could prove the numerator was always positive (the demoninator is positive), then the system seems internally consistent - any positive lambda__2 and lambda__3 would make the expression positive and then lambda__1 would be positive. Yet no positive solution can be found for all three equations.

For the calibration system, the signs of betas are as required, and the numerator is positive for positive lambdas.

Thanks for the best answer.

MatrixNew9.mw

@MaPal93 The explanation was added to the MatrixNew8.mw file.

As for the signs of the beta's, since they contain lambda's it might be possible to use the known signs to narrow down the possibilties for the lamba's, but my first look at that didn't yield anything obvious. In general it is harder to decide the conditions for something to be positive or negative than zero.

@MaPal93 

I can see how you compute explicitly the relationship between the lambdas and the Xs, but not the one between the lambdas and the betas?

I added some explanation to hopefully clarify this.

Both relationships are interesting, but I am still not sure if they trivially follow from the conjectures or if they can have some deeper interpretation.

They both arise because the problem was extended from 2 components (2-vectors and 2x2 matrices) by adding a row that was the sum of the first two, and not independent, but lambda__3 was introduced separately. Whether this is significant or not is not clear to me.

Once the required X_max and beta quatities are found, then there are some relationships between them and it may be possible to further simplify the problem (but the solution is just the same). I'll try to give this some more thought.

Did you say that there could be a chance for real and positive solutions given that beta_11, beta_22, beta_31, beta_32 are expected to be positive, while beta_12 and beta_21 negative? This combination does not violate the relationship between betas and lambdas but I don't know how to use the expected signs of the betas to get to cases allowing real and positive lambdas.

I didn't mean to imply anything about that case.

Finally, I see you edited your second last comment ("think more about the cases where the denominators are zero"). For rho__v = 0, sigma__v1 = sigma__v2, sigma__e1 = sigma__e2 then I guess we obtain beta_31= - beta_32, beta_21= - beta_22, beta_11= - beta_12...I am not sure why you want me to think more about these cases...

Sorry, I added that edit as a reminder to myself to think about singular solutions, and did give it some thought. For example if 0 = 0*lambda__2 then lambda__2 can be anything. PolynomialSystem and Maple generally do not consider cases where the parameters may have special relationships that might give special solutions. They can be found using for example Triangularize with output=lazard, but since you want general relationships I don't think this is a profitable way to go.