`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 no
On Thu, Jun 8, 2017 at 2:45 PM, Bert Gunter wrote:
> I think you may be confusing (S3) class and ?mode.
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.
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
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
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$v
5 matches
Mail list logo
