-
-
Notifications
You must be signed in to change notification settings - Fork 195
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
Allow using LinearAlgebra.I(n) as is #2090
Comments
Is there a reason you cannot use |
Passing the identity matrix as the IVs is convenient to get the solution in form of the corresponding fundamental matrices. Or maybe there is another way to get the solution in this form? |
2*I though is a very specific object though. It's not a matrix or a number, and it doesn't conform to any standard interfaces like that. If you were to keep this form then it also would only allow multiples of the identity matrix as the solution, which wouldn't hold in almost any case. In the cases which it did hold, you could just make it a scalar valued differential equation. |
This is why I suggest it may be type-cast to a matrix at problem construction similar to this SciML/Integrals.jl#208. But maybe passing I(n) to a problem is a very rare use case that doesn't require changes. |
Is your feature request related to a problem? Please describe.
When passed to a problem constructor,
LinearAlgebra.I(n)
should be treated as is, without manual type conversion by the user.For now, it requires some boilerplate to avoid errors that appear in various usages, e.g.:
I've seen this issue only with IVs but it might appear in other cases.
Describe the solution you’d like
Probably, problem constructors or solvers should just typecast to an appropriate type. Probably, always casting to
float(Matrix(LinearAlgebra.I(2)))
would be safe.Describe alternatives you’ve considered
Copy-pasting the boilerplate.
The text was updated successfully, but these errors were encountered: