From ripley at stats.ox.ac.uk  Mon Jul 23 11:33:39 2007
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Mon, 23 Jul 2007 10:33:39 +0100 (BST)
Subject: [Rd] R2.6 bug in arithmetics of S4 classes inherited from
 'array', or intended behavior?
In-Reply-To: <1185181337.6294.29.camel@dirac>
References: <1185181337.6294.29.camel@dirac>
Message-ID: <Pine.LNX.4.64.0707231017100.23845@gannet.stats.ox.ac.uk>

I believe this occurred with the change to make use of implicit generics, 
r42246.  Please check that for yourself (see the comment at the end).

If so it will need John Chambers' attention (he is currently offline).

On Mon, 23 Jul 2007, Oleg Sklyar wrote:

> Hi,
>
> I have an S4 class directly derived from 'array' as shown in the code
> below (EBImage package of Bioconductor 2.1, devel), it simply contains
> array adding a couple of slots:
>
> setClass ("Image",
>  representation (colormode="integer", filename="character",
>    compression="character", resolution="numeric", features="list"
>  ),
>  prototype (colormode= Grayscale, filename="no-name",
> compression="JPEG",
>    resolution=c(2.5e+6, 2.5e+6), features=list()
>  ),
>  contains = "array"
> )

Which is unfortunately not self-contained.

> No mathematical/arithmetical routines have been redefined for the class
> and this is what I was getting since R2.0, sum of two objects of class
> Image is Image again:
>
> version.string R version 2.5.1 (2007-06-27):
>> library(EBImage)
>> a <- Image(0, c(2,2))
>> class(a+a)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>
> The same stands for
>
> version.string R version 2.6.0 Under development (unstable) (2007-07-11
> r42199)
>> library(EBImage)
>> a <- Image(0, c(2,2))
>> class(a+a)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>
> Now, in the yesterday's revision of R2.6 I get the following:
>
> version.string R version 2.6.0 Under development (unstable) (2007-07-21
> r42284)
>
>> library(EBImage)
>> a <- Image(0, c(2,2))
>> class(a+a)
> [1] "array"
>
> Is this the intended behavior to fall back to the base class (same for
> *,/,-)? If yes, could someone point me to the following two things: what
> are the reasons behind and WHAT operators and functions have been
> affected -- I will need to redefine all those then. Moreover, it is not
> consistent:
>
>> class(a*2)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>> class(2*a)
> [1] "Image"
> attr(,"package")
> [1] "EBImage"
>
>
> Unfortunately, I do not have R versions installed between revisions
> 42199 and 42284, so I cannot narrow down to the particular revision.

But you can of course get any version out of SVN and thereby narrow this 
down.  Please don't expect others to do this for you.

svn up -r42245
make
...
svn up -r42246
make
...

confirms it for me.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] R2.6 bug in arithmetics of S4 classes inherited from 'array', or intended behavior?
Prof Brian Ripley