Hi David, thank you for your advice.
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. > > [...] > > > > The third option I came up with is > > Math::Matrix::Banded::Square > > Math::Matrix::Banded::Rectangular > > Math::Matrix::Banded::Symmetric > > > > This is all within the Math::Matrix::Banded namespace and > > reflects the sibling relationship between the three classes. > > What I can see as a disadvantage - apart from long names - is > > that the package would still be called Math-Matrix-Banded, but > > there is no class occupying the top level namespace, which > > might be confusing for users. [...] > > First, I am not a mathematician. > > > Follow the application domain taxonomy names makes the most sense. 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. > 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. > Your third option could work for module names if Square, > Rectangular, and Symmetric are at the same level of the taxonomy. > If they are the only three choices that will ever exist for > banded matrices, then one distribution named Math::Matrix::Banded > makes sense. > > > 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"? Maybe I should use Math::BandedMatrix::Square etc. or Math::MatrixBanded::Square etc. instead. This is what other people seem to have done with Math::MatrixReal, Math::MatrixBool, Math::MatrixSparse, Math::SparseMatrix and others. On the other hand, there is e.g. Math::Matrix::MaybeGSL, which has nothing to do with Math::Matrix. Cheers, Lutz
