On 1/1/13 10:52 PM, Pedro Giffuni wrote: > 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.
I simply would like to propose that we make use of our new automated test framework and introduce new tests for the functions where we change the implementation. If we found bugs in the old existing implementations we should adapt the tests to reflect the correct behaviour and correct results and should add a note in the release notes to make our users aware of the fix that can produce new unexpected I (but correct results). Having these kind of automated tests for all functions would be a huge improvement to ensure the quality of calc. And it would help to tweak, improve the implementation in the future. It should be a nice task to get started and make good progress quite fast (which is always motivating) Juergen > > Pedro. >
