openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: Solving this 0⁰ issue correctly (was Re: Calc behavior: result of 0 ^ 0)
Date Wed, 20 Feb 2013 14:54:52 GMT
I guess I shouldn't be surprised that this thread keeps reappearing
in my inbox ;).

----- Messaggio originale -----
> Da: Andrea Pescetti 
>>>  what the result of the power function in edge cases should be.
>>  So let me suggest a solution ... this really needs to be a per-document
>>  setting. ...
>>  3) If we make it a runtime setting --- all legacy documents in ODF
>>  format are evaluated according to the legacy mode.  So no
>>  compatibility break.   Users have a choice for mode for all new
>>  documents.  All Excel format documents by default are in
>>  Excel-compatibility mode.
> This seems the only solution where we could have consensus. It is a non-trivial 
> enhancement but it has advantages.

It is certainly not impossible but my experience with people changing colors
of bikeshed is that:

1) there must be some default value, which will lead to yet another
bikeshed color dispute.
2) No one will do anything about it because they lack the skills or
they never wanted the change done at all.

I am pretty sure the result will be (2).

>>>  Are you really suggesting to ship AOO on FreeBSD with different 
> behavior
>>>  then on eg Windows? ... Please don't do that.
> Yes, this should be avoided if possible. Let's try to avoid inconsistencies 
> across operating systems.

In this case there is actually no inconsistency as AOO has no
control over what pow() does. Technically the behaviour has always
been system dependent

There is a long history of patches for bugzilla issues that OOo was
very slow to adopt. The fact that distributions can now use
a very different Python version already induces much more

Oh, and python is a good example on how breaking backwards
compatibility is not a valid reason for a veto. I am of the opinion
that introducing python3 as the internal python would cause
too much trouble now to existing users (LO has less such users), but
the real reason why the change hasn't been made is not a veto:
people asked for it but no one has offered the work required in the
python module (and the MacOSX port).



View raw message