Add method to evaluate SCIP expressions without variables

[Joao-Dionisio]

This came up in my work, I don't know if there's a better way to do this. model.getVal() doesn't work, and Python's eval() can't deal with SCIP's log/exp, etc, so that's why I require a string and use eval() afterward.

It's possible that I made a mistake with the parenthesis, but it seems to be working.

EDIT: What do you think of this, Mo?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (99aa49d) 61.68% compared to head (d49902d) 61.77%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #771      +/-   ##
==========================================
+ Coverage   61.68%   61.77%   +0.08%     
==========================================
  Files          16       16              
  Lines        3255     3262       +7     
==========================================
+ Hits         2008     2015       +7     
  Misses       1247     1247              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Opt-Mucca]

@Joao-Dionisio What was the context where you needed to evaluate a constant expression? I think these scenarios would be exceedingly rare and should probably be done with other packages. Thoughts @mmghannam ?

I'd also recommend changing the name of the function. Something like eval_constant_expression()

[Joao-Dionisio]

Hey @Opt-Mucca! Yes, the use cases would be very limited. I defined a lambda expression that had pyscipopt's log, exp etc functions to incorporate into a constraint. But I'm also creating a heuristic that would attribute values to the variables in such a way that this lambda expression is constant. Without this method, I have no way of evaluating this constant.

Maybe people doing stuff with numerics, or just trying to check their results by hand would also benefit. Having scip.log(2) return log(2) isn't super helpful.

But for my own work I can just write a function, if you think it doesn't make much sense to add this, we can close the PR :)

[Opt-Mucca]

I'm not against it being added if the name is changed. If you have an actual use case for it then it's likely someone else might end up in the same situation. Just find it to be an interesting scenario.

[mmghannam]

I'd have to agree with @Opt-Mucca here. The method is not particularly related to SCIP. It also doesn't call the underlying SCIP instance or interact with it in any way. @Joao-Dionisio I just want to understand what did you want to pass to model.getVal()? I want to understand the use case more.

[Joao-Dionisio]

@mmghannam I just ended up writing a function that does the same thing, I agree that it doesn't need to be a PySCIPOpt method.

As for additional context, I have this degradation = lambda x: exp(exponent*x)*log(basis), where exp and log are PySCIPOpt functions. This then is added to another expression to make up a constraint in the model. As part of an heuristic, I need to calculate degradation(const), where const is an actual number provided by me. If I don't use this eval method, I need to work with things like this: ExprCons(sum(0.06079,prod(-1.0,sum(20.02,prod(0.0035614358919083995,sum(2219.282121,prod(-1.0,exp(0.1756831),log(0.68)),prod(-1.0,sum(0.0,prod(1.0,exp(0.0),log(0.16))))))))), 1e-05, None). This is an actual number, but I have no way of doing calculations with it.

But yeah, I think this PR can be closed, as a standalone function does the same thing and the usage is so limited.