Solve produces inconsistent results when a dummy variable is involved

[afleckenstein]

When working on the documentation for solve, the doctests mysteriously
failed after adding to the examples section. The parts that I added
weren't complained about, so I decided to do some manual testing.

If you solve an equation and the answer has a dummy variable, it
produces the correct result. However, if you try to solve the same
equation, the answer is different, but is still mathematically
correct. The coefficient of the dummy variable went up some integer
amount. If you tried to solve the equation again, the coefficient went
up again (by the same amount.) This was really a pain when trying to
do doctests and I couldn't figure out why they failed when I hadn't
touched the parts that failed.

I've already opened a trac ticket, #12809, which has more detailed
information.

[rjf]

I think this was posted twice, and the version I answered (and my
answer)
were deleted..

Anyway, this report does not reveal a bug in Maxima's solve. The
poster
agrees the answer is mathematically correct.

It is a bug in doctest. Further, I suspect it is a substantial design
flaw in the doctest concept, not amenable to a simple patch.

RJF

[William Stein]

On Fri, Apr 6, 2012 at 3:27 PM, rjf <fat...@gmail.com> wrote:
> I think this was posted twice, and the version I answered (and my
> answer)
> were deleted..
>
> Anyway, this report does not reveal a bug in Maxima's solve. The
> poster
> agrees the answer is mathematically correct.

It's definitely not a bug in solve.

> It is a bug in doctest.

No it's not.

>  Further, I suspect it is a substantial design
> flaw in the doctest concept, not amenable to a simple patch.

No it is isn't. See the ticket for an explanation:
http://trac.sagemath.org/sage_trac/ticket/12809

It does suggest we may want to consider reseting Maxima's counter for
dummy variables before calling solve. RJF, how does one do that in
Maxima?

[Nils Bruin]

On Apr 6, 3:55 pm, William Stein <wst...@gmail.com> wrote:

> It does suggest we may want to consider reseting Maxima's counter for
> dummy variables before calling solve.  RJF, how does one do that in
> Maxima?

I'm fairly sure that would lead to bugs. If a user constructs new
equations from the results of an earlier solve, then Maxima should
ensure that newly generated variables do not intersect with the
variables already occurring. Maxima currently does this by assuming
that users won't use variables of the form z1,z2,... by themselves and
by ensuring that it generates a monotone series. If you violate the
first assumption you can already get nonsensical responses:

sage: var('z1')
sage: solve( sin(z1)==cos(z1), z1, to_poly_solve=True)
[z1 == 1/4*pi + pi*z1]

This is actually a flaw in the maxima-to-sage translation:

(%i1) load(to_poly_solver);
(%o1) ...
(%i2) display2d: false;
(%o2) false
(%i3) to_poly_solve([sin(z1)=cos(z1)],[z1]);
(%o3) %union([z1 = (4*%pi*%z1+%pi)/4])

[Note %z1; not z1]

And maxima seems smart about avoiding collisions anyway:

(%i1) load(to_poly_solver);
(%o1) ...
(%i2) display2d: false;
(%o2) false
(%i3) to_poly_solve([sin(%z1)=cos(%z1)],[%z1]);
(%o3) %union([%z1 = (4*%pi*%z2+%pi)/4])

[note the use of %z2 instead of %z1]

so perhaps if we can ensure maxima uses "z" as prefix rather than "%z"
we might already be OK, and perhaps even reset the counter. Then
again, perhaps there might not be a counter:

(%i1) %z1=1;
(%o1) %z1 = 1
(%i2) load(to_poly_solver);
(%o2) ...
(%i3) display2d: false;
(%o3) false
(%i4) to_poly_solve([sin(x)=cos(x)],[x]);
(%o4) %union([x = (4*%pi*%z2+%pi)/4])

so it may simply be that the symbol %z1 already exists (and never
ceases to exist, because interned)

[Andrew Fleckenstein]

On Fri, Apr 6, 2012 at 9:58 PM, Nils Bruin <nbr...@sfu.ca> wrote:

On Apr 6, 3:55 pm, William Stein <wst...@gmail.com> wrote:

> It does suggest we may want to consider reseting Maxima's counter for
> dummy variables before calling solve.  RJF, how does one do that in
> Maxima?

I'm fairly sure that would lead to bugs. If a user constructs new
equations from the results of an earlier solve, then Maxima should
ensure that newly generated variables do not intersect with the
variables already occurring. Maxima currently does this by assuming
that users won't use variables of the form z1,z2,... by themselves and
by ensuring that it generates a monotone series. If you violate the
first assumption you can already get nonsensical responses:

This is why I was tentative to immediately try to figure out how to reset the counter. 

If we want to keep this functionality, the most straightforward (though the most tedious) solution

is to change all of the doctests. On the ticket (http://trac.sagemath.org/sage_trac/ticket/12809)

William mentioned that changing the counter to an ellipsis in the examples would be "perfectly reasonable."

Now that I think of it, all of the doctests would have to be changed anyway, even if we decided to reset

the counter.

Cheers,

Andrew

[rjf]

On Apr 6, 3:55 pm, William Stein <wst...@gmail.com> wrote:

> On Fri, Apr 6, 2012 at 3:27 PM, rjf <fate...@gmail.com> wrote:
>....

>
> > It is a bug in doctest.
>

> (WS) No it's not.

>
> >  Further, I suspect it is a substantial design
> > flaw in the doctest concept, not amenable to a simple patch.
>
> No it is isn't. See the ticket for an explanation:http://trac.sagemath.org/sage_trac/ticket/12809

Yes, it is a flaw in the doctest design.
If the answer is mathematically correct and it is in a simplified form
(which may present issues..)
then it should be accepted as correct.

If you want doctest to test for other properties (like is the
character string identical) then it
will product bogus failures.

Testing to see if a result is (a) mathematically correct and (b)
simplified are interesting problems.

For example, the result of an indefinite integration is given only up
to a constant, so comparing
expressions, or evaluating at a point, cannot be used to prove the
result of integration (antidifferentiation)
is correct.

Simplification is another interesting task.

Maxima presumably does not use z4 as a dummy variable if it already
has a value.
It should not just increment a counter.

>
> It does suggest we may want to consider reseting Maxima's counter for
> dummy variables before calling solve.  RJF, how does one do that in
> Maxima?

I'm sure that one could determine this by looking at the source code.