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

Create subsets with labels #59

Open
bgctw opened this issue Apr 30, 2019 · 6 comments
Open

Create subsets with labels #59

bgctw opened this issue Apr 30, 2019 · 6 comments

Comments

@bgctw
Copy link
Contributor

bgctw commented Apr 30, 2019

When working with parameter sets, often a subset of parameters are optimized, or studied in a sensitivity analysis. Extracting subsets is currently difficult with LabelledArrays.

Therefore, a subset function would be nice.

julia> zs = SLVector(a=1.0,b=2.0,c=3.0);
julia> zsSub = subset(zs, (:c,:a))
2-element SLArray{Tuple{2},Float64,1,2,(:c, :a)}:
 3.0
 1.0
@ChrisRackauckas
Copy link
Member

Does it need to be a different function? I'm not sure why this specifically should be a different function, and now just a getindex by a tuple of symbols?

@bgctw
Copy link
Contributor Author

bgctw commented May 2, 2019

I can imagine many cases of getindex, where actually the labels are not needed. And I want to avoid creating many new types for those slices. The type proliferation argument argues also against the subset function, but at least a separate function makes it more obvious and conscious, and allows the user to choose whether a new type is required.

@bgctw
Copy link
Contributor Author

bgctw commented May 2, 2019

Another reason might be performance. Just slicing the underlying SVector can be done by Arrays or SVectors. Creating, a new labelled type requires to convert the collection of symbols or indices to value types. But I should test, whether this actually yields a performance penalty.

@ChrisRackauckas
Copy link
Member

Adding the labels should be a performance issue. If you index by the labels I would think it should return essentially the subarray with the appropriate labels, if the labels are given in a structure that is directly inferrable. So it would have to be a tuple of symbols, and I guess you don't generally use getindex on a tuple, so that might be kind of odd. So maybe subset makes sense for that tuple of symbols case, but I'm not entirely convinced.

@bgctw
Copy link
Contributor Author

bgctw commented May 4, 2019

Do I understand correctly, that you (@ChrisRackauckas) propose that return type should depend on whether to index with integers or symbols and only indexing by symbols should return the labelled type?

Alternatively, indexing by "structure that is directly inferrable" (including a tuple of integers) could return a labelled result and others an array. Although, new and occasionally Julia users might not be always conscious of the meaning of "structure that is directly inferrable". While the distinction between Tuple and Array is clear, how should indices of StaticArray, and LabelledArray be handled? I would then constrain returning labelled results to tuples only, and let the user choose by converting indices of StaticArrays to Tuples.

I prefer a solution where indexing by a tuple of symbols, AbstractVector{Symbol}, or integers consistently return the same type and the user can choose by the invoked different functions.
Although returning a labelled subtype might not be possible with providing general AbstractVector{Symbol}. Still subset methods could support indices of LabelledArray and StaticArray.

@ChrisRackauckas
Copy link
Member

I see where you're going. Okay, let's give subset a try!

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

No branches or pull requests

2 participants