On Tue, 20 Nov 2007, Tim Hesterberg wrote:
I wrote the original rowSums (in S-PLUS).
There, rowSums() does not coerce integer to double.
Actaully, neither does R. It computes a double answer but does no
coercion per se.
However, one advantage of coercion is to avoid integer overflow.
On 21 Nov 2007, at 08:30, Prof Brian Ripley wrote:
On Tue, 20 Nov 2007, Tim Hesterberg wrote:
I wrote the original rowSums (in S-PLUS).
There, rowSums() does not coerce integer to double.
Actaully, neither does R. It computes a double answer but does no
coercion per se.
However, one
On Wed, 21 Nov 2007, Robin Hankin wrote:
On 21 Nov 2007, at 08:30, Prof Brian Ripley wrote:
On Tue, 20 Nov 2007, Tim Hesterberg wrote:
I wrote the original rowSums (in S-PLUS).
There, rowSums() does not coerce integer to double.
Actaully, neither does R. It computes a double answer
I wrote the original rowSums (in S-PLUS).
There, rowSums() does not coerce integer to double.
However, one advantage of coercion is to avoid integer overflow.
Tim Hesterberg
... So, why does rowSums() coerce to double (behaviour
that is undesirable for me)?
Hi
[R-2.6.0, macOSX 10.4.10].
The helppage says that rowSums() and colSums()
are equivalent to 'apply' with 'FUN = sum'.
But I came across this:
a - matrix(1:30,5,6)
is.integer(apply(a,1,sum))
[1] TRUE
is.integer(rowSums(a))
[1] FALSE
so rowSums() returns a float.
Why is this?
--
5 matches
Mail list logo
