openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: Incompatible changes in AOO 4.0 ?
Date Tue, 01 Jan 2013 21:52:49 GMT
Hi again;

----- Messaggio originale -----
> Da: Rob Weir 

> So there are two things here:
> 1) All the junk out to the 12th decimal place that might matter to a
> few people and which might be improved by moving to boost

I think this will indeed be improved by boost. Boost is really cool in
that it can promote automatically the number types if there is an
advantage when doing calculations

> 2) The edge stuff where we can very well break real world spreadsheets
> if we're not careful.
> This is not entirely about the 12th decimal place.  I was one of the
> co-authors of the OpenFormula specification used in ODF.  There is
> more there than just mathematical fact.  There are a lot of
> conventions, purely pragmatic conventions, involved in spreadsheet
> formulas, and we need to get those right as well.

Thanks to Regina's test spreadsheet I found that I had to change the default
boost policy for a simple reason: a scientist wants to know if there is an
overflow and is likely to want to stop all the calculations, a Calc user doesn't
really care too much and finds absolutely unacceptable to have the application
close when such thing happens.

Boost actually let's us control the math behavior very well.

> For example, take the POWER() function.  POWER(x;y) == x^y.   So what
> is POWER(0;0) ?   I'm sure boost returns something there.  But is it
> the same as AOO 3.4.1 returns?  And does it conform to OpenFormula?

I happen to have some memories of this specific case. Calc, like my
college HP calculator, erroneously sets the value to 1. Calculating
the limit, as we did in Calculus I, it can be proved the correct result is
infinite. This should be fixed in Calc.

OpenFormula is rather ambivalent: it says it is implementation dependent
and it can be 0, 1, or Infinite.

Boost has no opinion about it: Boost doesn't provide a replacement for this.

It is a perfectly valid point though, ee have to check those things function
by function.

> So before we attempt a brain transplant with the spreadsheet formulas,
> let's make sure we're all comfortable with the real-world risk this
> introduces and have a plan to find (and fix) the bugs this will
> inevitably introduce.  Of course, this is not a demand on you
> personally, but a challenge for the project overall.

Sure, we have to be careful. For good or for bad, boost doesn't provide
replacements for everything we do: I think basically the hyperbolic and
some power functions that are in my patch and the statistics functions.


View raw message