Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Namespace Math::Matrix::Banded
2 views
Skip to first unread message
Lutz Gehlen
Aug 23, 2020, 6:00:04 AM8/23/20
to module-...@perl.org
Hi all,
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.
I am planning to use the Math::Matrix::Banded namespace. However, I
require separate namespaces for rectangular (i.e. non-square) and
symmetric systems because they are stored differently and allow a
distinct set of algorithms.
I have considered
Math::Matrix::Banded
Math::Matrix::BandedRectangular
Math::Matrix::BandedSymmetric
What I don't like about this option is that the package name would
be Math-Matrix-Banded, but it would use namespaces outside the top
level namespace.
An obvious alternative would be
Math::Matrix::Banded
Math::Matrix::Banded::Rectangular
Math::Matrix::Banded::Symmetric
What I don't like here is that it suggests that the latter two
classes are subclasses of the first, which is not the case.
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.
Do you have any thoughts on this matter?
Thank you and best wishes,
Lutz
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.
I am planning to use the Math::Matrix::Banded namespace. However, I
require separate namespaces for rectangular (i.e. non-square) and
symmetric systems because they are stored differently and allow a
distinct set of algorithms.
I have considered
Math::Matrix::Banded
Math::Matrix::BandedRectangular
Math::Matrix::BandedSymmetric
What I don't like about this option is that the package name would
be Math-Matrix-Banded, but it would use namespaces outside the top
level namespace.
An obvious alternative would be
Math::Matrix::Banded
Math::Matrix::Banded::Rectangular
Math::Matrix::Banded::Symmetric
What I don't like here is that it suggests that the latter two
classes are subclasses of the first, which is not the case.
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.
Do you have any thoughts on this matter?
Thank you and best wishes,
Lutz
David Christensen
Aug 23, 2020, 9:45:03 AM8/23/20
to module-...@perl.org
Follow the application domain taxonomy names makes the most sense.
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).
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.
David
Lutz Gehlen
Aug 24, 2020, 10:00:03 AM8/24/20
to module-...@perl.org
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:
[...]
>
> 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
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.
> >
[...]
> > (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.
[...]
> > 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.
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).
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.
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
David Christensen
Aug 24, 2020, 8:30:03 PM8/24/20
to module-...@perl.org
On 2020-08-24 06:46, Lutz Gehlen wrote:
> Hi David,
>
> thank you for your advice.
YW. :-)
> 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.
>
> 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
> 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.
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.
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"?
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/
Lutz Gehlen
Aug 25, 2020, 5:15:02 AM8/25/20
to module-...@perl.org
Hi David
On Monday, 24.08.2020 17:17:30 David Christensen wrote:
> On 2020-08-24 06:46, Lutz Gehlen wrote:
[...]
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.
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
On Monday, 24.08.2020 17:17:30 David Christensen wrote:
> On 2020-08-24 06:46, Lutz Gehlen wrote:
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".
> - 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
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.
> 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.
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...
> >> 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.
> p.s. I should mention the Polar Bear book [1].
>
>
> [1]
> https://www.oreilly.com/library/view/information-architecture-4th/
> 9781491913529/
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
Lutz Gehlen
Aug 25, 2020, 5:15:03 AM8/25/20
to module-...@perl.org
Hi Neil,
On Monday, 24.08.2020 10:06:10 Neil Bowers wrote:
[...]
> One thing to be aware of, is that if you’re releasing a
> distribution Math-Matrix-Banded, then your distribution needs to
> include a module Math::Matrix::Banded[*].
Thank you, I wasn't aware of that.
> I like the model where you also have ::Square, ::Rectangular, and
> ::Symmetric — a class for each internal representation.
>
> Not knowing anything about your planned design, could you have
> Math::Matrix::Banded be the public facing interface, with the
> appropriate "back-end" loaded by it? This could either be
> explicit, with the caller telling you what type to use, or more
> DWIMish, by looking at the matrix and deciding which of the three
> back-ends to use, factory method stylee:
>
> use Math::Matrix::Banded;
> my $matrix =
> Math::Matrix::Banded->load_from_file('foobar.matrix'); print
> ref($matrix), "\n";
>
> # Math::Matrix::Banded::Symmetric
[...]
I like this idea a lot. The size of the matrix is immutable and set
at construction time, so whether it's square or not can be detected
automatically. Symmetry will have to be set explicitly since the
elements of the matrix are mutable.
Thanks,
Lutz
On Monday, 24.08.2020 10:06:10 Neil Bowers wrote:
[...]
> One thing to be aware of, is that if you’re releasing a
> distribution Math-Matrix-Banded, then your distribution needs to
> include a module Math::Matrix::Banded[*].
Thank you, I wasn't aware of that.
> I like the model where you also have ::Square, ::Rectangular, and
> ::Symmetric — a class for each internal representation.
>
> Not knowing anything about your planned design, could you have
> Math::Matrix::Banded be the public facing interface, with the
> appropriate "back-end" loaded by it? This could either be
> explicit, with the caller telling you what type to use, or more
> DWIMish, by looking at the matrix and deciding which of the three
> back-ends to use, factory method stylee:
>
> use Math::Matrix::Banded;
> my $matrix =
> Math::Matrix::Banded->load_from_file('foobar.matrix'); print
> ref($matrix), "\n";
>
> # Math::Matrix::Banded::Symmetric
[...]
I like this idea a lot. The size of the matrix is immutable and set
at construction time, so whether it's square or not can be detected
automatically. Symmetry will have to be set explicitly since the
elements of the matrix are mutable.
Thanks,
Lutz
David Christensen
Aug 25, 2020, 4:45:03 PM8/25/20
to module-...@perl.org
"Information architecture (IA) is the structural design of shared
information environments; the art and science of organizing and labeling
websites, intranets, online communities and software to support
usability and find-ability; and an emerging community of practice
focused on bringing principles of design, architecture and information
science to the digital landscape. Typically, it involves a model or
concept of information that is used and applied to activities which
require explicit details of complex information systems. These
activities include library systems and database development."
IA is one of those fields whose applications are all around us, but is
only noticed when done poorly. The above book makes you aware of the
concepts and techniques of IA, and helps you articulate its application
(and misapplication). While the book uses web sites for concrete
examples, IA is widely applicable (including CPAN).
David
0 new messages