@dharr thanks! 

1. Clear now.

2. In general I understand, but I thought my commands l1-remove(has, l1, I), l2-remove(has, l2, I), and l3-remove(has, l3, I) would return the complex solutions for the respective lambda, if any exist. Since they all return zero, I thought this meant all solutions were real. Am I wrong? 

3. I am not sure I got you. In your example the two specular equations generate specular elements for a solution. Don't look at your av variable but at your ans variable (i.e., implicit form) instead. In particular, look at your third one (with RootOf):

They are not exactly the same, but the RootOf term is the same (a quadratic). In short, the difference is just a sign and the -1. Instead, I get:

Check output 16 of the new script I already attached to see more clearly.

It is not the convolutedness that surprises me, but the fact that lambda_3 is a quartic in _Z, while lambda_2 is made of some weird combination of (actually the same) quartic and with some randomly looking leading coefficients. My question: is this "asymmetry" plausible from two perfectly symmetric equations? In particular, how can the significant difference in the size of the implicit forms for lambda_2 and lambda_3 be explained?

@dharr thank you for your answer. I have three related questions, with my new script attached:

1. What am I doing wrong when solving the reduced form system?
2. Am I understanding correctly that, in contrast to the provided example in the answer, only real solutions exist here (even if lambda_2 \= lambda_3)?
3. lambda_2 (l2[1]) and lambda_3 (l3[1]) are pretty much nonspecular (i.e., very different in size and form), while in the example provided in the answer the solutions are specular/very similar to each other, am I wrong?  

Script: 240124_specular_equations_nonspecular_solutions.mw

Thanks.

@Carl Love thanks for clarifying about the moderator issue. My question was not a follow-up.

Regarding the "mathematically equivalent solutions" comment, I am not sure why you are asking me this but it surely is a good question (what did you have in mind?). For interpretation, replace 'strategies' with dimensions. My three dimensions are highly symmetric, so it's not entirely surprising to me that lambda_1 = - lambda_2 - lambda_3. Plugging these back into my three betas gives me: 291223_gamma_disappear.mw 

@dharr @Axel Vogt thank you!

@Preben Alsholm thanks for pointing it out, I didn't know that. Lesson learned.

@dharr thank you. I guess the independence from the parameter is a good thing in my case, as it makes that solution much more manipulable compared to the others...

@dharr thank you. I'll see if I can come up with some ideas on how to fix my system accordingly...I am aware that is harder to decide the conditions for something to be positive or negative than zero, but please let me know if you have any update. 

Moreover, while also mmcdara contributed significantly and taught me a lot, best answer goes to you for the great effort to re-formulate the whole setup in matrix-form as a workaround to the issues with the algebra! (Now I am confident about the solving process and aware that difficulties stem from my initial conjectures).

@dharr thank you for the details. You write "I added some explanation to hopefully clarify this."...where?

"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." Yes, I don't expect lambda__3 to be the sum of the other two lambdas.

"I didn't mean to imply anything about that case" Maybe I was not clear on this. Those signs for the betas are embedded in the conjectures. In other words, I know in advance that the signs must be those that I mentioned for each beta. These signs are not a specific consequence of the calibration, as I think you meant. To emphasize further, regardless of the calibration beta_11, beta_22, beta_31, beta_32 must be positive, while beta_12 and beta_21 negative.

"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" Yes, I agree.

@dharr thanks! I looked at your scripts. 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?

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.

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.

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...

@dharr thanks a lot, really. That simple relationship between betas and lambdas is super interesting and I need to reflect more about it.

I don't have access to my laptop right now so I cannot check your worksheet at the moment.

! UPDATE !: perhaps it was important to mention that beta_11, beta_22, beta_31, beta_32 are expected to be *positive*, while beta_12 and beta_21 *negative*.

@mmcdara of course you can leave the thread if you desire to, but I think it's useful (also for the broader community) to push for different approaches and I personally appreciate your expertise.

why do talk about different directions in your latest comment below? The question is the same and the matrix-form reformulation did not lead to any real solutions. 

Overall, after addressing the big mistake with the numer command, would you surely rule out that my system has real and positive solutions? Is this your conclusion (together with the idea that is pointless to keep working with free parameters)?

@dharr thanks for trying hard.

Given your experience and, now, your knowledge of the setup in matrix-form...what could be the source of non-real solutions? Is it the way I set up my Xs and qs at the very beginning?

My mind now is on trying to reverse-engineer initial conjectures that would eventually lead me to real solutions...

@mmcdara I sent you an email.

@dharr I am stuck: 181123_MatrixForm.mw (I tried to follow your old example 250523_Analysis_old_problem.mw)

It seems that the quadratic for lambda__3 has no real solutions...do I need to impose the two conditions on lambda__2 before I try to solve for lambda__3? From your comment above I understood that I needed to first check whether real and positive solutions even existed for lambda__3, and only later remove any that don't obey the two conditions on lambda__2...

Moreover, it seems that the first condition on lambda__2 is not even real, while the second condition is contradictory to lambda__2 being assumed positive:

How to take it from here?

@dharr thank you for your efforts in reformulating the whole problem in matrix form. I am learning a lot from both you and @mmcdara. The matrix form really makes the problem look simpler (and easier to interpret perhaps) and was a smart way to avoid problematic denominators.

As far as I understood, the solution exists but can be in complex domain for some specific calibrations (as you show clearly). Yet, you write: "So finding conditions for positive solutions should not be intractable, though perhaps tedious."

How do you suggest to proceed next?

My ultimate goal would be to find some beautiful and interpretable expressions for the three lambdas in terms of uncalibrated parameters (perhaps with additional restrictions on the values of those parameters to ensure real solutions). Anyway, let's see. In the meantime, I am running your script with a non-zero rho_v, which definitely won't make things easier but perhaps setting it to zero  beforehand generated issues...