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

Unify interface for decompose and overapproximate #345

Closed
schillic opened this issue May 21, 2018 · 4 comments
Closed

Unify interface for decompose and overapproximate #345

schillic opened this issue May 21, 2018 · 4 comments
Assignees
Labels
simplification 👶 Simplifies code

Comments

@schillic
Copy link
Member

decompose basically calls overapproximate from a loop. Whenever we add a new overapproximate implementation, we also need to manually add a new implementation for decompose as well to support it there. Can we find a way to automate this process?
Maybe with macros?
Maybe by using the idea from #339 to only use Symbols as parameters and then determining the correct overapproximate function dynamically? Will this be efficient?

@mforets
Copy link
Member

mforets commented Jun 7, 2018

decompose's signature is:

function decompose(S::LazySet{N};
                   set_type::Type{<:Union{HPolygon, Hyperrectangle, Interval}}=Hyperrectangle,
                   ε::Real=Inf,
                   blocks::AbstractVector{Int}=default_block_structure(S, set_type),
                   block_types=Dict{Type{<:LazySet}, AbstractVector{<:AbstractVector{Int}}}(),
                   directions::Union{Type{<:AbstractDirections}, Void}=nothing
                  )::CartesianProductArray where {N<:Real}

Here, set_type is the target set type. Suppose that we generalize this to set_type::Type{<:LazySet}=Hyperrectangle,, isn't this what is needed to make it general? It ultimately depends on project being defined for such target type.

@schillic
Copy link
Member Author

schillic commented Jun 7, 2018

One idea is to have a new struct that wraps all those options instead and decides which analysis is performed. There should also be a to-string function that prints the resulting action, like "use set type $set_type".

@schillic
Copy link
Member Author

These options can be distinguished by their type. Hence we could at least offer a general constructor that only takes one argument.

@schillic
Copy link
Member Author

I would argue that the decompose interface is now much simpler and there is no need for this anymore.

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

No branches or pull requests

2 participants