SymPy attributes

[Francesco Bonazzi]

Do you think it could make sense to have attributes for atoms in SymPy?

Sometimes it could be convenient to store information on certain expressions, like SymPy atoms.

It came into the discussion of:
https://github.com/sympy/sympy/pull/12490

In this PR, IndexedBase is being loaded with more arguments. Potentially more arguments could be added in the future and through different kinds of objects (arrays and matrices could also be assigned the attributes discussed in that PR).

In Mathematica, atttributes are supported:

• https://reference.wolfram.com/language/ref/SetAttributes.html
• https://reference.wolfram.com/language/ref/Attributes.html

In Mathematica only a limited set of attributes can be assigned, and it's generally about basic mathematical behaviour.

We could potentially have a dictionary or a set assigned to atoms in a hidden global dictionary in sympy.core. What do you think?

[Aaron Meurer]

Why do they need to be set in a global dictionary?

You can already set whatever attributes you want on an atomic object.
So long as __eq__ checks against them it should work. I usually
recommend storing things in args if you can, as it makes things a lot
simpler, but it isn't required, at least for args == () objects.

Aaron Meurer

> --
> 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 post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/b4a612ef-7756-447b-996a-865fc9dd5968%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Francesco Bonazzi]

On Thursday, 20 April 2017 21:00:47 UTC+2, Aaron Meurer wrote:

Why do they need to be set in a global dictionary?

You can already set whatever attributes you want on an atomic object.
So long as __eq__ checks against them it should work. I usually
recommend storing things in args if you can, as it makes things a lot
simpler, but it isn't required, at least for args == () objects.

This argument arose as we need to put the same argument in different objects. For example, the introduction of an offset for indexed objects should affect both IndexedBase and Array, but should we add a new argument in __new__ to all of them? I believe that only defining arguments should be put in the arguments, while we need some extra space to put non-defining information associated to objects (for example, the way you want the printer to behave on them, you might also want to change it after the objects have been defined).

Don't the new-style assumptions have a global dictionary as a support?

[Aaron Meurer]

You could model it after the assumptions. I don't think you can reuse the assumptions dictionary because they can only be boolean values.

But way that Symbol('x') != Symbol('x', real=True) works is that Symbol defines _hashable_content which includes the assumptions dictionary. As long as you include the attributes in the _hashable_content, I believe it should work, at least for args == () objects (if there nonempty args it may be more complicated).

Aaron Meurer

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/04e21a30-0686-4b65-93b3-edee0f989056%40googlegroups.com.

[Francesco Bonazzi]

On Tuesday, 25 April 2017 01:32:30 UTC+2, Aaron Meurer wrote:

But way that Symbol('x') != Symbol('x', real=True) works is that Symbol defines _hashable_content which includes the assumptions dictionary. As long as you include the attributes in the _hashable_content, I believe it should work, at least for args == () objects (if there nonempty args it may be more complicated).

 

I don't think this is an issue, as adding the attributes would be associated to all instances of an object that have the same args. So an update to _hashable_content would not be necessary.

On Thu, Apr 20, 2017 at 4:37 PM, Francesco Bonazzi <franz....@gmail.com> wrote:

On Thursday, 20 April 2017 21:00:47 UTC+2, Aaron Meurer wrote:

Why do they need to be set in a global dictionary?

You can already set whatever attributes you want on an atomic object.
So long as __eq__ checks against them it should work. I usually
recommend storing things in args if you can, as it makes things a lot
simpler, but it isn't required, at least for args == () objects.

This argument arose as we need to put the same argument in different objects. For example, the introduction of an offset for indexed objects should affect both IndexedBase and Array, but should we add a new argument in __new__ to all of them? I believe that only defining arguments should be put in the arguments, while we need some extra space to put non-defining information associated to objects (for example, the way you want the printer to behave on them, you might also want to change it after the objects have been defined).

Don't the new-style assumptions have a global dictionary as a support?

--
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 post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

[Aaron Meurer]

On Tue, Apr 25, 2017 at 3:17 AM, Francesco Bonazzi <franz....@gmail.com> wrote:

On Tuesday, 25 April 2017 01:32:30 UTC+2, Aaron Meurer wrote:

But way that Symbol('x') != Symbol('x', real=True) works is that Symbol defines _hashable_content which includes the assumptions dictionary. As long as you include the attributes in the _hashable_content, I believe it should work, at least for args == () objects (if there nonempty args it may be more complicated).

 

I don't think this is an issue, as adding the attributes would be associated to all instances of an object that have the same args. So an update to _hashable_content would not be necessary.

But what's the value of making attributes global instead of local? It would seem that you could just end up breaking things, if some other code has a reference to the same object used for a different purpose. 

Aaron Meurer

 

On Thu, Apr 20, 2017 at 4:37 PM, Francesco Bonazzi <franz....@gmail.com> wrote:

On Thursday, 20 April 2017 21:00:47 UTC+2, Aaron Meurer wrote:

Why do they need to be set in a global dictionary?

You can already set whatever attributes you want on an atomic object.
So long as __eq__ checks against them it should work. I usually
recommend storing things in args if you can, as it makes things a lot
simpler, but it isn't required, at least for args == () objects.

This argument arose as we need to put the same argument in different objects. For example, the introduction of an offset for indexed objects should affect both IndexedBase and Array, but should we add a new argument in __new__ to all of them? I believe that only defining arguments should be put in the arguments, while we need some extra space to put non-defining information associated to objects (for example, the way you want the printer to behave on them, you might also want to change it after the objects have been defined).

Don't the new-style assumptions have a global dictionary as a support?

--
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 post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/04e21a30-0686-4b65-93b3-edee0f989056%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a6f65711-6317-466c-8eda-d65caf0814f7%40googlegroups.com.