Casadi array - #92
Open
sixpearls wants to merge 9 commits into
Open
Conversation
…helpfully make sure everything is being consistent. started working through a bunch of fixes after first attempts of updating backend files
…t errantly cause symbolic model instance for inputs using ops creation routines (eye/ones/etc)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
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 literalsdue to better
is_symbolicchecking, it may handle models with inputs from ops creation routines (eye/ones/etc) as numeric (correctly), should add testUPDATE (9/4/2026 1400): also interested in exploring additional wrapping on
expression_to_operatorto do substitutions if possible