>>>>> Avraham Adler
>>>>> on Wed, 2 Jun 2021 15:28:25 -0400 writes:
> Exactly. Is square is just brow=ncol, is positive definite can be
> implemented as a check that all eigenvalues > 0, which can be done with
> base, and is.symmetric can be simply brute forced in a loop comparing i,j
> with j,i.
> The fewer dependencies a package has, the more robust it is. It’s a fine
> balance between not reinventing the wheel and ceding too much stability to
> other packages.
> Thanks,
> Avi
Indeed. Further,
- isSymmetric() has been part of base for a long time
so the definition of an alternative in matrixcalc had been @_*#^$%
It's also supported by methods in the Matrix package
e.g. for sparse matrices etc so definitely something you
"should" use instead.
- is.square() is trivial and I think an explicit check such as
{ d <- dim(x); d[1] == d[2] }
is often more sensical, notably as in many of your functions
you'd need either nrow(.) or ncol(.) of your matrix anyway.
- A remark on Positive Definiteness (or also, often what you really want,
"Positive Semi-definitness", allowing 0 eigen values):
The Matrix package has an (S4) class "dpoMatrix"
of dense positive-definite (actually 'positive semi-definite') matrices.
In its validation method (yes, formal classes have validation!), we
use a cheap test instead of an expensive test with eigenvalues
(which is "too expensive": there are faster ones at least in theory,
e.g., trying an LDL' Cholesky decomposition and returning as soon as
a non-positive / negative entry in D would appear).
The really cheap "pre-test" you may want to use before or instead
of doing one of the more expensive ones is simply checking the diagonal:
if(any(diag(<matrix>)) < 0) "not positive-semidefinite"
if(any(diag(<matrix>)) <= 0) "not positive-definite"
Martin Maechler
(Maintainer of 'Matrix').
> On Wed, Jun 2, 2021 at 3:15 PM John Harrold <john.m.harr...@gmail.com>
> wrote:
>> To add another option. In the past when this has happened to me I've
found
>> other packages that provide similar functionality.
>>
>> I'm assuming that is.square just checks the number of columns == number
of
>> rows? And the others can probably be implemented pretty easily.
>>
>> On Wed, Jun 2, 2021 at 10:41 AM Ben Staton <stato...@gmail.com> wrote:
>>
>> > My package uses the MIT license, so would that not meet the
compatibility
>> > requirements?
>> >
>> > I will attempt to reach out to the package author - thanks for your
help!
>> >
>> > On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker <bbol...@gmail.com> wrote:
>> >
>> > > That all sounds exactly right.
>> > > GPL >= 2 allows you to use the material without asking permission
as
>> > > long as your package is compatibly licensed (e.g. also GPL).
>> > > Under normal circumstances it would be polite to ask permission,
but
>> > > if the reason for doing this is that the maintainer is unreachable in
>> > > the first place ...
>> > >
>> > > If you want to try a little harder, it seems quite possible that
you
>> > > can reach the matrixcalc maintainer at the (personal) e-mail address
>> > > shown in this page:
>> > >
>> > >
>> >
>>
https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042
>> > >
>> > > (Possibly an identity confusion, but I rate that as unlikely based
>> on
>> > > other facebook snooping)
>> > >
>> > > I don't think a short, polite e-mail request would be out of
bounds,
>> > > they can always ignore it or tell you to go away.
>> > >
>> > > cheers
>> > > Ben Bolker
>> > >
>> > > On 6/2/21 1:15 PM, Ben Staton wrote:
>> > > > Hello,
>> > > >
>> > > > Thank you for your detailed list of solutions.
>> > > >
>> > > > I was initially tempted to go with option 1 (move matrixcalc to
>> > suggests
>> > > > and check for its existence before using functions that rely on
it),
>> > but
>> > > as
>> > > > mentioned, this is not a long term fix.
>> > > >
>> > > > I unfortunately can't take on the responsibilities of option 2
>> > (becoming
>> > > > the package maintainer) -- there is much that this package does
that
>> I
>> > do
>> > > > not understand, and do not wish to feign authority!
>> > > >
>> > > > I plan to take option 3 (copy the needed functions into my
package).
>> > > There
>> > > > are only three functions I need from matrixcalc, and all three are
>> > fairly
>> > > > simple (is.square.matrix
>> > > > <https://rdrr.io/cran/matrixcalc/src/R/is.square.matrix.R>,
>> > > > is.symmetric.matrix
>> > > > <https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and
>> > > > is.positive.definite
>> > > > <https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>) and
>> > > there
>> > > > is only one function in postpack that needs them. I plan to define
>> them
>> > > > within the postpack function. matrixcalc is licensed under GPL >= 2
>> and
>> > > > based on my scan of the license text, this is allowed. Is that
>> correct?
>> > > >
>> > > > Regarding option 4 (contacting the matrixcalc maintainer), the
>> original
>> > > > email from CRAN mentioned that they have attempted to contact the
>> > package
>> > > > author with no response.
>> > > >
>> > > > Thank you!
>> > > >
>> > > > On Wed, Jun 2, 2021 at 9:52 AM J C Nash <profjcn...@gmail.com>
>> wrote:
>> > > >
>> > > >> I just downloaded the source matrixcalc package to see what it
>> > > contained.
>> > > >> The functions
>> > > >> I looked at seem fairly straightforward and the OP could likely
>> > develop
>> > > >> equivalent features
>> > > >> in his own code, possibly avoiding a function call. Avoiding the
>> > > function
>> > > >> call means NAMESPACE etc. are not involved, so fewer places for
>> > getting
>> > > >> into
>> > > >> trouble, assuming the inline code works properly.
>> > > >>
>> > > >> JN
>> > > >>
>> > > >>
>> > > >> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
>> > > >>> On 02/06/2021 12:13 p.m., Ben Staton wrote:
>> > > >>>> Hello,
>> > > >>>>
>> > > >>>> I received an email notice from CRAN indicating that my R
package
>> > > >>>> ('postpack') will be archived soon if I do not take any action
>> and I
>> > > >> want
>> > > >>>> to avoid that outcome. The issue is not caused by my package,
but
>> > > >> instead a
>> > > >>>> package that my package depends on:
>> > > >>>>
>> > > >>>> "... package 'matrixcalc' is now scheduled for archival on
>> > 2021-06-09,
>> > > >>>> and archiving this will necessitate also archiving its strong
>> > reverse
>> > > >>>> dependencies."
>> > > >>>>
>> > > >>>> Evidently, xyz has been returning errors on new R builds
prompting
>> > > CRAN
>> > > >> to
>> > > >>>> list it as a package to be archived. My package, 'postpack' has
>> > > >>>> 'matrixcalc' listed in the Imports field, which I assume is why
I
>> > > >> received
>> > > >>>> this email.
>> > > >>>>
>> > > >>>> I want to keep 'postpack' active and don't want it to be
>> archived. I
>> > > >> still
>> > > >>>> need package 'matrixcalc' for my package, but not for most
>> > functions.
>> > > >> Could
>> > > >>>> I simply move package 'matrixcalc' to the Suggests list and
submit
>> > the
>> > > >> new
>> > > >>>> version to CRAN to remove the "Strong Reverse Dependency" issue
>> that
>> > > >>>> triggered this email to avoid CRAN from archiving my package?
>> > > >>>
>> > > >>> That's part of one solution, but not the best solution.
>> > > >>>
>> > > >>> If you move it to Suggests, you should make sure that your
package
>> > > >> checks for it before every use, and falls back to
>> > > >>> some other calculation if it is not present. Be aware that once
it
>> > is
>> > > >> archived, almost none of your users will have it
>> > > >>> available, so this is kind of like dropping the functions that it
>> > > >> supports.
>> > > >>>
>> > > >>> Another solution which would be great for the community might be
>> for
>> > > you
>> > > >> to offer to take over as maintainer of
>> > > >>> matrixcalc. Then you'd fix whatever problems it has, and you
>> > wouldn't
>> > > >> need to worry about it. I haven't looked at the
>> > > >>> issues so I don't know if this is feasible.
>> > > >>>
>> > > >>> A third choice would be for you to copy the functions you need
from
>> > > >> matrixcalc into your own package so you can drop the
>> > > >>> dependency. This is generally legal under the licenses that CRAN
>> > > >> accepts, but you should check anyway.
>> > > >>>
>> > > >>> A fourth choice would be for you to contact the matrixcalc
>> > maintainer,
>> > > >> and help them to fix the issues so that
>> > > >>> matrixcalc doesn't get archived. They may or may not be willing
to
>> > > work
>> > > >> with you.
>> > > >>>
>> > > >>> I'd say my third choice is the best choice in the short term, and
>> 2nd
>> > > or
>> > > >> 4th would be good long term solutions.
>> > > >>>
>> > > >>> Duncan Murdoch
>> > > >>>
>> > > >>> ______________________________________________
>> > > >>> R-package-devel@r-project.org mailing list
>> > > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> > > >>
>> > > >
>> > > > [[alternative HTML version deleted]]
>> > > >
>> > > > ______________________________________________
>> > > > R-package-devel@r-project.org mailing list
>> > > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> > > >
>> > >
>> > > ______________________________________________
>> > > R-package-devel@r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> > >
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ______________________________________________
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>>
>>
>> --
>> John
>> :wq
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> --
> Sent from Gmail Mobile
> [[alternative HTML version deleted]]
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
