Skip to content

Full Rearrangement Support#9

Open
RLee64 wants to merge 16 commits into
stagingfrom
full-rearrangement-support
Open

Full Rearrangement Support#9
RLee64 wants to merge 16 commits into
stagingfrom
full-rearrangement-support

Conversation

@RLee64
Copy link
Copy Markdown
Owner

@RLee64 RLee64 commented Dec 19, 2025

Overview

Pull request addressing #5, this aims at extending functionality to support all reasonable rearrangement problems that SymEngine is capable of handling.

Changes

  • Cleaned up existing parsing from solved SymEngine equation to AST (mainly getting rid of unnecessary curly braces)
  • Added support for rearranging all trigonometric expressions
  • Fixed a bug with incorrect substitution of AST type MULT for SUB in unary minus case (this was an issue when we had SymEngine expression nodes with at least 3 children)
  • Added support for rearranging exponents and logarithms
  • Added support for other arithmetic operators (i.e. root, abs, ceil, floor, min, max, and rem)
  • Added support for rearranging differential equations
  • In order to add support for differential equation rearrangement, our method of populating the symbolMap and variableMap was adjusted to be created dynamically as we found variables. This allows us to keep track of the variable of integration as well.
  • Also fixed an issue where the variable of rearrangement couldn't be identified in the import map whenever the variable and equation were located in different files.
  • Added test cases to make sure unrearrangeable equations aren't being unintentionally manipulated

Notes

  • Just like in Extended Rearrangement #3 highlighted, SymEngine isn't capable of inversing transcendental functions. Here we can also see that this issue applies to a lot of other types of functions as well (e.g. abs, ceil, min), although their irreversibility here is arguably more understandable.

Failing Test Cases

  • The generator test cases that were failing in Extended Rearrangement #3 are still failing here, with the addition of Generator.sineImports as well. These models seem to all have some of their equations rearrangements, consequently altering their generated outputs, which ultimately fails the test checking output equivalence.
image

- Removed curly braces where unnecessary
- Changed explicit type declaration to auto
- Renamed symbolExpr to symbol
This was painful even with copilot's help........
Previously our conversion to simplify -1 * x to -x didn't account for multiplication expressions with more than 2 children (e.g. -1 * x * y), this led to incorrect conversion (i.e. -x - y).

This commit fixes this issue, and also structures the function a bit more clearly in general.
As seen in trigonometric functions, symengine is not capable of inversing transcendental functions. So no such test cases for those have been created.
In order to achieve this, we also have to adjust how our map is populated. Since we don't have access to the voi from an individual equation, we'll instead populate variables in our rearrangement map as we encounter them.
It's very difficult for us to try and make sure every equation we parse into a seEquation is rearrangeable. As such we'll let SymEngine throw errors and catch them to make sure a failed rearrangement doesn't nuke the analyser's ability to do its job.
We want to make sure they fail at rearranging and produce an NLA system
Experienced an issue where the symbol map doesn't account for when the rearrangement subject can have multiple names (which most likely occurs when the variable the equation is solving for is located in a different file).

This was discovered due to generator.sineImports failing (test case still fails, but for another reason now)
RLee64 added 7 commits January 9, 2026 13:11
Hopefully this change also fixes the issue for Mac/Linux (0_0 )
This is an issue that only occurs in symengine debug mode since symengine wants to make sure our derivatives match their canonicality requirements. The problem seems to be that placing symengine requires the independent variable to be in a function with the dependent variable before differentiation. Since this makes things difficult to convert to and from, I've instead opted to make differentiation a function symbol since we're not trying to rearrange for the differential anyway.
Again, symengine flags a canonical issue, but this time it's because when attempting to solve for an error, the internal symengine tries to create a non-canonical POW element. This completely forces our hand since symengine aborts the program after a canonical error, which means we can't catch the issue like in other cases. As a temporary measure I've removed the test case, but this is by no means ideal.
Need to review this in greater detail along with the others, but it seems the extended rearrangement capabilities have modified some of our equations to eliminate certain NLA systems.
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