On Apr 20, 2011, at 6:12 PM, Ronan Lamy wrote: > Le mercredi 20 avril 2011 à 17:38 -0600, Aaron S. Meurer a écrit : >> On Apr 20, 2011, at 5:15 PM, Vinzent Steinberg wrote: >> >>> On Apr 20, 8:55 pm, "Aaron S. Meurer" <[email protected]> wrote: >>>> The Solution class is indeed a good idea. >>>> >>>> I think it would be best to have a unified data structure independent of >>>> the number of solutions. The reason is that it is not clear from the >>>> outset how many solutions an equation or system of equations will have. >>>> That is why I think it would be better to have a list always or a >>>> dictionary always (or a list of dictionaries always). The list of >>>> dictionaries idea is one of the better ones, in my opinion. >>> >>> Should the Solution() class also represent subspaces which solve e.g. >>> an undetermined linear equation system? >>> >>> Vinzent >> >> Did you mean "underdetermined"? If so, then I think yes. As I was >> saying in a previous email, the cleanest way to handle a solution with >> parameters will be a class like this, I think. For example, the >> parameters will have to be dummy variables, so they will have to be >> accessible by themselves, i.e., we would have to return them along >> with the solution somehow. This can get messy if we return something >> using just builtin data types. And you should be able to pass a >> Solution class to solve along with some additional constraints to >> solve for some of the parameters. That sort of thing should be useful >> when solving ODEs or PDEs, for example. > > I *really* think solve() should return a Set, not an ill-defined ad-hoc > structure. Infinite solution sets don't necessarily have a parameter > (for instance x == tan(x)), or they could be more than one family of > solutions or more than one parameter, or the solution set could contain > families with different dimensionalities. There are a lot of possible > situations but they can all be represented by a set, because that's what > solving an equation means: finding the set of values of the variables > for which the equation holds. >
I see. You mean a generalized Set class that uses set builder notation. Yeah, I guess you are right, then. If there are any things we want Solution() to do that Set() wouldn't do, we could just make a Solution class that subclasses from Set. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
