a "numerically aided" filter may help:

map(x->[x,evalf(x)],[solve(p^3 - p + 1/10, p)]):
select(x->is(Re(op(2,x)),nonnegative),%):
map(simplify@evalc@(x->op(1,x)),%);
                            1/2    1/2
        1/2                3    373        Pi
  [2/3 3    sin(1/3 arctan(-----------) + ----),
                                9          6

                                  1/2    1/2
              1/2                3    373        Pi
        -1/3 3    sin(1/3 arctan(-----------) + ----)
                                      9          6

                            1/2    1/2
                           3    373        Pi
         + sin(-1/3 arctan(-----------) + ----)]
                                9          3

as it stands now 'is' does not provide a reliable filter (that example was for illustration, not for actual code). My question is whether a filter using a stronger  prover is a better option than a full rework of 'solve' to handle more general assumptions than those that can be formulated as a system of (in)equations.

Indeed, a stronger prover is very needed.

as it stands now 'is' does not provide a reliable filter (that example was for illustration, not for actual code). My question is whether a filter using a stronger  prover is a better option than a full rework of 'solve' to handle more general assumptions than those that can be formulated as a system of (in)equations.

Indeed, a stronger prover is very needed.

Instead of a full rewrite, it could perhaps have a filter postprocessing stage, something like Axel said:

select(is,[solve((p+1)^2-p^2, p)],nonnegative);
                                  []

Instead of a full rewrite, it could perhaps have a filter postprocessing stage, something like Axel said:

select(is,[solve((p+1)^2-p^2, p)],nonnegative);
                                  []

Perhaps it is better to take profit of the new inert form for the commands:

value(sum(2/%sqrt(k+2)-2/%sqrt(k+3),k=1..n));

                                          1/2
                              2        2 3
                        - ---------- + ------
                                 1/2     3
                          (n + 3)

Perhaps it is better to take profit of the new inert form for the commands:

value(sum(2/%sqrt(k+2)-2/%sqrt(k+3),k=1..n));

                                          1/2
                              2        2 3
                        - ---------- + ------
                                 1/2     3
                          (n + 3)

does not seem to work for non integer exponents, but can be done with a "generic" function call:

sum(f(k+2)-f(k+3),k=1..n);
eval(%,f=(x->2/sqrt(x)));

                           -f(n + 3) + f(3)

                                          1/2
                              2        2 3
                        - ---------- + ------
                                 1/2     3
                          (n + 3)

does not seem to work for non integer exponents, but can be done with a "generic" function call:

sum(f(k+2)-f(k+3),k=1..n);
eval(%,f=(x->2/sqrt(x)));

                           -f(n + 3) + f(3)

                                          1/2
                              2        2 3
                        - ---------- + ------
                                 1/2     3
                          (n + 3)

with two different error message sets (for identical input) is a confusing situation, to say the least, from my point of view.

I wonder whether there is a switch to make show the full version of the error messages within the Standard GUI.

thought this example is trivial, and you do not really need Maple to split, change index, etc., a package providing these tools for sums, as IntegrationTools does for integrals (ie 'Split', 'Change', 'Combine', etc), is still missing.

thought this example is trivial, and you do not really need Maple to split, change index, etc., a package providing these tools for sums, as IntegrationTools does for integrals (ie 'Split', 'Change', 'Combine', etc), is still missing.

Acer's posts are superb and Jacques is a classic (pun intended).

In view of their recent posts, I beleive that an additional good "prize" for them would be to reduce MaplePrimes weekend service interruptions.

would be much more useful. For logging, context information, etc.

would be much more useful. For logging, context information, etc.