Ah, but I see, something like 1 + '1' doesn't work. Coercion means automatic
conversion in an operator or function call. So even then, I don't see the need
for two separate sympify functions.
Also, what is the generic stuff? The commit messages and docstrings aren't
very clear.
Aaron Meurer
On Dec 7, 2010, at 7:34 PM, Aaron S. Meurer wrote:
> So are you suggesting that S(list) shouldn't work then (or else return a
> Tuple or whatever)? As for the difference between coercion and conversion,
> aren't they normally the same in Python anyway? For example, int(3),
> int(3.0), and int('3') all return 3.
>
> Aaron Meurer
>
> On Dec 7, 2010, at 5:24 PM, Ronan Lamy wrote:
>
>> Le lundi 06 décembre 2010 à 13:05 -0800, Ondrej Certik a écrit :
>>> On Mon, Dec 6, 2010 at 11:29 AM, smichr <[email protected]> wrote:
>>>>> The similarity between "simpify" and "simplify" is misleading.
>>>>
>>>> Yes, that would be...but it's SYMpify not SIMpify. But yes, they are
>>>> close. I (as has been pointed out) almost exclusively use S() and so
>>>> it's not a problem. Would there be any reason not to delete sympify
>>>> from the namespace and just provide S() as the standard conversion
>>>> call name?
>>>
>>> It seems like a good plan if everybody agrees. I believe S is some
>>> other global object, so it should be renamed and S should be a
>>> function. sympify() should return a deprecated warning for some time,
>>> before we remove it.
>>
>> I don't really have an opinion on the naming issue, but it seems
>> relevant to mention an insight I've had while trying to implement
>> generic functions and to refactor sympify() as such a generic function
>> (see http://github.com/rlamy/sympy/tree/generic ).
>>
>> So, the idea is that sympify(), as currently implemented, mixes two
>> distinct concepts: coercion and conversion. The difference between the
>> two can be hard to grasp but it corresponds quite well to the difference
>> between the internal-use function _sympify() and plain sympify().
>>
>> Coercion is the transformation of an object that is already conceptually
>> a sympy object into an actual sympy object, for example the
>> transformation of a Python int into a sympy Integer. End users are only
>> meant to use it implicitly, usually by using binary operators. For
>> instance, in the expression 'Integer(1)/3', the int instance '3' is
>> coerced to 'Integer(3)'.
>>
>> Conversion, on the other hand, is an explicit request to take any object
>> and return a sympy object. For instance, in 'S("1/3")', the string "1/3"
>> is converted to 'Rational(1, 3)'.
>>
>> If we want a consistent and easily explainable system, I think that the
>> two concepts should be clearly separated and that the result of both
>> should only ever be a sympy object (i.e. an instance of Basic).
>>
>> --
>> 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.
>>
>
--
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.
