Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni <pf...@apache.org>]

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.

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni <pf...@apache.org>]

Hi Juergen;


----- Messaggio originale -----
> Da: Jürgen Schmidt 
 ...
>>> 
>>>  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
> 

+1

It would be great to have some testing expert involved, and also some
documentation about how to add a new test.

This said, the testing framework is targeted for things that have
already been committed to the development tree, and before that
we should have already tested the correctness of the
implementation.

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Jürgen Schmidt <jo...@gmail.com>]

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