prod(0, 1:1000) ; 0 * Inf etc
I definitely do agree with you.
Basically, I see two different ways to proceed:
1. one could first check if there are any 0 in the vector and then
return 0 without computing the product
That would fail for prod(0,Inf), which should return the same thing as 0*Inf=NaN. Similarly for prod(0,NA) and prod(0,NaN). Scanning for all these things might well be slower than just doing the multiplications. Scanning also means that 0 is treated more commutatively than other numbers.
Yes you're right when vectors have special values - oupppsss. However, for the "more commutatively behaviour of 0", to me this is not a problem - just a computational trick. We all know easily how to multiply by 11. This is just the same. What we want is that the operator is still commutative which (of course) is still the case. However, you're probably right with the time consuming approach of checking 0 (as well as special values) within the vector. The question is what is the main objective? Fast computations but could lead to miss-calculations - in rarely cases. Or run codes a little bit slower while returning the appropriate values - a little bit more often. I'm not sure users do so many times products of really huge length vectors though - but this is only my point of view. Best, Mathieu
2. or convert prod(x1, x2, x3) in prod(c(x1, x2, x3))
c() can convert values of classy objects in undesirable ways. E.g.,
> now<-Sys.time()
> min(now-file.info(".")$mtime, now-file.info("..")$mtime)
Time difference of 3787.759 secs
> min(c(now-file.info(".")$mtime, now-file.info("..")$mtime))
[1] 1.052155 This may be considered a bug in c(), at least for class "timediff" (and "factor" and "ordered"), but c() removes attributes.
Martin Maechler a ?crit :
I think most of us would expect prod(0:1000) to return 0, and ...
... it does.
However, many of us also expect
prod(x1, x2) to be equivalent to
prod(c(x1,x2))
the same as we can expect that for min(), max(), sum() and such
members of the "Summary" group.
Consequently, prod(0, 1:1000) should also return 0,
but as you see, it gives NaN which may be a bit puzzling...
The explanation is relatively simple:
1) The internal implementation uses
prod(x1, x2) := prod(x1) * prod(x2)
which in this case is
2) 0 * Inf and that is not 0, but NaN;
not necessarily because we would want that, but I think just
because the underlying C math library does so.
I would personally like to change both behaviors,
but am currently only proposing to change prod() such as to
return 0 in such cases.
This would be S-plus compatible, in case that matters.
Opinions?
Martin Maechler, ETH Zurich & R-core
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
-- Institute of Mathematics Ecole Polytechnique F?d?rale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
---------------------------------------------------------------------------- Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position."
Institute of Mathematics Ecole Polytechnique F?d?rale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907