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

[Mathieu Ribatet]

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