On May 23, 2011, at 6:23 PM, Ronan Lamy wrote:
> Le lundi 23 mai 2011 à 18:01 -0600, Aaron S. Meurer a écrit :
>> 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.
>>
> Sure, but the problem is how to return an infinity of dicts. With just
> the values, you can have solve(x**2 > 1) == Interval(-1, 1). How do you
> handle that with dicts?
{x: Interval(-1, 1)}
>
>>> * 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.
>>
> Consider the solve_stuff example above: the dummy variables are the keys
> of the returned dicts and become therefore visible outside the function.
Yeah. I don't see how to solve that problem without having a solution class.
If you had a solution class, it would be easy, because you could just not put
the variables in the .free_symbols.
By the way, what do you think about extending RootOf and making that our
solution class?
Also, since whatever we do would break compatibility, why don't we just leave
it as it currently is until we can implement a nice solution class.
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.
