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

map is overwritten for non-StaticArrays. #282

Closed
andreasnoack opened this issue Aug 11, 2017 · 5 comments
Closed

map is overwritten for non-StaticArrays. #282

andreasnoack opened this issue Aug 11, 2017 · 5 comments

Comments

@andreasnoack
Copy link
Member

andreasnoack commented Aug 11, 2017

The problematic lines are

@inline function map(f, as::Union{SA,AbstractArray}...) where {SA<:StaticArray}
_map(f, same_size(as...), as...)
end
The new behavior might be JuliaLang/julia#21026. I'm not sure

This is on

Julia Version 0.7.0-DEV.1327
Commit 104dce7fcf* (2017-08-11 16:01 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin16.7.0)
  CPU: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT NO_AFFINITY HASWELL)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, haswell)
Environment:
@tkoolen
Copy link
Contributor

tkoolen commented Aug 16, 2017

Ref: JuliaLang/julia#21026 (comment).

@andyferris
Copy link
Member

Thanks. We'll need to dream up a workaround for this little "hack" to express such a set of types.

For anyone finding this (and issues like this): It's likely that at some point it will become too difficult to target both v0.6 and v0.7. Given Julia changes like JuliaLang/julia#23168 I'm very tempted to just say "StaticArrays should not be considered as suitable for "real work" on v0.7 until much closer to to the release time". I feel master should target v0.6 (with "feature" improvements like LU decompositions) and we merge any v0.7 fixes which are compatible with v0.6. I'm hopeful we can find a simple fix for this issue.

@c42f
Copy link
Member

c42f commented Aug 18, 2017

Hmm, this is unfortunate, though it was always a bit of a hack relying on this peculiarity.

The really nasty thing IIRC was if you try to do this in another way (by directly writing out various function signatures), the number of ambiguities quickly explodes in your face.

Another option might be to refactor the map internals to look a bit more like broadcast, as Broadcast.containertype() was pretty nice to hook into. Obviously this would be changes to Base...

@martinholters
Copy link
Collaborator

Fixed by #296. (Although the new behavior---only intercept map if the first argument (after the function) is a StaticArray--- still leaves something to be desired, this particular issue is fixed.)

@andyferris
Copy link
Member

OK, let's just close this since the OP seems to be resolved - there are always many things which can be improved further in StaticArrays :)

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

5 participants