search

JuliaArrays / BlockDiagonals.jl

Functionality for working efficiently with block diagonal matrices.
MIT License
51 stars 11 forks source link

Create a BlockArraysBase package to avoid name conflicts with BlockArrays #29

Open dmbates opened 5 years ago

dmbates commented 5 years ago

See the discussion in https://github.com/dmbates/MixedModels.jl/pull/216

Would you be open to having BlockDiagonals.jl depend on a BlockArraysBase.jl package in which the conflicting generics like nblocks were defined?

oxinabox commented 5 years ago

Seems legit to me

nickrobinson251 commented 5 years ago

Thanks think we decided to have this package not use the BlockArrays.jl machinery (though Blockarrays could have a Diagonal type https://github.com/JuliaArrays/BlockArrays.jl/issues/89)

So it depends on the details

Certainly open to the Idea

nickrobinson251 commented 4 years ago

I think this could make sense, since there are packages using BlockDiagonals.jl and BlockArrays.jl

I had envisioned this package as being for the case where you only want block-diagonal matrices and do not want to depend on BlockArrays.jl. My thought was "if you were depending on BlockArrays.jl anyway, then why not use the "Diagonal BlockArray" type provided there?", but evidently there's some reason to use both packages 😄 And anyway a standard interface to enable switching between "block array" packages would be nice.

What does @dlfivefifty think of putting generic core API of BlockArrays.jl into a "BlockArraysBase.jl" package?

I guess this would include blocksize, blocksizes, nblocks, and AbstractBlockArray, possibly also setblock!, getblock and maybe AbstractBlockSizes and Block?

dlfivefifty commented 4 years ago

As it happens I'm completely redesigning BlockArrays.jl:

https://github.com/JuliaArrays/BlockArrays.jl/pull/95

The idea is to include all block information in the axes, so BlockSizes is completely gone. I also renamed the functionality (with some incompatibility with previous termonlogy).

This makes a BlockArraysBase.jl package a bit simpler. It would contain:

  1. Block, BlockIndex, BlockIndexRange, and BlockRange
  2. blockaxes, blocksize, findblock, and findblockindex
  3. AbstractBlockArray. This is actually optional as there is now a better defined "block interface".
  4. BlockedUnitRange for the implementation of a blocked axes

I'm not sure about setblock! and getblock: I want to eventually remove them completely in favour of A[Block(5)] and A[Block(3)] .= .....

nickrobinson251 commented 4 years ago

Great timinng! Let's come back to this once that PR is in?

dlfivefifty commented 4 years ago

It would be fantastic if you have time to do a code review of that PR. The tests pass already, I'm just getting the doc tests to pass and in theory it would be ready to merge.

dkarrasch commented 4 years ago

Sorry for my ignorance, but what exactly is the difference between the "DiagonalBlockArray" and BlockDiagonal? I thought that the initial stimulus for this package was that BlockArrays.jl had some "undesirable" overhead in the structured/sparse block case?

EDIT: I must have missed that there are currently no linalg-methods in BlockArrays.jl, so the difference is that this package here provides multiplication methods for BlockMatrices.