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