Thanks Bert, I think we agree on the current behaviour, but I'm still not sure
if it's desirable. The mode isn't used for method dispatch. In the following
example, I have to write `log.foo` in order for the correct method to be called.
> x <- seq.int(5)
> class(x) <- c("integer", "foo")
> half <- function(x) UseMethod("half")
> half.default <- function(x) {
+ floor(x) / 2
+ }
> half.integer <- function(x) {
+ x %/% 2
+ }
> half(log(x)) # dispatches half.integer, not desired
[1] 0 0 0 0 0
attr(,"class")
[1] "integer" "foo"
> half(log(seq(5))) # dispatches half.default, as desired
[1] 0.0 0.0 0.5 0.5 0.5
> log.foo <- function(x) {
+ res <- log(as.numeric(x))
+ class(res) <- c("numeric", "foo")
+ res
+ }
> half(log(x)) # dispatches log.foo, then half.default, as desired
[1] 0.0 0.0 0.5 0.5 0.5
attr(,"class")
[1] "numeric" "foo"
Not only would I have to write `log.foo`, but I'd need to add my own `foo`
methods for the Math and Ops groups. Using a different class system might be a
better solution, but my preference would definitely be for the base functions
to coerce the class to numeric (which it indeed does if there are not multiple
classes).
Cole
________________________________________
From: Bert Gunter [bgunter.4...@gmail.com]
Sent: Thursday, June 08, 2017 4:45 PM
To: Beck, Cole
Cc: R-help
Subject: Re: [R] Math ops behaviour with multiple classes
I think you may be confusing (S3) class and ?mode.
> x <- seq.int(1:3)
> class(x)
[1] "integer"
> mode(x)
[1] "numeric"
> class(x+.5) ## coercion
[1] "numeric"
> mode(x+.5)
[1] "numeric"
But note:
> y <- as.integer(1)
> class(y)
[1] "integer"
> class(y) <- "foo"
> mode(y)
[1] "numeric"
> class(y+.5)
[1] "foo"
> mode(y+.5)
[1] "numeric"
And further:
> class(y) <-c("foo","integer")
> class(y+.5)
[1] "foo" "integer"
So basically, the behavior seems to be: when the class attribute can
be coerced to "numeric" by as.numeric(), it is. Otherwise it is left
as is.
Note that log is a primitive function not in the Ops groups, but has
similar behavior.
I would guess (corroboration or correction by more knowledgeable folks
appreciated!) that this sort of semi-confusion with S3 classes was one
of the motivators for adding the more rigorous S4 system.
HTH
Cheers,
Bert
Bert Gunter
"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Thu, Jun 8, 2017 at 9:40 AM, Cole Beck <cole.b...@vanderbilt.edu> wrote:
> I would expect that several math operations should always return values with
> a class of numeric. If the input is defined with multiple classes, however,
> the class attribute is preserved. I would think this may have some
> unintended side-effects. Here's an example:
>
>> sessionInfo()$R.version$version.string
> [1] "R version 3.4.0 (2017-04-21)"
>> x <- seq.int(5)
>> class(x)
> [1] "integer"
>> class(log(x))
> [1] "numeric"
>> class(x) <- c("integer", "foo")
>> log(x)
> [1] 0.0000000 0.6931472 1.0986123 1.3862944 1.6094379
> attr(,"class")
> [1] "integer" "foo"
>> x + 0.5
> [1] 1.5 2.5 3.5 4.5 5.5
> attr(,"class")
> [1] "integer" "foo"
>
> I do see the note in ?Arithmetic that states "All attributes (including
> class) are preserved if there is no coercion". Is this correct, or should
> the returned value have an updated class of c("numeric", "foo")? Should foo
> have its own methods to coerce the output to numeric?
>
> Thanks,
> Cole
>
> ______________________________________________
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
