Precision errors when converting python floats to SCIP_REALs

[Joao-Dionisio]

Conversion of Python types to C types sometimes yields precision errors. It's not clear to me when and why this happens.

m = Model()
x = m.addVar()
m.setObjective(15.32*x)
m.writeProblem("model.cip")

The values stay correct right up the call to SCIPchgVarObj in L1347

Interestingly, if we set the objective at variable creation, the same doesn't happen.

m = Model()
x = m.addVar(obj=15.32)
m.writeProblem("model.cip")

System

• OS: Ubuntu
• Version 22.04
• SCIP version 8.1.0
• How did you install pyscipopt? Source

[leoneifler]

The number 15.32 is not exactly representable in binary floating-point format. Why this does not happen if you set it at variable creation I have no idea, but I am guessing this is the overall reason for observing this effect.

[Joao-Dionisio]

Hey @leoneifler, thanks for looking into this! That is true, but at least in Python the precision is much higher:

In this PR we reverted manual variable typing, which seems to be the cause for this. See here:

Me and Mo discussed this yesterday, we have a feeling it might be due to calls to float in other files, like expr.pxi. In fact, we played around with some of this (but I can't tell for sure what did it 😞) and the error above no longer appears:

I have encountered this behavior in other circumstances as well, that's why I haven't created a PR.

Does this all seem reasonable, Leon? What do you think?

[DominikKamp]

Just for interest, I would like to ask what the actual reason for this was. It looks like a reversion is considered as a fix. Maybe it makes sense to try cdef double instead of cdef float because the Python float rather behaves like a C double, even more consistent would be cdef SCIP_Real if this is somehow possible.

[Joao-Dionisio]

Oh, hey @DominikKamp! Yeah this was pretty old, and I couldn't reproduce it anymore, I think the "fix" was just what you described.

And thanks for the tip, SCIP_Real is definitely possible to use in PySCIPOpt. I'll test this out over the coming days.

[DominikKamp]

Did it work?

[Joao-Dionisio]

Hey @DominikKamp! Yeah, I forgot about this. Just added a bunch of types and the tests pass and the above example also works, but it's difficult to know whether some other thing might go wrong.

I'll also add some types to the inputs, these shouldn't be controversial, I suppose. I'll create a PR by the end of this morning.

[Joao-Dionisio]

Okay, I managed to fail nearly 100% of the tests 😄

End of this morning might have been too optimistic.

[DominikKamp]

It is not urgent, I just thought some easy performance would be nice for the next release, but maybe it is more involved.

[Joao-Dionisio]

The performance gain should be quite small, as it only affects model creation for most people (and then some stuff on the callbacks, but again somewhat minimal gain). But yeah, I think it makes sense to do this, even if just to justify my inclusion in the release report :D