>>>>> 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