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

similar(staticarray, newsize) produces a statically sized array #22

Closed
andyferris opened this issue Aug 28, 2016 · 8 comments
Closed

similar(staticarray, newsize) produces a statically sized array #22

andyferris opened this issue Aug 28, 2016 · 8 comments

Comments

@andyferris
Copy link
Member

This is inefficient since the new size won't be known to the compiler, and Array would be faster. While speculative, future compiler enhancements might lead to proper constant propagation in this case, I think we should make this return an Array for now.

Should we introduce similar(array, Val{newsize})? It clashes with a method in base, but I think this usage makes more sense. @timholy?

@timholy
Copy link
Member

timholy commented Aug 29, 2016

Given that one could create an array of Val objects, we probably shouldn't co-opt that meaning of similar. How about introducing a specific type, like SDims{newsize}? Since that type doesn't yet exist, there's no code that could possibly break.

We might conceivably want SIndices{newinds} someday, so being able to dispatch on more than one type will also be nice.

@andyferris
Copy link
Member Author

How about introducing a specific type, like SDims{newsize}? Since that type doesn't yet exist, there's no code that could possibly break.

This is a bit like Stefan's proposal in JuliaLang/julia#18161.

Maybe Dimensions{(d1, d2,...)} ?

@timholy
Copy link
Member

timholy commented Aug 29, 2016

That would be fine. Base has Dims, and I was making that Static 😛 . But no objections to this version.

@timholy
Copy link
Member

timholy commented Aug 29, 2016

FYI there's also a typealias in base already called Indices which won't do what it would need to do here. Though really one could use Dimensions for both of them, having it contain either an NTuple{N,Int} or NTuple{N,AbstractUnitRange}.

@andyferris
Copy link
Member Author

andyferris commented Aug 30, 2016

That would be fine. Base has Dims, and I was making that Static 😛 . But no objections to this version.

Oh I get it now... :)

FYI there's also a typealias in base already called Indices which won't do what it would need to do here. Though really one could use Dimensions for both of them, having it contain either an NTuple{N,Int} or NTuple{N,AbstractUnitRange}.

So Indices helps with the non-1-based indexing?

In general, I have been wondering whether any isbits, indexable collection could be the indices... so SVector{3} would become SVector{1:3} but we could also have SVector{(:red, :green, :blue)} (EDIT: or rather some index or static dictionary, (:red => 1, :green => 2, :blue => 3))

@timholy
Copy link
Member

timholy commented Aug 30, 2016

Maybe yes. But one constraint needs to be contiguity, if the index type has such a notion. In other words, [1,2,4] would be right out.

@andyferris
Copy link
Member Author

Right... I guess this comes back to the old question about the difference between an array and a Dict. So what is the current definition of an array dimension? Any UnitRange? Would you like to extend that in any way?

@timholy
Copy link
Member

timholy commented Aug 30, 2016

At present, any AbstractUnitRange works (see https://github.com/timholy/CustomUnitRanges.jl). I'm all in favor of thinking about how to extend the notion of indices, but with full awareness of the potential for ambiguities (by which I mean potential for multiple conflicting meanings, e.g., my oops fixed in JuliaArrays/OffsetArrays.jl#12, or the issue re linear indices addressed by the addition of linearindices) or performance costs of generalizations.

You probably already saw JuliaLang/julia#10064 (comment).

oschulz pushed a commit to oschulz/StaticArrays.jl that referenced this issue Apr 4, 2023
* general collection mechanism

* cleanup

* fix promoted_eltype

* cleanup

* fix recursive

* cleanup

* respect user type

* add tests

* test pass no inf

* fix inference

* multidimensional case
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