Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
Hi Abby,
On 11/15/19 10:19 PM, Abby Spurdle wrote:
And indeed I think you are right on spot and this would mean
that indeed the implicit class
"matrix" should rather become c("matrix", "array").
I've made up my mind (and not been contradicted by my fellow R
corers) to try go there for R 4.0.0 next April.
I'm not enthusiastic about matrices extending arrays.
If a matrix is an array, then shouldn't all vectors in R, be arrays too?
The main distinguishing feature of matrices (and arrays) vs vectors is
that they have a dimension attribute.
x <- as.list(letters[1:8]) # just to show that it generalizes not only
to atomic vectors
is.vector(x) # TRUE
inherits(x, "matrix") # FALSE
dim(x) <- c(2, 4)
is.vector(x) # FALSE
inherits(x, "matrix") # TRUE
inherits(x, "array") # FALSE, but should be TRUE for consistency
dim(x) <- c(2, 2, 2)
is.vector(x) # FALSE
inherits(x, "matrix") # FALSE
inherits(x, "array") # TRUE
A matrix should be really nothing else just an array where
length(dim(x)) == 2L.
IMHO the only special object which has dimension attribute but is not a
special case of arrays is the data.frame.
Denes
#mockup
class (1)
[1] "numeric" "array"
Which is a bad idea.
It contradicts the central principle that R uses "Vectors" rather than "Arrays".
And I feel that matrices are and should be, a special case of vectors.
(With their inheritance from vectors taking precedence over anything else).
If the motivation is to solve the problem of 2D arrays, automatically
being mapped to matrices:
class (array (1, c (2, 2) ) )
[1] "matrix"
Then wouldn't it be better, to treat 2D arrays, as a special case, and
leave matrices as they are?
#mockup
class (array (1, c (2, 2) ) )
[1] "array2d" "matrix" "array"
Then 2D arrays would have access to both matrix and array methods...
Note, I don't want to enter into (another) discussion on the
differences between implicit class and classes defined via a class
attribute.
That's another discussion, which has little to do with my points above.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
arrays and matrices have a numeric dims attribute, vectors don't. If
statements lead to bad code.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Nov 15, 2019 at 1:19 PM Abby Spurdle wrote:
> > > And indeed I think you are right on spot and this would mean
> > > that indeed the implicit class
> > > "matrix" should rather become c("matrix", "array").
> >
> > I've made up my mind (and not been contradicted by my fellow R
> > corers) to try go there for R 4.0.0 next April.
>
> I'm not enthusiastic about matrices extending arrays.
> If a matrix is an array, then shouldn't all vectors in R, be arrays too?
>
> > #mockup
> > class (1)
> [1] "numeric" "array"
>
> Which is a bad idea.
> It contradicts the central principle that R uses "Vectors" rather than
> "Arrays".
> And I feel that matrices are and should be, a special case of vectors.
> (With their inheritance from vectors taking precedence over anything else).
>
> If the motivation is to solve the problem of 2D arrays, automatically
> being mapped to matrices:
>
> > class (array (1, c (2, 2) ) )
> [1] "matrix"
>
> Then wouldn't it be better, to treat 2D arrays, as a special case, and
> leave matrices as they are?
>
> > #mockup
> > class (array (1, c (2, 2) ) )
> [1] "array2d" "matrix" "array"
>
> Then 2D arrays would have access to both matrix and array methods...
>
> Note, I don't want to enter into (another) discussion on the
> differences between implicit class and classes defined via a class
> attribute.
> That's another discussion, which has little to do with my points above.
>
> __
> 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] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
> > And indeed I think you are right on spot and this would mean
> > that indeed the implicit class
> > "matrix" should rather become c("matrix", "array").
>
> I've made up my mind (and not been contradicted by my fellow R
> corers) to try go there for R 4.0.0 next April.
I'm not enthusiastic about matrices extending arrays.
If a matrix is an array, then shouldn't all vectors in R, be arrays too?
> #mockup
> class (1)
[1] "numeric" "array"
Which is a bad idea.
It contradicts the central principle that R uses "Vectors" rather than "Arrays".
And I feel that matrices are and should be, a special case of vectors.
(With their inheritance from vectors taking precedence over anything else).
If the motivation is to solve the problem of 2D arrays, automatically
being mapped to matrices:
> class (array (1, c (2, 2) ) )
[1] "matrix"
Then wouldn't it be better, to treat 2D arrays, as a special case, and
leave matrices as they are?
> #mockup
> class (array (1, c (2, 2) ) )
[1] "array2d" "matrix" "array"
Then 2D arrays would have access to both matrix and array methods...
Note, I don't want to enter into (another) discussion on the
differences between implicit class and classes defined via a class
attribute.
That's another discussion, which has little to do with my points above.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
> Pages, Herve
> on Thu, 14 Nov 2019 19:13:47 + writes:
> On 11/14/19 05:47, Hadley Wickham wrote:
>> On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
>> wrote:
>>>
Gabriel Becker
on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>>>
>>> > I agree that we can be careful and narrow and still see a
>>> > nice improvement in behavior. While Herve's point is valid
>>> > and I understand his frustration, I think staying within
>>> > the matrix vs c(matrix, array) space is the right scope
>>> > for this work in terms of fiddling with inheritance.
>>>
>>> [.]
>>>
>>>
> Also, we seem to have a rule that inherits(x, c) iff c %in%
class(x),
good point, and that's why my usage of inherits(.,.) was not
quite to the point. [OTOH, it was to the point, as indeed from
the ?class / ?inherits docu, S3 method dispatch and inherits
must be consistent ]
> which would break -- unless we change class(x) to return the whole
set of inherited classes, which I sense that we'd rather not do
>>>
>>> []
>>>
Note again that both "matrix" and "array" are special [see ?class] as
being of __implicit class__ and I am considering that this
implicit class behavior for these two should be slightly
changed
And indeed I think you are right on spot and this would mean
that indeed the implicit class
"matrix" should rather become c("matrix", "array").
>>>
>>> I've made up my mind (and not been contradicted by my fellow R
>>> corers) to try go there for R 4.0.0 next April.
>>
>> I can't seem to find the previous thread, so would you mind being a
>> bit more explicit here? Do you mean adding "array" to the implicit
>> class?
> It's late in Europe ;-)
> That's my understanding. I think the plan is to have class(matrix())
> return c("matrix", "array"). No class attributes added to matrix or
> array objects.
> It's all what is needed to have inherits(matrix(), "array") return TRUE
> (instead of FALSE at the moment) and S3 dispatch pick up the foo.array
> method when foo(matrix()) is called and there is no foo.matrix method.
Thank you, Hervé! That's exactly the plan.
>> Or adding it to the explicit class? Or adding it to inherits?
>> i.e. which of the following results are you proposing to change?
>>
>> is_array <- function(x) UseMethod("is_array")
>> is_array.array <- function(x) TRUE
>> is_array.default <- function(x) FALSE
>>
>> x <- matrix()
>> is_array(x)
>> #> [1] FALSE
>> x <- matrix()
>> inherits(x, "array")
>> #> [1] FALSE
>> class(x)
>> #> [1] "matrix"
>>
>> It would be nice to make sure this is consistent with the behaviour of
>> integers, which have an implicit parent class of numeric:
> I agree but I don't know if Martin wants to go that far for R 4.0.
again, correct.
In the mean time, thanks to Tomas Kalibera, my small change has
been tested on all of CRAN and Bioc (Software) packages
R CMD check
but no '--as-cran' nor any environment variable settings such
as ((strongly recommended by me for package developers !))
_R_CHECK_LENGTH_1_CONDITION_=true
_R_CHECK_LENGTH_1_LOGIC2_=verbose
>From the package checks, and my own checks I've started noticing
only today, that indeed, the _R_CHECK_LENGTH_1_CONDITION_=true
environment variable setting
--- stemming more or less directly from an R-devel (mailing list)
proposal by Henrik Bengtsson --
and documented in help("if") since R 3.5.0,
*together* with the proposal of
class() |--> c("matrix", "array")
is triggering many new ERRORs because the bad use ofclass(.) == "..."
which I've blogged about is very often inside if(), i.e.,
if (class(object) == "foobar") # or ` != ` or
Now in "new R-devel", and when object is a matrix,
if ( class(object) == "foobar")
<===>
if (c("matrix","array") == "foobar")
<===>
if (c(FALSE, FALSE))
which is "fine" (i.e, just giving the infamous warning.. which
is often surpressed by testthat or similar wrappers)
unless you set the env.var .. as I think you R-devel readers all
should do :
> Sys.unsetenv("_R_CHECK_LENGTH_1_CONDITION_")
> if(c(FALSE,FALSE)) 1 else 2
[1] 2
Warning message:
In if (c(FALSE, FALSE)) 1 else 2 :
the condition has length > 1 and only the first element will be used
> Sys.setenv("_R_CHECK_LENGTH_1_CONDITION_" = TRUE)
> if(c(FALSE,FALSE)) 1 else 2
Error in if (c(FALSE, FALSE)) 1 else 2 : the condition has length > 1
>
> Hopefully that's the longer term plan though (maybe for R 4.1?).
I'm not making promises here.
Maybe if we could agree to make the
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On 11/14/19 05:47, Hadley Wickham wrote:
> On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
> wrote:
>>
>>> Gabriel Becker
>>> on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>>
>> > I agree that we can be careful and narrow and still see a
>> > nice improvement in behavior. While Herve's point is valid
>> > and I understand his frustration, I think staying within
>> > the matrix vs c(matrix, array) space is the right scope
>> > for this work in terms of fiddling with inheritance.
>>
>> [.]
>>
>>
Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
>>>
>>> good point, and that's why my usage of inherits(.,.) was not
>>> quite to the point. [OTOH, it was to the point, as indeed from
>>>the ?class / ?inherits docu, S3 method dispatch and inherits
>>>must be consistent ]
>>>
>>> > which would break -- unless we change class(x) to return the whole
>>> set of inherited classes, which I sense that we'd rather not do
>>
>>[]
>>
>>> Note again that both "matrix" and "array" are special [see ?class] as
>>> being of __implicit class__ and I am considering that this
>>> implicit class behavior for these two should be slightly
>>> changed
>>>
>>> And indeed I think you are right on spot and this would mean
>>> that indeed the implicit class
>>> "matrix" should rather become c("matrix", "array").
>>
>> I've made up my mind (and not been contradicted by my fellow R
>> corers) to try go there for R 4.0.0 next April.
>
> I can't seem to find the previous thread, so would you mind being a
> bit more explicit here? Do you mean adding "array" to the implicit
> class?
It's late in Europe ;-)
That's my understanding. I think the plan is to have class(matrix())
return c("matrix", "array"). No class attributes added to matrix or
array objects.
It's all what is needed to have inherits(matrix(), "array") return TRUE
(instead of FALSE at the moment) and S3 dispatch pick up the foo.array
method when foo(matrix()) is called and there is no foo.matrix method.
> Or adding it to the explicit class? Or adding it to inherits?
> i.e. which of the following results are you proposing to change?
>
> is_array <- function(x) UseMethod("is_array")
> is_array.array <- function(x) TRUE
> is_array.default <- function(x) FALSE
>
> x <- matrix()
> is_array(x)
> #> [1] FALSE
> x <- matrix()
> inherits(x, "array")
> #> [1] FALSE
> class(x)
> #> [1] "matrix"
>
> It would be nice to make sure this is consistent with the behaviour of
> integers, which have an implicit parent class of numeric:
I agree but I don't know if Martin wants to go that far for R 4.0.
Hopefully that's the longer term plan though (maybe for R 4.1?).
Note that there are other situations that could follow e.g.
data.frame/list and probably more...
H.
>
> is_numeric <- function(x) UseMethod("is_numeric")
> is_numeric.numeric <- function(x) TRUE
> is_numeric.default <- function(x) FALSE
>
> x <- 1L
> is_numeric(x)
> #> [1] TRUE
> inherits(x, "numeric")
> #> [1] FALSE
> class(x)
> #> [1] "integer"
>
> Hadley
>
--
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
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
wrote:
>
> > Gabriel Becker
> > on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>
> > I agree that we can be careful and narrow and still see a
> > nice improvement in behavior. While Herve's point is valid
> > and I understand his frustration, I think staying within
> > the matrix vs c(matrix, array) space is the right scope
> > for this work in terms of fiddling with inheritance.
>
> [.]
>
>
> > > Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
> >
> > good point, and that's why my usage of inherits(.,.) was not
> > quite to the point. [OTOH, it was to the point, as indeed from
> > the ?class / ?inherits docu, S3 method dispatch and inherits
> > must be consistent ]
> >
> > > which would break -- unless we change class(x) to return the whole
> > set of inherited classes, which I sense that we'd rather not do
>
> []
>
> > Note again that both "matrix" and "array" are special [see ?class] as
> > being of __implicit class__ and I am considering that this
> > implicit class behavior for these two should be slightly
> > changed
> >
> > And indeed I think you are right on spot and this would mean
> > that indeed the implicit class
> > "matrix" should rather become c("matrix", "array").
>
> I've made up my mind (and not been contradicted by my fellow R
> corers) to try go there for R 4.0.0 next April.
I can't seem to find the previous thread, so would you mind being a
bit more explicit here? Do you mean adding "array" to the implicit
class? Or adding it to the explicit class? Or adding it to inherits?
i.e. which of the following results are you proposing to change?
is_array <- function(x) UseMethod("is_array")
is_array.array <- function(x) TRUE
is_array.default <- function(x) FALSE
x <- matrix()
is_array(x)
#> [1] FALSE
x <- matrix()
inherits(x, "array")
#> [1] FALSE
class(x)
#> [1] "matrix"
It would be nice to make sure this is consistent with the behaviour of
integers, which have an implicit parent class of numeric:
is_numeric <- function(x) UseMethod("is_numeric")
is_numeric.numeric <- function(x) TRUE
is_numeric.default <- function(x) FALSE
x <- 1L
is_numeric(x)
#> [1] TRUE
inherits(x, "numeric")
#> [1] FALSE
class(x)
#> [1] "integer"
Hadley
--
http://hadley.nz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On 11/12/19 14:03, Abby Spurdle wrote: >> You can have your own rant about "user-defined binary operators being >> over-used within the R community" without suggesting that my rant was >> rude. > > I wasn't suggesting that you were rude. > I was questioning a trend. ok, well, I must ave misinterpreted the markup you've put around your rant then... Have a nice day, H. -- 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
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
> You can have your own rant about "user-defined binary operators being > over-used within the R community" without suggesting that my rant was > rude. I wasn't suggesting that you were rude. I was questioning a trend. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On 11/12/19 12:21, Abby Spurdle wrote: > > >> x %inherits% "data.frame" > > IMHO, I think that user-defined binary operators are being over-used > within the R community. > > I don't think that they're "cute" or stylish. > I think their use should be limited to cases, where they significantly > increase the readability of the code. > > However, readability, is a (partly) subjective topic... > > > You can have your own rant about "user-defined binary operators being over-used within the R community" without suggesting that my rant was rude. I don't think it was and, in any case, I was not going after a individual in particular. Contrary to popular belief and to what I tell my daughter, rolling your eyes in public is not rude at all and is actually a lot of fun. You should try it ;-) -- 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
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
>x %inherits% "data.frame" IMHO, I think that user-defined binary operators are being over-used within the R community. I don't think that they're "cute" or stylish. I think their use should be limited to cases, where they significantly increase the readability of the code. However, readability, is a (partly) subjective topic... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On 11/11/19 01:40, Martin Maechler wrote:
>> Duncan Murdoch
>> on Sun, 10 Nov 2019 11:48:26 -0500 writes:
>
> > On 10/11/2019 9:17 a.m., Bryan Hanson wrote:
> >>
> >>
> >>> On Nov 10, 2019, at 3:36 AM, Martin Maechler
> wrote:
> >>>
> Gabriel Becker
> on Sat, 2 Nov 2019 12:37:08 -0700 writes:
> >>>
> I agree that we can be careful and narrow and still see a
> nice improvement in behavior. While Herve's point is valid
> and I understand his frustration, I think staying within
> the matrix vs c(matrix, array) space is the right scope
> for this work in terms of fiddling with inheritance.
> >>>
> >>> [.]
> >>>
> >>>
> > Also, we seem to have a rule that inherits(x, c) iff c %in%
> class(x),
>
> good point, and that's why my usage of inherits(.,.) was not
> quite to the point. [OTOH, it was to the point, as indeed from
> the ?class / ?inherits docu, S3 method dispatch and inherits
> must be consistent ]
>
> > which would break -- unless we change class(x) to return the whole
> set of inherited classes, which I sense that we'd rather not do
> >>>
> >>> []
> >>>
> Note again that both "matrix" and "array" are special [see ?class]
> as
> being of __implicit class__ and I am considering that this
> implicit class behavior for these two should be slightly
> changed
>
> And indeed I think you are right on spot and this would mean
> that indeed the implicit class
> "matrix" should rather become c("matrix", "array").
> >>>
> >>> I've made up my mind (and not been contradicted by my fellow R
> >>> corers) to try go there for R 4.0.0 next April.
> >>>
> >>> I've found the few places in base R that needed a change (to
> >>> pass 'make check-all' in the R sources) and found that indeed a
> >>> overzealous check in 'Matrix' needed also a change (a place
> >>> where the checking code assume class() |--> "matrix" ).
> >>>
> >>> There are certainly many more package (codes and checks) that
> >>> need adaption .. i.e., should be changed rather *before* the
> >>> above change is activated in R-devel (and then will affect all CRAN
> >>> and Bioconductor checks.)
> >>>
> >>> To this end, I've published an 'R Blog' yesterday,
> >>>
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_R-5Fblog-5Fclass-5Fthink-5F2x=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Haem9CPNVAwtpdrnFb50tn-RoEohzBVpzJRgkjRFqBg=TFCIJjbe482LLMV-P2B9vTc5G8nIcW0Ekx25qhuzCOg=
> >>>
> >>> which translates to
> >>>
> >>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.r-2Dproject.org_Blog_public_2019_11_09_when-2Dyou-2Dthink-2Dclass.-2Dthink-2Dagain_index.html=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Haem9CPNVAwtpdrnFb50tn-RoEohzBVpzJRgkjRFqBg=kbZV1cxdT0uFW2gX8iCQmV-SANS8xCp678it1okCRqs=
> >>>
> >>> notably mentioning why using class(x) == "" (or '!=') or
> >>> switch(class(.) ...) is quite unsafe and hence bad and you
> >>> should very often not replace class(x) by class(x)[1] but
> >>> really use the "only truly correct" ;-)
> >>>
> >>> inherits(x, "...")
> >>> or
> >>> is(x, "") # if you're advanced/brave enough (:-) to
> >>> # use formal classes (S4)
> >>
> >> Thanks for the helpful blog post Martin. Is the following
> >>
> >> “test_class” %in% class(some_object)
> >>
> >> which I think in your symbols would be
> >>
> >> “…” %in% class(x)
> >>
> >> safe as far as you see it? By safe, I mean equivalent to your
> suggestion of inherits(x, “…”) .
>
> > Those aren't equivalent if S4 gets involved. You can see it if you run
> > this code:
>
> > example("new") # Creates an object named t2 of class "trackcurve"
> ># that contains "track"
>
> > inherits(t2, "track") # TRUE
> > "track" %in% class(t2) # FALSE
>
> > I can't think of any examples not involving S4.
>
> > Duncan Murdoch
>
> Thank you, Duncan.
> That's definitely a strong reason for inherits(), because often
> in such code, you don't know in advance what objects will be
> passed to your function.
>
>
> On Twitter, others have asked "the same", arguing that
>
> "" %in% class(.)
>
>> uses usual syntax, and thus looks less intimidating than
>> inherit() and less cryptic than is()
%-/ (<- ASCII version of the rolling eyes emoji)
The most cryptic of the 3 forms being by far:
"" %in% class(x)
You need to be able to read thru this to
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
> Duncan Murdoch
> on Sun, 10 Nov 2019 11:48:26 -0500 writes:
> On 10/11/2019 9:17 a.m., Bryan Hanson wrote:
>>
>>
>>> On Nov 10, 2019, at 3:36 AM, Martin Maechler
wrote:
>>>
Gabriel Becker
on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>>>
I agree that we can be careful and narrow and still see a
nice improvement in behavior. While Herve's point is valid
and I understand his frustration, I think staying within
the matrix vs c(matrix, array) space is the right scope
for this work in terms of fiddling with inheritance.
>>>
>>> [.]
>>>
>>>
> Also, we seem to have a rule that inherits(x, c) iff c %in%
class(x),
good point, and that's why my usage of inherits(.,.) was not
quite to the point. [OTOH, it was to the point, as indeed from
the ?class / ?inherits docu, S3 method dispatch and inherits
must be consistent ]
> which would break -- unless we change class(x) to return the whole
set of inherited classes, which I sense that we'd rather not do
>>>
>>> []
>>>
Note again that both "matrix" and "array" are special [see ?class] as
being of __implicit class__ and I am considering that this
implicit class behavior for these two should be slightly
changed
And indeed I think you are right on spot and this would mean
that indeed the implicit class
"matrix" should rather become c("matrix", "array").
>>>
>>> I've made up my mind (and not been contradicted by my fellow R
>>> corers) to try go there for R 4.0.0 next April.
>>>
>>> I've found the few places in base R that needed a change (to
>>> pass 'make check-all' in the R sources) and found that indeed a
>>> overzealous check in 'Matrix' needed also a change (a place
>>> where the checking code assume class() |--> "matrix" ).
>>>
>>> There are certainly many more package (codes and checks) that
>>> need adaption .. i.e., should be changed rather *before* the
>>> above change is activated in R-devel (and then will affect all CRAN
>>> and Bioconductor checks.)
>>>
>>> To this end, I've published an 'R Blog' yesterday,
>>>
>>> http://bit.ly/R_blog_class_think_2x
>>>
>>> which translates to
>>>
>>>
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again/index.html
>>>
>>> notably mentioning why using class(x) == "" (or '!=') or
>>> switch(class(.) ...) is quite unsafe and hence bad and you
>>> should very often not replace class(x) by class(x)[1] but
>>> really use the "only truly correct" ;-)
>>>
>>> inherits(x, "...")
>>> or
>>> is(x, "") # if you're advanced/brave enough (:-) to
>>> # use formal classes (S4)
>>
>> Thanks for the helpful blog post Martin. Is the following
>>
>> “test_class” %in% class(some_object)
>>
>> which I think in your symbols would be
>>
>> “…” %in% class(x)
>>
>> safe as far as you see it? By safe, I mean equivalent to your suggestion
of inherits(x, “…”) .
> Those aren't equivalent if S4 gets involved. You can see it if you run
> this code:
> example("new") # Creates an object named t2 of class "trackcurve"
># that contains "track"
> inherits(t2, "track") # TRUE
> "track" %in% class(t2) # FALSE
> I can't think of any examples not involving S4.
> Duncan Murdoch
Thank you, Duncan.
That's definitely a strong reason for inherits(), because often
in such code, you don't know in advance what objects will be
passed to your function.
On Twitter, others have asked "the same", arguing that
"" %in% class(.)
> uses usual syntax, and thus looks less intimidating than
> inherit() and less cryptic than is()
I think you should all use -- and *teach* --
inherits(.) more often, and it would no longer be intimidating.
Also, for the speed fetishists: inherits() will typically be
slightly (but significantly) faster than ` %in% class(.) `
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
On 10/11/2019 9:17 a.m., Bryan Hanson wrote:
On Nov 10, 2019, at 3:36 AM, Martin Maechler wrote:
Gabriel Becker
on Sat, 2 Nov 2019 12:37:08 -0700 writes:
I agree that we can be careful and narrow and still see a
nice improvement in behavior. While Herve's point is valid
and I understand his frustration, I think staying within
the matrix vs c(matrix, array) space is the right scope
for this work in terms of fiddling with inheritance.
[.]
Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
good point, and that's why my usage of inherits(.,.) was not
quite to the point. [OTOH, it was to the point, as indeed from
the ?class / ?inherits docu, S3 method dispatch and inherits
must be consistent ]
which would break -- unless we change class(x) to return the whole
set of inherited classes, which I sense that we'd rather not do
[]
Note again that both "matrix" and "array" are special [see ?class] as
being of __implicit class__ and I am considering that this
implicit class behavior for these two should be slightly
changed
And indeed I think you are right on spot and this would mean
that indeed the implicit class
"matrix" should rather become c("matrix", "array").
I've made up my mind (and not been contradicted by my fellow R
corers) to try go there for R 4.0.0 next April.
I've found the few places in base R that needed a change (to
pass 'make check-all' in the R sources) and found that indeed a
overzealous check in 'Matrix' needed also a change (a place
where the checking code assume class() |--> "matrix" ).
There are certainly many more package (codes and checks) that
need adaption .. i.e., should be changed rather *before* the
above change is activated in R-devel (and then will affect all CRAN
and Bioconductor checks.)
To this end, I've published an 'R Blog' yesterday,
http://bit.ly/R_blog_class_think_2x
which translates to
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again/index.html
notably mentioning why using class(x) == "" (or '!=') or
switch(class(.) ...) is quite unsafe and hence bad and you
should very often not replace class(x) by class(x)[1] but
really use the "only truly correct" ;-)
inherits(x, "...")
or
is(x, "") # if you're advanced/brave enough (:-) to
# use formal classes (S4)
Thanks for the helpful blog post Martin. Is the following
“test_class” %in% class(some_object)
which I think in your symbols would be
“…” %in% class(x)
safe as far as you see it? By safe, I mean equivalent to your suggestion of
inherits(x, “…”) .
Those aren't equivalent if S4 gets involved. You can see it if you run
this code:
example("new") # Creates an object named t2 of class "trackcurve"
# that contains "track"
inherits(t2, "track") # TRUE
"track" %in% class(t2) # FALSE
I can't think of any examples not involving S4.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
> On Nov 10, 2019, at 3:36 AM, Martin Maechler
> wrote:
>
>> Gabriel Becker
>>on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>
>> I agree that we can be careful and narrow and still see a
>> nice improvement in behavior. While Herve's point is valid
>> and I understand his frustration, I think staying within
>> the matrix vs c(matrix, array) space is the right scope
>> for this work in terms of fiddling with inheritance.
>
> [.]
>
>
>>> Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
>>
>> good point, and that's why my usage of inherits(.,.) was not
>> quite to the point. [OTOH, it was to the point, as indeed from
>> the ?class / ?inherits docu, S3 method dispatch and inherits
>> must be consistent ]
>>
>>> which would break -- unless we change class(x) to return the whole
>> set of inherited classes, which I sense that we'd rather not do
>
> []
>
>> Note again that both "matrix" and "array" are special [see ?class] as
>> being of __implicit class__ and I am considering that this
>> implicit class behavior for these two should be slightly
>> changed
>>
>> And indeed I think you are right on spot and this would mean
>> that indeed the implicit class
>> "matrix" should rather become c("matrix", "array").
>
> I've made up my mind (and not been contradicted by my fellow R
> corers) to try go there for R 4.0.0 next April.
>
> I've found the few places in base R that needed a change (to
> pass 'make check-all' in the R sources) and found that indeed a
> overzealous check in 'Matrix' needed also a change (a place
> where the checking code assume class() |--> "matrix" ).
>
> There are certainly many more package (codes and checks) that
> need adaption .. i.e., should be changed rather *before* the
> above change is activated in R-devel (and then will affect all CRAN
> and Bioconductor checks.)
>
> To this end, I've published an 'R Blog' yesterday,
>
> http://bit.ly/R_blog_class_think_2x
>
> which translates to
>
>
> https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again/index.html
>
> notably mentioning why using class(x) == "" (or '!=') or
> switch(class(.) ...) is quite unsafe and hence bad and you
> should very often not replace class(x) by class(x)[1] but
> really use the "only truly correct" ;-)
>
> inherits(x, "...")
> or
> is(x, "") # if you're advanced/brave enough (:-) to
> # use formal classes (S4)
Thanks for the helpful blog post Martin. Is the following
“test_class” %in% class(some_object)
which I think in your symbols would be
“…” %in% class(x)
safe as far as you see it? By safe, I mean equivalent to your suggestion of
inherits(x, “…”) .
Thanks, Bryan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] class() |--> c("matrix", "arrary") [was "head.matrix ..."]
> Gabriel Becker
> on Sat, 2 Nov 2019 12:37:08 -0700 writes:
> I agree that we can be careful and narrow and still see a
> nice improvement in behavior. While Herve's point is valid
> and I understand his frustration, I think staying within
> the matrix vs c(matrix, array) space is the right scope
> for this work in terms of fiddling with inheritance.
[.]
> > Also, we seem to have a rule that inherits(x, c) iff c %in% class(x),
>
> good point, and that's why my usage of inherits(.,.) was not
> quite to the point. [OTOH, it was to the point, as indeed from
> the ?class / ?inherits docu, S3 method dispatch and inherits
> must be consistent ]
>
> > which would break -- unless we change class(x) to return the whole
> set of inherited classes, which I sense that we'd rather not do
[]
> Note again that both "matrix" and "array" are special [see ?class] as
> being of __implicit class__ and I am considering that this
> implicit class behavior for these two should be slightly
> changed
>
> And indeed I think you are right on spot and this would mean
> that indeed the implicit class
> "matrix" should rather become c("matrix", "array").
I've made up my mind (and not been contradicted by my fellow R
corers) to try go there for R 4.0.0 next April.
I've found the few places in base R that needed a change (to
pass 'make check-all' in the R sources) and found that indeed a
overzealous check in 'Matrix' needed also a change (a place
where the checking code assume class() |--> "matrix" ).
There are certainly many more package (codes and checks) that
need adaption .. i.e., should be changed rather *before* the
above change is activated in R-devel (and then will affect all CRAN
and Bioconductor checks.)
To this end, I've published an 'R Blog' yesterday,
http://bit.ly/R_blog_class_think_2x
which translates to
https://developer.r-project.org/Blog/public/2019/11/09/when-you-think-class.-think-again/index.html
notably mentioning why using class(x) == "" (or '!=') or
switch(class(.) ...) is quite unsafe and hence bad and you
should very often not replace class(x) by class(x)[1] but
really use the "only truly correct" ;-)
inherits(x, "...")
or
is(x, "") # if you're advanced/brave enough (:-) to
# use formal classes (S4)
Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
