@AliKhan But what you call C in your original post is the "simple addition" of A and B. Could you write more explicitly the pattern that you want?

You call that an example? Please provide example values for the parameters lambda, n, and p such that RootFinding:-Analytic does not find all the roots.

How about posting an example?

@acer It's easy to account for any duplication of the sort that your example shows. Continuing right from the end of your example

length(sprintf("%m", eval({a,c})));

                      78914

So, to check the total memory used by any group of variables, use the %m trick on the set of them.

@acer It's easy to account for any duplication of the sort that your example shows. Continuing right from the end of your example

length(sprintf("%m", eval({a,c})));

                      78914

So, to check the total memory used by any group of variables, use the %m trick on the set of them.

You asked the same question before on 13 jan 2013, and I answered it. Did you try using that answer?

@PatD 

I did what I suggested: converting each expression to an optimized procedure, and then using fsolve in list-of-procedures mode. It still returned unevaluated, but after only about five minutes, because the optimized procedures evaluate about 200 times (if I recall correctly) faster than the original expressions. I don't know how it took for you. I think that the trouble is numerical instability, as you suggest. I'm guessing that what's needed is to have the internal computations done at a higher precision than what's needed for the final result. As far as I can see at ?fsolve,details, fsolve has no such capability. But I think that there are other packages, like DirectSearch, that offer that capability.

I will continue this in the new thread that you started.

@PatD 

I did what I suggested: converting each expression to an optimized procedure, and then using fsolve in list-of-procedures mode. It still returned unevaluated, but after only about five minutes, because the optimized procedures evaluate about 200 times (if I recall correctly) faster than the original expressions. I don't know how it took for you. I think that the trouble is numerical instability, as you suggest. I'm guessing that what's needed is to have the internal computations done at a higher precision than what's needed for the final result. As far as I can see at ?fsolve,details, fsolve has no such capability. But I think that there are other packages, like DirectSearch, that offer that capability.

I will continue this in the new thread that you started.

I'd say rehabilitated rather than exonerated. Nonetheless, it's an excellent rehabilitation, and an interesting technique. I vote up. But perhaps not a comphrehendable explanation for someone's second session with Maple.

I'd say rehabilitated rather than exonerated. Nonetheless, it's an excellent rehabilitation, and an interesting technique. I vote up. But perhaps not a comphrehendable explanation for someone's second session with Maple.

@PatD

The approach I outlined above is working so far. There are 3 "small" expressions, and 6 large ones. The massive GUI-killing monster C[2] that you presented yesterday is one of the small ones! The large ones are about 200 times larger than that in their original form! As I predicted, C[2] compressed down to about 100 lines of code, and the larger ones are at about 300 lines of code (which shows the tremendous amount of redundancy that there usually is in large expressions). The larger compressions are taking 5 - 10 minutes, proceeding as I type here. I will garbage collect the original C[1], ..., C[9] before running fsolve.

@PatD

The approach I outlined above is working so far. There are 3 "small" expressions, and 6 large ones. The massive GUI-killing monster C[2] that you presented yesterday is one of the small ones! The large ones are about 200 times larger than that in their original form! As I predicted, C[2] compressed down to about 100 lines of code, and the larger ones are at about 300 lines of code (which shows the tremendous amount of redundancy that there usually is in large expressions). The larger compressions are taking 5 - 10 minutes, proceeding as I type here. I will garbage collect the original C[1], ..., C[9] before running fsolve.

@Markiyan Hirnyk

That generates the sample space, in a sense, but not in a way that is helpful for solving the problem, because your sample space is far from equiprobable. To see this, consider a problem with much smaller numbers:

A box contains two white balls and one black ball. Two balls are selected at random without replacement. What is the probability that both selected balls are white?

Using combinat:-choose in list mode gives us:

combinat:-choose([w,w,b], 2);

[[b, w], [w, w]]

If we assume, incorrectly, that this is an equiprobable sample space, we get the wrong answer, 1/2. And if we don't make that assumption, then generating the sample space does not help in getting a numeric answer to the problem.

We can generate an equiprobable sample space by using choose in set mode:

combinat:-choose({w1,w2,b}, 2);

{{b, w1}, {b, w2}, {w1, w2}}

from which we see that the answer is 1/3.

For the OP's problem, it is infeasible to generate the equiprobable sample space (nor did the problem ask for that), as it has (52 C 9) ~ 4 billion elements.

Thanks. I haven't tried the copy/paste, although I've seen that you can select the whole array. Where would I paste it? And what would the format (GIF, JPG, etc.) be? My immediate desire is to upload to MaplePrimes, but FireFox (my web browser) only allows pasting plaintext to MaplePrimes.

Thanks. I haven't tried the copy/paste, although I've seen that you can select the whole array. Where would I paste it? And what would the format (GIF, JPG, etc.) be? My immediate desire is to upload to MaplePrimes, but FireFox (my web browser) only allows pasting plaintext to MaplePrimes.