From r.hankin at noc.soton.ac.uk  Tue Apr 22 09:17:16 2008
From: r.hankin at noc.soton.ac.uk (Robin Hankin)
Date: Tue, 22 Apr 2008 08:17:16 +0100
Subject: [Rd] prod(0, 1:1000) ;  0 * Inf  etc
In-Reply-To: <Pine.GSO.4.56.0804211820460.26934@devsun3201.insightful.com>
References: <18444.50059.714864.992037@stat.math.ethz.ch>
	<480CDF56.5070104@epfl.ch>
	<Pine.GSO.4.56.0804211820460.26934@devsun3201.insightful.com>
Message-ID: <25B79FD5-59A1-441D-8393-9033AC7F7CAE@noc.soton.ac.uk>

Interesting problem this.

My take on it would be that the "true" value depends
on how fast the "0" approaches 0 and how fast the "n"
approaches infinity.

Consider

f1 <- function(n){prod(1/n , seq_len(n))}
f2 <- function(n){prod(1/factorial(n) , seq_len(n))}
f3 <- function(n){prod(n^(-n) , seq_len(n))}

All these are equal to prod( "small number" , 1:"big number")

but applying these functions to an increasing sequence gives different
behaviour:

 > sapply(c(10,100,1000),f1)
[1]  3.628800e+05 9.332622e+155           Inf
 > sapply(c(10,100,1000),f2)
[1]   1   1 NaN
 > sapply(c(10,100,1000),f3)
[1] 3.628800e-04 9.332622e-43          NaN
 >


f1() tends to infinity, f2() tends to 1, and f3() tends to zero.

Figuring out the appropriate limit in cases like this is a job
for a symbolic system.

I would say the original behaviour is desirable.


rksh



On 22 Apr 2008, at 02:43, Bill Dunlap wrote:

> 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."
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Robin Hankin
Uncertainty Analyst and Neutral Theorist,
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
  tel  023-8059-7743



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