On Mon, 21 Apr 2008, Mathieu Ribatet wrote:
> 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.
> 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@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@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."
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
