Two general remarks:
* it is hard to know what symptoms you are encountering when you speak in
generalities or suggest treatments rather than giving reproduceable examples
of problems
* the Maxima community in general does not in general support
user-contributed (contrib) code like GF, which may be incorrect, untested,
inefficient, incompatible, etc.
Now for the detailed remarks....
On Thu, Jan 21, 2010 at 2:20 PM, Oliver Kullmann
<O.Kullmann at swansea.ac.uk>wrote:
> As mentioned below, if one could force Maxima always to use just one
> representation, then all our problems would go away.
>
So THAT is the key to World Peace! I knew it was something simple.
> expand((x1+x2+x3)^200)$ -- using general
> representation
> > Evaluation took 1.8600 seconds (1.8600 elapsed)
> > rat((x1+x2+x3)^200)$ -- using CRE
> representation
> > Evaluation took 0.0300 seconds (0.0300 elapsed)
>
> We don't have such applications (likely; but it's not easy to find out
> since
> one cannot switch at a global level).
>
CRE is in general contagious for algebraic operations. So if you want fast
polynomial/rational-function calculations, your input should be in CRE form.
> Sure, for others it will be essential, but the current ambiguous state of
> things doesn't look well-designed.
>
The design is not perfect, and neither is the implementation.
> > It causes just a never-ending stream of problems. (Just remember the
> > apparently forgotten gf-package, which is in its most important
functions
> > not working because of CRE-problems.)
The gf package is in the "contrib" section, which means that it is
user-contributed code which may or may not work properly, may or may not be
tested extensively, and may or may not be compatible with other parts of the
system.
"When" refers to whether or not some Maxima-function will produce CRE or
> not.
> If this would be specified, then one could solve the CRE-problem at the
> source,
> that is, after calling the function we immediately convert the result to
> non-CRE-form.
>
I am not sure of the exhaustive list, but I believe that all functions in
the rational function section of the manual return CRE, except for ratsimp
and radcan. They all use CRE's internally. Beyond that, most mathematical
functions (sin, etc.) and most subroutines (integrate, etc.) perform a
ratdisrep on CREs before doing anything else. A few do not (diff preserves
CRE).
What particular ones are you concerned about?
With "historical baggage" I mean the not really peaceful coexistence of the
> two forms. I guess first only one form was there, then the second was
> added,
> in a kind of ad-hoc fashion.
>
Probably true, but we consider it a bug when there is not peaceful
coexistence, and these bugs generally get fixed (because they are almost
always trivial to fix).
> (%i1) gcdex (x*(y + 1), y^2 - 1, x);
> Evaluation took 0.0160 seconds (0.0225 elapsed) using 187.594 KB.
> (%o1) [0,1/(y^2-1),1]
>
You are apparently setting your display to 1-dimensional by setting
display2d:false in your initialization routine. I agree that the /R/
convention, to the extent that it's useful, should also work in 1-d
displays, but others have, if I remember correctly, disagreed.
> Programming at the Maxima-level. Regarding the gf-package, one just needs
> to run
> through the examples from the documentation to see that many are broken; if
> my
> student has the time he'll write (many) bug-reports.
>
I do not know if anyone is maintaining the user-contributed gf package.
> Otherwise it is just the case that for example we need to check polynomials
> for
> equality,
The test is(equal( expr1, expr2 ) ) should work correctly for any
combination of CRE or general representation expr<i>'s. If it does not, it
is a bug that should be fixed.
> or they are looked-up in a hash-table,
Could you please give a concrete example of how this fails?
> or simply in a list (possibly also a set), and that then one always has to
> worry which of the two forms
> is the polynomial in.
Please give concrete examples of the problems you're having. And please
keep in mind the difference between syntactic and semantic equality: x*(x-1)
is semantically equal to x^2-x, but not syntactically. Some operations are
syntactic, some semantic. The semantic ones are in general NOT guaranteed
since equivalence of algebraic expressions is in theory uncomputable and in
practice can be difficult (even when not impossible).
> If there is no global switch to force a single representation,
> then all what one can do is likely just to use the conversions on a
> case-by-case basis.
> For that it would be useful if the documentations would clearly say when
> CRE is
> produced; just consider for example gcd:
>
Could you please give concrete examples where you are having problems?
I believe gcd follows the general rule, that CRE is contagious. Internally,
GCD of polynomials (not numbers) is performed in CRE, thus
gcd((x-1)^3,(x-1)^2) returns x^2-2*x+1, not (x-1)^2.
The intent is that the user should not care whether an expression is
represented in CRE or general form in general. There are two kinds of
problem with that:
1) conceptual / black-box problems: that some simplifications do not apply
to CREs, e.g. rat(sqrt(x))^2 ==> sqrt(x)^2 (because sqrt(x) is treated as a
formal variable);
2) implementation problems: some subsystems do not work properly in the
presence of CREs
It is hard to tell from your mail whether you are running into (1), which is
unlikely to change, or into (2), which we try to fix as we find problems.
Note that we have similar problems with various kinds of number as well:
there are modules which do not handle floating-point or bigfloat, but only
integers and rational numbers. Sometimes this is inherent in their function
(what does it mean to factor a polynomial with approximate coefficients?),
but often it is a bug.
-s