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

Deprecate fallback elsize for AbstractArray #26379

Merged
merged 1 commit into from
Mar 12, 2018
Merged

Conversation

mbauman
Copy link
Member

@mbauman mbauman commented Mar 8, 2018

Just like the deprecation of strides (#25321), the default implementation for elsize is generally not true. This deprecates the fallback, restructures it to be defined on the type (and not the value), and implements it where possible for the builtin array types and wrappers.

Just like the deprecation of strides (#25321), the default implementation for `elsize` is generally not true. This deprecates the fallback, restructures it to be defined on the type (and not the value), and implements it where possible for the builtin array types and wrappers.
@mbauman mbauman added arrays [a, r, r, a, y, s] deprecation This change introduces or involves a deprecation labels Mar 8, 2018
@@ -44,6 +44,7 @@ function size(a::ReinterpretArray{T,N,S} where {N}) where {T,S}
tuple(size1, tail(psize)...)
end

elsize(::Type{<:ReinterpretArray{T}}) where {T} = sizeof(T)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem totally safe --- it seems like the parent array type would need to be involved somehow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no relation imposed by this code between the memory layout of a reinterpret array and its parent. However, it does impose that T is a known isbits type, which has a known memory size (although not stride) equal to sizeof(T)

Copy link
Member Author

@mbauman mbauman Mar 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Jeff is right. Am I correct in thinking about the three cases here?

  • sizeof(eltype(R)) < sizeof(eltype(R.parent)): the elsize of the parent should appear in ReshapedArray's second stride.
  • sizeof(eltype(R)) == sizeof(eltype(R.parent)): elsize and strides should match
  • sizeof(eltype(R)) > sizeof(eltype(R.parent)): The reshaped array is only a strided array if sizeof(eltype(R.parent)) == elsize(R.parent). We cannot pass this object to BLAS otherwise, since BLAS will assume that the bits are contiguous.

Edit: I'm not — I had been thinking that reinterpret added a dimension (which would be nice to save a divrem), but it cannot because it supports non-integral ratios between the two elsizes (so long as the total first dimension works out to an integer).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I'm going to follow this up with the strides portion of #26072, which will include part of that. I'm not sure how to handle that third bullet point, though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should maybe merge this now anyway, since it's no worse than it was before.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's less of a problem now that #26393 is merged — only reinterprets of DenseArrays (and contiguous views thereof) are considered strided now. We'll have to be very careful about how ReinterpretArrays opt-in to being considered strided in the future. I think we'll just need to demand that elsize(parent(R)) == sizeof(eltype(parent(R))) and stride(parent(R), 1) == 1. In all other cases, this cannot be correct.

@JeffBezanson JeffBezanson added this to the 1.0 milestone Mar 12, 2018
@mbauman mbauman merged commit 0a7bb64 into master Mar 12, 2018
@mbauman mbauman deleted the mb/deprecateelsize branch March 12, 2018 04:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] deprecation This change introduces or involves a deprecation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants