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.
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
