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

I managed to figure out what your original post meant, but I can't make sense of this. How about trying to do what you want in a worksheet and uploading the results?

I managed to figure out what your original post meant, but I can't make sense of this. How about trying to do what you want in a worksheet and uploading the results?

To answer your second question---about multiple functions on the same graph: Yes, all that is easily done with plots:-display. See ?PlottingGuide. For a complete answer, post your question in a separate thread.

To answer your second question---about multiple functions on the same graph: Yes, all that is easily done with plots:-display. See ?PlottingGuide. For a complete answer, post your question in a separate thread.

@brian bovril Do you mean all the factorings of 36 into 3 parts? The program under discussion in this thread does not consider 1 to be a part of any factoring, but the results could be easily modified to include 1. Just take all the factorings, Factorings(36,1), Factorings(36,2), and Factorings(36,3), and pad the results with the appropriate number of 1s.

@Markiyan Hirnyk I'm not try to prove anything about the expression F in the mathematical sense of proof. I'm trying to prove, if you could call it that, or verify, that plot was unable to evaluate F at any of the values that it chose, except for k = 0. It may well be that there are other values of k at which F can be evaluated.

Now I am convinced that this situation---where plot can only evaluate the expression at one value---should be considered a bug, because it should give the same warning message that one gets if it can't evaluate the expression at any values. Displaying empty axes with no warning is not helpful.

Compare plot(1+x*I, x= 0..1) with plot(1+x*I, x= 1..2).