Issues with pytorch bindings in the case where structural_feasibility=False.

[oomcth]

This PR addresses the issue raised in #406.

Summary of Changes

I’ve added a test file under test/src/ to verify the correctness of the PyTorch bindings (with and without structural feasibility) by comparing them to the NumPy bindings.

The test only checks that gradients are returned, not that they are numerically correct (yet).

If needed, I can extend the test to compare PyTorch gradients to the NumPy ones.

For now, the test only covers the case where:

• There is exactly one equality and one inequality constraint.
• The QP problem is feasible.

The goal was to test that both forward and backward passes work as expected in a simple, feasible QP setup.

Note on cvxpy.py Rename

To avoid a conflict with the official cvxpy Python library, I had to rename the file:

test/src/cvxpy.py → test/src/cvxpy_test.py

This is because I use the actual cvxpy library inside the new test file.

If the rename causes a problem for your codebase structure, I can:

• Either remove the use of cvxpy in the test.
• Or move it to a location that doesn’t interfere.

Please do not merge this PR until we confirm the cvxpy.py rename is acceptable.

Known Limitations

This PR does not guarantee the bindings behave correctly in all edge cases.

I suspect there may still be minor bugs in cases such as:

• QPs with no equality or no inequality constraints.
• Higher-dimensional constraints or unusual input combinations.

For now, this PR ensures that forward/backward behavior is sound in the simple case I test.

For now, the PR gives an idea of the kind of issues we encounter in the bindings. These issues apparently only concern cases where structural_feasibility=False. I will likely continue the PR either next week or at the beginning of September to ensure everything is okay.