On Dec 13, 2010, at 8:31 PM, Ronan Lamy wrote:
> Le mardi 07 décembre 2010 à 19:38 -0700, Aaron S. Meurer a écrit :
>> 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.
>
> The point is to avoid calling the conversion function when implementing
> an unrelated function. There are currently many methods and functions
> that call the full sympify() (with some inconsistencies:
> simplify('(1-x**2)/(1-x)') raises but cancel('(1-x**2)/(1-x)') works).
> In most or perhaps all cases, they should only perform coercion. If the
> user wants to use a string, they can wrap it with S() - explicit is
> better than implicit.
>
I see. I was thinking why have separate functions as opposed to one function
with a keyword argument, but I think either one could be reasonable in this
case. I do agree that sympy_function(string) is bad style and should be
discouraged at best.
>> Also, what is the generic stuff? The commit messages and docstrings
>> aren't very clear.
>
> Well, I'm not quite sure yet... The general idea is to allow a single
> function to call different implementations depending on the types of its
> arguments - like built-in functions such as len() or iter(), but without
> the special method name trick.
If we require everything to be Basic, what is the use of this?
>
>
>> 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)?
>
> Yes, I'm suggesting one of these. Also, I think we should have S.True
> and S.False and let S(True) and S(False) return these.
Why? Is this needed for the Boolean stuff?
Aaron Meurer
>
>>>
>>> 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.
>
--
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.
