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