Sheehan Olver
Sheehan Olver
We should add `blockvcat(A,B,...)` that produces a blocked array. For example `blockvcat(1:5,10:12)[Block(1)] == 1:5`. But also supporting the case where`A` and `B` are blocked, where the block structure is concatenated....
It would be helpful if non-blocked arrays behaved as follows: ```julia view(1:5, Block(1)) === 1:5 ``` This is consistent with the new behaviour for block views of block arrays.
The broadcast code is not type stable, see below. The code seems quite complicated with generated functions, so I think the best would be to right special case code for...
It's sometimes useful to have multiple layers of blocks, see conversation in https://github.com/JuliaDiffEq/MultiScaleArrays.jl/issues/25 I think one way to do this would be to support some sort of `BlockView` that converts...
This error seems unnecessary; ```julia julia> mortar([[1,2] [3,4]]) ERROR: All blocks must have ndims consistent with ndims = 2 of `blocks` array. Stacktrace: [1] sizes_from_blocks(::Array{Int64,2}) at /Users/solver/Projects/BlockArrays.jl/src/blockarray.jl:241 [2] mortar(::Array{Int64,2}) at...
At the moment `BlockArray(arr::AbstractArray{T,N},..)` creates a `BlockArray{T,N,typeof(arr)}`. However, for many types subarrays are not of the same type (e.g., `Diagonal`). I think it is safer to always convert to `Array`....
At the moment FFTW.jl converts to column major. This is particularly silly since, apparently, FFTW itself then converts back to row major: https://www.fftw.org/fftw3_doc/Column_002dmajor-Format.html It therefore seems natural to support row...
Note that Julia supports a [strided array interface](https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-strided-arrays). At the moment FFTW only works with `StridedArray` which means other types can't use it, see below example. I assume this is...
Should calling `lmul!` with something that's not a `StridedArray` error out like this? ```julia julia> n = 10; F = FFTW.plan_r2r(randn(n), FFTW.REDFT00) FFTW r2r REDFT00 plan for 10-element array of...
Overall, I like the overriding of `*` for planned transforms. But it is a bit odd that `*` modifies what you multiply in the following: ```julia P = plan_fft!(x); P...