Symbolic API: isinstance(x**2, Pow) or (x**2).is_Pow?

[certik]

Currently in SymPy (as well as symengine.py) you can use both (x**2).is_Pow and isinstance(x**2, sym.Pow):

In [1]: import sympy as sym

In [3]: sym.var("x")
Out[3]: x

In [4]: (x**2).is_Pow
Out[4]: True

In [5]: isinstance(x**2, sym.Pow)
Out[5]: True

But you can only use isinstance(sym.log(x), sym.log) but not sym.log(x).is_Log or sym.log(x).is_log:

In [6]: isinstance(sym.log(x), sym.log)
Out[6]: True

In [7]: sym.log(x).is_Log
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Input In [7], in <cell line: 1>()
----> 1 sym.log(x).is_Log

AttributeError: 'log' object has no attribute 'is_Log'

In [8]: sym.log(x).is_log
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Input In [8], in <cell line: 1>()
----> 1 sym.log(x).is_log

AttributeError: 'log' object has no attribute 'is_log'

In order to be consistent ("just one way of doing it"), wouldn't it make sense to only support isinstance(log(x), log) and isinstance(x**2, Pow), but not (x**2).is_Pow?

CC @isuruf, @asmeurer, @oscarbenjamin

[oscarbenjamin]

I would prefer something like

(x**2).func == Pow
log(x).func == log

I think it is a mistake that log is a Python class and log(x) an instance of that class. It would be better if Pow and log could be symbolic objects in their own right. Lots of problems are caused by the "classes as expression heads" design and many things can only be made to work with metaclasses because of this. We should not define an API around the idea that you can use things like log with isinstance.

Using .func is tricky though because it is not completely specified what .func is supposed to be and I am not sure that it always is the type or if there are some cases where .func might be a dynamically generated callable that still works with expr.func(*expr.args) but cannot otherwise be compared with anything.

The API should specify carefully what the expectations are around .func. There is also the question of what .func is supposed to do for atomic types:

In [1]: e = Integer(3)

In [2]: e.func
Out[2]: sympy.core.numbers.Integer

In [3]: e.func(*e.args)
---------------------------------------------------------------------------
TypeError  

[certik]

Internally in LPython we currently have SymbolicAddQ functions in ASR, as you can see in https://github.com/lcompilers/lpython/pull/2351/files#diff-74441dbd48d53636aaa60d41ea8ca4f7f5a55137c494cf18317a8b5a086079b3R143, but we can also change/improve that later as needed. We can map any Python syntax/semantics to this. In the backend we currently use SymEngine, which at the C++ level uses an internal enum variable type_code_: https://github.com/symengine/symengine/blob/de9ad4499d2f2d6b0b0b7087588b505b4abe1be9/symengine/basic.h#L113.

In Python, we could use something similar, and have dedicated variables for type codes (say POW=1, MUL=2, ...). Or we can use classes. The .func is effectively a type code.

Or should the "Pow" by a symbolic object, other than the Pow class and other than an integer variable POW=1? In Mathematica they use a concept of a Head.

[oscarbenjamin]

In Mathematica x**2 is basically just:

Tree([Power, x, 2])

The Head is here is just the element at index 0:

In[5]:= e[[0]]
Out[5]= Power

In[6]:= e[[1]]
Out[6]= x

In[7]:= e[[2]]
Out[7]= 2

There is nothing special about Power here as distinct from x except that it displays differently:

In[8]:= Power[x, 2]
Out[8]= x ^ 2

In[9]:= x[Power, 2]
Out[9]= x[Power, 2]

In[10]:= Power[x, 2][[0]] == Power
Out[10]= True

In[11]:= x[Power, 2][[0]] == x
Out[11]= True

I think that for now the main thing is just that the way to check the expression head should be something that is not tied to any particular design for how the expression classes are implemented in terms of Python language types. In that sense expr.is_Pow is fine except that the approach obviously does not scale to having many different expression types.

[certik]

Yes exactly. Internally in LPython we have language independent way. But now we need some Python syntax. Say for the "log". What do you think is the best way?

In Mathematica, Power is I think just a symbol, it's not tied to the internal representation.

[oscarbenjamin]

In terms of what is currently possible I think that it should be

log(x).func == log

Ideally it would be possible to use Python's match/case statement for this as well like

match expr:
    case log(x): # not sure what is needed to make this work
         ...

Most of the time we should want to use pattern matching

if (x**2).matches(a**2):
    ...

What we should not include in the API is the idea that you can do

isinstance(obj, log)

because that can only work if log is a Python type and it would be better if log was not a Python type.

[certik]

Perfect. Should we use log(x).func or log(x).head?

What exactly should log be in a.func == log? A variable? Or even unspecified, just provided by the library (say sympy / symengine / protosym) ?

[oscarbenjamin]

I think that log should be what you "call" to create the expression log(x). Unless there are existing interfaces that involve using log in some other way I would try not to define more precisely what log should be.

[asmeurer]

I agree it should just be func and there shouldn't be anything assumed about it other than == comparison and expr.func(*expr.args) recreates expr.

[certik]

Ok, so log can be either a current SymPy class, or a function log, or anything else that has the following two properties:

• a.func == log
• a.func(*a.args) == a

And then we also need to use the same (?) log to construct expressions, like this:

• a = log(x)**2

So log has to be either a class (or metaclass in SymPy) or a function, or something that implements the __call__ method etc. We are not specifying what it has to be.

Correct?

[anutosh491]

Thanks for this discussion. I think we use something a.func to get the class type. I shall think on how we could design this in the ASR.

[certik]

@asmeurer, @oscarbenjamin one more question: we are now implementing the a.func == Pow approach in #2367. Should we support is_Pow at all? The PR allows it, but I think we should not support it (#2367 (comment)), since there should be just one way of doing things.

[oscarbenjamin]

I think ideally SymPy would not use things like is_Pow but it is difficult to remove even SymPy's internal use of these attributes because of all of the cyclic import problems there would be with every other approach.