Repository metrics
- Stars
- (686 stars)
- PR merge metrics
- (Avg merge 19d 17h) (36 merged PRs in 30d)
Description
Right now, when using a "view" on an array slice (i.e., a sub-array that does not create a copy but directly operates on the original data), we use both the function-style view(...), e.g.,
# Interpolate to bottom lower left element
multiply_dimensionwise!(
view(u, :, :, :, :, bottom_lower_left_id), forward_lower, forward_lower, forward_lower,
view(old_u, :, :, :, :, old_element_id), u_tmp1, u_tmp2)
(ref) and the macro-style @views, e.g.,
# Copy old element data to new element container
@views elements.u[:, :, :, :, element_id] .= old_u[:, :, :, :, old_element_id]
(ref). I think for the sake of new (Julia) users (and my own sanity, but really it's about the first one), it would be beneficial to use only one of the two approaches in general.
Personally, I prefer @views since it is (usually) only a performance enhancement that does not change the code logic, thus I like that it can be "slapped on" an existing expression without changing the expression itself. Also, my brain is much faster in deciphering what @views u[:, :, :, :, element_id] means than for view(u, :, :, :, :, element_id) (especially in expressions with multiple views), since it intuitively recognizes the brackets [ ] as array accessors. However, a case can also be made for view(...), as it moves the "verb" closer to the "subject", i.e., it is immediately clear which arrays are affected.
Before #145 was merged, we had about 2 view(...)s and 25 @views in master; now it is about 60 view(...)s and 25 @views.
I'm sorry for bringing up yet another consistency issue, but this one can be resolved fairly easy I think (especially, if we just use @views everywhere :smiling_imp:)