@acer 

This could be an option:

RemoveAllAssumptions:=proc() 
local u;  global `property/object`,`property/OrigName`:
for u in map(op,[indices(`property/OrigName`)]) do
`property/object`[u]:=``:
end do:
zip(assign, map(op,[entries(`property/OrigName`)]), map(op,[entries(`property/OrigName`)])):
`property/OrigName`:=table():
end proc:

It should restore the property tables property/object and property/OrigName to their initial state, and assign back to the variables on which a property was attached, their names as value. I.e. it should provide a "property restart".

z:=y;
                                z := y

assume(x>0);
y:=x;

                                y := x

z;
                                  x

RemoveAllAssumptions():
about(x);
x:
  nothing known about this object

z;
                                  x

y;
                                  x

@lxyuzs 

Actually, the solutions of abs(x)^2=1 are the points on the unit circle in the complex plane, not just 1,-1,I,-I. And for the original system, they have the form b[2]=1/2,b[3]=exp(I*phi)/2,b[4]=-1/2,b[5]=-exp(I*phi)/2, -Pi<phi<=Pi, provided that lambda[2]+2*B=0:

eval(eq,[b[2]=1/2,b[3]=exp(I*phi)/2,b[4]=-1/2,b[5]=-exp(I*phi)/2]) assuming phi::real:
algsubs(lambda[2]+2*B=0,%);
                               {0 = 0}

The problem lays in the transformation of the equation into a pair of equations for x and abs(x)=_X say, as the assumption was made in the code that x is real, so that these equations are generated:

SolveTools:-Transformers:-Abs([[{abs(x)^2-1},{}, {x}, {}, true, false, 1, {x}]]);
               2
  [[{_X - x, _X  - 1, 0 < _X}, {1 <> 0}, {_X, x}, {}, true, false, 1, {x}],
              2
  [{_X + x, _X  - 1, 0 < _X}, {1 <> 0}, {_X, x}, {}, true, false, 1, {x}],
                  2
  [{_X, _X - x, _X  - 1}, {1 <> 0}, {_X, x}, {}, true, false, 1, {x}]]
     

This assumption contradicts the generic implicit assumption that the variables are complex. So, I consider it a bug.

@lxyuzs 

Actually, the solutions of abs(x)^2=1 are the points on the unit circle in the complex plane, not just 1,-1,I,-I. And for the original system, they have the form b[2]=1/2,b[3]=exp(I*phi)/2,b[4]=-1/2,b[5]=-exp(I*phi)/2, -Pi<phi<=Pi, provided that lambda[2]+2*B=0:

eval(eq,[b[2]=1/2,b[3]=exp(I*phi)/2,b[4]=-1/2,b[5]=-exp(I*phi)/2]) assuming phi::real:
algsubs(lambda[2]+2*B=0,%);
                               {0 = 0}

The problem lays in the transformation of the equation into a pair of equations for x and abs(x)=_X say, as the assumption was made in the code that x is real, so that these equations are generated:

SolveTools:-Transformers:-Abs([[{abs(x)^2-1},{}, {x}, {}, true, false, 1, {x}]]);
               2
  [[{_X - x, _X  - 1, 0 < _X}, {1 <> 0}, {_X, x}, {}, true, false, 1, {x}],
              2
  [{_X + x, _X  - 1, 0 < _X}, {1 <> 0}, {_X, x}, {}, true, false, 1, {x}],
                  2
  [{_X, _X - x, _X  - 1}, {1 <> 0}, {_X, x}, {}, true, false, 1, {x}]]
     

This assumption contradicts the generic implicit assumption that the variables are complex. So, I consider it a bug.

@PatrickT 

Maple 13.02 produces the same error message. The problem seems to be that Algebraic:-RecursiveDensePolynomials:-rpoly does not handle symbolic coefficients. Replacing them with numbers makes it work:

with(Algebraic:-RecursiveDensePolynomials):
V := Vector([[a4*X[2]^2+a1*X[1]+a5*X[1]*X[2]+a2*X[2]+a3*X[1]^2],[(b1*X[1]+b2*X[2])^2]]):
eval(V[1],zip(`=`,[op(indets(V[1],suffixed(a)))],[seq(1..5)]));
rpoly(%,[X[1],X[2]]);
op(2,%);
                 2                                       2
           4 X[2]  + X[1] + 5 X[1] X[2] + 2 X[2] + 3 X[1]

                  2                             2
            3 X[1]  + (1 + 5 X[2]) X[1] + 4 X[2]  + 2 X[2]

                       [[0, 2, 4], [1, 5], [3]]

There is a problem of undocumentation here.

@PatrickT 

Maple 13.02 produces the same error message. The problem seems to be that Algebraic:-RecursiveDensePolynomials:-rpoly does not handle symbolic coefficients. Replacing them with numbers makes it work:

with(Algebraic:-RecursiveDensePolynomials):
V := Vector([[a4*X[2]^2+a1*X[1]+a5*X[1]*X[2]+a2*X[2]+a3*X[1]^2],[(b1*X[1]+b2*X[2])^2]]):
eval(V[1],zip(`=`,[op(indets(V[1],suffixed(a)))],[seq(1..5)]));
rpoly(%,[X[1],X[2]]);
op(2,%);
                 2                                       2
           4 X[2]  + X[1] + 5 X[1] X[2] + 2 X[2] + 3 X[1]

                  2                             2
            3 X[1]  + (1 + 5 X[2]) X[1] + 4 X[2]  + 2 X[2]

                       [[0, 2, 4], [1, 5], [3]]

There is a problem of undocumentation here.

See also here about such a "strong assumptions context" and theorem provers. It sounds to me that such a check mechanism could be introduced in a way similar to the protected mechanism, by using attributes. It would be better though, if the assume mechanism used also attributes, instead of assignment of auxiliary variables.

See also here about such a "strong assumptions context" and theorem provers. It sounds to me that such a check mechanism could be introduced in a way similar to the protected mechanism, by using attributes. It would be better though, if the assume mechanism used also attributes, instead of assignment of auxiliary variables.

@eithne The point is, in my opinion, that statements like:

Mathematics: Updates to the VectorCalculus, DifferentialAlgebra, MathematicalFunctions, and Student packages, the convert command, and tools for solving differential equations

and

just incremental improvements/fixes to existing features.

provide too little useful information. If your purpose is that the users guess the changes, it is OK.

But I believe that the users deserve better information, and what I would expect from you is a list in clear, explicit and detailed style. Something like: this command in the VectorCalculus package produced this output and now it was improved to this other one, etc. Certainly, if you have that information internally, I do not see the point of not providing it to the users. It cannot be too much work. 

@acer My question is clearly about this Standard GUI display behavior, not about your workaround.

@acer My question is clearly about this Standard GUI display behavior, not about your workaround.

I have posted quite a number of complaints during the beta and initial period of primes 2. Most of them were about serious issues. My understanding is that the administrators are aware of them, but they were not addressed up to now. So, until there is a positive change in this regards, I do not see any reason for me to add more complaints to the list.

Acer, isn't the need to use ascii output a step backward?

Acer, isn't the need to use ascii output a step backward?

@David 

Yes, either use forward slashes "/" or double backslashes "\\".

@David 

Yes, either use forward slashes "/" or double backslashes "\\".