On Mon, Feb 18, 2013 at 12:26 AM, Jürgen Schmidt <jogischm...@gmail.com>wrote:
> 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. +1 on this suggestion... It seems to me that a user controlled option might work best in this case. > 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 > > > > -- ---------------------------------------------------------------------------------------- MzK "Achieving happiness requires the right combination of Zen and Zin."
