Re: [sympy] Using methos rather than funtions
On Thu, 14 May 2020 at 08:01, David Bailey wrote: > > > Well I assumed all along that Poly objects were a much more efficient way of > representing polynomials - presumably an array of tuples of coefficients and > exponents where the coefficient is non-zero. If these things are all > converted back before the user gets the result, that is just fine. The > comparison with Mathematica is interesting, but maybe lead me astray. There > there are multiple types of objects (e.g. integers, integer arrays, etc) that > behave and display identically to users but have a different internal > structures and iner-rconvert silently as required. I'm not familiar with Mathematica myself but the way this works in sympy is that an expression will be converted to Poly internally by algorithms that need it. For example when calling factor(expr) the expression will be converted to a Poly and the factorisation algorithm is performed with the resulting Poly. This happens internally though so that from the user perspective factor is called with Expr and returns Expr. The Poly class is available to users for doing efficient calculations with polynomials but to get the advantages of the efficient calculations you need to be clear that you are using Poly and not mix it up with Expr. This is similar to the way in Python that you need to be careful not to mix floats into a calculation that involves ints. Provided you don't input any floats most operations with int will give int. There is one exception though in Python 3 which is that dividing two ints gives a float so division is the operation to be careful about. This is done because in general the ratio of two integers is not an integer. Sometimes it is an integer but it's important that the type of the output be predictable so a float is always returned even if the result could be an int. Likewise with Poly most operations will give Poly e.g. Poly+Poly->Poly but division will always give Expr: Poly/Poly->Expr. -- Oscar -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxT-CPASgNJ4Dooj%2BA2dr-m5bJA-D-gzJK_CAt7WJuK-Yw%40mail.gmail.com.
Re: [sympy] Using methos rather than funtions
On 14/05/2020 01:13, Oscar Benjamin wrote:
On Wed, 13 May 2020 at 23:39, David Bailey wrote:
Dear Group,
I notice this item in the highlights of 1.6.
DEPRECATION: Passing Poly as the integrand to the integrate function or
Integral class is now deprecated. Use the integrate method instead e.g. Poly(x,
x).integrate(x)
I do feel a little uneasy about pushing people to use object oriented syntax
rather than the integrate function is undesirable. I mean for mathematicians
and others who have not come across object oriented programming, I would have
thought the dot notation does not come naturally and will confuse because it
suggests a product! This notation is also alien to Mathematica, which many will
be familiar with.
Hi David,
Perhaps this is similar to the other thread in that the release note
emphasises what someone should worry about in case their code might
break rather than what the real rationale for the change is.
Poly objects are not something that most users need to use. For
example you can integrate a polynomial like this:
>>> from sympy import Symbol, integrate
>>> x = Symbol('x')
>>> p = x**2 + x
>>> integrate(p, x)
x**3/3 + x**2/2
This integrates a polynomial just fine. The object p here would be
known mathematically as a polynomial but in sympy jargon it is an
instance of Expr rather than of Poly. Poly is a class separate from
Expr that has different methods and behaves in different ways and is
intended to be used in particular contexts where every object is known
to be a polynomial and more general expression classes are
unnecessary.
What has changed in sympy 1.6 is that Poly is no longer a subclass of
Expr and the ways in which Poly and Expr can be interchanged have been
reduced. For example in sympy 1.5.1 you can do:
>>> from sympy import Poly, Symbol, exp
>>> x = Symbol('x')
>>> p = Poly(x**2, x)
>>> p
Poly(x**2, x, domain='ZZ')
>>> p * exp(x)
x**2*exp(x)
What happened here is that we had a Poly but then we multiplied it by
something that couldn't be represented as a Poly because x**2*exp(x)
is not polynomial in x so the result was implicitly converted to an
Expr. Had we multiplied by something else the result might have been a
Poly:
>>> p*x
Poly(x**3, x, domain='ZZ')
So sometimes Poly*Expr gives an Expr and sometimes a Poly. This is not
easy to work with programmatically because Poly and Expr have
completely different methods and attributes.
In SymPy 1.6 Poly and Expr are more clearly separate. The calculation
above will still be the same but will give a warning:
>>> from sympy import Poly, Symbol, exp
>>> x = Symbol('x')
>>> p = Poly(x**2, x)
>>> p * exp(x)
/Users/enojb/current/sympy/sympy/sympy/polys/polytools.py:74:
SymPyDeprecationWarning:
Mixing Poly with non-polynomial expressions in binary operations has
been deprecated since SymPy 1.6. Use the as_expr or as_poly method to
convert types instead. See https://github.com/sympy/sympy/issues/18613
for more info.
SymPyDeprecationWarning(
x**2*exp(x)
This is showing that if you wanted a product like Expr*Expr -> Expr
then you should convert the Poly to Expr first. Otherwise if you
wanted Poly*Poly->Poly then you should convert the Expr to a Poly (and
specify the generator). Methods as_expr and as_poly are provided for
these conversions.
This might seem confusing if you haven't used the Poly class much but
remember that most users have no need to use the Poly class. If you do
want to use the Poly class then it is very useful for certain things.
One example is that integrating a polynomial can be implemented much
more efficiently than integrating a general expression which is why
Poly has an integrate method that can do this for you. So anyone who
is currently using Poly with the integrate function is advised that
the simple fix to their code is to use the Poly.integrate method.
--
Oscar
Well I assumed all along that Poly objects were a much more efficient
way of representing polynomials - presumably an array of tuples of
coefficients and exponents where the coefficient is non-zero. If these
things are all converted back before the user gets the result, that is
just fine. The comparison with Mathematica is interesting, but maybe
lead me astray. There there are multiple types of objects (e.g.
integers, integer arrays, etc) that behave and display identically to
users but have a different internal structures and iner-rconvert
silently as required.
David
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/89593117-d506-52d2-5b1b-c4e67c864cf1%40dbailey.co.uk.
Re: [sympy] Using methos rather than funtions
On Wed, 13 May 2020 at 23:39, David Bailey wrote:
>
> Dear Group,
>
> I notice this item in the highlights of 1.6.
>
> DEPRECATION: Passing Poly as the integrand to the integrate function or
> Integral class is now deprecated. Use the integrate method instead e.g.
> Poly(x, x).integrate(x)
>
> I do feel a little uneasy about pushing people to use object oriented syntax
> rather than the integrate function is undesirable. I mean for mathematicians
> and others who have not come across object oriented programming, I would have
> thought the dot notation does not come naturally and will confuse because it
> suggests a product! This notation is also alien to Mathematica, which many
> will be familiar with.
Hi David,
Perhaps this is similar to the other thread in that the release note
emphasises what someone should worry about in case their code might
break rather than what the real rationale for the change is.
Poly objects are not something that most users need to use. For
example you can integrate a polynomial like this:
>>> from sympy import Symbol, integrate
>>> x = Symbol('x')
>>> p = x**2 + x
>>> integrate(p, x)
x**3/3 + x**2/2
This integrates a polynomial just fine. The object p here would be
known mathematically as a polynomial but in sympy jargon it is an
instance of Expr rather than of Poly. Poly is a class separate from
Expr that has different methods and behaves in different ways and is
intended to be used in particular contexts where every object is known
to be a polynomial and more general expression classes are
unnecessary.
What has changed in sympy 1.6 is that Poly is no longer a subclass of
Expr and the ways in which Poly and Expr can be interchanged have been
reduced. For example in sympy 1.5.1 you can do:
>>> from sympy import Poly, Symbol, exp
>>> x = Symbol('x')
>>> p = Poly(x**2, x)
>>> p
Poly(x**2, x, domain='ZZ')
>>> p * exp(x)
x**2*exp(x)
What happened here is that we had a Poly but then we multiplied it by
something that couldn't be represented as a Poly because x**2*exp(x)
is not polynomial in x so the result was implicitly converted to an
Expr. Had we multiplied by something else the result might have been a
Poly:
>>> p*x
Poly(x**3, x, domain='ZZ')
So sometimes Poly*Expr gives an Expr and sometimes a Poly. This is not
easy to work with programmatically because Poly and Expr have
completely different methods and attributes.
In SymPy 1.6 Poly and Expr are more clearly separate. The calculation
above will still be the same but will give a warning:
>>> from sympy import Poly, Symbol, exp
>>> x = Symbol('x')
>>> p = Poly(x**2, x)
>>> p * exp(x)
/Users/enojb/current/sympy/sympy/sympy/polys/polytools.py:74:
SymPyDeprecationWarning:
Mixing Poly with non-polynomial expressions in binary operations has
been deprecated since SymPy 1.6. Use the as_expr or as_poly method to
convert types instead. See https://github.com/sympy/sympy/issues/18613
for more info.
SymPyDeprecationWarning(
x**2*exp(x)
This is showing that if you wanted a product like Expr*Expr -> Expr
then you should convert the Poly to Expr first. Otherwise if you
wanted Poly*Poly->Poly then you should convert the Expr to a Poly (and
specify the generator). Methods as_expr and as_poly are provided for
these conversions.
This might seem confusing if you haven't used the Poly class much but
remember that most users have no need to use the Poly class. If you do
want to use the Poly class then it is very useful for certain things.
One example is that integrating a polynomial can be implemented much
more efficiently than integrating a general expression which is why
Poly has an integrate method that can do this for you. So anyone who
is currently using Poly with the integrate function is advised that
the simple fix to their code is to use the Poly.integrate method.
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHVvXxRMSfYD8%2BAmwOCRPq3f-2X_ZCc4qoi-MRgRGYk6QUTJxw%40mail.gmail.com.
