One solution could be to use one customized list class with the following
feature.
1. print([]) ---> None
2. print([x]) ---> x
3. print([a,b,c]) ---> [a,b,c]
This allows to always have the same kind of object from Python view, and to
keep one explorary mode from one console point of view.
I really don't think that is a good idea to return one "poly-typic"
solution, it is not a good practice. One class, one function must return
only one type of object.
It is simplier to use
* for oneSolution in TheSolutions:*
* ....*
rather than to have to do
*if type(theSolutions) == "list": *
* ...*
* else:*
* ...*
C.
2012/6/3 Joachim Durchholz <[email protected]>
> Am 03.06.2012 10:49, schrieb [email protected]:
>
> 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.
>>
>
> In mathematical daily work, such assumptions remain implicit.
> If SymPy forced every user to make such assumptions explicit, that would
> make using it much more hassle.
>
> In general, I'm quite sceptical about making all assumptions explicit.
> It's rigorous and useful for proof work, but it's unsuitable for
> exploratory mode.
> As an extreme example of rigor, take Principia Mathematica (Whitehead &
> Russell). They stopped after volume III due to "intellectual exhaustion",
> which isn't suprising given that they needed pages to prove that 1+1=2
> (which isn't as ridiculous as it may sound, but still too much effort for
> too little effect for most mathematical purposes).
>
> My personal idea of typical SymPy usage is that it's more exploratory than
> proof, so I'd prefer making SymPy accept more variation over making SymPy
> require more assumptions.
> That said, I'm aware that that's not necessarily the direction that you're
> ultimately aiming for. In that case, all I mean to say that any solution to
> the problem at hand should not urge us towards requiring more 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.
>>
>
> Does he?
> If all single-parameter functions accept lists and single values alike,
> doing the Right Thing (TM) on lists, is there still a need to distinguish?
>
>
> --
> 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 sympy+unsubscribe@**
> googlegroups.com <sympy%[email protected]>.
> For more options, visit this group at http://groups.google.com/**
> group/sympy?hl=en <http://groups.google.com/group/sympy?hl=en>.
>
>
--
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.
