Defining boolean operators

[j-thib]

Hi, has anyone been successful at defining certain boolean operators such as "or"? For instance, here is a snippet from my model instantiation.

    model = PySRRegressor(
    niterations = 350
    binary_operators= ["OR(x1, x2) = Float32(x1 == Float32(true) || x2 == Float32(true))"],
    
    extra_sympy_mappings={
        "OR": lambda x1, x2: sympy.Or(x1, x2)
    },...

Upon searching in this space, the function returned doesn't include the defined "or" operator, instead returning a constant prediction. I have been successful with "and", "greater than" and "less than", but "or" seems to be causing problems. Is there something causing "or" to be more difficult for PySR to explore?

Thanks!

[MilesCranmer]

Hi @j-thib,

Keep in mind that PySR performs all calculations in the space of real numbers, so to do calculations like this, it is much easier to treat numbers greater than 0 as true, and numbers less than 0 as false.

Otherwise, to get a true, it would have to exactly land on x1 = 1.0, which, if it's doing constant optimization, is basically going to be impossible.

I would do this instead:

OR(x, y) = ((x > zero(x)) | (y > zero(y))) * one(x)
AND(x, y) = ((x > zero(x)) & (y > zero(y))) * one(x)

This assumes that x > 0 => true and x <= 0 => false. It should be much easier for it to search.

Also, some Julia stuff: zero(x) returns a 0.0 but with the same precision as x. Easier than writing Float32(0.0). The * one(x) is just to convert from a Bool back to a Float.

Then for your sympy version, I would actually write it like this:

"OR": lambda x, y: sympy.Piecewise((1.0, (x > 0) | (y > 0)), (0.0, True)),
"AND": lambda x, y: sympy.Piecewise((1.0, (x > 0) & (y > 0)), (0.0, True)),

Cheers,
Miles

[MilesCranmer]

Why those operators instead of lt(x, y) = (x < y) * one(x)? Not sure I follow why they use (x > 0) < (y > 0) instead

[MilesCranmer]

And the sympy operator, lambda x, y: x < y

[j-thib]

I have no reasoning beyond that I thought it might help to define all operators in similar terms. However, I previously tried what you just suggested and was not successful.

I am a bit stumped, but suspect that the difficulty has something to do with the hierarchical structure of the operator search. Is it possible that the "OR" operator is not being rewarded due to high stochasticity and is therefore pruned early on?

[MilesCranmer]

Hm, I suppose it could be. One option is to try smoothing it, rather than having a discontinuous function. For example, given we know that or has points {(0,0)->0, (0,1)->1, (1,0)->1, (1,1)->1}, you could do 2D interpolations between those points, and set the values outside those boundaries to be just 0 or 1 accordingly

[MilesCranmer]

For example, smooth_or(x,y)=clamp(clamp(x, 0, 1) + clamp(y, 0, 1), 0, 1) is a bit like an or, but it’s continuous