On Mon, Feb 18, 2013 at 3:58 AM, Andre Fischer <awf....@gmail.com> wrote: > On 18.02.2013 01:15, Pedro Giffuni wrote: >> >> Hello; >> >> >> Well, as you might imagine I am really tired of the flame storm that >> went around the 0 ^ 0 issue. My intention here is not at all to re-start >> that discussion. I really have much more fun things to do. >> I am actualy a fan of Clint Eastwood so let me remember one of >> my favorite movies ever. >> >> THE GOOD >> >> It didn't really take me long but I found a technical solution for the >> dilemma. >> >> - The numerical issues were caused by a copy-paste error where the >> C++ wrapper used int for the exponent instead of a double. Once >> found it was trivial to fix. >> >> - Considering the "vetos" I still think they are invalid but I think they >> both reflect a community concern so I have addressed it. >> >> The new patch [1] now defines in SAL's math.h the following: >> >> #define SAL_STRICTER_MATH >> >> >> This currently only affects the power function and acts as a >> sort of "excel compatibility" flag. This is very simple at this time >> but it fulfills it's task: you can easily change the behaviour >> during compile time. > > > I am sorry but I don't think this is a good idea because: > > - The SAL_STRICTER_MATH flag needs documentation as to what it shall > accomplish. > > - At the moment only the rtl_math_powr() function uses this flag so it looks > more like a quick fix then a general concept. > > - The value of the flag can not be set from the outside. You have to change > the source file in order to change it. Such a change can not be made by a > user and a developer has to know that a) the flag exists, b) has to locate > the file where to change it, c) read the code to understand the consequences > of doing so. > > > > I would suggest at least to make the flag overridable by the makefile via > some -DSAL_STRICTER_MATH=ON/OFF definition. > > Better make this a configuration switch. Yes, there are too many of these, > but we probably have even more unmaintained compile time switches. > > Even better, turn this into a switch that can be altered via Tools->Options > at runtime by the user. The user is ultimately the only person who knows > what the result of the power function in edge cases should be. >
I think this is a key observation. Working in an Excel-compatible mode versus an OpenOffice-backwards-compatible mode doesn't make sense as a build-time mode. That is not how the product is used. We don't have users who only access Excel documents and never access legacy OpenOffice, LibreOffice, Symphony or Calligra documents. And we don't have users who never access Excel documents. A user can access an Excel document and then 5 minutes later need to open an older OpenOffice document, and then after lunch need to edit an old Excel document. We're not improving things if we treat these preferences as hard-coded compile-time options. Also, the value of 0^0 is just one of 61 different implementation-defined values in OpenFormula, and not the most interesting one of them either. There are others that impact, to a greater degree, interop with MS Office. But I think we'd all agree that defining compile-time options for all 61 would be crazy. So let's not start down that road. So let me suggest a solution that I hope would gain a greater degree of consensus, based on the observation (which I owe to a comment Dennis made in Bugzilla) that this really needs to be a per-document setting. A full solution would look like this: 1) There are a bundle of formula-evaluation related behaviors that we treat together, as belonging to either "Excel-compatibility mode" or "legacy mode". The value of 0^0 would be one of these behaviors. 2) There would be a run-time mode that could be configured to evaluate a spreadsheet in one mode or the other. 3) When a new spreadsheet is created and saved as ODF we store the mode used to evaluate the document as document metadata. So when the document is read we know exactly the assumptions made to evaluate it. 4) Earlier versions of AOO/OOo and LibreOffice and Symphony will not understand this metadata, but this will improve over time as more people upgrade to AOO 4.0. We can also coordinate with LibreOffice and Calligra and maybe they would be interested in adopting a similar setting. 5) When a new spreadsheet is created it uses a user-defined mode of evaluation. By default in AOO 4.0 the mode would be "legacy mode". But this would be a user-settable in a dialog. In future versions of AOO, we can reconsider changing the default. It will be easier to transition this once the install base has moved over to versions of AOO that support "excel-compatibility mode". 6) When loading a Excel format document (XLS or XLSX) we automatically switch into excel-compatibility-mode, since that format is typically used to interop with Excel or with Excel-compatible applications. So more work, yes. But look at the different in interoperability. 1) Current situation in the code -- We're always in "legacy-mode", even when processing documents that come from Excel. This is true not only for 0^0, but a range of other calculation-related behaviors. So users today have some interop problems. 2) Pedro's solution only deals with 0^0 and does it with an undocumented, obscure compile time setting and breaks legacy compatibility in order to improve Excel compatibility. It is forcing users to choose -- do I install a backwards compatible version of AOO or an Excel-compatible version? It is using an axe where a scalpel is needed. 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. So I think option #3 is an all-around better solution that we should aim for. It is an open question whether such an approach can be extended to other areas beyond calculation modes, e.g., layout in Writer. Regards, -Rob > >> >> It is actually an advance because having this in SAL gives us control: >> our current behavior is platform dependent. >> >> THE UGLY >> >> The discussion so far has been centered around the default. I >> consider myself agnostic in this case: I think that it is better >> to use the stricter criteria and be compatible with MS Excel. >> A lot of people worry about compatibility issues. >> >> With my FreeBSD hat on, I think in the unsupported platforms >> (FreeBSD, OS2, Solaris) the compatibility issue isn't really a >> concern (the ASF has never provided officially binaries) but >> the Excel behaviour is useful for interoperability. >> >> I think the best option would be if existing users take a decision >> before release what behaviour the want and if the case is to revert >> we can add something like >> >> #if defined(WINOS) || defined(MACOSX) || defined(LINUX) >> #defined SAL_STRICTER_MATH >> #endif > > > I am not sure that the logic is right here. First you say that for FreeBSD, > OS2 and Solaris compatibility is not an issue and imply that using > "stricter" math on these platforms where OK. But then you define > SAL_STRICTER_MATH for Windows, MacOS and Linux. Which one is right? > > Besides, I hope that this code snipped will not go into a source file like > rtl/math.hxx. The SAL_STRICTER_MATH flag is technically not tied to any > platform. But a test like the one above would suggest that it does only run > on Windows, Mac, and Linux. > > > But the most important point is that with logic like this the choice of > using "stricter" math still has to be made when AOO is built, ie not by > users but by developers and ultimately by the release engineer. > > >> >> You get the idea. Doing this is rather ugly but I can live with it > > > I can not. > > >> as >> at least windows and MacOSX have the option to use Excel if they >> want to be serious about math. >> >> I guess we could add it as a configure option but we already have >> too many of them and even then there has to be a default. >> >> This is something I think the comunity has to decide on by voting >> before the release. I won't take the decision but since I take care >> for FreeBSD, I think we will opt for the Excel compatibility (I do >> have to consult with Maho though). > > > Are you really suggesting to ship AOO on FreeBSD with different behavior > then on eg Windows? > What good can come from that? Documents would not be compatible inside the > same application when moved from one platform to another. Please don't do > that. > > -Andre > > >> >> THE BAD >> >> (Please stop reading here if you are sensible to non-technical issues) >> >> First I should thank Greg Stein for clarifying the correct sense and reach >> of the veto. I also want to thank people that have expressed their support >> in private or public. It is clear to me that we are still too young as a >> community >> in AOO and that people still have a long way to learn in matters of >> behaviour. >> >> I am not as much disappointed by the discussion (which I think >> doesn't correspond to the impact of the patch) but by the fact that >> I was not given the chance to work on it and that I have been >> insulted in the process. >> >> I strongly complained when Dave's commit was reverted and I find >> it absolutely unacceptable in the way it was done with me. First >> of all the harassment: I am a volunteer, I am not here to receive >> something in the lines of "Revert now or else ...", and second the >> lack of respect for my work. >> >> It *is* rude, really ... I *don't* care much what happens with the patch, >> if it should be disabled or not, but I DO want respect. >> >> I think I deserve reparation for the commit reversal: this shouldn't have >> happened. I request the code be restated as it should have never been >> reverted in the first place. This is all symbolical as there is a new >> version. >> Once the new version is in, I will let anyone else decide if you guys >> want to ifdef it or add a configure option or whatever: I don't really >> want >> to be involved in this anymore. >> >> >> I also want an assurance that this will never *ever* happen again (I am >> talking about the revert, I guess bikesheds are unavoidable). >> >> If people really don't like my patches (yes, according to the Berne >> convention >> I do own them) I will take them with me but I prefer if there is a >> civilized >> discussion and not this circus we have been experiencing these last days. >> >> Pedro. >> >> [1] http://people.apache.org/~pfg/patches/patch-power00 > >
