I would like to ask an expert to point out the cause of the error
detected in the computation shown below.
Thanks in advance.
expre := 2*e**( - 2*nu + 2*psi)*(
- df(nu,r,2) - df(nu,z,2) + df(psi,r,2) - df(psi,r)**2
+ df(psi,r)*r**(-1) + df(psi,z,2) - df(psi,z)**2);
- 2*nu + 2*psi
expre := 2*e *( - df(nu,r,2) - df(nu,z,2) + df(psi,r,2)
2 -1 2
- df(psi,r) + df(psi,r)*r + df(psi,z,2) - df(psi,z) )
factorize num expre;
2*psi 2*psi 2*psi
***** - 2*e *df(nu,r,2) - 2*e *df(nu,z,2) + 2*e *df(psi,r,2)
2*psi 2 2*psi -1 2*psi
- 2*e *df(psi,r) + 2*e *df(psi,r)*r + 2*e *df(psi,z,2)
- 2*e *df(psi,z) invalid as polynomial
***** Continuing with parsing only ...
If I look at what "num" gives on that then in ways that may be bad but that are liable to be a consequence of "on combineexpt" it ends uip with a "r^(-1)" in it. If go "off combinexexpt" things behave better!!!
I suspect one issue here is that the factoriser was coded in the expectation that it was to factorize polynomials, so having almost ANY odd switches that mess with exponents or how fractions are formed or how things are simplified other than the default way may pain it - as might having non-integer coefficients (as in "on rounded").
If I put "../r" rather than "...*r^(-1)" in your original that also avoids combineexpt preserving the negative exponent and causing pain. I think I believe that combineexpt is intended for cases where you have square roots etc around and is just hurting here.
But wrt this and any other issues, I am a bit swamped with an exam period and will hardly surface for another fortnight (then I just have to worry about helping celebrate actually taking their degrees, or picking up the mess if they have not done well enough) so if any of the other developers have some free time at present and can look into thinngs that would be GREAT!
The response to the comments by A.Norman
> If I look at what "num" gives on that then in ways that may
> be bad but that are liable to be a consequence of
> "on combineexpt" it ends uip with a "r^(-1)" in it.
> If go "off combinexexpt" things behave better!!!
It will not. The point is that the example presented is only
a model of a small fragment torn out from a more lengthy computation
which just utilizes (or intends to utilize, to be more precise)
the functionality of "on combineexpt" facility.
Moreover, this point (the failure of a specific computation) is
not of a major interest (I'll explain below why).
> I suspect one issue here is that the factoriser was
> coded in the expectation that it was to factorize polynomials,
> so having almost ANY odd switches that mess with exponents
> or how fractions are formed or how things are simplified
> other than the default way may pain it - as might
> having non-integer coefficients (as in "on rounded").
So, "combineexpt" is an 'odd' switch? in what respect and
under what conditions? what limitations its use imposes?
are these pointed out in documentation?
> If I put "../r" rather than "...*r^(-1)" in your original
> that also avoids combineexpt preserving the negative
> exponent and causing pain. I think
> I believe that combineexpt is intended for
> cases where you have square roots etc around and
> is just hurting here.
This fact is a useful observation, certainly, but not
a problem solution.
As a matter of fact, the failure shown in example
displays the effect arising in a more lengthy computation
and the expression, generated here as output of "num",
which must be a polynomial but is not, arises irrespectively
to the way of the coding of input data.
It should be emphasized, that most likely the meaning of
the trouble is more serious than simply an odd fault of
a single computation. At the final stage, it is manifested
by appearance of a term with a _negative_ power in a polynomial.
This is not an illusion (the form of output) as one may ascertain
inspecting its SQ-form. A negative power presents, actually.
Then, probably, the basic data structure standard is violated
(the question for experts: may a polynomial in Reduce
include negative powers in SQ-representation? probably not...)
and one may suppose that any routine dealing with
polynomials would fail to handle such data.("factorize"
is one of them used for demonstration purposes exclusively).
It is in order to separately emphasize here that such an effect
was absent in older reduce versions (3.7, 3.6, for example).
That's why it is unlikely, for a user, that "combineexpt" should
be treated as basically odd mode used here in an improper way.
So, there is a reason to suppose that the upgrading 3.7 (1999)
-> 3.8 (2009) had been accompanied with the creeping a bug
coming to life if "combineexpt" is on which is able to notably
deteriorate algebraic processor capabilities.
Is it wrong?
Apologies if you did not find my attempt at a quickish response helpful. As per my previous message I am under some pressure from other parts of my life so I *MAY* be able to come back to look more in a couple of weeks, and your explanation that the particular effect you note did not arise in 3.7 gives at least a further chance to look. But I think one of my views on all this is that the transition to an open source version could easily have been associated with all sorts of bugs being in place at present, since the open source release is based on a development snapshot rather than a version that will have had the testing that went into 3.7 and 3.8 before they were released... but being now open source anybody can help track down exactly what the cause is of anything they do not like4, and anybody who had the "professional" releaser of 3.7 or 3.8 (ie with all the source code) can run comparisons and tests and help try to work out just what has got broken.
If you still have an earlier version it might be really helpful if you can seek the smallest possible example where 3.7 and the current open source release show changes that hurt...
Again I rather hope that one of the developers other than me will join in looking too. I can write as co-author of the factorizer (and from that somewhat strange perspective almost all flags and options are odd!).