On 10/30/07, Fabrizio Caruso <caruso at dm.unipi.it> wrote:
>
> For example, could someone tell me how to have a test for the following
> command ...
A workaround: replace -(2*a*x^2+...)/4 by (-1/4)*(2*a*x^2+...).
However, this is not a good general solution. In general, a simplified
expression Q should be the same as parse_string(string(Q)) -- as well as to
expand(Q,0,0). This is currently not true in several cases:
* floating-point and bfloat numbers
* where intentionally blocks simplification (e.g. factor(36))
* CRE (rat) expressions where the variable order does not correspond to the
general simplifier's variable order
* -1/2*(a+b), which corresponds to the internal form (-1/2)*(a+b), but
prints as -(b+a)/2, which reads/simplifies as ( -1*b+ -1*a)/2
Are there other cases?
In the case of floats and bfloats, the Lisp world has long sought to have
reversible print algorithms, and I believe our Lisps use reversible print by
default for floats, but Maxima considers it more user-friendly (I guess) to
show a rounded result. Perhaps some setting of fpprinprec (true?) should
mean "print reversibly". We would still need to implement the appropriate
algorithm for blfoats.
In the case of factor, it is a bit of a hack that factor returns
unsimplified results, and this already causes other problems (e.g.
part(factor(36),1) => 4, not 2^2). I think we can ignore this case.
In the case of CRE expressions, the test result probably needs to be
expressed as ''(rat(...,x,y)).
Finally, we come to the -(b+a)/2 case. There are several issues here:
String should probably produce a reversible output, namely (-1/2)*(b+a).
This is arguably less readable, but seems OK.
Another, -1/3*(b+a) and -1*(b+a)/3 do not act consistently in the
parser/simplifier. The first one gives (-b-a)/3 and the second gives
(-1/3)*(b+a), and in fact (-b-a)/3 - (-1/3)*(b+a) does not simplify! On the
other hand, if we don't simplify -(a+b) to -a-b, then -(a+b)+a won't
simplify to -b without some rather messy cases in the simplifier.
I think some soft simplification should be allowed like parenteses and
> reordering.
We have previously had bugs in Maxima where the problem was that the
simplifier wasn't consistent about ordering or parentheses. These bugs
would not be detected in the test suite if we allowed "soft
simplification". And in fact one might well argue that your example has
found a bug -- though I suppose it is a misfeature in the sense that the
behavior is intentional.
-s