x.simplify() or simplify(x) or both

[Ondrej Certik]

Hi,

I sent a patch implementing Basic.simplify():

http://groups.google.com/group/sympy-patches/browse_thread/thread/af95cd2b52745d2b

and we should discuss it with everyone, let's discuss it here.

Fabian:

"
I'm 0 for this. Don't see the need for this, I think that there are already
too many classmethods for Basic, and having sympify as a classmethod and as
a static method (same name, different arguments expected) would only confuse
users ...
"

Ondrej:

"
Yeah. I find it handy sometimes, but I agree with your point.

Others, what do you think?
"

Vinzent:

"
I think we should really decide which methods should be kept as class
methods and which not.

I don't like it for example that all linear algebra functions are an
attribute of Matrix.

Currently, it doesn't seem to be systematic or consistent. Maybe we
should discuss

* when to use class methods
* when to use static methods and
* when to use both.

Are there important reasons or motivations?
"

Let's get this discussed. We had this discussion before already:

http://groups.google.com/group/sympy/browse_thread/thread/f59919f28cfd2df6/843689054b06e55c#843689054b06e55c

But since sympy has matured a lot since then, it's time to revise it again.

Now I tend to think that only the very basic stuff should be part of
Basic and everything else should be implemented using regular
functions. In Mathematica you also can do everything using functions.
That way we can easily extend sympy and add more modules. We can add
deprecation warnings into Basic.limit() or Basic.integrate().

What do you think?

Ondrej

[Fabian Seoane]

Totally agree. We also should try to make Basic self-contained, that
is, no references to other modules that are not part of the code, that
is more elegant
and should make changing the core less painful ...

To my mind comes for example the method Basic.as_poly, which I think
is superfluous since it is in Basic, but there are no uses for this in
methods in the core
(why not use Poly() instead?)

Other related things: we should agree on how to name assumptions, I've
seen in the code is_integer and is_Integer, is_number and
is_Number ... we really need some
rules on coding style ...

>
>
> What do you think?
>
> Ondrej
>
> >

--------------------
Fabian Seoane
http://fseoane.net

[Fredrik Johansson]

On Fri, Oct 17, 2008 at 10:50 AM, Fabian Seoane <fabian...@gmail.com> wrote:
> Other related things: we should agree on how to name assumptions, I've
> seen in the code is_integer and is_Integer, is_number and
> is_Number ... we really need some
> rules on coding style ...

x.is_Integer means x is an Integer instance with a definite value;
x.is_integer means that it is any symbolic expression representing an
integer.

Fredrik

[Ondrej Certik]

See also this issue for our general assumptions rewrite:

http://code.google.com/p/sympy/issues/detail?id=1047

Ondrej

[Fabian Seoane]

I'm a bit confused ...
what is then the difference between x.is_Integer and isinstance(x,
Integer) ?

>
>
> Fredrik

[Vinzent Steinberg]

On Oct 17, 11:31 am, Fabian Seoane <fabian.seo...@gmail.com> wrote:
> I'm a bit confused ...
> what is then the difference between x.is_Integer and isinstance(x,  
> Integer) ?

AFAIK x.is_Integer is faster than isinstance(x, Integer).

Vinzent