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

Linear model #6

Closed
wants to merge 8 commits into from
Closed

Linear model #6

wants to merge 8 commits into from

Conversation

tpunnoose
Copy link
Contributor

The remaining items to do include:

  • figure out how to make macros work inside local scope
  • make macro code cleaner
  • remove allocations from the inplace linearization/discretization methods
  • improve documentation

Copy link
Member

@bjack205 bjack205 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work so far. I mentioned this a couple places, but there seems to be a lot of repetitive code in here, which makes it hard to maintain and debug. I'd like to clean it up a little bit. Julia is usually pretty good at making a lot out a few lines of code. Let's think a bit more about how we can clean it up and make it more unified. I'm also not in love with the interface yet. Having separate macros for time invariant and time-varying for example: we should have one and just pass a is_time_varying flag to the macro, like we do for is_affine.


Creates a struct that looks like:
```julia
struct (name){TA, TB, Td} <: ContinuousLTI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you using RefValue to allow the values to change? I'm curious if this is any more efficient than just making the struct mutable? I think I'd prefer to make the struct mutable since it'll probably make it easier to understand what's going on.


return (A_d, B_d)
function _ltv_affine(name, n, m, N, supertype)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of redundant code in here. For example, I think it would be pretty easy to combine the affine and non-affine functions in one. Just have a little bit of branching for the few things that are different rather than copying a bunch of code. It makes it easier to maintain and reduces bloat.

@@ -0,0 +1,197 @@
"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General comment here: this file seems overly verbose. There's a lot of repeated code. Is there a way we can clean this up to make it easier to understand and maintain?

_discretize!(::Type{Q}, ::Val{true}, discrete_model::DiscreteLinearModel, continuous_model::ContinuousLinearModel, k::Integer, dt) where {Q<:Explicit} =
_discretize!(Q, Val(true), discrete_model, get_A(continuous_model, k), get_B(continuous_model, k), get_d(continuous_model, k), k, dt)

function _discretize!(::Type{Exponential}, ::Val{true}, discrete_model::DiscreteLinearModel, A::AbstractMatrix, B::AbstractMatrix, d::AbstractVector, k::Integer, dt)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel these discretization schemes are tangential to the ones in integration.jl. I'd like to have one place of integration schemes, rather than placing them in different places and without having them be interchangeable. Can we unify the ways these are used? For example, I should be able to use RK4 with discrete_jacobian or discretize.

@tpunnoose tpunnoose closed this Sep 17, 2020
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.

2 participants