Hi,
I reply to this mail, because I have some remarks to Andrea's statements
(see below). But please excuse, if I (as german) perhaps use not always
the right english words/expressions/definitions.)
But first:
Norbert Thibaud has cleared the mathematical questions and shown, that
statements like Petros "0^0 = 1 is NOT mathematically correct." are
meaningless.
0^0 is a "shortcut" or "symbol" for something meaningfull in special
cases or models.
Mathematic is a set of theories that has (at least) 2 great sectors:
Theoretical/pure mathematics and applied mathematics which are different
in methodology.
"Pure" models or theories are based on axioms and definitions. Axioms
must be "complete" and not "contradictory" but are otherwise "free".
Definitions have to be reasonable (and helpfull). Statements/proofs (if
derived correctly out of the axioms) are "true" only in the respective
model. In other models they make no sense.
As the definition of 0^0 = 1 is _not_ wrong and not unreasonable (false
is a wrong category in this case), for me the problems reduces to:
Are there more (and "heavier") advantages than disadvantages when
changing the behaviour in Calc?
The whole line of OOo-versions (I have tested also with StarOffice 7 and
8, if necessary I can also test with V5.2 but I think it's not worth the
time to install etc.) defines 0^0=1. So generations of Calc-Spreadsheets
rely on this even if only a very few may explicitly use this features.
On the other side only one advantage was cited: The compatibilty with
Excel. For me, the backward-compatibility is worth more. (See also my
comment to 5) below.)
Am 13.02.2013 01:00, schrieb Andrea Pescetti:
Dennis E. Hamilton wrote:
The objective is to achieve consensus. I believe it is clear that
there is
no consensus on the proposed change and the proposal fails.
I still have to see some credible arguments here, since most of the
feedback was misplaced. What we learned so far is:
1) Nobody so far exhibited a spreadsheet that would be broken by the new
behavior. Rob has one, which was even published, so I'm sure he can
and Norbert has given another Example where the old definition allows to
model the correct mathematical behaviour for x^y. And you forget the
many generations of older spreadsheets.
share it for everybody to have a look. Even better, we have a fantastic
collection of Calc templates at
http://templates.openoffice.org/en/taxonomy/term/3923 ; seeing one of
those templates break would help.
2) Everybody feels the need to say something about 0 ^ 0, but threads
like this one are not pleasant to read. If you have nothing to say,
please don't say anything. And if you have a lot to say, please limit
yourself to what's strictly needed. Especially, undoing a volunteer's
work without some concrete (in ODF format, in this case!) reasons is
something the project must avoid.
Generally I agree with "must avoid". But I did not see a discussion, if
this change shouldt be done.
3) Mathematics and the standards are two different worlds. If a standard
is mathematically wrong, change the standard and come back.
That is false: The standard is mathematically correct.
4) We implement a standard, ODF. There 0 ^ 0 can legitimately be
evaluated to 0, 1 or an error.
5) We read another standard, OOXML. There 0 ^ 0 can only be evaluated as
an error; the fact that OpenOffice will evaluate 0 ^ 0 from a XLSX file
to 1 is a bug.
This is false: It is no bug!
If Excel were the standard it would be true. And if, then calc must also
implement the leap-year bug. (And I think nobody would want to implement
such an error.)
But true is, that Calc now is not Excel-compatibel in this case which
leads to the core-question "backwards-comp. vs. Excel comp.".
6) Anyone whose spreadsheets depend on 0 ^ 0 being evaluated to 1 (or to
zero, or to an error for that matter) has entered the dangerous world of
"implementation-defined" behavior: even if you save in a standard format
I'm a little bit confused. Everthing in applications is
"implementation-defined" what else?
like ODF, your spreadsheet depends on a particular ODF implementation
(e.g., on the specific version of OpenOffice you used).
Also the change would be "implementation-defined" and the behaviour
would shurely depend on the OOo-Version used.
Based on 5 and 6 I would actually still believe that it's good to
evaluate 0 ^ 0 to error (so that we fix the bug in 5 and we choose the
most strict behavior in 6). But I fully agree with Marcus in saying this
issue is much smaller than the discussion around it, so I can surely
change my opinion if I finally see some real-world spreadsheets impacted
by the change. When we have those, also Pedro will likely see reasons
for reverting the change. In short: provide concrete examples and
everybody will be happy.
Making controverse changes against many good reasons if not somebody
else proves that it is negative, is no good collaboration.
I understand, that Pedro will be frustrated, if his patch is reverted,
especially if it was much work. But perhaps he can understand, that his
math-argument was not valid and that other reasons speak for backw.-comp.
And perhaps in the future it would be better to discuss incompatibility
issues before anybody begins to code.
Regards,
Andrea.
--
Grüße
Günter Marxen
