Two similar Set[] patterns matching differently in Mathics3 and wolframscript

[rocky]

Description

These two Set assignments, when they exist together, seem to match differently in Mathics3 than in wolframscript:

Bug[n_Integer,_] := Print["Negative ", n] /; (n<0)
Bug[n_Integer,maxpart_Integer] := Print["Integer ", n]

How to Reproduce

In mathics:

In[1]:= Bug[n_Integer,_] := Print["Negative ", n] /; (n<0)
Out[1]= None

In[2]:= Bug[-5, 3]
Negative -5
Out[2]= None

In[3]:= Bug[n_Integer,maxpart_Integer] := Print["Integer ", n]
Out[3]= None

In[4]:= Bug[-5, 3]
Integer -5
Out[4]= None

In wolframscript:

In[1]:= Bug[n_Integer,_] := Print["Negative ", n] /; (n<0)                                    

In[2]:= Bug[-5, 3]                                                                            
Negative -5

In[3]:= Bug[n_Integer,maxpart_Integer] := Print["Integer ", n]                                

In[4]:= Bug[-5, 3]                                                                            
Negative -5

What's going on, and why?

Expected behavior

The wolframscript behavior

Workarounds

In combinatoria V0.9 basically the two Set statements were combined into one Set statement with an explicit If test.

Additional context

Noticed in getting Combinatorical V0.9's Partitions[] function working.

[rocky]

To me there is this vague sense that when one rule has more restrictions than another, when it matches it should be take precedence over a more general rule. But is this what is going on? Or maybe the order of execution of the Set has an effect?

So I also wonder where this kind of thing is spelled out. Is this something that I should ask on Mathematica Stack Overflow for an explanation?

[axkr]

See:

• https://reference.wolfram.com/language/tutorial/TransformationRulesAndDefinitions.html#26982

A "left-hand-side" without a "pattern member" can be matched with "equals" and can always be tried before the rules which contain patterns (and the "equals rules" can therefore be stored in a tree or hash map internally). This is used in the f example for f[1].

From the website

if two rules both contain complicated /; conditions, it may not be possible to work out which is more general

So if complicated rules are used it's not clear to me how the rules are ordered (and also important "which rules are equivalent", so that an existing rule could be replaced by a new rule) .
In the Symja Rubi port we decided to create the full-form of all Rubi rules directly from WMA's internal DownValues to ensure that they are in the correct order.
Symja itself has the same "different" behaviour as described in this bug at the moment.

[rocky]

@axkr - thanks - this is very informative.

In a language like Python or Java, there would be a lint program that would warn about such behavior and might solicit the user to make a change or facilitate making the change.

I suppose Mathics3 could have a flag or mode where we provide something like this.

For example, as I have done in Combinatorica, if one of the cases is a Block or a Module, one can always turn the Condition into an If statement inside the Module/BLock.

[mmatera]

In Mathics we just store all the patterns, sorted using a "pattern sort" criteria. Maybe what we need to change is some detail in how the sorting is done.

[rocky]

In Mathics we just store all the patterns, sorted using a "pattern sort" criteria. Maybe what we need to change is some detail in how the sorting is done.

Maybe, but note that the WMA reference cited also says that WMA sometimes uses the order in which Rules were given. So we have to be sensitive to this too.