Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All assumptions applied to functions of time should be transferred to their discrete versions #215

Open
moorepants opened this issue Aug 29, 2024 · 11 comments
Labels

Comments

@moorepants
Copy link
Member

The generation of discrete variables looks like:

        self.previous_discrete_state_symbols = \
            tuple([sm.Symbol(f.__class__.__name__ + 'p', real=True)
                   for f in self.state_symbols])

This sets a real=True assumption on each new discrete symbol but any other assumptions that may have been applied to the continuous symbol would be lost. This can have an unexpected effect when the Jacobian is calculated if some assumptions would change the output of the Jacobian wrt to any discrete symbol.

@moorepants
Copy link
Member Author

A related issue is that the CSE variables don't have the assumptions of the expressions they replace. See #216 for related info.

@moorepants moorepants added the bug label Aug 30, 2024
@Peter230655
Copy link
Contributor

Peter230655 commented Jan 26, 2025

As far as opty is concerned, does this mean the following:
Say, the state variable is x1, and has certain assumptions, say, real=True, positive=True
Then x1i, x1p, x1n should have the same assumptions?

Similar with other variables that will be discretized?

@moorepants
Copy link
Member Author

Yes, but this may need more thought than I've explained here. I recall thinking the fix isn't so simple. That's why I didn't pursue.

@moorepants
Copy link
Member Author

Yes, this is a bit deeper issue: #215 (comment)

@Peter230655
Copy link
Contributor

Yes, this is a bit deeper issue: #215 (comment)

So I better stay away from it.

@moorepants
Copy link
Member Author

If you have symbols with assumptions and your form an expression with those symbols, you can then ask what assumptions hold for the expression. When you apply CSE to a large expression you get all these subexpressions and the associated substitution variable. You then have to ask what assumptions apply to that substitution variable.

This needs to be thought out wrt to the CSEd jacobian we do.

@Peter230655
Copy link
Contributor

Peter230655 commented Jan 26, 2025

If you have symbols with assumptions and your form an expression with those symbols, you can then ask what assumptions hold for the expression. When you apply CSE to a large expression you get all these subexpressions and the associated substitution variable. You then have to ask what assumptions apply to that substitution variable.

This needs to be thought out wrt to the CSEd jacobian we do.

If I understand correctly:

  • Say, a, b are real positive. Then for c = a - b a positivity assumption for c does not make sense anymore unless a > b is guaranteed for some reason.
  • If, say, a is an integer, then for c = sin(a) an integer assumption does for c not make sense in general.

If this is right, then if c = arbitrary_function(a1, a2, ...., an) pretty much the only assumption left for c is real=True?

@moorepants
Copy link
Member Author

What if the arbitrary function calculates eigenvalues, then real=True can't be assumed!

@Peter230655
Copy link
Contributor

Peter230655 commented Jan 26, 2025

What if the arbitrary function calculates eigenvalues, then real=True can't be assumed!

....unless the matrix in question is guaranteed to be symmetric.
So, even real=True cannot be assumed in general.
Not much left.

@moorepants
Copy link
Member Author

Technically these kinds of things can be with sympy's "new" assumption system.

@Peter230655
Copy link
Contributor

Technically these kinds of things can be with sympy's "new" assumption system.

I think, I keep my hands off this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants