Re: [Rd] survival changes
> In the next version of the survival package I intend to make a non-upwardly compatable > change to the survfit object. With over 600 dependent packages this is not something to > take lightly, and I am currently undecided about the best way to go about it. I'm looking > for advice. > > The change: 20+ years ago I had decided not to include the initial x=0,y=1 data point in > the survfit object itself. New Package -> Bad idea. Copying Python -> The worst idea... Version element -> Not sure I understand how that works, but probably a bad idea. If all you want to do, is add an initial data point, that shouldn't be an issue. However, I'm assuming that you want to make other more significant changes to your object. So, at face value, a new object class would be the best option, so number (2) from your list of options. Note there is another possibility. With a little bit of tricky-ness, you can check if your constructor is called by a function inside a package. In which case, you can check the publication date of that package (if published after your package), and then then respond accordingly. Then you can ask the maintainers of the other packages to update their packages, but at their own time. Abs [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [EXTERNAL] Re: survival changes
Would this not be the case *for* a new package? FWIW I would much prefer packages maintainers who make significant changes also change the name of the package (e.g. to survival2). That way disturbance is minimized and the package’s developers can add features and refactor their code much faster. On Sun, 2 Jun 2019 at 10:03 am, Therneau, Terry M., Ph.D. via R-devel < r-devel@r-project.org> wrote: > > > On 6/1/19 1:32 PM, Marc Schwartz wrote: > > > >> On Jun 1, 2019, at 12:59 PM, Peter Langfelder < > peter.langfel...@gmail.com> wrote: > >> > >> On Sat, Jun 1, 2019 at 3:22 AM Therneau, Terry M., Ph.D. via R-devel > >> wrote: > >>> In the next version of the survival package I intend to make a > non-upwardly compatable > >>> change to the survfit object. With over 600 dependent packages this > is not something to > >>> take lightly, and I am currently undecided about the best way to go > about it. I'm looking > >>> for advice. > >>> > >>> The change: 20+ years ago I had decided not to include the initial > x=0,y=1 data point in > >>> the survfit object itself. It was not formally an estimand and the > plot/points/lines etc > >>> routines could add this on themselves. That turns out to have been a > mistake, and has led > >>> to a steady proliferation of extra bits as I realized that the time > axis doesn't always > >>> start at 0, and later (with multi state) that y does not always start > at 1 (though the > >>> states sum to 1), and later the the error doesn't always start at 0, > and another > >>> realization with cumulative hazard, and ... > >>> The new survfit method for multi-state coxph models was going to add > yet another special > >>> case. Basically every component is turning into a duplicate of "row > 1" vs "all the > >>> others". (And inconsistently named.) > >>> > >>> Three possible solutions > >>> 1. Current working draft of survival_3.0.3: Add a 'version' element > to the survfit object > >>> and a 'survfit2.3' function that converts old to new. All my > downstream functions (print, > >>> plot,...) start with an "if (old) update to new" line. This has > allowed me to stage > >>> updates to the functions that create survfit objects -- I expect it to > happen slowly. > >>> There will also be a survfit3.2 function to go backwards. Both the > forward and backwards > >>> functions leave objects alone if they are currently in the desired > format. > >>> > >>> 2. Make a new class "survfit3" and the necessary 'as' functions. The > package would contain > >>> plot.survfit and plot.survfit3 methods, the former a two line "convert > and call the > >>> second" function. > >>> > >>> 3. Something I haven't thought of. > >> A more "clean break" solution would be to start a whole new package > >> (call it survival2) that would make these changes, and deprecate the > >> current survival. You could add warnings about deprecation and urging > >> users to switch in existing survival functions. You could continue > >> bugfixes for survival but only add new features to survival2. The new > >> survival2 and the current survival could live side by side on CRAN for > >> quite some time, giving maintainers of dependent packages (and just > >> plain users) enough time to switch. This could allow you to > >> change/clean up other parts of the package that you could perhaps also > >> use a rethink/rewrite, without too much concern for backward > >> compatibility. > >> > >> Peter > > > > Hi, > > > > I would be cautious in going in that direction, bearing in mind that > survival is a Recommended package, therefore included in the default R > distribution from the R Foundation and other parties. To have two versions > can/will result in substantial confusion, and I would argue against that > approach. > > > > There is language in the CRAN submission policy that covers API changes, > which strictly speaking, may or may not be the case here, depending upon > which direction Terry elects to go: > > > > "If an update will change the package’s API and hence affect packages > depending on it, it is expected that you will contact the maintainers of > affected packages and suggest changes, and give them time (at least 2 > weeks, ideally more) to prepare updates before submitting your updated > package. Do mention in the submission email which packages are affected and > that their maintainers have been informed. In order to derive the reverse > dependencies of a package including the addresses of maintainers who have > to be notified upon changes, the function > reverse_dependencies_with_maintainers is available from the developer > website." > > > > > > Given the potential extent and impact of the changes being considered, > it would seem reasonable to: > > > > 1. Post a note to R-Devel (possibly R-Help to cover a larger useR base) > regarding whatever changes are finalized and formally announce them. The > changes are likely to affect end useRs as well as package maintainers. > > > > 2. Send communications directly via
Re: [Rd] [EXTERNAL] Re: survival changes
On 6/1/19 1:32 PM, Marc Schwartz wrote: On Jun 1, 2019, at 12:59 PM, Peter Langfelder wrote: On Sat, Jun 1, 2019 at 3:22 AM Therneau, Terry M., Ph.D. via R-devel wrote: In the next version of the survival package I intend to make a non-upwardly compatable change to the survfit object. With over 600 dependent packages this is not something to take lightly, and I am currently undecided about the best way to go about it. I'm looking for advice. The change: 20+ years ago I had decided not to include the initial x=0,y=1 data point in the survfit object itself. It was not formally an estimand and the plot/points/lines etc routines could add this on themselves. That turns out to have been a mistake, and has led to a steady proliferation of extra bits as I realized that the time axis doesn't always start at 0, and later (with multi state) that y does not always start at 1 (though the states sum to 1), and later the the error doesn't always start at 0, and another realization with cumulative hazard, and ... The new survfit method for multi-state coxph models was going to add yet another special case. Basically every component is turning into a duplicate of "row 1" vs "all the others". (And inconsistently named.) Three possible solutions 1. Current working draft of survival_3.0.3: Add a 'version' element to the survfit object and a 'survfit2.3' function that converts old to new. All my downstream functions (print, plot,...) start with an "if (old) update to new" line. This has allowed me to stage updates to the functions that create survfit objects -- I expect it to happen slowly. There will also be a survfit3.2 function to go backwards. Both the forward and backwards functions leave objects alone if they are currently in the desired format. 2. Make a new class "survfit3" and the necessary 'as' functions. The package would contain plot.survfit and plot.survfit3 methods, the former a two line "convert and call the second" function. 3. Something I haven't thought of. A more "clean break" solution would be to start a whole new package (call it survival2) that would make these changes, and deprecate the current survival. You could add warnings about deprecation and urging users to switch in existing survival functions. You could continue bugfixes for survival but only add new features to survival2. The new survival2 and the current survival could live side by side on CRAN for quite some time, giving maintainers of dependent packages (and just plain users) enough time to switch. This could allow you to change/clean up other parts of the package that you could perhaps also use a rethink/rewrite, without too much concern for backward compatibility. Peter Hi, I would be cautious in going in that direction, bearing in mind that survival is a Recommended package, therefore included in the default R distribution from the R Foundation and other parties. To have two versions can/will result in substantial confusion, and I would argue against that approach. There is language in the CRAN submission policy that covers API changes, which strictly speaking, may or may not be the case here, depending upon which direction Terry elects to go: "If an update will change the package’s API and hence affect packages depending on it, it is expected that you will contact the maintainers of affected packages and suggest changes, and give them time (at least 2 weeks, ideally more) to prepare updates before submitting your updated package. Do mention in the submission email which packages are affected and that their maintainers have been informed. In order to derive the reverse dependencies of a package including the addresses of maintainers who have to be notified upon changes, the function reverse_dependencies_with_maintainers is available from the developer website." Given the potential extent and impact of the changes being considered, it would seem reasonable to: 1. Post a note to R-Devel (possibly R-Help to cover a larger useR base) regarding whatever changes are finalized and formally announce them. The changes are likely to affect end useRs as well as package maintainers. 2. Send communications directly via e-mail to the relevant package maintainers that have dependencies on survival. 3. Consider a longer deprecation time frame for relevant functions, to raise awareness and allow for changes to be made by package maintainers and useRs as may be apropos. Perhaps post reminders to R-Help at relevant time points in advance as you approach the formal deprecation and release of the updated package. Terry, if you have not used it yet and/or are not aware of it, take a look at ?Deprecated in base: https://stat.ethz.ch/R-manual/R-devel/library/base/html/Deprecated.html which is helpful in setting up a deprecation process. If you Google "deprecating functions in R", there are numerous examples/flows of use and the associated processes, since the help page does not
[Rd] Possible bug in formatC
I do not know if this is a bug or a case of improper documentation. The documentation for formatC() implies that the difference between the options format="f" and format="g" is that with "g", scientific format is sometimes used. There is another difference between them that is not mentioned in the documentation. drop0trailing=FALSE is ignored when format is set to "g" unless flag contains "#" (this is the documented behavior for format="fg"). For instance, the first line below return " 2.5", whereas the second returns the expected "2.50". formatC(2.50, format="g", digits=3, drop0trailing=F) formatC(2.50, format="g", digits=3, drop0trailing=F, flag="#") -- sessionInfo(): R version 3.5.3 (2019-03-11) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows >= 8 x64 (build 9200) Matrix products: default locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.5.3 tools_3.5.3 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Patch suggestion for stats:::summary.stl
There appears to be a single "\n" missing from the body of stats:::summary.stl,
causing the "Time.series components" and "IQR" sections to butt up against each
other. The fix should be to simply switch
cat(" IQR:\n")
for
cat("\n IQR:\n")
While looking at this function I wondered: Has it been considered to include a
printout of explained variance?
For example, following the IQR pattern:
cat("\n Variance:\n")
exv <- apply(cbind(STL = object$time.series, data = object$time.series %*%
rep(1, 3)), 2L, var)
print(rbind(format(exv, digits = max(2L, digits - 3L)),
` %` = format(round(100 * exv/exv["data"], 1))), quote = FALSE)
—Aksel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] survival changes
> On Jun 1, 2019, at 12:59 PM, Peter Langfelder > wrote: > > On Sat, Jun 1, 2019 at 3:22 AM Therneau, Terry M., Ph.D. via R-devel > wrote: >> >> In the next version of the survival package I intend to make a non-upwardly >> compatable >> change to the survfit object. With over 600 dependent packages this is not >> something to >> take lightly, and I am currently undecided about the best way to go about >> it. I'm looking >> for advice. >> >> The change: 20+ years ago I had decided not to include the initial x=0,y=1 >> data point in >> the survfit object itself. It was not formally an estimand and the >> plot/points/lines etc >> routines could add this on themselves. That turns out to have been a >> mistake, and has led >> to a steady proliferation of extra bits as I realized that the time axis >> doesn't always >> start at 0, and later (with multi state) that y does not always start at 1 >> (though the >> states sum to 1), and later the the error doesn't always start at 0, and >> another >> realization with cumulative hazard, and ... >> The new survfit method for multi-state coxph models was going to add yet >> another special >> case. Basically every component is turning into a duplicate of "row 1" vs >> "all the >> others". (And inconsistently named.) >> >> Three possible solutions >> 1. Current working draft of survival_3.0.3: Add a 'version' element to the >> survfit object >> and a 'survfit2.3' function that converts old to new. All my downstream >> functions (print, >> plot,...) start with an "if (old) update to new" line. This has allowed me >> to stage >> updates to the functions that create survfit objects -- I expect it to >> happen slowly. >> There will also be a survfit3.2 function to go backwards. Both the forward >> and backwards >> functions leave objects alone if they are currently in the desired format. >> >> 2. Make a new class "survfit3" and the necessary 'as' functions. The package >> would contain >> plot.survfit and plot.survfit3 methods, the former a two line "convert and >> call the >> second" function. >> >> 3. Something I haven't thought of. > > A more "clean break" solution would be to start a whole new package > (call it survival2) that would make these changes, and deprecate the > current survival. You could add warnings about deprecation and urging > users to switch in existing survival functions. You could continue > bugfixes for survival but only add new features to survival2. The new > survival2 and the current survival could live side by side on CRAN for > quite some time, giving maintainers of dependent packages (and just > plain users) enough time to switch. This could allow you to > change/clean up other parts of the package that you could perhaps also > use a rethink/rewrite, without too much concern for backward > compatibility. > > Peter Hi, I would be cautious in going in that direction, bearing in mind that survival is a Recommended package, therefore included in the default R distribution from the R Foundation and other parties. To have two versions can/will result in substantial confusion, and I would argue against that approach. There is language in the CRAN submission policy that covers API changes, which strictly speaking, may or may not be the case here, depending upon which direction Terry elects to go: "If an update will change the package’s API and hence affect packages depending on it, it is expected that you will contact the maintainers of affected packages and suggest changes, and give them time (at least 2 weeks, ideally more) to prepare updates before submitting your updated package. Do mention in the submission email which packages are affected and that their maintainers have been informed. In order to derive the reverse dependencies of a package including the addresses of maintainers who have to be notified upon changes, the function reverse_dependencies_with_maintainers is available from the developer website." Given the potential extent and impact of the changes being considered, it would seem reasonable to: 1. Post a note to R-Devel (possibly R-Help to cover a larger useR base) regarding whatever changes are finalized and formally announce them. The changes are likely to affect end useRs as well as package maintainers. 2. Send communications directly via e-mail to the relevant package maintainers that have dependencies on survival. 3. Consider a longer deprecation time frame for relevant functions, to raise awareness and allow for changes to be made by package maintainers and useRs as may be apropos. Perhaps post reminders to R-Help at relevant time points in advance as you approach the formal deprecation and release of the updated package. Terry, if you have not used it yet and/or are not aware of it, take a look at ?Deprecated in base: https://stat.ethz.ch/R-manual/R-devel/library/base/html/Deprecated.html which is helpful in setting up a deprecation process. If you
Re: [Rd] survival changes
On Sat, Jun 1, 2019 at 3:22 AM Therneau, Terry M., Ph.D. via R-devel wrote: > > In the next version of the survival package I intend to make a non-upwardly > compatable > change to the survfit object. With over 600 dependent packages this is not > something to > take lightly, and I am currently undecided about the best way to go about it. > I'm looking > for advice. > > The change: 20+ years ago I had decided not to include the initial x=0,y=1 > data point in > the survfit object itself. It was not formally an estimand and the > plot/points/lines etc > routines could add this on themselves. That turns out to have been a > mistake, and has led > to a steady proliferation of extra bits as I realized that the time axis > doesn't always > start at 0, and later (with multi state) that y does not always start at 1 > (though the > states sum to 1), and later the the error doesn't always start at 0, and > another > realization with cumulative hazard, and ... > The new survfit method for multi-state coxph models was going to add yet > another special > case. Basically every component is turning into a duplicate of "row 1" vs > "all the > others". (And inconsistently named.) > > Three possible solutions > 1. Current working draft of survival_3.0.3: Add a 'version' element to the > survfit object > and a 'survfit2.3' function that converts old to new. All my downstream > functions (print, > plot,...) start with an "if (old) update to new" line. This has allowed me > to stage > updates to the functions that create survfit objects -- I expect it to happen > slowly. > There will also be a survfit3.2 function to go backwards. Both the forward > and backwards > functions leave objects alone if they are currently in the desired format. > > 2. Make a new class "survfit3" and the necessary 'as' functions. The package > would contain > plot.survfit and plot.survfit3 methods, the former a two line "convert and > call the > second" function. > > 3. Something I haven't thought of. A more "clean break" solution would be to start a whole new package (call it survival2) that would make these changes, and deprecate the current survival. You could add warnings about deprecation and urging users to switch in existing survival functions. You could continue bugfixes for survival but only add new features to survival2. The new survival2 and the current survival could live side by side on CRAN for quite some time, giving maintainers of dependent packages (and just plain users) enough time to switch. This could allow you to change/clean up other parts of the package that you could perhaps also use a rethink/rewrite, without too much concern for backward compatibility. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Converting non-32-bit integers from python to R to use bit64: reticulate
> Juan Telleria Ruiz de Aguirre > on Thu, 30 May 2019 18:46:29 +0200 writes: >Thank you Gabriel for valuable insights on the 64-bit integers topic. >In addition, my statement was wrong, as Python3 seems to have unlimited >(and variable) size integers. If you are interested in using unlimited size integers, you could use the CRAN R package 'gmp' which builds on the GMP = GNU MP = GNU Multi Precision C library. https://cran.r-project.org/package=gmp (and for arbitrary precision "floats", see CRAN pkg 'Rmpfr' built on package gmp, and both the GNU C libraries GMP and MPFR: https://cran.r-project.org/package=Rmpfr ) >Division between Int-32 and Int-64 seems to only happen in Python2. >Best, >Juan >El miércoles, 29 de mayo de 2019, Gabriel Becker >escribió: >> Hi Juan, >> >> Comments inline. >> >> On Wed, May 29, 2019 at 12:48 PM Juan Telleria Ruiz de Aguirre < >> jtelleria.rproj...@gmail.com> wrote: >> >>> Dear R Developers, >>> >>> There is an interesting issue related to "reticulate" R package which >>> discusses how to convert Python's non-32 bit integers to R, which has had >>> quite an exhaustive discussion: >>> >>> https://github.com/rstudio/reticulate/issues/323 >>> >>> Python seems to handle integers differently from R, and is dependant on >>> the >>> system arquitecture: On 32 bit systems uses 32-bit integers, and on 64-bit >>> systems uses 64-bit integers. >>> >>> So my question is: >>> >>> As regards R's C Interface, how costly would it be to convert INTSXP from >>> 32 bits to 64 bits using C, on 64 bits Systems? Do the benefits surpass >>> the >>> costs? And should such development be handled from within R Core / >>> Ordinary >>> Members , or it shall be left to package maintainers? >>> >> >> Well, I am not an R-core member, but I can mention a few things: >> >> 1. This seems like it would make the results of R code non-reproducible >> between 32 and 64bit versions of R; at least some code would give different >> results (at the very least in terms of when integer values overflow to NA, >> which is documented behavior). >> 2. Obviously all integer data would take twice as much memory, memory >> bandwidth, space in caches, etc, even when it doesn't need it. >> 3. Various places treat data /data pointers coming out of INTSXP and >> LGLSXP objects the same within the internal R sources (as currently they're >> both int/int*). Catching and fixing all those wouldn't be impossible, but >> it would take at least some doing. >> >> For me personally 1 seems like a big problem, and 3 makes the conversion >> more work than it might have seemed initially. >> >> As a related side note, as far as I understand what I've heard from R-core >> members directly, the choice to not have multiple types of integers is >> intentional and unlikely to change. >> >> Best, >> ~G >> >> >> >> >>> >>> Thank you! :) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] survival changes
On Sat, Jun 1, 2019 at 5:22 AM Therneau, Terry M., Ph.D. via R-devel wrote: > > In the next version of the survival package I intend to make a non-upwardly > compatable > change to the survfit object. With over 600 dependent packages this is not > something to > take lightly, and I am currently undecided about the best way to go about it. > I'm looking > for advice. > I encountered several issues like this while making a change to xts. I encountered several buggy and inconsistent behaviors while moving attributes from the xts object to the xts object's index attribute. I don't want to "fix" some of these in the next version, because downstream packages may rely on the old behavior. Though it's specific to Python, "API Evolution the Right Way" has many good strategies. https://emptysqua.re/blog/api-evolution-the-right-way/ The "Deleting Features" and "Changing Behavior" sections are most relevant to your situation. > The change: 20+ years ago I had decided not to include the initial x=0,y=1 > data point in > the survfit object itself. It was not formally an estimand and the > plot/points/lines etc > routines could add this on themselves. That turns out to have been a > mistake, and has led > to a steady proliferation of extra bits as I realized that the time axis > doesn't always > start at 0, and later (with multi state) that y does not always start at 1 > (though the > states sum to 1), and later the the error doesn't always start at 0, and > another > realization with cumulative hazard, and ... > The new survfit method for multi-state coxph models was going to add yet > another special > case. Basically every component is turning into a duplicate of "row 1" vs > "all the > others". (And inconsistently named.) > > Three possible solutions > 1. Current working draft of survival_3.0.3: Add a 'version' element to the > survfit object > and a 'survfit2.3' function that converts old to new. All my downstream > functions (print, > plot,...) start with an "if (old) update to new" line. This has allowed me > to stage > updates to the functions that create survfit objects -- I expect it to happen > slowly. > There will also be a survfit3.2 function to go backwards. Both the forward > and backwards > functions leave objects alone if they are currently in the desired format. > This seems reasonable. It would also give you opportunity to warn users if functions that expect a new object receive an old object. That would help them convert any of their functions that rely on the old structure/behavior. You could also add a global option to enable warnings with the default set to FALSE for the first release. Let users know they can set that option to TRUE to identify places where they may need to modify their use cases. > 2. Make a new class "survfit3" and the necessary 'as' functions. The package > would contain > plot.survfit and plot.survfit3 methods, the former a two line "convert and > call the > second" function. > Rather than an entirely new class, I wonder if you could instead make the new class a subclass. I'm not sure whether this has advantages over adding an element, but it's another possibility. > 3. Something I haven't thought of. > I don't have any other ideas, but I would be happy to discuss offline if that would be helpful. > Number 2 has a cleanness about it, but there is a long term nuisance about it > wrt > documentation. Users, not unreasonably, expect the survfit function to > produce a survfit > object, and that is what they look for in the help pages. > > I plan to have 3.0-x on github before userR so that users can begin to play > with it (and > to get feeback before pushing to CRAN), so need to make a decision. > > Terry T. > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2019 | www.rinfinance.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] survival changes
In the next version of the survival package I intend to make a non-upwardly compatable change to the survfit object. With over 600 dependent packages this is not something to take lightly, and I am currently undecided about the best way to go about it. I'm looking for advice. The change: 20+ years ago I had decided not to include the initial x=0,y=1 data point in the survfit object itself. It was not formally an estimand and the plot/points/lines etc routines could add this on themselves. That turns out to have been a mistake, and has led to a steady proliferation of extra bits as I realized that the time axis doesn't always start at 0, and later (with multi state) that y does not always start at 1 (though the states sum to 1), and later the the error doesn't always start at 0, and another realization with cumulative hazard, and ... The new survfit method for multi-state coxph models was going to add yet another special case. Basically every component is turning into a duplicate of "row 1" vs "all the others". (And inconsistently named.) Three possible solutions 1. Current working draft of survival_3.0.3: Add a 'version' element to the survfit object and a 'survfit2.3' function that converts old to new. All my downstream functions (print, plot,...) start with an "if (old) update to new" line. This has allowed me to stage updates to the functions that create survfit objects -- I expect it to happen slowly. There will also be a survfit3.2 function to go backwards. Both the forward and backwards functions leave objects alone if they are currently in the desired format. 2. Make a new class "survfit3" and the necessary 'as' functions. The package would contain plot.survfit and plot.survfit3 methods, the former a two line "convert and call the second" function. 3. Something I haven't thought of. Number 2 has a cleanness about it, but there is a long term nuisance about it wrt documentation. Users, not unreasonably, expect the survfit function to produce a survfit object, and that is what they look for in the help pages. I plan to have 3.0-x on github before userR so that users can begin to play with it (and to get feeback before pushing to CRAN), so need to make a decision. Terry T. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
