Mathics DownValues[f]//FullForm is different from Mathematica's

[aravindh-krishnamoorthy]

This is an implementation detail and I'm not sure if this must be fixed. In any case, Rubi seems to make assumptions on Mathematica's internal representation of DownValues of SetDelayed rules.

Description

In Mathematica, DownValues are SetDelayed[lhs, Condition[rhs, cond]] whereas in Mathics, they are SetDelayed[Condition[lhs, cond], rhs] as shown below.

In Mathematica,

In[1]:= f[A_, x_] := x /; x == 2;
In[2]:= DownValues[f] // FullForm
Out[2]//FullForm= {RuleDelayed[HoldPattern[f[Pattern[A,Blank[]],Pattern[x,Blank[]]]],Condition[x,Equal[x,2]]]}

On the other hand, in Mathics:

In[1]:= f[A_, x_] := x /; x == 2;
In[2]:= DownValues[f] // FullForm
Out[2]//FullForm= {RuleDelayed[HoldPattern[Condition[f[Pattern[A, Blank[]], Pattern[x, Blank[]]], Equal[x, 2]]], x]}

How to Reproduce

See above.

Output Given

Out[2]//FullForm= {RuleDelayed[HoldPattern[Condition[f[Pattern[A, Blank[]], Pattern[x, Blank[]]], Equal[x, 2]]], x]}

Expected behavior

The following, if compatibility with Mathematica in this is desired:

Out[2]//FullForm= {RuleDelayed[HoldPattern[f[Pattern[A,Blank[]],Pattern[x,Blank[]]]],Condition[x,Equal[x,2]]]}

Your Environment

Mathics 7.0.1dev0
on CPython 3.11.10 | packaged by conda-forge | (main, Oct 16 2024, 01:27:36) [GCC 13.3.0]
using SymPy 1.13.3, mpmath 1.3.0, numpy 2.1.3, cython Not installed

Workarounds

Conversion Mathics $\leftrightarrow$ Mathematica can be performed using these rules:

dvMathicsToMath = RuleDelayed[Verbatim[HoldPattern][Verbatim[Condition][lhs_,cond_]],rhs_] :> RuleDelayed[HoldPattern[lhs],Condition[rhs,cond]];
dvMathToMathics = RuleDelayed[Verbatim[HoldPattern][lhs_], Verbatim[Condition][rhs_,cond_]] :> RuleDelayed[HoldPattern[Condition[lhs,cond]],rhs];

Priority

Low. Non-blocking.

Additional context

N/A

[rocky]

If this turns out to be about how something is internally represented, we might address it sooner. as its own thing.

However if this turns out not to be about the internal structuring about how FullForm is presenting the information, then that is one of the other big problems that remain to be addressed. @mmatera - your thoughts?

I have in mind coming out with a release soon. But I hesitate because there is this small stuff for Rubi which we are addressing, and I'd like to have at least some version of Rubi running for the next release.

After that I think we can focus on Boxing and Formatting. That is likely to have a lot of interim breakages, because a lot of tests have to be rewritten to expect the changed output.

[aravindh-krishnamoorthy]

I have in mind coming out with a release soon. But I hesitate because there is this small stuff for Rubi which we are addressing, and I'd like to have at least some version of Rubi running for the next release.

I think the current Rubi codebase works well for a majority of the algebraic tests. The only remaining (blocking) issue is with TimeConstrained[], which seems to hang randomly. Unfortunately, Steps[] will require more work. So, would a Rubi release without Steps[] and for algebraic functions be interesting? If so, do you have a date in mind where it's best to have this Rubi release ready?

[rocky]

I have in mind coming out with a release soon. But I hesitate because there is this small stuff for Rubi which we are addressing, and I'd like to have at least some version of Rubi running for the next release.

I think the current Rubi codebase works well for a majority of the algebraic tests. The only remaining (blocking) issue is with TimeConstrained[], which seems to hang randomly.

We can probably put a little more work on TimeConstrained to try to make it better.

Unfortunately, Steps[] will require more work. So, would a Rubi release without Steps[] and for algebraic functions be interesting?

I think it would be interesting. I'd like to be able to show progress toward getting existing packages working. Personally, I am expecting that a novice user is going to start using Mathics3 for its ability to run Rubi. Rather, I think we should attract more people like you who see some potential here and would be willing to work on either the Rubi Mathics3 code or some other similar code like KnotTheory package (or something else).

If so, do you have a date in mind where it's best to have this Rubi release ready?

Originally, I had wanted it to be now or in December. However because of this work and a flurry of other activity, as soon as that activity dies down.

The next release will break the API yet again due to the changes in passing operator information from the scanner to mathics core. And for that there is probably one more piece of information I think we should pass back even if we don't (and probably won't) use it in the next release so that we don't break API in the release after the next.

As I've said, after the next release there may be a bit of downtime as we try to get boxing and formatting under control. But with the next release, I believe people will be able to install fro emscripten/pyoide.

[mmatera]

However if this turns out not to be about the internal structuring about how FullForm is presenting the information, then that is one of the other big problems that remain to be addressed. @mmatera - your thoughts?

This is not about how FullForm formats a rule, but how WMA and Mathics handles rules of the form

RuleDelayed[expr_, Condition[repl_, cond_]]

In WMA, if we apply the rule f[x_]:>x/;x==2 to the expression f[3], the interpreter understands the same as we apply the rule f[x_]/;x==2:>x, i.e., check that f[3] matches with the pattern f[x_], and then if x satisfies the condition. If it does, replaces the expression by the replacement (in this case, 2).

In Mathics, the interpreter understands that f[x_]:>x/;x==2 matches with f[3], and then f[3]/. f[x_]/;x==2:>x results in 3/;3==2.

Now, when Mathics execute a (Delayed) assignment instruction f[x_]:= g[x], the rule f[x_]:>g[x] is stored into the definition of f. On the other hand, for conditional assignments like f[x_]:=x/;x==2, in Mathics, we reformat the rule to obtain the right result. Now, if we fix the logic in handling these kind of rules, we can then replace the behavior of the assignment.

I have in mind coming out with a release soon. But I hesitate because there is this small stuff for Rubi which we are addressing, and I'd like to have at least some version of Rubi running for the next release.

After that I think we can focus on Boxing and Formatting. That is likely to have a lot of interim breakages, because a lot of tests have to be rewritten to expect the changed output.

[rocky]

@mmatera Thanks for the information. This sounds like a deeper kind of problem and that to fix may require a lot of changes or breakage. Let's postpone handling this until after the next release.

[mmatera]

@mmatera Thanks for the information. This sounds like a deeper kind of problem and that to fix may require a lot of changes or breakage. Let's postpone handling this until after the next release.

Maybe it is not super complex, but yes requires changes in several places. I do not know how much this affects Ruby and other packages, but I can report this as an issue.

[rocky]

Thanks - please add this problem and the insight behind the problem in an issue. I've noticed a tendency to underestimate the difficulty and magnitude of tasks rather than overestimate tasks. The good thing about issues is that they provide a better forum for discussion before code is written.