I don't see how this discussion impacts the results of SERIESSUM. The nice aspect of SERIESSUM is that it specifies precisely what the result should be. So long as no exponents are negative, it requires that SERIESSUM(0;...) be either c[0] or 0 depending on whether or not 0 is included in the set of exponents. c[0] is the coefficient for the term having exponent 0. That's a very specific, whether or not astonishing, definition.
There is no requirement that SERIESSUM use POWER(a,n) as the implementation for the 0^0 case. The SERIESUM definition appears to be independent of what an implementation-defined 0^0 might be. I'm not challenging your preference. I'm just observing that the SERIESSUM definition is explicitly separate from the POWER definition concerning 0^0. - Dennis PS: It appears that Excel does not satisfy the OpenFormula definition. =SERIESSUM(0,0,1,C1:C1) where C1 = PI() returns #NUM! SERIESSUM(1,0,1,C1:C1) returns PI(). This is the case for Excel 2010 and Excel 2013 (Preview). Since SERIESSUM has no implementation in Apache OpenOffice, any interchange-interoperability failure is yet to come. -----Original Message----- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, February 10, 2013 15:10 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 Hi all, Here my view: We should not change the current behavior, because - It is one of three allowed result, so it is not an error. - Changing it, would break old documents. - returning 1 will be consistent with SERIESSUM (I know, that SERIESSUM is currently not yet adapted to ODF1.2, but for SERIESSUM there is no choice.) - returning 1 is the same as in BASIC. Andrea Pescetti schrieb: > A good practical example of backwards-incompatible changes in version > 4.0 is the behavior of Calc while computing 0 ^ 0. > > You can find a long issue, with different points of view, about this at: > https://issues.apache.org/ooo/show_bug.cgi?id=114430 > but in short: > - Obviously, 0 ^ 0 is an illegal operation in mathematics and the result > is undefined/invalid > - In 3.4.1, "=0 ^ 0" returns 1 > - In 4.0, as patched by Pedro (see issue), "=0 ^ 0" would return an error > - According to ODF, valid results are 0, 1, error > - We gain interoperability since Excel returns an error too > - We lose backwards compatibility if someone was relying on the fact > that OpenOffice returns 1 as the result of "=0 ^ 0" > > I'm OK with the proposed change, provided we advertise it in the release > notes. I'm not aware of any cases where someone is actively using the > fact that in Calc 0 ^ 0 evaluates to 1, and even if someone did, I would > say that his spreadsheets should not compute 0 ^ 0 at all. It allows you to design a generic table of value in some cases, without the need to use always case distinction. A side > benefit would be that school students quickly wanting to find out what > is the result of 0 ^ 0 would be told the truth (it's an error) instead > of being presented with a numeric result and no warnings. (Then the > student would go on and write "= - 2 ^ 2" and have a lot of fun, but > this is out of scope here). The question is, whether "0^0=1" is more useful than "0^0=undefined". > > Is there consensus that this is a reasonable backwards-incompatible > change, or compelling reasons to revert it? There is no consensus. Kind regards Regina
