Hi David On Monday, 24.08.2020 17:17:30 David Christensen wrote: > On 2020-08-24 06:46, Lutz Gehlen wrote: [...] > > On Sunday, 23.08.2020 06:37:47 David Christensen wrote: > >> On 2020-08-23 02:40, Lutz Gehlen wrote: > > [...] > > > >>> I am working on a set of modules dealing with banded matrices > >>> (aka band matrices or band diagonal matrices). These are a > >>> certain kind of sparse matrices where all entries are known to > >>> be 0 except close to the main diagonal. Obviously, this > >>> condition can be exploited for efficient storage and > >>> algorithms. > >> > >> Follow[ing] the application domain taxonomy names makes the > >> most sense [to me].> > > Hm, that depends on what you consider as the application domain. > > > > From an analytical (in a mathematical sense in contrast to > > > > numerical) point of view, there is a clear hierarchy. There are > > general (rectangular) matrices; square matrices are a subset of > > them, and symmetric matrices are again a subset of square > > matrices. You might argue that I should use the following > > namespaces: Math::Matrix::Banded > > Math::Matrix::Banded::Square > > Math::Matrix::Banded::Square::Symmetric > > I suppose that this is what you mean by following the > > application > > domain taxonomy or am I wrong? > > > > However, from a numerical point of view, the three types are > > treated rather separately. Specifically, for banded matrices, > > the three types are stored in different ways and in many cases, > > you would not apply an algorithm for general square matrices to > > a symmetric one even if you could, because there are more > > efficient/stable/etc algorithms at your disposal. Hence, you > > might rather consider them at the same taxonomic level. This is > > what I have in mind. > > > > One might think of looking at other libraries that implement > > this > > kind of software, but they are typically written in C or Fortran > > and rather tend to very short and cryptic function names like > > sgbtrf instead of hierarchical namespaces. > > I would favor an analytical mathematics taxonomy over a numerical > methods taxonomy or a computer science taxonomy. This should make > it easier for users who work in the field to grok the > distribution.
I see your point, but I am not sure I agree. Users looking for these modules are interested in the computer science and even implementation part because they have a large problem that makes this necessary. From an analytical perspective the size of the matrix does not matter and if the user does not need to care then he/she will rather pick a general purpose matrix distribution. It does not make a lot of sense to take advantage of the banded structure of a 10x10 matrix. However, if it is a 10000x10000 matrix and I know its banded then I am acutely aware of and interested in this property and what it implies from a numerical perspective. > I would add these information architecture considerations; > > - If the term "rectangular matrix" is the general case for all > matrices, I would drop "rectangular" and just use "matrix". Yes, if I go the hierarchical way then this makes a lot of sense. > - If banded is a special case for rectangular matrices, square > matrices, and symmetric matrices, I would apply "banded" as a > suffix: > > > Thus: > > Math::Matrix::Banded > > Math::Matrix::Square::Banded > > Math::Matrix::Square::Symmetric::Banded This goes both ways. Yes, banded is a special case let's say of a square matrix, but square is also a special case of a banded matrix. The choice depends on which property you consider more fundamental or want to highlight more. I consider the bandedness as more fundamental for the reasons discussed above. I expect a potential user of my modules to look specifically for a distribution supporting banded matrices. That does not mean that the shape is not important, but the user will not type "square" into the search field, but "banded". Additionally, I like the idea by Neil Bowers to have a central Math::Matrix::Banded module whose constructor dispatches to the specific classes. I think it makes sense for them to sit in a shared namespace. > That said, each author could also document their implementation; > to allow direct usage and/or optimization by interested users. > > > >> If your implementation is OO and maps 1:1 with the taxonomy, > >> that > >> would be ideal. If not, I might have modules per the taxonomy > >> where it makes sense, and put everything else into > >> sub-directories organized by whatever makes sense for them > >> (such > >> as OO modules, utility functions, whatever). > > > > Not sure I understand the second part of your advice. However, > > my > > implementation is OO and arguably maps with the taxonomy as > > discussed above, so it might not be relevant. > > If your OO design does not map 1:1 with the chosen taxonomy, I was > suggesting a distribution tree similar to the following: > > Math-Matrix-Banded > > |-- lib > | > | |-- Math > | | > | | |-- Matrix > | | | > | | | |-- Banded > | | | | > | | | | |-- OO > | | | | | > | | | | | |-- <OO implementation tree> > | | | | | > | | | | |-- Util.pm > | | | | |-- <other stuff as required> > | | | | > | | | | Banded.pm > | | | | Square > | | | | > | | | | |-- Banded.pm > | | | | |-- Symmetric > | | | | | > | | | | | |-- Banded.pm > | > |-- t > | > | |-- <test scripts> > | > |-- MANIFEST > |-- Makefile.PL > |-- README > > The lib/Math/Matrix/Banded/OO directory would hold your > implementation: > > - The OO sub-directory would contain your OO implementation. > > - The file Util.pm would contain whatever non-OO stuff you need. > > - Other files and directories as needed. > > > The files: > > - lib/Math/Matrix/Banded.pm > > - lib/Math/Matrix/Square/Banded.pm > > - lib/Math/Matrix/Square/Symmetric/Banded.pm > > would provide documentation per the analytical mathematics > taxonomy and provide a translation layer from this taxonomy into > your OO implementation. Yourself, myself, and any other > author(s) would want to collaborate on the translation layer. Thank you for your elaborate explanation! > But, I now see a problem -- the Math::Matrix::Square namespace is > not properly contained within the Math-Matrix-Banded > distribution. Therefore, Math-Matrix-Square-Banded must be its > own distribution. Similarly, Math-Matrix-Square-Symmetric-Banded > must be its own distribution. If there is common stuff that can > be shared, put it into the first and make the latter two > dependent upon the first. Yes, in that case, separate distributions would be required. At the current stage of my implementation there is no shared code because the underlying data structures are specific to each case. There are dependencies, though, e.g. an object of one class producing an object of another. If I release the modules as separate distributions I will need to add inter-dependencies (avoiding circular ones!). Let's see. > The hardest part is planning for the unknown. What name do I use > when I create my FBP implementation? These names: [...] > You can chase your tail forever when it comes to these kinds of > questions... I can certainly see that :-). > >> But if there are other types of banded matrices, if those terms > >> are really at different levels, or if there are other taxonomy > >> issues, perhaps you should release multiple distributions -- > >> one > >> per work product, named per the taxonomy. The idea is that you > >> do not want to block future modules or distributions. > > > > Hm, they are the only three choices I foresee, but people might > > have other ideas. Hence, you have a point. > > > > Thinking about this point, I'm also getting second thoughts on > > using the Math::Matrix namespace to start with. There is a > > Math::Matrix distribution, does this imply that the entire > > Math::Matrix namespace should be considered "reserved"? > > I would consider CPAN user names to be "reserved". I would not > worry about picking a name Math-Matrix-*, so long as it does not > collide with any *.pm or *.pod file in any distribution. Ok, thanks for your advice. > p.s. I should mention the Polar Bear book [1]. > > > [1] > https://www.oreilly.com/library/view/information-architecture-4th/ > 9781491913529/ Thank you for the pointer. I find it hard to grasp from the descriptions on O'Reilly and Amazon what the book actually covers, which does not mean I shouldn't read it (possibly the opposite). Best wishes, Lutz
