On 2/18/13 1:15 AM, 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 don't think that this new define is a clean and good approach to move forward. I would prefer to introduce a further power function that behaves like Excel. The import filter should be changed to use the new one in the future. The export will revert this. When I remember it correctly there is already some mode for this. > > 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. sure and I believe there is a better way for this specific case by introducing a further power function as described above. > > 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. please don't move on this level. I am sure sure we don't really want a different behaviour on different platforms. Our users would be completely confused and nobody would understand what's happened. > > 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 > > You get the idea. Doing this is rather ugly but I can live with it as > at least windows and MacOSX have the option to use Excel if they > want to be serious about math. yes I get your idea and don't like it because I think it gives the completely wrong impression. I believe that majority now want the old behaviour and if we want support for the excel behaviour we have to discuss and to find a new approach. > > 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). again if you prefer to go your own way here for one platform I believe it is the completely wrong way and you potentially damage much more with such a direction. > > 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. +1, it 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 am personally strongly against this, we are not in a play school. Rob had made a mistake and he apologized for this already. If the patch gets reworked and the behaviour is as before without this ugly define option we can talk about it. Otherwise I would recommend to let is as it is now and seek a solution first. We can discuss the ifdef or configure option in another thread but I personally don't like both and believe it's the wrong way. > > > 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. > sorry Petro, I very much appreciate what you are doing but you are a big part of this so called circus from my pov. Really clever would have been to revert the patch immediately on your own, show understanding for the concerns and move into further discussion. Or better not integrate the patch at all because there were already concerns when I get it correct. Juergen > Pedro. > > [1] http://people.apache.org/~pfg/patches/patch-power00 >
