Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove vacuous solutions from solve #14229

Open
ppurka opened this issue Mar 5, 2013 · 15 comments
Open

Remove vacuous solutions from solve #14229

ppurka opened this issue Mar 5, 2013 · 15 comments

Comments

@ppurka
Copy link
Member

ppurka commented Mar 5, 2013

Sometimes solve and its variants tend to report vacuous solutions. A recent one from ask.sagemath is the following:

sage: x,y = var('x,y')
sage: solve([x^2*y^2 <= x^2*y, x^2*y^2 > x^2*y],[x,y])
[[x == 0, 1 < y, 0 != 0], [x == 0, y < 0, 0 != 0]]

Shouldn't we remove these meaningless solutions? The attached patch contains a potential solution. If it seems reasonable, then similar changes could be introduced in solve_ineq.

The output of the above command after this patch is as expected:

sage: x,y = var('x,y')
sage: solve([x^2*y^2 <= x^2*y, x^2*y^2 > x^2*y],[x,y])
[]

If you can translate this to maxima proper, please feel free to do so and submit a patch upstream.


Workaround: call maxima_calculus("domain: real") before solve (see comment 12).

CC: @kcrisman @jondo

Component: symbolics

Issue created by migration from https://trac.sagemath.org/ticket/14229

@ppurka ppurka added this to the sage-5.11 milestone Mar 5, 2013
@ppurka
Copy link
Member Author

ppurka commented Mar 5, 2013

Apply to devel/sage

@ppurka
Copy link
Member Author

ppurka commented Mar 5, 2013

comment:1

Attachment: trac_14229-remove_vacuous_solutions.patch.gz

@ppurka

This comment has been minimized.

@ppurka

This comment has been minimized.

@nbruin
Copy link
Contributor

nbruin commented May 26, 2013

comment:5

This kind of change should really be made to maxima, not to sage's postprocessing of what maxima returns.

@ppurka
Copy link
Member Author

ppurka commented May 26, 2013

Work Issues: port to upstream

@ppurka
Copy link
Member Author

ppurka commented May 26, 2013

comment:6

If someone knows how to translate this to maxima, please feel free to put this upstream. Thanks! [ I can not spend time in learning maxima right now. :( ]

@ppurka

This comment has been minimized.

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented May 27, 2013

comment:7

Helloooooooo !!

You remove equations that do not contain a variable, but couldn't 0=0 appear from time to time ? Secondly, can't the expression "bool(solution_list)" be costly from time to time ?

You could also write, later in the patch

sol_list = filter(_test_solution, string_to_list_of_solutions(repr(s)))

Nathann

@ppurka
Copy link
Member Author

ppurka commented May 27, 2013

comment:8

0==0 can appear, but bool(0==0) should evaluate to True. Which is fine by me. The point is to remove solutions which are clearly false. Anyway, this patch is going nowhere since nbruin suggests putting this upstream (I can not do that now).

EDIT: bool(solution_list) is done only when a symbolic expression (i.e., not a list of symbolic expressions) is input and there are no variables in the symbolic expression. This shouldn't introduce a significant slowdown. The solve function itself will probably take way more time than what these boolean checks will take.

@jdemeyer jdemeyer modified the milestones: sage-5.11, sage-5.12 Aug 13, 2013
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.1, sage-6.2 Jan 30, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.2, sage-6.3 May 6, 2014
@nbruin
Copy link
Contributor

nbruin commented Jul 18, 2014

comment:12

These vacuous solutions seem to arise from the fact that solving inequalities with domain: complex gives some problems, which is to be expected. So rather than trying to clean up the mess afterwards, we should find a way of setting domain: real in maxima before solving inequalities:

sage: sage: x,y = var('x,y')
sage: maxima_calculus("domain: real")
real
sage: sage: solve([x^2*y^2 <= x^2*y, x^2*y^2 > x^2*y],[x,y])
[]

See sage-devel too.

@nbruin
Copy link
Contributor

nbruin commented Jul 18, 2014

comment:14

One may be concerned with performance when we have to set these flags all the time. On the expect interface that's probably silly anyway, and on the library interface we can reach a little deeper and save some time:

sage: maxima_calculus(1) # make sure maxima_lib is initialized
sage: from sage.libs.ecl import EclObject,ecl_eval
sage: set_complex=ecl_eval("(defun sc () (setf $DOMAIN '$COMPLEX))")
sage: set_real=ecl_eval("(defun sc () (setf $DOMAIN '$REAL))")
sage: %timeit set_complex()
100000 loops, best of 3: 2.14 µs per loop
sage: %timeit maxima_calculus("domain: complex")
10000 loops, best of 3: 146 µs per loop

For comparison:

sage: %timeit solve([x<y],[x,y])
100 loops, best of 3: 4.6 ms per loop

so I think we can afford a little set_real.eval(); ...solve iquality; set_complex.eval();. We could keep a flag on what we set last and be lazy with flipping, but I expect that solving inequalities is relatively rare, and always slow, so we shouldn't slow down other operations with testing for a flag. To give you an idea, the following does call into maxima:

sage: %timeit integrate(x,x)
1000 loops, best of 3: 693 us per loop

@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.3, sage-6.4 Aug 10, 2014
@jondo
Copy link

jondo commented Feb 12, 2015

comment:16

Replying to @nbruin:

so I think we can afford a little set_real.eval(); ...solve iquality; set_complex.eval();.

So do you think this should be done in the Sage solve function when it detects inequalities?

@jondo
Copy link

jondo commented Feb 12, 2015

Changed work issues from port to upstream to none

@jondo

This comment has been minimized.

@mkoeppe mkoeppe removed this from the sage-6.4 milestone Dec 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants