[Rd] prod(0, 1:1000) ; 0 * Inf etc

[Bill Dunlap]

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 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."