Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays
> Radford Neal
> on Fri, 9 Sep 2016 10:29:14 -0400 writes:
>> Radford Nea:
>> > So it may make more sense to move towards consistency in the
>> > permissive direction, rather than the restrictive direction.
>>
>> > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things
>> > like matrix(1,2,2)+(1:8).
>>
>> Martin Maechler:
>> That is an interesting idea. Yes, in my view that would
>> definitely also have to allow the latter, by the above argument
>> of not treating the dim/dimnames attributes special. For
>> non-arrays length-1 is not treated much special apart from the
>> fact that length-1 can always be recycled (without warning).
> I think one could argue for allowing matrix(1,1,1)+(1:8) but not
> matrix(1,2,2)+(1:8). Length-1 vectors certainly are special in some
> circumstances, being R's only way of representing a scalar. For
> instance, if (c(T,F)) gives a warning.
well, the if(.) situation is very special and does not weigh
much for me, here.
> This really goes back to what I think may have been a basic mistake in
> the design of S, in deciding that everything is a vector, then halfway
> modifying this with dim attributes, but it's too late to totally undo
> that (though allowing a 0-length dim attribute to explicitly mark a
> length-1 vector as a scalar might help).
(yes; I think there are also other ideas of adding true small
scalars to R... I am not familiar with those, and in any case
that should be a completely different thread and not be
discussed in this one)
>> > And I think there would be some significant problems. In addition to
>> > the 10-20+ packages that Martin expects to break, there could be quite
>> > a bit of user code that would no longer work - scripts for analysing
>> > data sets that used to work, but now don't with the latest version.
>>
>> That's not true (at least for the cases above): They would give
>> a strong warning
> But isn't the intent to make it an error later? So I assume we're
> debating making it an error, not just a warning.
Yes, that's correct.
But if we have a longish deprecation period (i.e. where there's
only a warning) all important code should have been adapted
before it turns to an error
(( unless for those people who are careless enough to "graciously"
use something like suppressWarnings(...) in too many places )).
> (Though I'm
> generally opposed to such warnings anyway, unless they could somehow
> be restricted to come up only for interactive uses, not from deep in a
> program the user didn't write, making them totally mysterious...)
>> *and* the logic and relop versions of this, e.g.,
>> matrix(TRUE,1) | c(TRUE,FALSE) ; matrix(1,1) > 1:2,
>> have always been an error; so nothing would break there.
> Yes, that wouldn't change the behaviour of old code, but if we're
> aiming for consistency, it might make sense to get rid of that error,
> allowing code like sum(a%*%b rather than forcing the programmer to write sum(c(a%*%b)> Of course; that *was* the reason the very special treatment for
arithmetic
>> length-1 arrays had been introduced. It is convenient.
>>
>> However, *some* of the conveniences in S (and hence R) functions
>> have been dangerous {and much more used, hence close to
>> impossible to abolish, e.g., sample(x) when x is numeric of length 1,
> There's a difference between these two. Giving an error when using a
> 1x1 matrix as a scalar may detect some programming bugs, but not
> giving an error doesn't introduce a bug. Whereas sample(2:n) behaving
> differently when n is 2 than when n is greater than 2 is itself a bug,
> that the programmer has to consciously avoid by being aware of the quirk.
> Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays
> > But isn't the intent to make it an error later? So I assume we're > > debating making it an error, not just a warning. > > Yes, that's correct. > But if we have a longish deprecation period (i.e. where there's > only a warning) all important code should have been adapted > before it turns to an error That might be true for continuously-used code. But for old scripts for analysing some dataset that someone decides to run again five years from now, they will be reduced to trying to guess which version of R they ran under originally, or if they now want to use newer features, to doing a binary search for the most recent version of R for which they still work, or of course going through the script trying to find the problem. This wouldn't be a disaster, but I'm not seeing the magnitude of benefit that would justify imposing this burden on users. A language specification shouldn't really be changing all the time for no particular reason. Radford Neal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Announcing the R Documentation Task Force
To clarify, the developers, Duncan Murdoch, Michael Lawrence, and Martin Maechler, who are R Core Developers are participating in the project, but this should not be construed to be an endorsement from the R Core Developers as a whole, and the work of the R Documentation Task Force is not guaranteed to be included in R Core. My apologies to any who may have misinterpreted the intentions of the announcement. Sincerely, Andrew Redd On Fri, Sep 9, 2016 at 8:46 PM Andrew Redd wrote: > cross-posting announcement to R-Announce, R-devel and R-package-devel. > > The R Consortium recently announced > ( > https://www.r-consortium.org/news/blogs/2016/08/r-consortium-funds-three-projects-july > ) > support of the R Documentation Task Force. The task force aims to > design and implement the next generation documentation system for R. We > aim to take the best from the many attempts to improve documentation and > unify them into a system that will be more standard, flexible and > powerful. We have the support and participation of R Core Developers. > The full proposal is available on the announcement website given above. > > If you have expertise in documentation systems or documentation of > objects or interest in building a documentation system we invite you to > participate. We will be considering documentation in all common forms > such as function and class documentation, but also areas such as data > frames, non-standard objects, packages, and how vignettes fit into the > documentation framework. If you have opinions or concerns that you > would like to make sure are addressed please join. > > To join send an email to Andrew dot Redd at hsc dot utah dot edu, > expressing your interests, skills or expertise as it relates to R > documentation. Also email if you have ideas or concerns but do not wish > to play and active role. > > Thank you, > Andrew Redd > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays
On Mon, Sep 12, 2016 at 9:51 AM, Radford Neal wrote: > > > But isn't the intent to make it an error later? So I assume we're > > > debating making it an error, not just a warning. > > > > Yes, that's correct. > > But if we have a longish deprecation period (i.e. where there's > > only a warning) all important code should have been adapted > > before it turns to an error > > That might be true for continuously-used code. But for old scripts > for analysing some dataset that someone decides to run again five > years from now, they will be reduced to trying to guess which version > of R they ran under originally, In the general case this is true of any packages they use anyway, though. And if you go back far enough old package versions can't even be installed for current versions of R. Results are always contingent on the software, including versions, used to generate them imho. There are ways to try to address this, but they can be painful and generally require extra work the author of any 5 year old script you have in your hands now likely didn't do. > or if they now want to use newer > features, to doing a binary search for the most recent version of R > for which they still work, or of course going through the script > trying to find the problem. > Now you're talking not about running a script, though, but of maintaining and developing it. I know from personal experience how painful developing on top of legacy code can be, but nonetheless sometimes It needs to be maintained and updated. If you really want absolute safety, that is (more or less) possible, but it means staying in an old version of R with old package versions. I don't think the expectation of being guaranteed to be able to use new features and unmodified legacy code at the same time is reasonable. It's great what that does happen, but it's a bonus imho, not a requirement. Best, ~G > > This wouldn't be a disaster, but I'm not seeing the magnitude of > benefit that would justify imposing this burden on users. A language > specification shouldn't really be changing all the time for no > particular reason. > >Radford Neal > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker, PhD Associate Scientist (Bioinformatics) Genentech Research [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays
Hi,
On 09/12/2016 08:21 AM, Martin Maechler wrote:
Radford Neal
on Fri, 9 Sep 2016 10:29:14 -0400 writes:
>> Radford Nea:
>> > So it may make more sense to move towards consistency in the
>> > permissive direction, rather than the restrictive direction.
>>
>> > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things
>> > like matrix(1,2,2)+(1:8).
>>
>> Martin Maechler:
>> That is an interesting idea. Yes, in my view that would
>> definitely also have to allow the latter, by the above argument
>> of not treating the dim/dimnames attributes special. For
>> non-arrays length-1 is not treated much special apart from the
>> fact that length-1 can always be recycled (without warning).
> I think one could argue for allowing matrix(1,1,1)+(1:8) but not
> matrix(1,2,2)+(1:8). Length-1 vectors certainly are special in some
> circumstances, being R's only way of representing a scalar. For
> instance, if (c(T,F)) gives a warning.
well, the if(.) situation is very special and does not weigh
much for me, here.
> This really goes back to what I think may have been a basic mistake in
> the design of S, in deciding that everything is a vector, then halfway
> modifying this with dim attributes, but it's too late to totally undo
> that (though allowing a 0-length dim attribute to explicitly mark a
> length-1 vector as a scalar might help).
(yes; I think there are also other ideas of adding true small
scalars to R... I am not familiar with those, and in any case
that should be a completely different thread and not be
discussed in this one)
>> > And I think there would be some significant problems. In addition to
>> > the 10-20+ packages that Martin expects to break, there could be quite
>> > a bit of user code that would no longer work - scripts for analysing
>> > data sets that used to work, but now don't with the latest version.
>>
>> That's not true (at least for the cases above): They would give
>> a strong warning
> But isn't the intent to make it an error later? So I assume we're
> debating making it an error, not just a warning.
Yes, that's correct.
But if we have a longish deprecation period (i.e. where there's
only a warning) all important code should have been adapted
before it turns to an error
(( unless for those people who are careless enough to "graciously"
use something like suppressWarnings(...) in too many places )).
Any reason for not using the formal deprecation mechanism (i.e.
.Deprecated()) for this? The advantage being that 'R CMD check'
reports deprecation warnings and not ordinary warnings, IIRC. It
won't help (and won't hurt either) in the case of packages using
suppressWarnings(...) but maybe suppressWarnings() shouldn't suppress
deprecation warnings, at least be default.
Cheers,
H.
> (Though I'm
> generally opposed to such warnings anyway, unless they could somehow
> be restricted to come up only for interactive uses, not from deep in a
> program the user didn't write, making them totally mysterious...)
>> *and* the logic and relop versions of this, e.g.,
>> matrix(TRUE,1) | c(TRUE,FALSE) ; matrix(1,1) > 1:2,
>> have always been an error; so nothing would break there.
> Yes, that wouldn't change the behaviour of old code, but if we're
> aiming for consistency, it might make sense to get rid of that error,
> allowing code like sum(a%*%b rather than forcing the programmer to write sum(c(a%*%b)> Of course; that *was* the reason the very special treatment for
arithmetic
>> length-1 arrays had been introduced. It is convenient.
>>
>> However, *some* of the conveniences in S (and hence R) functions
>> have been dangerous {and much more used, hence close to
>> impossible to abolish, e.g., sample(x) when x is numeric of length 1,
> There's a difference between these two. Giving an error when using a
> 1x1 matrix as a scalar may detect some programming bugs, but not
> giving an error doesn't introduce a bug. Whereas sample(2:n) behaving
> differently when n is 2 than when n is greater than 2 is itself a bug,
> that the programmer has to consciously avoid by being aware of the quirk.
> Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
