Skip to content

Casadi array - #92

Open
sixpearls wants to merge 9 commits into
mainfrom
casadi-array
Open

Casadi array#92
sixpearls wants to merge 9 commits into
mainfrom
casadi-array

Conversation

@sixpearls

@sixpearls sixpearls commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Casadi 3.8 introduces an ArrayInterface class which handles much of the numpy compatibility issues. This PR attempts update the backend to use ArrayInterface instances for symbolic expressions rather than raw MX objects to simplify the condor code base for performance and maintainability.

  • ended up changing the symbol generating algorithm to generate flat symbols, wrap with array, then reshape appropriately; this seems straightforward to get right and may enable support for higher dimensional expressions

  • currently a bug in casadi that causes incorrect behavior for matrix multiply of ArrayInterface objects with numpy arrays; to get tests to pass and documentation to build, model expressions using numpy arrays are changed to use casadi arrays through the backend shim. We need to decide if this is desirable; I could imagine backend-specific numerical storage could be more efficient but I am not sure that this API can be used to specify anything other than dense matrices so there may not be a purpose except consistency of using the shim. If this is undesired, a new issue should be made to track casadi release and revert the examples back.

    • UPDATE (9/4/2026 1400): based on offline discussion probably OK to user ops.array, especially if we can use it to make other things nicer like supporting construction of arrays using a mix of casadi.MX (wrapped in array or not) and numeric literals
  • due to better is_symbolic checking, it may handle models with inputs from ops creation routines (eye/ones/etc) as numeric (correctly), should add test

    • UPDATE (9/4/2026 1400): initial tests don't work, probably worth fixing as part of this PR
  • UPDATE (9/4/2026 1400): also interested in exploring additional wrapping on expression_to_operator to do substitutions if possible

    • UPDATE (9/4/2026 2230): benchmarked by running pytest, this is a substantial slowdown. It's possible it could have a positive impact on coding SIGMA, but maybe it's too much technical debt at this point?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant