Opened 9 years ago
Last modified 6 months ago
#2617 new defect
solve() can return undefined points as "solutions"
Reported by: | cwitty | Owned by: | was |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | calculus | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: | todo |
Description
Consider the following examples (reported by Dean Moore here: http://groups.google.com/group/sage-support/browse_thread/thread/5555e780a76b3343#)
sage: solve(sin(x^2)/x == 0) [x == 0] sage: solve(sin(x^2)/x^2 == 0) [x == 0] sage: solve(sin(x^2)/x^3 == 0) [x == 0]
None of these functions are even defined at x=0, so that should not be returned as a solution. (The first two functions can be extended to x=0 by taking limits, in which case x=0 is a solution to the first one but not the second; the third function has a vertical asymptote at x=0.)
Change History (17)
comment:1 Changed 9 years ago by
- Priority changed from major to critical
comment:2 Changed 8 years ago by
This is a Maxima bug as of 5.16.3, and has been reported there as 2845005 (see http://sourceforge.net/tracker/?func=detail&aid=2845005&group_id=4933&atid=104933).
comment:3 follow-up: ↓ 4 Changed 8 years ago by
Perhaps related issue is also that the solving acot(x) == 0 ends with error message "The number 0 isn't in the domain of cot"
The online tool Mathatmatical Assistant on Web ( http://user.mendelu.cz/marik/maw/index.php?lang=en&form=main ) has a wrapper for maxima's solve ( http://mathassistant.cvs.sourceforge.net/viewvc/mathassistant/maw/common/maw_solve.mac?revision=1.14&view=markup )
I hope, it could be used also in Sage. I'll try it, hope within a week.
comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 8 years ago by
Replying to robert.marik:
Perhaps related issue is also that the solving acot(x) == 0 ends with error message "The number 0 isn't in the domain of cot"
No, this is an appropriate error message (it's from Maxima, not Sage). There are no solutions to acot(x)==0, at least over the reals (and presumably over the complex field as well?). Now that we know about that error, it would be easy to put a catch in for something like that error message and return sage: solve(acot(x),x) [] instead. Feel free to open a ticket for that and put me in the cc: field.
But this is unrelated to the issue in the ticket, which is a genuine Maxima bug, as far as I can tell.
comment:5 in reply to: ↑ 4 Changed 7 years ago by
- Report Upstream set to N/A
Replying to kcrisman:
Replying to robert.marik:
Perhaps related issue is also that the solving acot(x) == 0 ends with error message "The number 0 isn't in the domain of cot"
No, this is an appropriate error message (it's from Maxima, not Sage). There are no solutions to acot(x)==0, at least over the reals (and presumably over the complex field as well?). Now that we know about that error, it would be easy to put a catch in for something like that error message and return sage: solve(acot(x),x) []
This will be addressed (not the main point of this ticket) in the patch for #7745. The main point is still a bug in Maxima 5.20.1.
comment:6 Changed 7 years ago by
I had an idea to introduce new option to solve, which
- Takes only explicit solutions
- Substitutes into equation and if an error appears, removes this "solution" from the list.
The problem in this approach is, that for example ln(0)=-Infinity in Sage and so x=0 will be still reported as a solution of x/ln(x)=0. The problem could be solved by substituting values in Maxima and not in Sage, but I am still thinking on some cleaner solution. And still have no idea what should be returned as solution of x*ln(x-3) == 0. Distinguish in this new option, if the user works in real domain or in complex doman? Something like check_domain = False, True, or 'real'?
Any idea?
comment:7 Changed 7 years ago by
As it turns out, to_poly_solve can handle this sort of thing (see in Maxima the share/contrib/rtest_to_poly_solver.mac line 1092). But we would have to figure out a way to interpret the if statements properly (for instance, to note that twice an integer plus one is not zero).
/* Sage Ticket 2617; see also Sage mailing list 18 March 2008 */ nicedummies(to_poly_solve(sin(x^2)/x,x)); %union(%if(2*%z0+1 # 0,[x = -sqrt(2*%pi*%z0+%pi)],%union()), %if(2*%z0+1 # 0,[x = sqrt(2*%pi*%z0+%pi)],%union()), %if(%z1 # 0,[x = -sqrt(2)*sqrt(%pi)*sqrt(%z1)],%union()), %if(%z1 # 0,[x = sqrt(2)*sqrt(%pi)*sqrt(%z1)],%union()))$ nicedummies(to_poly_solve(sin(x^2)/x^2,x)); %union(%if(2*%z0+1 # 0,[x = -sqrt(2*%pi*%z0+%pi)],%union()), %if(2*%z0+1 # 0,[x = sqrt(2*%pi*%z0+%pi)],%union()), %if(%z1 # 0,[x = -sqrt(2)*sqrt(%pi)*sqrt(%z1)],%union()), %if(%z1 # 0,[x = sqrt(2)*sqrt(%pi)*sqrt(%z1)],%union()))$ nicedummies(to_poly_solve(sin(x^2)/x^3,x)); %union(%if(2*%z0+1 # 0,[x = -sqrt(2*%pi*%z0+%pi)],%union()), %if(2*%z0+1 # 0,[x = sqrt(2*%pi*%z0+%pi)],%union()), %if(%z1 # 0,[x = -sqrt(2)*sqrt(%pi)*sqrt(%z1)],%union()), %if(%z1 # 0,[x = sqrt(2)*sqrt(%pi)*sqrt(%z1)],%union()))$
comment:8 Changed 6 years ago by
- Priority changed from critical to major
comment:9 Changed 4 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:10 Changed 3 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:11 Changed 3 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:12 Changed 3 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:13 Changed 21 months ago by
- Stopgaps set to todo
comment:14 Changed 12 months ago by
SO, has this issue been fixed yet? What of kcrisman and robert.marik's suggestions? Also is there a reason that there is no branch to edit?
comment:15 Changed 12 months ago by
Presumably not fixed. No branch because no one has posted one yet - if you have a fix you can be the first to post a branch!
comment:16 Changed 6 months ago by
kcrisman, in your post (from 7 years ago) you had mentioned to_poly_solve in maxima's share/contrib. It's been a while since then, so it is not located there anymore. I couldn't find it anywhere in Maxima's source on github though, so i wasn't sure if it was still used at all. Does sage/maxima use it at all?
I've been looking at several old tickets, all involving solving equations. One was using find_root, which uses scipy, and the other had to do with solve just like this one. I think it would be best to just have one, no? As far as I can tell, they do about the same thing, and they both have issues. On a similar note, if to_poly_solve resolves this issue, then maybe we should use that for all equation solving?
comment:17 Changed 6 months ago by
We definitely have that method and it is still in Maxima. Looks like it moved to https://sourceforge.net/p/maxima/code/ci/master/tree/share/to_poly_solve/.
However, find_root
is explicitly supposed to be a numerical solver, while solve
is supposed to be an exact solver. Because to_poly_solve
sometimes returns numerical answers in rare situations, there could be some overlap. Also, to_poly_solve
is not what we want for all solving, because it changes some other things and of course might take longer for simple ones. It has a specific purpose, but that is not a general purpose.
On the other hand, if sympy can now solve everything Maxima does, one could try to switch the default algorithm to use that instead. I don't know if we're at that point, though.
Is this a bug in Maxima? In that case we should report those to them? This also seams like a fairly serious issue, so I am elevating this to critical.
Cheers,
Michael