Request for discussion on kind system
76 views
Skip to first unread message
JSS95
Aug 2, 2021, 4:37:51 AM8/2/21
to sympy
Kind system was introduced to SymPy since version 1.8, but it is not fully implemented yet and it may be confusing to those who did not participate in its discussion. So I wrote a brief wiki page covering the basic idea :
Kind system · sympy/sympy Wiki (github.com)
I am planning to start working on this topic again, but I would like to hear other ideas first. If you are interested, please take a look at the page and leave your opinion here.
Jisoo Song
Jonathan Gutow
Aug 2, 2021, 5:24:34 PM8/2/21
to sy...@googlegroups.com
Is there a discussion page/tab attached to github wikis? If so, how do I find it? I do have some questions/thoughts on this.
Jonathan
From: sy...@googlegroups.com <sy...@googlegroups.com> on behalf of JSS95 <jeeso...@snu.ac.kr>
Sent: Monday, August 2, 2021 3:37 AM
To: sympy <sy...@googlegroups.com>
Subject: [sympy] Request for discussion on kind system
Sent: Monday, August 2, 2021 3:37 AM
To: sympy <sy...@googlegroups.com>
Subject: [sympy] Request for discussion on kind system
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Kind system was introduced to SymPy since version 1.8, but it is not fully implemented yet and it may be confusing to those who did not participate in its discussion. So I wrote a brief wiki page covering the basic idea :
Kind system · sympy/sympy Wiki (github.com)
I am planning to start working on this topic again, but I would like to hear other ideas first. If you are interested, please take a look at the page and leave your opinion here.
Jisoo Song
--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ae10d7b4-fcae-4ea8-b026-dd13bf7f5dc9n%40googlegroups.com.
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ae10d7b4-fcae-4ea8-b026-dd13bf7f5dc9n%40googlegroups.com.
Oscar Benjamin
Aug 2, 2021, 5:49:40 PM8/2/21
to sympy
On Mon, 2 Aug 2021 at 22:24, Jonathan Gutow <gu...@uwosh.edu> wrote:
>
> Is there a discussion page/tab attached to github wikis? If so, how do I find it? I do have some questions/thoughts on this.
Best place to start the discussion is here. Then the wiki page can be
>
> Is there a discussion page/tab attached to github wikis? If so, how do I find it? I do have some questions/thoughts on this.
updated following the discussion (it can also have a link back to the
discussion here).
--
Oscar
Aaron Meurer
Aug 3, 2021, 6:17:03 PM8/3/21
to sympy
I have some comments based on what is written.
> One major obstacle in this approach is that we cannot use kind-dependent attributes (i.e. MatAdd.shape) anymore. This can be resolved by defining a shape() function which returns the shape of any matrix-kind object, and replace the shape attribute with this function over entire SymPy codebase.
I think it's still technically possible to have shape as an attribute.
A general way to do it would be to allows kinds to specify attributes
and then Expr (Basic?) would add those attributes if it has the
corresponding kind. Of course x.shape will raise an exception if x is
not a matrix kind, but a shape() function would also do the same
thing.
> One more important point for kind system is that we need to support the operations between different kinds. Currently, a single MatMul class deals with multiplication between matrices, and multiplication between scalar and matrix altogether. (Perhaps this is an design error and we need two separate ScalarMul and BilinearProduct classes.) In order to make Mul do this, we need to define the NumberKind x MatrixKind -> MatrixKind rule. This can be done by kind dispatching system, which is already supported.
I agree that MatMul holding both a scalar and matrix part might be a
design error, as it's the source of a lot of complexity and bugs in
code that uses MatMul.
I'm not exactly sure what a better design would be, however. One idea
would be to represent scalars as a special matrix object, which would
mathematically represent a*I (where I is an identity of an appropriate
shape), but the printers would still treat like an actual scalar. That
way a Mul with matrices would contain matrix objects only, not scalars
and matrices.
> Finally, it must be stressed that Kind instance must be singleton, and we should not implement complicated set theory logic here. This is to facilitate the determination of the kind of associative operation with very large number of arguments.
I'm a little confused by this paragraph. I don't see why Kind
instances need to be singletons in the Python sense (like SymPy's
SingletonMeta), although maybe that isn't what you meant. I agree we
shouldn't try to go crazy with Monoids and Rings and so on (at least
at this stage), but again, I'm not clear if that is what you are
talking about here.
Aaron Meurer
> One major obstacle in this approach is that we cannot use kind-dependent attributes (i.e. MatAdd.shape) anymore. This can be resolved by defining a shape() function which returns the shape of any matrix-kind object, and replace the shape attribute with this function over entire SymPy codebase.
I think it's still technically possible to have shape as an attribute.
A general way to do it would be to allows kinds to specify attributes
and then Expr (Basic?) would add those attributes if it has the
corresponding kind. Of course x.shape will raise an exception if x is
not a matrix kind, but a shape() function would also do the same
thing.
> One more important point for kind system is that we need to support the operations between different kinds. Currently, a single MatMul class deals with multiplication between matrices, and multiplication between scalar and matrix altogether. (Perhaps this is an design error and we need two separate ScalarMul and BilinearProduct classes.) In order to make Mul do this, we need to define the NumberKind x MatrixKind -> MatrixKind rule. This can be done by kind dispatching system, which is already supported.
I agree that MatMul holding both a scalar and matrix part might be a
design error, as it's the source of a lot of complexity and bugs in
code that uses MatMul.
I'm not exactly sure what a better design would be, however. One idea
would be to represent scalars as a special matrix object, which would
mathematically represent a*I (where I is an identity of an appropriate
shape), but the printers would still treat like an actual scalar. That
way a Mul with matrices would contain matrix objects only, not scalars
and matrices.
> Finally, it must be stressed that Kind instance must be singleton, and we should not implement complicated set theory logic here. This is to facilitate the determination of the kind of associative operation with very large number of arguments.
I'm a little confused by this paragraph. I don't see why Kind
instances need to be singletons in the Python sense (like SymPy's
SingletonMeta), although maybe that isn't what you meant. I agree we
shouldn't try to go crazy with Monoids and Rings and so on (at least
at this stage), but again, I'm not clear if that is what you are
talking about here.
Aaron Meurer
Oscar Benjamin
Aug 3, 2021, 6:58:54 PM8/3/21
to sympy
On Tue, 3 Aug 2021 at 23:17, Aaron Meurer <asme...@gmail.com> wrote:
>
> > Finally, it must be stressed that Kind instance must be singleton, and we should not implement complicated set theory logic here. This is to facilitate the determination of the kind of associative operation with very large number of arguments.
>
> I'm a little confused by this paragraph. I don't see why Kind
> instances need to be singletons in the Python sense (like SymPy's
> SingletonMeta), although maybe that isn't what you meant. I agree we
> shouldn't try to go crazy with Monoids and Rings and so on (at least
> at this stage), but again, I'm not clear if that is what you are
> talking about here.
Part of the idea of kind as opposed to type is that there are no
>
> > Finally, it must be stressed that Kind instance must be singleton, and we should not implement complicated set theory logic here. This is to facilitate the determination of the kind of associative operation with very large number of arguments.
>
> I'm a little confused by this paragraph. I don't see why Kind
> instances need to be singletons in the Python sense (like SymPy's
> SingletonMeta), although maybe that isn't what you meant. I agree we
> shouldn't try to go crazy with Monoids and Rings and so on (at least
> at this stage), but again, I'm not clear if that is what you are
> talking about here.
subkinds in the way that we have subtypes (or subclasses). An object
has exactly one kind e.g. NumberKind, BooleanKind etc. No object can
be both a Number and a Boolean because those are two distinct kinds
and all kinds are mutually exclusive. The kind of a particular object
therefore can always be an instance of a Python singleton class unless
the kind needs to be parametrised like MatrixKind(NumberKind).
Things like Monoid and Ring don't make sense in this context because
you'd end up having combinations that are super/subsets of each other
like Monoid and Group or Ring and Field (every group is a monoid and
every field is a ring). For these it makes more sense to have
attributes like is_Field, is_Ring etc because then the attributes can
be set independently. The fact that `.kind` is a single attribute and
can only have a single value is a deliberate design choice to make it
clear that an object can only be of one kind.
--
Oscar
Aaron Meurer
Aug 4, 2021, 3:58:53 AM8/4/21
to sympy
On Tue, Aug 3, 2021 at 4:58 PM Oscar Benjamin
<oscar.j....@gmail.com> wrote:
>
> On Tue, 3 Aug 2021 at 23:17, Aaron Meurer <asme...@gmail.com> wrote:
> >
> > > Finally, it must be stressed that Kind instance must be singleton, and we should not implement complicated set theory logic here. This is to facilitate the determination of the kind of associative operation with very large number of arguments.
> >
> > I'm a little confused by this paragraph. I don't see why Kind
> > instances need to be singletons in the Python sense (like SymPy's
> > SingletonMeta), although maybe that isn't what you meant. I agree we
> > shouldn't try to go crazy with Monoids and Rings and so on (at least
> > at this stage), but again, I'm not clear if that is what you are
> > talking about here.
>
> Part of the idea of kind as opposed to type is that there are no
> subkinds in the way that we have subtypes (or subclasses). An object
> has exactly one kind e.g. NumberKind, BooleanKind etc. No object can
> be both a Number and a Boolean because those are two distinct kinds
> and all kinds are mutually exclusive. The kind of a particular object
> therefore can always be an instance of a Python singleton class unless
> the kind needs to be parametrised like MatrixKind(NumberKind).
I see, although I don't in principle see why kinds couldn't be
<oscar.j....@gmail.com> wrote:
>
> On Tue, 3 Aug 2021 at 23:17, Aaron Meurer <asme...@gmail.com> wrote:
> >
> > > Finally, it must be stressed that Kind instance must be singleton, and we should not implement complicated set theory logic here. This is to facilitate the determination of the kind of associative operation with very large number of arguments.
> >
> > I'm a little confused by this paragraph. I don't see why Kind
> > instances need to be singletons in the Python sense (like SymPy's
> > SingletonMeta), although maybe that isn't what you meant. I agree we
> > shouldn't try to go crazy with Monoids and Rings and so on (at least
> > at this stage), but again, I'm not clear if that is what you are
> > talking about here.
>
> Part of the idea of kind as opposed to type is that there are no
> subkinds in the way that we have subtypes (or subclasses). An object
> has exactly one kind e.g. NumberKind, BooleanKind etc. No object can
> be both a Number and a Boolean because those are two distinct kinds
> and all kinds are mutually exclusive. The kind of a particular object
> therefore can always be an instance of a Python singleton class unless
> the kind needs to be parametrised like MatrixKind(NumberKind).
subclassed or combined, even though I agree it doesn't make sense for
the classes we have now.
I'm mostly just allergic to the word "singleton" in SymPy because I
think putting stuff on SingletonRegistry is almost always unnecessary
and has bad consequences. So as long as we aren't proposing doing
that, I'm fine with this.
>
> Things like Monoid and Ring don't make sense in this context because
> you'd end up having combinations that are super/subsets of each other
> like Monoid and Group or Ring and Field (every group is a monoid and
> every field is a ring). For these it makes more sense to have
> attributes like is_Field, is_Ring etc because then the attributes can
> be set independently. The fact that `.kind` is a single attribute and
> can only have a single value is a deliberate design choice to make it
> clear that an object can only be of one kind.
talking about?
But as I said, I don't think Ring, etc. make sense here.
To me, the idea behind kind is that it is the mathematical "type" of
an object (except we call it "kind" instead of "type" because "type"
already has another meaning in Python). For example, the mathematical
type of 1 is a scalar number. It happens to be an element of the ring
Z, but it's also an element of Q or R or Z[x]. But, critically, it's
*not* an element of, say, the ring of n x n matrices, because the "1"
in that ring is actually a different mathematical type. It's rather I,
the n x n identity matrix, which has many of the same properties as 1,
but is not a scalar number whereas 1 is.
Two objects are of the same kind if they are literally elements of
some ambient algebra, rather than just homomorphic images. The ambient
algebra itself is not that important. We could say matrices, for
instance, are part of some sort of "matrix algebra" that allow adding
and multiplying and so on. But if we could also extend this with other
matrix operations (like e.g., a tensor product), and, critically,
doing so would only be a question of building a class for that
operation. It would not require extending the kind.
There's probably also a nice mathematical type theory (or maybe
category theory) way of looking at this, but I'm not fluent enough in
either to really attempt that.
Aaron Meurer
>
> --
> 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+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRk_6qc4B7bzgpBf3oXmnMtzzzf_FdGzKej8FQHWrofUQ%40mail.gmail.com.
> --
> 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+un...@googlegroups.com.
JSS95
Aug 4, 2021, 9:48:05 PM8/4/21
to sympy
I removed singleton reference from the paragraph. Thanks.
Jisoo Song
Aaron Meurer
Aug 5, 2021, 7:19:52 PM8/5/21
to sympy
On Tue, Aug 3, 2021 at 4:16 PM Aaron Meurer <asme...@gmail.com> wrote:
>
> I have some comments based on what is written.
>
> > One major obstacle in this approach is that we cannot use kind-dependent attributes (i.e. MatAdd.shape) anymore. This can be resolved by defining a shape() function which returns the shape of any matrix-kind object, and replace the shape attribute with this function over entire SymPy codebase.
>
> I think it's still technically possible to have shape as an attribute.
> A general way to do it would be to allows kinds to specify attributes
> and then Expr (Basic?) would add those attributes if it has the
> corresponding kind. Of course x.shape will raise an exception if x is
> not a matrix kind, but a shape() function would also do the same
> thing.
We can think of this as a dispatching question. We need to dispatch
>
> I have some comments based on what is written.
>
> > One major obstacle in this approach is that we cannot use kind-dependent attributes (i.e. MatAdd.shape) anymore. This can be resolved by defining a shape() function which returns the shape of any matrix-kind object, and replace the shape attribute with this function over entire SymPy codebase.
>
> I think it's still technically possible to have shape as an attribute.
> A general way to do it would be to allows kinds to specify attributes
> and then Expr (Basic?) would add those attributes if it has the
> corresponding kind. Of course x.shape will raise an exception if x is
> not a matrix kind, but a shape() function would also do the same
> thing.
the various classes (Add, Mul, etc.) on the attributes (in this
example, just 'shape'). For the core classes, I think it makes the
most sense for this information to live on the MatrixKind class
somehow. For matrix specific classes, they can define shape
themselves, which would be used instead of the Kind shape logic.
Aaron Meurer
David Bailey
Aug 7, 2021, 6:40:32 AM8/7/21
to sy...@googlegroups.com
Dear All,
Has anyone else encountered this problem - which seemed to start after I
moved to SymPy 1.8? Of course, it might have resulted from an 'upgrade'
of Windows itself.
import sympy
from sympy import symbols
import matplotlib
matplotlib.use("Qt5Agg")
from sympy.plotting import plot
x = symbols('x')
plot(x*x)
This produces no plot but this output:
Traceback (most recent call last):
File "C:\SymPyProject\test.py", line 13, in <module>
plot(x*x)
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
1740, in plot
plots.show()
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
221, in show
self._backend = self.backend(self)
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
1459, in __new__
return MatplotlibBackend(parent)
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
1191, in __init__
self.plt = self.matplotlib.pyplot
AttributeError: 'NoneType' object has no attribute 'pyplot'
Note that the line matplotlib.use("Qt5Agg") was recommended to me
because I work in Windows 10 (64 bits). It used to work well.
David
Has anyone else encountered this problem - which seemed to start after I
moved to SymPy 1.8? Of course, it might have resulted from an 'upgrade'
of Windows itself.
import sympy
from sympy import symbols
import matplotlib
matplotlib.use("Qt5Agg")
from sympy.plotting import plot
x = symbols('x')
plot(x*x)
This produces no plot but this output:
Traceback (most recent call last):
File "C:\SymPyProject\test.py", line 13, in <module>
plot(x*x)
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
1740, in plot
plots.show()
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
221, in show
self._backend = self.backend(self)
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
1459, in __new__
return MatplotlibBackend(parent)
File "C:\PythonSystem\lib\site-packages\sympy\plotting\plot.py", line
1191, in __init__
self.plt = self.matplotlib.pyplot
AttributeError: 'NoneType' object has no attribute 'pyplot'
Note that the line matplotlib.use("Qt5Agg") was recommended to me
because I work in Windows 10 (64 bits). It used to work well.
David
Davide Sandona'
Aug 7, 2021, 6:45:00 AM8/7/21
to sy...@googlegroups.com
Hello Davide,
In order to use Qt5 you need to install the following dependency:
pip install PyQt5
After that it should work fine!
Davide.
--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/395963f8-8cd2-c973-fcf9-705a0505fa8f%40dbailey.co.uk.
Oscar Benjamin
Aug 7, 2021, 7:31:02 AM8/7/21
to sympy
Maybe that error message could be improved...
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAO%3D1Z09oCm_%2B9EitLZ3U-u3k0_-qk2YCybYK%3DxOZ1kZDiOwB%3Dw%40mail.gmail.com.
David Bailey
Aug 7, 2021, 9:49:04 AM8/7/21
to sy...@googlegroups.com
On 07/08/2021 11:44, Davide Sandona'
wrote:
Hello Davide,
In order to use Qt5 you need to install the following dependency:
pip install PyQt5
After that it should work fine!
Davide.
Thank you so much for that! I had installed that originally, but then I moved computers...
It would be so nice if major packages trapped that sort of thing and gave a sensible diagnostic, or even offered to perform the necessary installation.
David
Reply all
Reply to author
Forward
0 new messages