On Wed, Feb 20, 2013 at 9:54 AM, Pedro Giffuni <p...@apache.org> wrote: > 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 >
I don't believe this is true. ANSI C, C99, ISO C++ all require that pow(x,0) return 1 for all values of x. This is also a POSIX requirement. ODF 1.2 permits other values, but to the extent we use the standard C library's pow() function we should be consistent on all platforms, to the extent their C runtime is conforming. -Rob > 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 > inconsistencies. > > 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). > > cheers, > > Pedro. >
