@mmcdara 

YES. Sorry, my mistake. In the script I attached I was correct, but in the body of the posted question I was wrong. I meant Max{ E[A|B,C] - (gamma/2)*V[A|B,C] } (gamma being a constant parameter) instead of Max{ E[A|B,C] + V[A|B,C] }. Question's body just updated. 

@mmcdara thanks. I understand that this is the generic procedure to build joint bivariate normal distributions (N=2) and joint trivariate normal distributions (N=3).

Maybe a naive question, but how do I make it a function/procedure so that I can conveniently apply it to my bivariate (nu_1, nu_2) and my trivariate (u_1, u_2, u_3), taking care automatically of all the idiosyncratic notation? I am dealing with many symbols so, for example, all the correlations/covariances must be carefully defined with the proper subscripts (see 070423_Optimization.mw).

You wrote: "As you have all the formulas for step2 and beyond". I am not confident at all about these. Are you saying that:

1. My understanding of the 3D-version of the theorem (the pictures) is correct?
2. My translation of its matrix form into Maple (LinearProjectionTheorem_3dimensions.mw) is correct?

@Carl Love @mmcdara

It's known as mean-variance utility framework or CARA-Gaussian framework. See, for example:

• https://economics.stackexchange.com/questions/30677/mean-variance-optimization-in-a-utility-maximization-framework
• https://quant.stackexchange.com/questions/25728/why-do-we-assume-quadratic-utility-in-portfolio-theory
• https://economics.stackexchange.com/questions/33688/utility-theory-and-portfolio-optimization-utility-of-what-exactly

A classic academic paper using this framework: https://www.jstor.org/stable/1805228 (equation 7, page 5 of the freely downloadable pdf).

@mmcdara 

Did you have a chance to look at my comment above?

I'd like to know how to further process the problematic 6-by-6 lambdas sub-system:

1. Is there a smart way to use numerical approaches (fsolve()?) to help or guide Maple to find, eventually, an analytical solution?
2. @Carl Love you wrote about singular solutions: "some valuation of some parameters that will yield a solution that cannot be obtained by applying the same valuation to a general solution. The parameter valuations that lead to singular solutions can often be guessed by using valuations that would produce zeros in denominators in the general solution." How to do this in 270323_complex.mw?

Thank you for the continued support!

@sand15 thank you for the clarification!

@mmcdara

I let it run overnight (~8h) and, as I suspected, the execution is still running. I have been trying to solve the whole 8 eqs x 8 vars system, as well as the lambdas-only 6 eqs x 6 vars sub-system (270323_complex.mw).

At least now we know that it's the 6x6 lambda sub-system to cause issues: here's the output for the complementary sub-system of two equations in the mus: SOLUTION_complex_mu.pdf (for @Carl Love: SOLUTION_complex_mu.txt), which was solved in less than 1 minute. Moreover, unlike the solving of the whole 8by8 system which has a rich LOG output, infolevel[] does not produce much for the lambdas sub-system which, since about ~8h, only displays:

'''

Main: Entering solver with 6 equations in 6 variables

Main: attempting to solve as a linear system

Main: attempting to solve as a polynomial system

SolverVariableOrder: using the variable order lambda__ki3 > ..ki1 > ..jk2 > ..jk1 > ..ki2 > ..jk3

'''

I am now trying to solve the 6by6 lambda sub-system by executing the following block:

Download grob.mw

Carl Love, might this 6x6 lambdas sub-system have those singular solutions that you mentioned before? 

The file SOLUTION_complex_mu_final.pdf (or in txt SOLUTION_complex_mu_final.txt) is, instead, the output once sol_lambda is plugged back in sol_mu (at the end of the maple script attached on top of this comment). Maybe a naive question, but why do I even obtain this since its execution is after save sol_lambda and the solver for sol_lambda is still running? 

UNRELATED (NAIVE) QUESTION: why these lambdas for the "simple" version we solved before do not simplify further? Please check highlighted comment at the bottom of Analytical_SOL.mw 

Thank you.

@mmcdara 

All good with the params now.

You wrote: "Once these last solve command end, the next instruction (save) will save MySolution in the m-file." Yes, I understand this...but I don't know when it will end. Might take hours? In any case, I will upload the .m file here, converted to pdf, once solve() is completed (what if it doesn't?).

@mmcdara 

Great.

Good catch with indets(MyEqs) minus MyVars. Thanks to it I found out a spelling mistake of mine in argmin2 (a beta__jk1 instead of a beta__jk3). The following is the correct one:

However, I still read sqrt(Sigma__0jk) and sqrt(Sigma__0ki) as params (in addition to Sigma__0jk and Sigma__0ki, as expected). Why?

You asked: "Could you please remove the # character at the beginning of the last line, execute it, and send me the file SOLUTION_complex.m with the extension changed to pdf ?"

Do you mean I should interrupt the execution of solve() after some time and then execute the "save" line of code to produce the .m file? If that's what you meant, here it is: SOLUTION_complex.pdf

(but of course "Warning, unassigned variable `MySolution` in save statement" is displayed after the save command as solve() was interrupted)

@mmcdara 

Your answer to my first question is very clear. Thanks a lot. 

Regarding the second one:

My machine has 128 cores (256 threads) and over 1TB of RAM. GPU is an NVIDIA Tesla A100. What's the most effective way on Maple to maximise the usage of such computational power? Please check: Groebner.mw

Given your experience, you might get some ideas from the output I get from instanciating MyEqs with som calibration data before attempting to solve...please check: 260323_complex.mw.

You also wrote: "Try and analyze the system to see if you can solve one subsystem, then the other, and insert the solution into the first's)." How to do this systematically?

@mmcdara 

Thanks.

I changed the covariance rho__XX__23 into rho__nu (at the beginning of the script, not at the calibration step) for better readability. But when it reaches the solve(), the compiler reads 

SOLUTION_copie.m

and exit the if(). So when we play around with the calibrations the displayed solutions have rho__XX__23 instead of rho__nu. How to fix this?

It seems like a minor issue, but let me explain why I need this. In 230323_updated1_Problem_mmcdara_complex.mw, which I still haven't fixed according to the latest script 240323_simple_calibration.mw, when expanding the more complex quadratic argument (for both minimization1 and minimization 2) we will have also the following terms:

So in total, in the "complex" version, we will have 4 correlations [ rho__nu, rho__u__jijk, rho__u__jiki, rho__u__jkki ]. If not defined, of course these 3 additional correlations will automatically be considered as 0 when computing Mean(argmin1 or 2), but I think it would be nice to have them as additional exogenous parameters to play with at the calibration step. Notice that these additional 3 correlations do not even appear in the "simple" version (hence we don't need to define them in the script's preamble). How to adapt 230323_updated1_Problem_mmcdara_complex.mw accordingly?

I guess we'll also need a separate SOLUTION_complex_copie.m file...

@mmcdara 

Your two latest .mw scripts go above and beyond. Thank you!

I loaded the .pdf file into the same folder where 240323_simple_calibration.mw is, then changed its extension to .m (just renaming it) and changed the .mw script as you suggested. What am I doing wrong? Please check 250323_simple_calibration.mw

@mmcdara 

Thank you for your latest script. It's quite late in my TZ right now and will check the details tomorrow morning. At a first glance the script looks really exhaustive.

Can I get back to you tomorrow just in case I still have doubts about it? I will also try to adapt it to my "complex" setup and see what it leads to.

I really appreciate your efforts. Not only you kept looking for a solution, but you also took care of explaining everything in detail and in providing the most exhaustive and instructive answers. I learned a lot in this thread. I am sure many other beginners in Maple community will find your insights beneficial to solve their own problems. Thank you.

Anticipating that I haven't gone through the details of your latest script yet, here is an example of a readable solution with a simple calibration (am I making sense?): 

@Carl Love thank you again for your insights.

The solutions as in 240323_UPDATED_Problem_simple_mmcdara.mw look promising in the sense that at least mu_jk and mu_ki only depend on q_0jk, q_0ki (mu_jk=q_0jk and mu_ki=q_0ki as I suspected - for reasons that go beyond this thread). The lambda_jk and lambda_ki, instead, are extremely long and reported in the implicit form. If you remove the 1000000 output size limit you can display them. What would you be able to tell by looking at these?

We could play around with this calibration to make it easier to interpret my solutions:

@mmcdara 

Sorry for the misunderstanding. I thought I was clear. I upvoted your answer and I will definitely "select this answer as the best one" once the answer is complete. 

Your latest script, UPTADED VERSION 230323_updated1_Problem_mmcdara.mw, addresses the problem summarized in  lambdas.mw, which I attached in the original post in this thread. In this sense, my original question never changed. Only in my latest comment I introduced a more complicated version of the same problem (230323_updated1_Problem_mmcdara_complex.mw).

"So I won't try to solve this umpteenth variant, given that your previous problem doesn't have any solution."

Why the solve command in your latest script is not something like the following?

@mmcdara 

Thanks for explaining.

This is the "simple" version:

230323_updated1_Problem_mmcdara_simple.mw

This is the "complex" version:

230323_updated1_Problem_mmcdara_complex.mw

• "So tell what eqmujk is meant to represent and I'll return your file corrected."

I just wanted to collect my solutions into variables to be first evaluated for my definitions of alphas and betas, and later used in solve() at the end of the script.

For the simple version:

• eqmujk = mu_jk
• eqmuki = mu_ki
• eqljk = lambda_jk
• eqlki = lambda_ki 

For the complex version:

• eqmujk = mu_jk
• eqmuki = mu_ki
• eqljk1 = lambda_jk1
• eqljk2 = lambda_jk2
• eqljk3 = lambda_jk3
• eqlki1 = lambda_ki1 
• eqlki2 = lambda_ki2
• eqlki3 = lambda_ki3