will return the sums of each pair (ie [a,b], [b,c], [a,c]), in a Vector. What did I misunderstand? You can use Vector, list, vector or tables for the answer. Or even an expression sequence, but I would not recommend that.

will return the sums of each pair (ie [a,b], [b,c], [a,c]), in a Vector. What did I misunderstand? You can use Vector, list, vector or tables for the answer. Or even an expression sequence, but I would not recommend that.

Sometimes there is only one RootOf in the output from solve, and yet it has a label, which seems unnecessary. That usually happens when, internally, multiple RootOfs existed in intermediate computations, and they needed to be 'different', so had to be differentiated via a label. Solve will factor its input, and otherwise manipulate it to make the problem ``simpler''. In some cases, that means that the problem will be solved completely, even if the degree is higher than 4. This is the case for all 2-term polynomial equations for example (like x^8-3 or x^18-13*x^5).

Sometimes there is only one RootOf in the output from solve, and yet it has a label, which seems unnecessary. That usually happens when, internally, multiple RootOfs existed in intermediate computations, and they needed to be 'different', so had to be differentiated via a label. Solve will factor its input, and otherwise manipulate it to make the problem ``simpler''. In some cases, that means that the problem will be solved completely, even if the degree is higher than 4. This is the case for all 2-term polynomial equations for example (like x^8-3 or x^18-13*x^5).

I would be rather surprised if you found something in Maple which is significantly better resource-wise (ie combined time and memory). One way or another, there will be all sorts of memory allocation needed, and the big question is whether it will be one large chunk (as in the above) or lots of little chunks. Little chunks will cause more gc() pressure. The only minor thing you can try is to use seq instead of map in the second case, to avoid some of the overhead of function calls.

Parts of assume() do know that the integers divide into exactly the evens and the odds (this is what LinearProp is for). However, as far as I know, neither solve nor simplify know very much about integer properties. This is one of those areas where things work quite well already, but there still are improvements that could be done. What is going on is that solve breaks the problem up into pieces, solves those, then reassembles the solution, and does not notice that the assembled pieces "simplify".

Parts of assume() do know that the integers divide into exactly the evens and the odds (this is what LinearProp is for). However, as far as I know, neither solve nor simplify know very much about integer properties. This is one of those areas where things work quite well already, but there still are improvements that could be done. What is going on is that solve breaks the problem up into pieces, solves those, then reassembles the solution, and does not notice that the assembled pieces "simplify".

Long long ago, when solve was first written and computers were slow (we're talking pre-386 here, and megabytes is what you measured you disk capacity with, not your computer's memory), it was deemed to be "too much" to return all answers. Only the ones that would have been found by someone in first year were deemed to be worth always returning. You had to ask harder for "all" of them. And now times have changed, a lot, and yet in this area Maple has not. It has all the power, and all the code necessary to return the 'right' answer, but that is still not the default. Why, you ask? Because there is a chance that it might break someone's code, you know, the ultimate in backwards compatibility. The GUI is 'innovative', the math engine is history-bound. The irony is just too much.

Long long ago, when solve was first written and computers were slow (we're talking pre-386 here, and megabytes is what you measured you disk capacity with, not your computer's memory), it was deemed to be "too much" to return all answers. Only the ones that would have been found by someone in first year were deemed to be worth always returning. You had to ask harder for "all" of them. And now times have changed, a lot, and yet in this area Maple has not. It has all the power, and all the code necessary to return the 'right' answer, but that is still not the default. Why, you ask? Because there is a chance that it might break someone's code, you know, the ultimate in backwards compatibility. The GUI is 'innovative', the math engine is history-bound. The irony is just too much.

{op(e)} will return that. But that's not what you seemed to be asking for...

indets(e,'function'); will return {f(x), g(y), h(z)}. From there, extracting further information is easy. For example, if you want those that depend on x, you can do select( depends, indets(e,'function'), {x});

There are a couple of quite knowledgeable people here on primes on sparse, exact linear algebra (and I am not one of them!). If you give more details of the structure of your matrix, some people might be able to direct you to specific places to look. I also know several of the people behind LinBox, as well as several experts in that domain -- with enough details in hand, I could pass on your problem and see what they reply.

While an explicit U(s) may make the expressions bigger, it contains so much valuable information that I believe that Maple's solvers would have a much better chance of doing something with the explicit version than with an implicit function U(s). Think of it this way: int(U(s), s=0..1) for a generic U has to return unevaluated, because there is nothing that can be derived from that. But for the U above, Maple gets:

 > int(U,s=0..1);

                                           2
                                     k_2 Pi
           k_1 - k_2 - 2 k_1 ln(2) + ------- - 4 k_2 ln(2)
                                        6

So I think your 'actual' problem may be much more solveable than an overly generalized version of the same.

While an explicit U(s) may make the expressions bigger, it contains so much valuable information that I believe that Maple's solvers would have a much better chance of doing something with the explicit version than with an implicit function U(s). Think of it this way: int(U(s), s=0..1) for a generic U has to return unevaluated, because there is nothing that can be derived from that. But for the U above, Maple gets:

 > int(U,s=0..1);

                                           2
                                     k_2 Pi
           k_1 - k_2 - 2 k_1 ln(2) + ------- - 4 k_2 ln(2)
                                        6

So I think your 'actual' problem may be much more solveable than an overly generalized version of the same.

That has to be one of the most obscure ways of manufacturing a quit DAG that I have ever seen. Kudos. I discovered the following hilarious difference between the two Maple GUIs: proc() done end; in 1) Classic prints as

                         proc() quit end proc

2) Standard prints as

                         proc() stop end proc

! TTY Maple agrees with Classic.