On 2020-08-24 06:46, Lutz Gehlen wrote:
Hi David,
thank you for your advice.
YW. :-)
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 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".
- 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
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.
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.
The hardest part is planning for the unknown. What name do I use when I
create my FBP implementation? These names:
Math::Matrix::Banded::OO
Math::Matrix::Square::Banded::OO
Math::Matrix::Square::Symmetric::Banded::OO
would leave *::FBP for me, *::Structured for the other guy, and
*::Quantum for the future.
You can chase your tail forever when it comes to these kinds of questions...
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.
David
p.s. I should mention the Polar Bear book [1].
[1]
https://www.oreilly.com/library/view/information-architecture-4th/9781491913529/
