Where we are with respect to Expression ListExpression

[rocky]

Yesterday, @mmatera (almost) finished of basically the first round or cut at sorting Expression versus ListExpression constructor calls.

I have been experimenting with the code to try to understand what this gives us and what remains. There is alas still a lot just in Expression/ListExpression untangling but right now it still would be good to pause and take stock.

With this we could start doing benchmark testing. Here, I'd like others to get involved. The results may also be less biased too.

General Performance Questions

But there are also some generic benchmark questions I have like:

• Is PyPy or Pyston better for Mathics? (Or choose something else - Python 11?)
• Is Pyston or Cython Python better for running specific Python modules

Benchmark sources

Finding a good benchmark suite of a normal Mathematica load that we can focus on. Some sources I see are:

• https://community.wolfram.com/groups/-/m/t/2118125
• http://rosettacode.org/wiki/Rosetta_Code

On the positive side, code that was too slow to load before like Rubi and KnotTheory now loads in a reasonable amount of time.
On the negative side, neither of these come any closer to working.

Removing Extraneous Conversions

In this branch I have code that has removed the conversions should you want to try using that. (Sorry about the typo in the branch name).

What I have been using to compare this against is 4.0.0-benchmark. This is basically the 4.0.0 code with one additional benchmark file that I use for testing against. In that branch you'll see a file with some timings I have been periodically doing to make sure we are going in the right direction

I will look into having a way in one branch where at startup time we can have a fully instrumented checking on List/Expression creation (even more so than we do now) but in the normal case use the fast expression evaluation.

Follow ons

I looked at whether we can now use the simpler and faster isinstance(x, ListExpression) instead of the more general and slower x.has_form("List", None) which comes up quite a bit.

Nope.

Basically the reason not is that there are lots of Expression() calls inside the evaluation of some expression like this:

def walk_levels(..):
  ... 
   new_expr = Expression(head, *leaves)

which will convert ListExpression into Expression. A simple remedy here is to do a lookup by head name on the expression constructor which would return Expression or ListExpression or something else as appropriate.

[mmatera]

Benchmark sources

Finding a good benchmark suite of a normal Mathematica load that we can focus on. Some sources I see are:

• https://community.wolfram.com/groups/-/m/t/2118125
• http://rosettacode.org/wiki/Rosetta_Code

Interesting. I am going to try to reap some examples from there, and build more benchmarks.

On the positive side, code that was too slow to load before like Rubi and KnotTheory now loads in a reasonable amount of time. On the negative side, neither of these come any closer to working.

These packages are good to discover symbols with are not implemented. I have to look at it again at some point. But OK, at least now it fails faster...

Removing Extraneous Conversions

In this branch I have code that has removed the conversions should you want to try using that. (Sorry about the typo in the branch name).

What I have been using to compare this against is 4.0.0-benchmark. This is basically the 4.0.0 code with one additional benchmark file that I use for testing against. In that branch you'll see a file with some timings I have been periodically doing to make sure we are going in the right direction

I will look into having a way in one branch where at startup time we can have a fully instrumented checking on List/Expression creation (even more so than we do now) but in the normal case use the fast expression evaluation.

Follow ons

I looked at whether we can now use the simpler and faster isinstance(x, ListExpression) instead of the more general and slower x.has_form("List", None) which comes up quite a bit.

Nope.

If we want to check that the head of an expression is SymbolList, what is wrong about just to check x.get_head() is SymbolList?

Basically the reason not is that there are lots of Expression() calls inside the evaluation of some expression like this:

def walk_levels(..):
  ... 
   new_expr = Expression(head, *leaves)

which will convert ListExpression into Expression. A simple remedy here is to do a lookup by head name on the expression constructor which would return Expression or ListExpression or something else as appropriate.

Apart from the problem with that approach is that it adds a tiny overhead to each expression, which is a very frequent operation, this would break the modularity we gain with the last changes. I think that is good to be able to deal with different representations of expressions of the form {a,b,...} sharing the same interface.

Then, I guess that the right place to ensure the conversion is in the specific places where the expressions are created.
For example, if at some point we have a built-in that produces a large array of floating point numbers, probably we want a representation
NumpyListExpression that stores the elements in a numpy.darray. This object would have an even simpler evaluation method (simply do nothing). Moreover, if we want a Part of the array, we shouldn't use the walk_parts based code, but something that uses the numpy native part selectors.

On the other hand, there are cases where Expression(SymbolList,...) is going to appear because the parser creates them when it parses a string of the form {a,b,c,...}. These cases are not problematic because at the first evaluation, it is going to be converted to ListExpression. As the inputs are usually short strings, that kind of conversions are not too expensive.

[rocky]

If we want to check that the head of an expression is SymbolList, what is wrong about just to check x.get_head() is SymbolList?

Perfectly fine thing to do. You were the one that suggested isinstance() :-)

[mmatera]

Yes, then I tested it, I realized that it was not a good idea, and comment on that in one of the PRs. But OK. Let's think about this.

[rocky]

Apart from the problem with that approach is that it adds a tiny overhead to each expression, which is a very frequent operation,

I didn't explain this well.

constructor_map = {
SymbolList: lambda head, *args, **kwargs: ListExpression(*args, **kwargs)
 # other mappings for other kinds of expressions
}

def walk_levels(..):
  ... 

   constructor_fn = constructor_map.get(head, Expression)
   new_expr = constructor_fn(head, *leaves)

[mmatera]

Oh, OK, that is what I had in mind, thank you!