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

Dimension of an Array is type-specific? #28698

Closed
azraq27 opened this issue Aug 16, 2018 · 5 comments
Closed

Dimension of an Array is type-specific? #28698

azraq27 opened this issue Aug 16, 2018 · 5 comments
Labels
arrays [a, r, r, a, y, s] error handling Handling of exceptions by Julia or the user

Comments

@azraq27
Copy link

azraq27 commented Aug 16, 2018

I came upon this having difficulty implementing an unsafe_wrap from a multidimensional array returned from a C function (using Julia v0.7)

It appears that Array cares about the type of the dimension that it was defined with. As in:

julia> Array{Float32,Int32(1)} == Array{Float32,1}
false

In my function that processed the C array, I used a variable for my dimension, which happened to be an Int32, and it was causing unsafe_wrap to crash. When I cast the dimension as Int64, everything works fine. For example:

julia> unsafe_wrap(Array{Float32,Int32(5)},p,(161,191,151,1,6));
ERROR: StackOverflowError:
Stacktrace:
 [1] #unsafe_wrap#60(::Bool, ::Function, ::Type, ::Ptr{Float32}, ::NTuple{5,Int64}) at ./pointer.jl:92
 [2] (::getfield(Base, Symbol("#kw##unsafe_wrap")))(::NamedTuple{(:own,),Tuple{Bool}}, ::typeof(unsafe_wrap), ::Type, ::Ptr{Float32}, ::NTuple{5,Int64}) at ./none:0
 ... (the last 2 lines are repeated 13774 more times)
 [27551] #unsafe_wrap#60(::Bool, ::Function, ::Type, ::Ptr{Float32}, ::NTuple{5,Int64}) at ./pointer.jl:92
 [27552] unsafe_wrap(::Type, ::Ptr{Float32}, ::NTuple{5,Int64}) at ./pointer.jl:92

julia> unsafe_wrap(Array{Float32,5},p,(161,191,151,1,6));

I can't see a reason the dimension of an Array needs to be type-specific. Is there a good reason for that? Could we upgrade them all to Int64?

I'm also not sure why the dimension being defined as an Int32 caused unsafe_unwrap to crash.

Thanks.

@JeffBezanson
Copy link
Sponsor Member

The type system compares parameters using ===; they have to be identical for the types to match. I think it's best just to require Int and give better errors. Inserting code to convert from other integer types to Int is possible, but I think it's too much complexity for something so fundamental.

@JeffBezanson JeffBezanson added the arrays [a, r, r, a, y, s] label Aug 16, 2018
@azraq27
Copy link
Author

azraq27 commented Aug 16, 2018

In this scenario it seems annoying, but I can appreciate keeping consistency within the type system as a whole is important.

But, why is unsafe_wrap failing with a StackOverflowError? Why does changing the dimension from a Int64 to Int32 suddenly make it overflow?

@mbauman
Copy link
Sponsor Member

mbauman commented Aug 16, 2018

It's because the method table is defined with an expectation that the dimension is an Int value. In this case, it's expecting to be able to match the number of elements in the dimensions tuple (an NTuple{5, Int}) against the number of dimensions in the array (Array{Float32, Int32(5)}).

Note that you get the same stack overflow if you pass it an Array{Float32, 4}. We could probably just use a bit better error messages here.

@mbauman mbauman added the error handling Handling of exceptions by Julia or the user label Aug 16, 2018
@azraq27
Copy link
Author

azraq27 commented Aug 17, 2018

Sounds reasonable. Having some more informative error messages about this seems like a good solution.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Mar 15, 2021

At some point we'll add type-parameter typeof constraints, at which point this will be handled. I don't have the exact issue number for that, but it does exist already elsewhere.

@vtjnash vtjnash closed this as completed Mar 15, 2021
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] error handling Handling of exceptions by Julia or the user
Projects
None yet
Development

No branches or pull requests

4 participants