30 views

Skip to first unread message

Apr 4, 2012, 9:31:25 PM4/4/12

to sage-devel

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.

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.

Apr 6, 2012, 6:27:28 PM4/6/12

to sage-devel

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

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

Apr 6, 2012, 6:55:04 PM4/6/12

to sage-...@googlegroups.com

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.

> 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?

Apr 6, 2012, 9:58:23 PM4/6/12

to sage-devel

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
> 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?

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)

Apr 7, 2012, 7:44:25 AM4/7/12

to sage-...@googlegroups.com

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:I'm fairly sure that would lead to bugs. If a user constructs new

> 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?

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

Apr 7, 2012, 4:14:10 PM4/7/12

to sage-devel

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

>....

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.

>....

>

> > It is a bug in doctest.

>

> (WS) No it's not.
> > 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.

>

> 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.
> > 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

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?

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu