Just to be clear. Little user code will be broken, because any correct
user code already checks whether the solution is a list or not. See
below for the exceptions.

>> I dislike this strongly. I would like to know if there are similar
>> sentiments in the community.
>
> I share this dislike. However, solutions do not come easy.

Great, However just making all return values into lists will not break
much code. It will break only code that has set correct assumptions to
ensure only one solution and thus it does not need to check whether
the result is a list.


> Take square roots for example.
> Usually, you expect zero, one, or two solutions.
> However, somebody working with geometries expects exactly one answer out of
> the square root in the calculation; for him, a square root has exactly one
> answer.

The correct way to deal with this is to set assumptions. I do not
think my question is related to this, as in you example the user still
needs to check whether he received a list or a single value. If he
sets assumptions correctly it will be a single value. If not, it may
be a single value, it may be a list.

> Mathematicians seem to deal with this by ignoring the difference between
> lists/tuples/sets and single values. This goes as far as neglecting to
> define the sine of a set of reals, taking for granted that sin(1, 2, 3) is
> defined as (sin 1, sin 2, sin 3).

I think that this comment is unrelated to the problem. I am talking
about one function with single arguments (solve with its standard
arguments) returning all its solutions (as it already does). The only
inconsistency I am talking about it that if there is only one solution
the solution is returned itself and not in an one-element list.

> It IS possible to take this kind of wilful imprecision to code. We'd need to
> make all SymPy-related single-argument functions to accept arbitrary
> containers as argument, and construct a similarly-structured data structure
> with the ground values replaced by the results of the single-argument
> variant.

Actually you described the numpy broadcasting rule. We have a bug
report about this[1], however it is not related to my question (see
last comment).

[1]http://code.google.com/p/sympy/issues/detail?id=537

-- 
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.

Reply via email to