@Carl Love This member usually posts worksheets using Maple 18, and that might still be his working version. Your cited post's code would need revising, to run in that version, I believe.

Fyi, when I ramped up the size and number of RHSs to both be very large I sometimes obtained a result that contained Float(undefined).  However I was sometimes able to obtain a solution by other means in that case, ie. I'm not sure that I was encountering inconsistency in the random example. It was rare. I didn't poke around.

Timing performance of your prior code seemed quite similar to that of the LAPACK tridiagonal solver (as I accessed it), although the latter usually produced a slightly smaller residual. The timing differences were affected by the order in which they were run, and aspects that hinted the loading of shared external objects was a factor.

@Carl Love Yes, sorry.

@Carl Love Right you are, of course (I knew that but was not thinking, it might be a WFH thing).

I think that it's interesting how much garbage collection is part of some of these timings.

Something that I was considering mentioning was that these kinds of schemes can vary in performance according to which aspect of the problems grows in size. So for this problem it might be whether the number of items or the number of keys (or both) grows large.

When I was writing the simple loop code I showed in my Answer I was primarily thinking about dealing with a small number of unsorted keys relative to the number of items. I would write it differently for a large number of keys and, as I did mention in my Answer, I'd consider using ListTools:-Classify. (I lnow I used an example with 10^3 keys in comparison with Kitonum's code -- what I do and what I think don't always match.)

For a large enough number of items but a small number of keys (here, distinct eigenvalues lists) the scheme I coded performs modestly better than Carl's scheme. 

But Carl's scheme scales up much better as both the number of keys as well as the number of items grows large.

Another consideration which sometimes comes into play is how many such computations need to be done, and whether any part is repeated.

And that is an important takeaway, I think -- that the scheme should be taken which best suits the character of the actual data.

Unfortunately, in this question we have not been provided with the actual data, so there is no way to know what would be best except for guessing.

We can also observe that, for some sizes of problem, the repetition and ordering of the compared computations matters and has an effect. Therefore a better comparison would involve separate sessions. (The generated examples below are random and hence session-dependent, but should be large enough that the timings are representative and still meaningfully comparable across sessions.)

Here are some more data points, for fun:

Download grouplistcomp.mw

ps. I know that the code snippet to generate random examples could be improved. I didn't consider it important enough to optimize.

@hakan So, do you mean like this?

I'll also put in Kitonum's procedure, in case you wish to compare. Of course the order of the sublists may differ in the result, but it's not difficult to use a list rather than a set of the keys -- arranged as you prefer.

I repeat each twice for the larger example, interleaved, to show that the timing's are not just a consequence of which runs first.

Download grouplist.mw

@fmoraga So did you not read my earlier response about syntax for multiplication? Making the simple edit of adding explicition multiplication symbols in two places (Eq2, Eq3) seems to clear up the problem.

It is unclear why you prefer one representation of W_dot over others. Perhaps you have reasons for that.

If you want also to eliminate {Q_dot_C,Q_dot_H,T_c,T_h} specifically alongside {W_dot} then you could call eliminate against the union of those together -- and obtain no restrictions on the remaining variables. Or you could simply call solve directly against that union -- since the remaining variables are all free.

And you could then use eval as the second step to extract only the W_dot formula, which is simpler than having another solve call as the second step.

I suppose that you realize that you could also eliminate {Q_dot_C, Q_dot_H, eta} specifically in addition to W_dot. Or, you could simply take Eq1 as the answer, or use only Eq4.

Here are your original elimination, and a couple of others.

Download Tarea1_ac3.mw

@nikoo This answer is nonsense.

Start off by stating clearly what it means to you for a point to be a solution to this system.

Does it mean that the forward error (substituting results into the rhs-lhs of the equations, and taking absolute values, say) must be less than some specific value, and if so what? At what working precision ought that to hold. Be specific.

Are you looking for a value such that -- at high enough working precision, and if the point is refined to enough accurate decimal places -- that forward error could be made arbitrarily small?

Or would you be content with results in which the points only minimize the forward error (or some other suitable objective) and that it can be approached as an optimization problem? You may be forced into this position due to the fact that your equations already have floating-point coefficients(!). Actual "roots" may not exist, because of imprecise coefficients in the equations.

The nature of your final results (approximates actual roots, only minimizes some objective, etc) may well bear on the validity of use of the results in further scientific computation. Few people consider that properly.

@Jameel123 If I go here then I see a link to here, which contains a link to this, which in turn has two links, apparently for version 1 and 2 of a package.

The second link has a download link (a compressed tar file named adyz_v2_0.tar.gz, apparently containing a "DESOLVII" instructional worksheet and a Desolv-IIa.mpl file).

@Lali_miani If you are still using Maple 12 (like many of your previous Questions) then you can do it as follows.

(The elementwise operator `~` did not work in Maple 12. But it is not necessary to use that -- or even to map -- since expressions are taken by solve as equal to zero by default.)

restart;
kernelopts(version);

    Maple 12.02, X86 64 LINUX, Dec 10 2008 Build ID 377066

P:=x->x^4+x^3+a*x^2+sqrt(2)*x+b:

evalc([Re,Im](P(1+I)));

                   1/2           1/2
            [-6 + 2    + b, 2 + 2    + 2 a]

solve(%);

                        1/2
                       2              1/2
             {a = -1 - ----, b = 6 - 2   }
                        2

eval(P(x),%);

                /      1/2\
       4    3   |     2   |  2    1/2          1/2
      x  + x  + |-1 - ----| x  + 2    x + 6 - 2
                \      2  /

solve(%);

                                     1/2                        1/2
 1 + I, 1 - I, -3/2 - 1/2 I + 1/2 I 2   , -3/2 + 1/2 I - 1/2 I 2

There is no attachment.

@John Blacksad While these are even more ways (including using commands explictly), you could also get the characteristic matrix or the eigenvalues more directly. (I don't know whether you were doing an assignment question that required you do each step.)

Download maple_ac2.mw

And here are some ways, using commands explicitly,

Download mapleac3.mw

@Kitonum But my points were not about how the timing mechanism itself was used, and I don't see how you last comment contradicts any of them.

If you're going to identify numerically computed roots then Roots(...,numeric) isn't much worse of a choice than Analytic(...), and for the example you gave it is slightly faster unless you give one a leg up advantage by adjusting working precision in an ad hoc manner. It doesn't make so much sense to compare against Roots as symbolic solver.

Yes, there are indeed cases in which symbolic Roots(...) "goes away" while attempting to verify symbolically, as you showed. That is the give-and-take between it and symbolic solve. The latter has the problem that it can sometimes miss roots, or (more often) deliver some symbolic results which are not actually roots. We'd all love it is the trig engine within solve were able to compute roots: without need for verification, not miss any, and not return non-roots. It seems difficult.

Verification via shake is a partial solution, but a little tricky to do "right".

@Kitonum Your timings are not well done, to the point of being invalid, for several reasons.

1) You didn't include the time cost for identify.
2) The choice of working precision in evalf[12] is ad hoc and problem dependent.
3) If you're going to compare, then compare numeric techniques (or at least the same kind of computation).

More fair and sensible might be,

restart;
Eq:=sin(x)=simplify(convert(sin(Pi/60),radical)):
CodeTools:-Usage(identify(Student:-Calculus1:-Roots(Eq, x=3*Pi/2..5*Pi,numeric)));
memory used=58.85MiB, alloc change=4.00MiB, cpu time=660.00ms, real time=661.00ms, gc time=71.72ms
                [121     179     241     299   ]
                [--- Pi, --- Pi, --- Pi, --- Pi]
                [60      60      60      60    ]
restart;
Eq:=sin(x)=simplify(convert(sin(Pi/60),radical)):
CodeTools:-Usage(identify(evalf([RootFinding:-Analytic(Eq, re=3*Pi/2..5*Pi, im=-1..1)])));
memory used=68.42MiB, alloc change=72.00MiB, cpu time=833.00ms, real time=778.00ms, gc time=147.56ms
                [179     299     241     121   ]
                [--- Pi, --- Pi, --- Pi, --- Pi]
                [60      60      60      60    ]

The Analytic approach does not seem to beat out the numeric Roots approach in terms of performance. There is some variation according to the choices of working precision, but that is ad hoc and makes the comparison pretty pointless unless there is a programmatic scheme for determining that precision.

Moreover, for more general problems there may be additional complex roots which have to be accomodated (either by figuring out a suitable complex band, or sieving out, etc), which adds overhead.

Lastly, the whole approach of using identify is highly suspect unless one also verifies the results symbolically -- which involves additional overhead.

@Christopher2222 As far as I can tell you are just flailing about, trying wrong combinations at random.

Double forward slashes make no sense whatsoever, except it reveals that you don't understand the effect of double backslashes.

Redirecting stderr may work in the CLI's ssystem, but not the GUI's. So trying that in a direct ssystem call may well not be the answer, as mentioned. You seem to have tried the opposite, and it seems weird that you did so. Doing it (properly) a shell script might do better here, but you have to know how to pass arguments properly.

Either disable ffmpeg logging using a low logging level option, or log to a file, as suggested. You seem to have tried the opposite, and it seems weird that you did so.

I cannot tell how you tried to specify an output, since you didn't show explicitly.

I suggest that if you cannot get a simple example to work then you might not be a suitable individual for trying to cobble together a package for accessing ffmpeg from escaped shell commands.