Re: [Rd] array() ignores illegal non-list dimnames
> William Dunlap via R-devel
> on Thu, 17 Dec 2015 14:40:18 -0800 writes:
> Is there a reason that array() silently ignores dimnames
> that are not a list but matrix() gives an error?
>> str(matrix(11:14, 2, 2, dimnames=c("Rows","Cols")))
> Error in matrix(11:14, 2, 2, dimnames = c("Rows", "Cols")) :
> 'dimnames' must be a list
>> str(array(11:14, dim=c(2, 2), dimnames=c("Rows","Cols")))
> int [1:2, 1:2] 11 12 13 14
of course there must be a historical reason why this lapsus
happens, ;-)
but it is definitely not as intended, and I'll commit a fix for
R-devel and R-patched "immediately".
> I noticed this in lhs:::geneticLHS, which has the line
> J <- array(NA, dim = c(n, k, pop), dimnames = c("points",
> "variables", "hypercubes"))
> where the non-list dimnames has no effect, and no warning or error.
so we will see some CRAN (and may off-CRAN) packages
producing errors after the change,
but indeed, these errors will be catching programming errors !
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
Thanks a lot, Bill!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] For integer vectors, `as(x, "numeric")` has no effect.
> Martin Maechler
> on Sat, 12 Dec 2015 10:32:51 +0100 writes:
> John Chambers
> on Fri, 11 Dec 2015 10:11:05 -0800 writes:
>> Somehow, the most obvious fixes are always back-incompatible these days.
>> The example intrigued me, so I looked into it a bit (should have been
doing something else, but )
>> You're right that this is the proverbial thin-edge-of-the-wedge.
>> The problem is in setDataPart(), which will be called whenever a class
extends one of the vector types.
>> It does
>> as(value, dataClass)
>> The key point is that the third argument to as(), strict=TRUE by
default. So, yes, the change will cause all integer vectors to become double
when the class extends "numeric". Generally, strict=TRUE makes sense here and
of course changing THAT would open up yet more incompatibilities.
>> For back compatibility, one would have to have some special code in
setDataPart() for the case of integer/numeric.
>> John
>> (Historically, the original sin was probably not making a distinction
between "numeric" as a virtual class and "double" as a type/class.)
> Yes, indeed. In the mean time, I've seen more cases where
> "the change will cause all integer vectors to become double when the
class extends "numeric".
> seems detrimental.
> OTOH, I still think we could go in the right direction ---
> hopefully along the wishes of bioconductor S4 development, see
> Martin Morgan's e-mail:
> [This is all S4 - only; should not much affect base R / S3]
> Currently, "integer" is a subclass of "numeric" and so the
> "integer become double" part seems unwanted to me.
> OTOH, it would really make sense to more formally
> have the basic subclasses of "numeric" to be "integer" and "double",
> and to let as(*, "double") to become different to as(*, "numeric")
> [Again, this is just for the S4 classes and as() coercions, *not* e.g.
> for as.numeric() / as.double() !]
> In the DEPRECATED part of the NEWS for R 2.7.0 (April 2008) we
> have had
> o The S4 pseudo-classes "single" and double have been removed.
> (The S4 class for a REALSXP is "numeric": for back-compatibility
> as(x, "double") coerces to "numeric".)
> I think the removal of "single" was fine, but in hindsight,
> maybe the removal of "double" -- which was partly broken then --
> possibly could rather have been a fixup of "double" along the
> following
> Current "thought experiment proposal" :
> 1) "numeric" := {"integer", "double"} { class - subclasses }
> 2) as(1L, "numeric") continues to return 1L .. since integer is
> one case of "numeric"
> 3) as(1L, "double") newly returns 1.0 {and in fact would be
> "equivalent" to as.double(1L)}
> After the above change, S4 as(*, "double") would correspond to S3
as.double
> but as(*, "numeric") would continue to differ from
> as.numeric(*), the former *not* changing integers to double.
> Martin
Also note that e.g.
class(pi)would return "double" instead of "numeric"
and this will break all the bad programming style usages of
if(class(x) == "numeric")
which I tend to see in gazillions of user and even package codes
This bad (aka error prone !) because "correct" usage would be
if(inherits(x, "numeric"))
and that of course would *not* break after the change above.
- - - -
A week later, I'm still pretty convinced it would be worth going
in the direction proposed above.
But I was actually hoping for some encouragement or "mental support"...
or then to hear why you think the proposition is not good or not
viable ...
>> On Dec 11, 2015, at 1:25 AM, Martin Maechler
wrote:
Martin Maechler
on Tue, 8 Dec 2015 15:25:21 +0100 writes:
>>>
John Chambers
on Mon, 7 Dec 2015 16:05:59 -0800 writes:
>>>
> We do need an explicit method here, I think.
> The issue is that as() uses methods for the generic function coerce()
but cannot use inheritance in the usual way (if it did, you would be
immediately back with no change, since "integer" inherits from "numeric").
>>>
> Copying in the general method for coercing to "numeric" as an
explicit method for "integer" gives the expected result:
>>>
>> setMethod("coerce", c("integer", "numeric"), getMethod("coerce",
c("ANY", "numeric")))
> [1] "coerce"
>> typeof(as(1L, "numeric"))
> [1] "double"
>>>
> Seems like a reasonable addition to the code, unless someone sees a
problem.
> John
>>>
I guess that that some package checks (in CRAN + Bioc + ... -
land) will break,
but I still think we should add such a coercion to R.
>>>
Martin
>>>
>>> Hmm... I've tried to add the above to R
>>> and do notice that there are consequenc
Re: [Rd] For integer vectors, `as(x, "numeric")` has no effect.
As I tried to say on Dec. 11, there are two levels of "fix":
1. The fix to the complaint in the OP's subject heading is to conform to the
default third argument, strict=TRUE: as(1L, "numeric") == 1.0
This generates some incompatibilities, as for classes that extend "numeric".
But still leaves class(1.0) "numeric" and typeof(1.0) "double".
The workaround for class definitions that really need NOT to coerce integers to
double is to define a class union, say
setClassUnion("Number", c("numeric", "integer"))
and use that for the slot.
2. The "right" concept is arguably that "numeric" is a virtual class with two
subclasses, "double" and "integer". Given a time machine back to < 1998, that
would be my choice. But already in the 1998 S4 book, "numeric" was equated
with "double".
so, there it is, IMO. This is what you get with a successful open-source
language: Much hassle to do the "right thing" after the fact and the more
change, the more hassle.
Fix 1. seems to me an actual bug fix, so my inclination would be to go with
that (on r-devel), advertising that it may change the effective definition of
some classes.
But I can sympathize with choosing 1, 2 or neither.
John
PS: Until Jan. 4, I may be even poorer at replying than usual, while getting
the current book off to the publisher.
On Dec 19, 2015, at 3:32 AM, Martin Maechler wrote:
>> Martin Maechler
>>on Sat, 12 Dec 2015 10:32:51 +0100 writes:
>
>> John Chambers
>>on Fri, 11 Dec 2015 10:11:05 -0800 writes:
>
>>> Somehow, the most obvious fixes are always back-incompatible these days.
>>> The example intrigued me, so I looked into it a bit (should have been doing
>>> something else, but )
>
>>> You're right that this is the proverbial thin-edge-of-the-wedge.
>
>>> The problem is in setDataPart(), which will be called whenever a class
>>> extends one of the vector types.
>
>>> It does
>>> as(value, dataClass)
>>> The key point is that the third argument to as(), strict=TRUE by default.
>>> So, yes, the change will cause all integer vectors to become double when
>>> the class extends "numeric". Generally, strict=TRUE makes sense here and
>>> of course changing THAT would open up yet more incompatibilities.
>
>>> For back compatibility, one would have to have some special code in
>>> setDataPart() for the case of integer/numeric.
>
>>> John
>
>>> (Historically, the original sin was probably not making a distinction
>>> between "numeric" as a virtual class and "double" as a type/class.)
>
>> Yes, indeed. In the mean time, I've seen more cases where
>> "the change will cause all integer vectors to become double when the class
>> extends "numeric".
>> seems detrimental.
>
>> OTOH, I still think we could go in the right direction ---
>> hopefully along the wishes of bioconductor S4 development, see
>> Martin Morgan's e-mail:
>
>> [This is all S4 - only; should not much affect base R / S3]
>> Currently, "integer" is a subclass of "numeric" and so the
>> "integer become double" part seems unwanted to me.
>> OTOH, it would really make sense to more formally
>> have the basic subclasses of "numeric" to be "integer" and "double",
>> and to let as(*, "double") to become different to as(*, "numeric")
>> [Again, this is just for the S4 classes and as() coercions, *not* e.g.
>> for as.numeric() / as.double() !]
>
>> In the DEPRECATED part of the NEWS for R 2.7.0 (April 2008) we
>> have had
>
>> oThe S4 pseudo-classes "single" and double have been removed.
>> (The S4 class for a REALSXP is "numeric": for back-compatibility
>> as(x, "double") coerces to "numeric".)
>
>> I think the removal of "single" was fine, but in hindsight,
>> maybe the removal of "double" -- which was partly broken then --
>> possibly could rather have been a fixup of "double" along the
>> following
>
>> Current "thought experiment proposal" :
>
>> 1) "numeric" := {"integer", "double"} { class - subclasses }
>> 2) as(1L, "numeric") continues to return 1L .. since integer is
>> one case of "numeric"
>> 3) as(1L, "double") newly returns 1.0 {and in fact would be
>> "equivalent" to as.double(1L)}
>
>> After the above change, S4 as(*, "double") would correspond to S3 as.double
>> but as(*, "numeric") would continue to differ from
>> as.numeric(*), the former *not* changing integers to double.
>
>> Martin
>
> Also note that e.g.
>
>class(pi)would return "double" instead of "numeric"
>
> and this will break all the bad programming style usages of
>
> if(class(x) == "numeric")
>
> which I tend to see in gazillions of user and even package codes
> This bad (aka error prone !) because "correct" usage would be
>
> if(inherits(x, "numeric"))
>
> and that of course would *not* break after the change above.
>
> - - - -
>
> A week later, I'm still pretty convinced it would be worth going
> in the direction proposed above.
>
> But I was actually hoping for some encouragement or "mental
