From: SourceForge.net <noreply@so...>  20040419 19:49:51

Bugs item #884300, was opened at 20040125 13:57 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve and ALL Initial Comment: Solve/algsys is inconsistent in how it represents the solution "all values satisfy the equation": solve([x=x],x) returns ALL solve([y=y],x) returns ALL solve([x=x],[x]) returns ALL solve([x=x],[x,y]) returns [[x = %R10, y = %R9]] solve([],[x]) returns [] First of all, the last case is simply wrong. The solution to "find all x such that the empty set of constraints is satisfied" is "all x", not "no x" (which is what [] means). After all, the y=y case above includes an equation which doesn't even mention x. The other cases are inconsistent. We should use one or the other. The %R10 approach (from algsys) seems better, because it is completely consistent with the non all case. Any program using Solve will have to make a special case for ALL otherwise. I would also argue that SOLVE_INCONSISTENT_ERROR should default to FALSE. That is, inconsistent systems should return [], not give an error.  >Comment By: Stavros Macrakis (macrakis) Date: 20040419 15:49 Message: Logged In: YES user_id=588346 A similar problem: solve( (x1)^2 = (1x)^2 , x) returns [x=x] and not ALL. This is actually worse than an inconsistency: since x appears on both sides of the solution, a calling program will assume that Solve failed to find a solution.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&group_id=4933 