Irrelevant warning on UpSetDelayed

[tueda]

Mathics gives a warning message UpSetDelayed::write: Tag Pattern in a b_ is Protected for the following definition:

a b_ ^:= c

though the definition seems to work (for example, 2 a becomes c).

$ mathics

Mathics 2.2.0
on CPython 3.9.4 (default, Apr  7 2021, 05:45:11)
using SymPy 1.8, mpmath 1.2.1, numpy 1.20.3

Copyright (C) 2011-2021 The Mathics Team.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
See the documentation for the full license.

Quit by evaluating Quit[] or by pressing CONTROL-D.

In[1]:= a b_ ^:= c
UpSetDelayed::write: Tag Pattern in a b_ is Protected.
Out[1]= None

In[2]:= 2 a
Out[2]= c

This comes from FeynRules v2.3.47, Core/Initialisation.m:1219:

ME[mu_,nu_] ff_[indx___,del[f_,mu_],indy___]^:=ff[indx,del[f,nu],indy];

I also found a subtle difference between Mathics and Mathematica: 1 a becomes c in Mathics but remains a in Mathematica with the above pattern, though I am not sure whether this can be problematic in practice.

[rocky]

Thanks for the reports. They aren't been ignored, it is just that may take a while before we get to.

So I just wanted to let you know what's up (at least for me).

Ever since I started working on this project the, it has been a struggle to get the code to where it should be circa 2021. I've been amazed at how much back-levelness there has been:

• Python 2.7 to 3.9, adding type annotations and reformatting code
• Splitting out Django code, CLI, code Mathics Symbol and Operator Data,
• Updating MathJax, and threejs on django
• Refactoring the code so that it is more scalable
• Removing unit tests from the documentation tests

in addition to adding built-in functions and fixing them. And this is nowhere near a complete list. The amount if cleanup still needed is still enormous and wlll take months if not a year.

A month or so ago I thought we'd be in shape to start fixing up larger projects. Personally I started with Combinatorica, and that's been the only thing that we've been able to do. Even in that area, I couldn't go with the last release which was a few years ago but needed to start with something circa 1990! And I am about 1/3 of the way though the code there.

Given this, a reasonable approach for tackling this is to start with an older version of FeynRules which probably be much smaller and not use as many fancy features. Then work up in releases. We had to do that for threejs as well - we couldn't go from r49 circa 2013 to r124 in one shot. It took 3 or 4 iterations. The same was true for Django. And even doing this may take several months to get something usable.

The other aspect about this that appeals to me in this approach is that we see something working initially sooner and incrementally it gets better.

[rocky]

Sorry I closed by accident when trying to adjust the font size in ^^^^ . I t amzes me that hitting "-" in the wrong way will close the issue!