On May 23, 2011, at 4:43 PM, Ronan Lamy wrote: > Le lundi 23 mai 2011 à 12:53 -0600, Aaron S. Meurer a écrit : >> On May 22, 2011, at 9:50 AM, Chris Smith wrote: >> >>> Ronan Lamy wrote: >>>> Le dimanche 22 mai 2011 à 14:38 +0545, Chris Smith a écrit : >>>>> >>>>> I think that sets make more sense, too, but it's useful to >>>>> have the >>>>> variables in the output, and dicts are the easiest way to >>>>> handle them. >>>>> What about using sets of frozen dicts? Frozen dicts aren't >>>>> builtins >>>>> but there are simple free implementations (I just adapted one >>>>> from >>>>> http://code.activestate.com/recipes/414283/), that work in >>>>> all python >>>>> versions. They can easily be converted to/from dicts and subs >>>>> should >>>>> be able to use them directly. >>>>> >>>>> The way 1694ms is designed now, the solve routine is just a wrapper >>>>> to _solve (which contains the core solving routines). It would be >>>>> easy to add keywords to control the output in any variety of ways. >>>>> _solve will return [(x1, x2, ...), (v11, v12, ..), (v21, v22, ...) >>>>> ...] where the xi are the symbols and vij is the jth solution for >>>>> variable i; solve can then remap this to whatever we decide upon. >>>>> >>>> But this can't generalise to infinite solution sets. Why do you want >>>> to >>>> repeat part of the input (the variables) in the output? In >>>> solve(Eq(x**2, 1), x), x should be a bound variable. If you put it in >>>> the output, you make it free. >>> >>> Because as long as we support symbol guessing (so solve(x - 3) works AND >>> solve([x + y - 2, x - y - 3]) works) we need to disambiguate the output for >>> the multi-equation system since it gives rise to ambiguity as I recently >>> showed: you can't know if you are getting x, y pairs or y, x pairs. >>> >>> We could say that the results will always be sorted according to the free >>> symbols of the equations if the symbols were guessed, but then the user has >>> to assemble that in order to interpret the output...which defeats the >>> purpose of symbol_guessing. If we had a free_symbols function then I guess >>> we could make it work with an iterable so someone could do >>> >>> eqs = [x + y - 2, x - y - 3] >>> syms = free_symbols(eqs) >>> solve(eqs, *syms) >>> >>> But with that much typing they may as well have just looked and typed x, y >>> after 'eqs,' So let's get rid of symbol guessing? >> >> -1. Even without guessing, referencing the solutions by the symbol >> makes things easier to read and to reference programmatically. It's >> much easier to say sol[x] than to figure out what position x was in and >> call sol[i]. > > OK, let's say it's a hassle to have to remember that x is in position 0 > after typing solve(equations, (x, y, z)) or to have to write > dict(zip(variables, solution)). The dict solution has bigger problems: > * no way to extend it to infinite solution sets
Why not? There are an infinite number of solutions, but still a finite number of variables. > * you need to remember the variable in the univariate case > * you can't use the solution without knowing the variables. This makes > it very cumbersome to use a function like the following: > def solve_stuff(...): > x, y, z = [Dummy() for _ in range(3)] > f = Lambda(...) > return solve(f(x, y, z), (x, y, z)) > * you can't cache solve results in any useful way, because solve(x-1) != > solve(y-1) > * putting the variables in the dict lets temporary symbols escape the > scope they were created in - this is exactly the kind of situation that > prevents Vinzent's local assumptions hack from making new-style > assumptions a viable alternative to the old ones. I don't understand how they escape the scope. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
