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

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

Open
dmbates opened this issue Oct 16, 2019 · 7 comments
Open

Comments

@dmbates
Copy link

dmbates commented Oct 16, 2019

See the discussion in JuliaStats/MixedModels.jl#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
Copy link
Member

Seems legit to me

@nickrobinson251
Copy link
Contributor

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

So it depends on the details

Certainly open to the Idea

@nickrobinson251
Copy link
Contributor

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
Copy link
Member

dlfivefifty commented Dec 17, 2019

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

JuliaArrays/BlockArrays.jl#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
Copy link
Contributor

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

@dlfivefifty
Copy link
Member

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
Copy link
Contributor

dkarrasch commented Dec 17, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants