Change the ordering of how sympy mappings are collected so that user-defined mappings override existing ones

[romanovzky]

Hi,

In #856 a problem with the cbrt function led to a redefinition of the sympy mapping here #858 . While this solved the problem of using model.predict, the new mapping is cumbersome to read in sympy or latex form, making it hard to reuse the expression downstream.

A simple solution for this would be to change the mapping back to sympy.cbrt to force nice looking expressions for latex and other applications outside the python API. However, this is difficult to do without the user writing their own parsing function to emulate the functionality of https://github.com/MilesCranmer/PySR/blob/master/pysr/export_sympy.py.

A simple solution would be to change in

PySR/pysr/export_sympy.py

Line 81 in 871a710

def pysr2sympy(

    local_sympy_mappings = {
        **create_sympy_symbols_map(feature_names_in),
        **(extra_sympy_mappings if extra_sympy_mappings is not None else {}),
        **sympy_mappings,
    }

to

    local_sympy_mappings = {
        **create_sympy_symbols_map(feature_names_in),
        **sympy_mappings,
        **(extra_sympy_mappings if extra_sympy_mappings is not None else {}),
    }

this way, the extra_sympy_mappigns would override the internal ones (sympy_mappings), allowing for the user to change the cbrt to a more readable format after training and validating the result using the python API.

This change would also allow users to have more control over the sympy mappings used beyond the specific problem that I've encountered.

[MilesCranmer]

That’s a really great point! Yes I am all for that. In fact I’d even consider the current behavior a bug; so this is very worth changing. (Happy to take a PR if you have time; otherwise I will eventually get to it)

[romanovzky]

See #868