Le mardi 14 décembre 2010 à 11:49 -0700, Aaron S. Meurer a écrit :
> 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.
So, even if we don't change anything else, I think we should make those
functions use _sympify instead of sympify, or perhaps remove
sympification entirely (after all, I don't remember anybody complaining
that 'simplify(1)' doesn't work, so why should 'cancel(1)'?).
> >> 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?
Obviously, we can't require the arguments of sympify() to be Basic,
which is why this was the first function I tried to "genericise". For
ordinary sympy functions, it allows to define new functions without
altering existing classes and to define new classes making use of
existing functions without altering them.
There are already plenty of functions that are effectively generic. They
use one of 3 mechanisms:
* 1) Call some predefined method on their argument (either
_eval_the_function or __the_function__)
* 2) Find a function whose name matches the argument class name inside
some namespace (usually a class): that's what printers and "ask
handlers" do.
* 3) Use ugly ad-hoc elif chains.
3) is unpythonic. 1) doesn't allow new functions without modifying the
core. 2) forces every new class to modify the functions' namespace.
> >
> >
> >> 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?
Actually, there are several reasons to do it:
* as I said, it allows us to say that sympify() always returns a sympy
object, i.e. an instance of Basic
* it's the only way to ensure that all arguments of Boolean expressions
are instances of Basic
* it would force us to clarify whether functions return a Boolean
expression or a built-in bool (in the latter case, None can often be
returned as well).
--
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.
