Skip to content

Math ops behaviour with multiple classes

5 messages · Bert Gunter, Cole Beck, Hadley Wickham +1 more

#
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
#
I think you may be confusing (S3) class and ?mode.
[1] "integer"
[1] "numeric"
[1] "numeric"
[1] "numeric"

But note:
[1] "integer"
[1] "numeric"
[1] "foo"
[1] "numeric"

And further:
[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.beck at vanderbilt.edu> wrote:
#
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.
+   floor(x) / 2
+ }
+   x %/% 2
+ }
[1] 0 0 0 0 0
attr(,"class")
[1] "integer" "foo"
[1] 0.0 0.0 0.5 0.5 0.5
+   res <- log(as.numeric(x))
+   class(res) <- c("numeric", "foo")
+   res
+ }
[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
#
On Thu, Jun 8, 2017 at 2:45 PM, Bert Gunter <bgunter.4567 at gmail.com> wrote:
Your point is well made, but to be precise, I think you should talk
about the "type of" an object, not it's mode. mode() is a wrapper
around typeof(), designed (I believe) for S compatibility.

Hadley
#
Cole, that cow left the barn decades ago. 

You really should read Patrick Burns' discussion of the history of R [1].

[1] http://www.burns-stat.com/documents/presentations/inferno-ish-R/