Sheehan Olver

There's no obvious culprit I can see so will take some time to debug

I agree, but I think someone (other than me, I don't have time) just needs to take the lead on this and make a PR...

No

I think this fallback should be removed: https://github.com/nolta/Elliptic.jl/blob/7ed7dfbb0df9398920562b27df7d3cf782b0fa76/src/Elliptic.jl#L63 It would be better for the code to error on a `BigFloat` value than to silently convert to `Float64`>

ArrayFire looks really cool! Exactly what I need I think... Sent from my iPhone > On 26 Apr 2016, at 18:44, Simon [email protected] wrote: > > I have to correct...

Same as https://github.com/JuliaArrays/BlockArrays.jl/issues/120 would love a PR fixing this

> What does this code serve for? This converts, for example, `view(A,Block(1), Block(2))` to `view(A,Block(1,2))`. Note if there is only one block and its a `AbstractBlockVector` then the line above...

Not yet but the current implementation could be modified to take a vector of bandwidths. This sort of thing does come up a lot

No I don’t think there are any performance regressions since it doesn’t really use the fact that all the bandwidths are the same. and if there was anywhere that made...

Yes I haven't made sure `Transpose{T,