Problems with BESSELJ

[Regina Henschel]

Hi all,

looking at issue http://www.openoffice.org/issues/show_bug.cgi?id=40309 
I get some problems:

The algorithm, which is used for x<=30 is not good. The results become
invalid for larger order and for larger x.  I guess that this was the
reason to switch to the asymptotic formula for x>30. But this formula
has the precondition that x is much larger than order^2. My tests show,
that for c significant digits, you need x > order^2*13^c (estimation).

Searching around I come across an iterative solution from Peter
Deuflhard [1] (German). My tests as Basic macro results in an accuracy
of at least 12 digits. But it needs approximately order+x*1.1+30 iterations.
[1] http://www.mathematik.uni-dortmund.de/ieem/BzMU/BzMU2007/Deuflhard.pdf

So the question is, how much iterations are acceptable?

For example BESSELJ(3000;200) results in -7,79235815417491E-003 with the
current implementation with asymptotic formula, but the true value is
-1.186524260848996e-2. Gnumeric results -1.186524260848841E-002, my
Basic version of Deuflhard's algorithm results -1,18652426084901E-002.
But calculating this needs 3147 iterations. For order 200 you would need
x>520000 to result in at least 1 digit accuracy with the asymptotic formula.

Second problem: The current implementation restricts the order to
integer values. In mathematic the order need not to be integer. ODF1.2
also allows non-integer order. Are there plans to implement a solution
in OOo with non-integer orders? I personally have no idea how to do it.

So the question is, shall I implement Deuflhard's algorithm nevertheless?

Perhaps warn the user in the help, that large input values results in
long lasting calculations? Or return an error, if neither asymptotic
formula results at least 2 digits (How tell the user, that the result is
not accurate?) nor Deuflhard's algorithm calculates in reasonable time
(where to cut?)?

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Regina,

On Sunday, 2009-06-28 20:20:17 +0200, Regina Henschel wrote:

> Searching around I come across an iterative solution from Peter  
> Deuflhard [1] (German). My tests as Basic macro results in an accuracy  
> of at least 12 digits. But it needs approximately order+x*1.1+30
> iterations.
> [1] http://www.mathematik.uni-dortmund.de/ieem/BzMU/BzMU2007/Deuflhard.pdf
>
> So the question is, how much iterations are acceptable?

Depends of course on the cost per iteration. Hard to say. How much time
is a user willing to wait for an accurate result? Which still doesn't
say anything about a series of values to be calculated. But, since
a non-accurate solution wouldn't help much, I guess having to wait
a little isn't too much.. so I just throw a number and say 10000. Does
that help anything?

> For example BESSELJ(3000;200) results in -7,79235815417491E-003 with the  
> current implementation with asymptotic formula, but the true value is  
> -1.186524260848996e-2. Gnumeric results -1.186524260848841E-002, my  
> Basic version of Deuflhard's algorithm results -1,18652426084901E-002.  
> But calculating this needs 3147 iterations. For order 200 you would need  
> x>520000 to result in at least 1 digit accuracy with the asymptotic
> formula.

> Second problem: The current implementation restricts the order to  
> integer values. In mathematic the order need not to be integer. ODF1.2  
> also allows non-integer order. Are there plans to implement a solution  
> in OOo with non-integer orders? I personally have no idea how to do it.

No plans. Is there any practical benefit in calculating non-integer
orders? Does any spreadsheet application do it?

> So the question is, shall I implement Deuflhard's algorithm nevertheless?
>
> Perhaps warn the user in the help, that large input values results in  
> long lasting calculations?

What is "large" and what is "long lasting"?

> Or return an error, if neither asymptotic  
> formula results at least 2 digits (How tell the user, that the result is  
> not accurate?)

A few functions set errNoConvergence if a function can't determine
a result.

> nor Deuflhard's algorithm calculates in reasonable time  
> (where to cut?)?

"reasonable time" depends on user perspective and intention. I don't
think there is a general reasonable timeout.

Btw, newer g++ compilers (>= 4.3) have some bessel functions built-in,
as part of the TR1 extensions, see
http://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1, it appears that
MSVC does not have them though. Also the Boost library provides bessel
functions, I don't know off-hand which library version introduced them
and if it is in the one OOo uses. Maybe time to finally upgrade ;-)

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Regina Henschel]

Hi Eike,

Eike Rathke schrieb:

> Hi Regina,
>
> On Sunday, 2009-06-28 20:20:17 +0200, Regina Henschel wrote:
>
>> Searching around I come across an iterative solution from Peter  
>> Deuflhard [1] (German). My tests as Basic macro results in an accuracy  
>> of at least 12 digits. But it needs approximately order+x*1.1+30
>> iterations.
>> [1] http://www.mathematik.uni-dortmund.de/ieem/BzMU/BzMU2007/Deuflhard.pdf
>>
>> So the question is, how much iterations are acceptable?
>
> Depends of course on the cost per iteration. Hard to say. How much time
> is a user willing to wait for an accurate result? Which still doesn't
> say anything about a series of values to be calculated. But, since
> a non-accurate solution wouldn't help much, I guess having to wait
> a little isn't too much.. so I just throw a number and say 10000. Does
> that help anything?

With 10000 iterations you get convergence for x<6000 - might be x<10000
- depending on order N. When I calculate the asymptotic formula with
MuPad in high precision, then I get only 2 to 3 (estimated in the mean)
accurate digits even for x>200*N^2. From point of accuracy this
asymptotic formula is unusable.

>
>> For example BESSELJ(3000;200) results in -7,79235815417491E-003 with the  
>> current implementation with asymptotic formula, but the true value is  
>> -1.186524260848996e-2. Gnumeric results -1.186524260848841E-002, my  
>> Basic version of Deuflhard's algorithm results -1,18652426084901E-002.  
>> But calculating this needs 3147 iterations. For order 200 you would need  
>> x>520000 to result in at least 1 digit accuracy with the asymptotic
>> formula.
>
>> Second problem: The current implementation restricts the order to  
>> integer values. In mathematic the order need not to be integer. ODF1.2  
>> also allows non-integer order. Are there plans to implement a solution  
>> in OOo with non-integer orders? I personally have no idea how to do it.
>
> No plans. Is there any practical benefit in calculating non-integer
> orders?

I don't know. The Bessel-functions are used in technical tasks. I also
don't know, which ranges are really necessary for x and for order N.

  Does any spreadsheet application do it?
Excel rounds down to integer. The comment in ODF spec 16.15.11 says that
Gnumeric allow fractional N, but my Gnumeric 1.6.3 rounds down too. In
the comment Kspread is said to allow fractional N, but I haven't got
that program.

>
>> So the question is, shall I implement Deuflhard's algorithm nevertheless?
>>
>> Perhaps warn the user in the help, that large input values results in  
>> long lasting calculations?
>
> What is "large" and what is "long lasting"?

I would have to implement it in C++ to see how long it really lasts. The
Basic macro lasts several seconds for x>10000. The effort is linear in x.

>
>> Or return an error, if neither asymptotic  
>> formula results at least 2 digits (How tell the user, that the result is  
>> not accurate?)
>
> A few functions set errNoConvergence if a function can't determine
> a result.

That would be better than returning a result, which has no correct
digit, as the current solution does.

>
>> nor Deuflhard's algorithm calculates in reasonable time  
>> (where to cut?)?
>
> "reasonable time" depends on user perspective and intention. I don't
> think there is a general reasonable timeout.

So I would prefer to implement an iterative solution and drop the
inaccurate asymptotic part. The algorithm should converge, but I
hesitate to use a while-loop without any cut. I need to test, for which
x I can get a result in 1 second. Of cause the help should warn the user
about high x-values. The asymptotic formula can be mentioned in the help
in Wiki. It is not long and the user can write it directly as
spreadsheet formula, if he needs huge x-values. That way he is aware of
the accuracy problem.

>
> Btw, newer g++ compilers (>= 4.3) have some bessel functions built-in,
> as part of the TR1 extensions, see
> http://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1, it appears that
> MSVC does not have them though.

The MSVC Express edition has not any of that functions.

  Also the Boost library provides bessel
> functions, I don't know off-hand which library version introduced them
> and if it is in the one OOo uses. Maybe time to finally upgrade ;-)

You are right to remember me to Boost, I have overlooked it. I had a
look at Boost now. The Bessel functions (and a lot of others) are
included in library "Math Toolkit" since version 1.35.0. I see version
1.34.0 in OOo. There is a description in
http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/bessel/bessel.html.


Having an actual version of the Boost library would solve a lot of other
accuracy problems too. I would prefer upgrading Boost library. When can
the upgrade be done? Using it then would mean to rewrite most of
interpr3, interpr6 and analysis part of scaddin, which might take a
while. I guess rewrite can be done step by step. In the long run we need
no longer to struggle with accuracy of special functions and get free
time for fixing other issues.

Nevertheless, I can provide a patch with the Deuflhard algorithm likely
in time for OOo3.2 when give me a "go".

BTW, I still need a decision on the UI name of the left tailed
F-distribution to finish that work. I have FDISTL in mind.

kind regards
Regina





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Regina,

On Tuesday, 2009-06-30 23:34:27 +0200, Regina Henschel wrote:

> Excel rounds down to integer. The comment in ODF spec 16.15.11 says that  
> Gnumeric allow fractional N, but my Gnumeric 1.6.3 rounds down too. In  
> the comment Kspread is said to allow fractional N, but I haven't got  
> that program.

Just tried with KSpread 2.0rc1, it returns an error for fractional N.

>> What is "large" and what is "long lasting"?
>
> I would have to implement it in C++ to see how long it really lasts. The  
> Basic macro lasts several seconds for x>10000. The effort is linear in x.

Basic of course is some orders of magnitude slower than C++.

> You are right to remember me to Boost, I have overlooked it. I had a  
> look at Boost now. The Bessel functions (and a lot of others) are  
> included in library "Math Toolkit" since version 1.35.0. I see version  
> 1.34.0 in OOo. There is a description in  
> http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/bessel/bessel.html.
>
>
>
> Having an actual version of the Boost library would solve a lot of other  
> accuracy problems too. I would prefer upgrading Boost library.

Seems really the best option.

> When can the upgrade be done?

Don't know. I don't have time for it until OOo3.2, I'll try to ping
Thorsten to see if he's willing, he already did the upgrade to 1.34;
I just know he'll be on vaction soon, so it would take its time anyway.

> Nevertheless, I can provide a patch with the Deuflhard algorithm likely  
> in time for OOo3.2 when give me a "go".

Yes, of course, that would be nice.

> BTW, I still need a decision on the UI name of the left tailed  
> F-distribution to finish that work. I have FDISTL in mind.

Ah, I thought we already agreed on that, yes, I think FDISTL is fine.

Thanks
  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Regina Henschel]

Hi Eike,

Eike Rathke schrieb:
> Hi Regina,
>
> On Tuesday, 2009-06-30 23:34:27 +0200, Regina Henschel wrote:

>>> What is "large" and what is "long lasting"?
>> I would have to implement it in C++ to see how long it really lasts. The  
>> Basic macro lasts several seconds for x>10000. The effort is linear in x.
>
> Basic of course is some orders of magnitude slower than C++.

I have attached a draft patch to issue 40309. You can use it to test the
performance. On my PC a single calculation with x=5000000 lasts about 1
second.

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Regina Henschel]

Hi Eike,

Eike Rathke schrieb:
> Hi Regina,
>
> On Sunday, 2009-06-28 20:20:17 +0200, Regina Henschel wrote:

>> Or return an error, if neither asymptotic  
>> formula results at least 2 digits (How tell the user, that the result is  
>> not accurate?)
>
> A few functions set errNoConvergence if a function can't determine
> a result.

I cannot find such an exception, I only find
throw CSS::lang::IllegalArgumentException()
and
throw CSS::uno::RuntimeException()

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Regina,

On Saturday, 2009-07-04 23:44:36 +0200, Regina Henschel wrote:

> I have attached a draft patch to issue 40309. You can use it to test the  
> performance.

Unfortunately I currently have no time to test things.

> On my PC a single calculation with x=5000000 lasts about 1  
> second.

To identify whether performance would hurt it would be good to have some
real world usage examples of BESSELJ. Without, 5000000 is just a number
as any other, and for smaller values it would be faster ;-)  I tend to
integrate your work and see if anyone complains.. the old implementation
isn't as accurate as it should be.

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Eike Rathke]

Hi Regina,

On Saturday, 2009-07-04 23:52:18 +0200, Regina Henschel wrote:

>>> Or return an error, if neither asymptotic  formula results at least 2
>>> digits (How tell the user, that the result is  not accurate?)
>>
>> A few functions set errNoConvergence if a function can't determine
>> a result.
>
> I cannot find such an exception, I only find
> throw CSS::lang::IllegalArgumentException()
> and
> throw CSS::uno::RuntimeException()

Argh, I forgot those are Add-In functions. Bah, other exceptions aren't
allowed. Well, use IllegalArgumentException() then. The other
possibility would be to move the code into the core, where
SetError(errNoConvergence) would be possible, but that would pull in
a whole string of changes for the Excel export.

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Daniel Rentz]

Eike Rathke schrieb:

> Hi Regina,
>
> On Saturday, 2009-07-04 23:52:18 +0200, Regina Henschel wrote:
>
>>>> Or return an error, if neither asymptotic  formula results at least 2
>>>> digits (How tell the user, that the result is  not accurate?)
>>> A few functions set errNoConvergence if a function can't determine
>>> a result.
>> I cannot find such an exception, I only find
>> throw CSS::lang::IllegalArgumentException()
>> and
>> throw CSS::uno::RuntimeException()
>
> Argh, I forgot those are Add-In functions. Bah, other exceptions aren't
> allowed. Well, use IllegalArgumentException() then. The other
> possibility would be to move the code into the core, where
> SetError(errNoConvergence) would be possible, but that would pull in
> a whole string of changes for the Excel export.

Well. Don't know if there are any preparations to export a built-in
function as add-in. Maybe I did something for EUROCONVERT that is
useful. Import needs to be changed too. Anyway, I would volunteer to do
these changes. :)

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Daniel,

On Wednesday, 2009-07-08 18:37:59 +0200, Daniel Rentz wrote:

>> Argh, I forgot those are Add-In functions. Bah, other exceptions aren't
>> allowed. Well, use IllegalArgumentException() then. The other
>> possibility would be to move the code into the core, where
>> SetError(errNoConvergence) would be possible, but that would pull in
>> a whole string of changes for the Excel export.
>
> Well. Don't know if there are any preparations to export a built-in  
> function as add-in. Maybe I did something for EUROCONVERT that is  
> useful.

Indeed, you did at least tell Lvyue how to do it ;-)
http://www.openoffice.org/issues/show_bug.cgi?id=93789

> Import needs to be changed too. Anyway, I would volunteer to do  
> these changes. :)

Great! When done, can you please describe the necessary steps in the
wiki? Probably best as a separate subpage under
http://wiki.services.openoffice.org/wiki/Calc/Implementation/

Thanks
  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Eike Rathke]

Hi Daniel,

On Wednesday, 2009-07-08 18:37:59 +0200, Daniel Rentz wrote:

> Anyway, I would volunteer to do these changes. :)

Roll back! ;-)

That would complicate things even further because the addin.Analysis
name is used in API calls, moving implementation to the core would make
it necessary to compensate for in the compiler.

As the Add-In interfaces are not exported, the easiest solution would be
to introduce a new exception, let's say NoConvergenceException, and set
errNoConvergence accordingly in ScUnoAddInCall::ExecuteCallWithArgs().

Regina, do you need help with that?

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Regina Henschel]

Hi Eike,

Eike Rathke schrieb:

> Hi Daniel,
>
> On Wednesday, 2009-07-08 18:37:59 +0200, Daniel Rentz wrote:
>
>> Anyway, I would volunteer to do these changes. :)
>
> Roll back! ;-)
>
> That would complicate things even further because the addin.Analysis
> name is used in API calls, moving implementation to the core would make
> it necessary to compensate for in the compiler.
>
> As the Add-In interfaces are not exported, the easiest solution would be
> to introduce a new exception, let's say NoConvergenceException, and set
> errNoConvergence accordingly in ScUnoAddInCall::ExecuteCallWithArgs().
>
> Regina, do you need help with that?

Yes, I need a lot of help with that.

(1) How do I "introduce a new exception"?


(2) I have tried the following too. Instead of my provisional
        return 888.88;
I write
        throw ::com::sun::star::uno::RuntimeException();
Now the spreadsheet shows
        #VALUE!
in cell and
        Error: Wrong data type
in status bar in that cases.

But it shows this, whatever I write in
ScUnoAddInCall::ExecuteCallWithArgs(). I have tried it there with

         catch(uno::RuntimeException&)
         {
               nErrCode = errNoConvergence;
         }

and (only for testing) with

         catch(uno::Exception&)
         {
//            nErrCode = errNoValue;
             nErrCode = errDivisionByZero;
         }

Where comes the #VALUE! from?

(3) I have tried to use the Message of the exception. But there I fail
already in the syntax.

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Niklas Nebel]

On 07/09/09 12:17, Regina Henschel wrote:

> (2) I have tried the following too. Instead of my provisional
>     return 888.88;
> I write
>     throw ::com::sun::star::uno::RuntimeException();
> Now the spreadsheet shows
>     #VALUE!
> in cell and
>     Error: Wrong data type
> in status bar in that cases.
>
> But it shows this, whatever I write in
> ScUnoAddInCall::ExecuteCallWithArgs(). I have tried it there with
>
>         catch(uno::RuntimeException&)
>         {
>               nErrCode = errNoConvergence;
>         }
>
> and (only for testing) with
>
>         catch(uno::Exception&)
>         {
> //            nErrCode = errNoValue;
>             nErrCode = errDivisionByZero;
>         }
>
> Where comes the #VALUE! from?

XIdlMethod::invoke wraps exceptions from the add-in in an
InvocationTargetException. You have to extend the handling of that one.

Niklas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Regina,

On Thursday, 2009-07-09 12:17:43 +0200, Regina Henschel wrote:

> (1) How do I "introduce a new exception"?

The attached (hopefully not stripped by the mailing list software) patch
adds the ::com::sun::star::sheet::NoConvergenceException to the offapi
module. After having applied the patch, build and deliver the offapi
module, then build and deliver the offuh module that creates the C++
header files.

In scaddins' bessel.hxx add

#include <com/sun/star/sheet/NoConvergenceException.hpp>

and add ::com::sun::star::sheet::NoConvergenceException to the Bessel*()
functions' throw lists.

As in the analsis.* files the declarations use macros, for consistency
in analysisdefs.hxx add

#define THROWDEF_RTE_IAE_NCE throw(CSS::uno::RuntimeException,CSS::lang::IllegalArgumentException,CSS::sheet::NoConvergenceException)

and in analysis.hxx change THROWDEF_RTE_IAE to THROWDEF_RTE_IAE_NCE for
all getBessel*() functions, same in analysis.cxx

In bessel.hxx add ::com::sun::star::sheet::NoConvergenceException to the
throw lists of all Bessel*() functions.

In bessel.cxx add

using ::com::sun::star::sheet::NoConvergenceException;

and NoConvergenceException to the Bessel*() functions' throw lists.

If I didn't forget anything that should do.


> (2) ScUnoAddInCall::ExecuteCallWithArgs()

See also Niklas' reply. Adding a condition

            else if ( rWrapped.TargetException.getValueType().equals(
                    getCppuType( (sheet::NoConvergenceException*)0 ) ) )
                nErrCode = errNoConvergence;

to the

        catch(reflection::InvocationTargetException& rWrapped)

block should do. Of course you'll also need to add

#include <com/sun/star/sheet/NoConvergenceException.hpp>

to the file.


> (3) I have tried to use the Message of the exception. But there I fail  
> already in the syntax.

The original exception's Message should be available as
rWrapped.TargetException.Message

Hope that helps,

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

diff -Npu DEV300/offapi/com/sun/star/sheet/makefile.mk offapi/com/sun/star/sheet/makefile.mk
--- DEV300/offapi/com/sun/star/sheet/makefile.mk 2009-04-28 22:02:10.000000000 +0200
+++ offapi/com/sun/star/sheet/makefile.mk 2009-07-09 13:35:27.000000000 +0200
@@ -166,6 +166,7 @@ IDLFILES=\
  NamedRangeFlag.idl\
  NamedRanges.idl\
  NamedRangesEnumeration.idl\
+ NoConvergenceException.idl\
  PasteOperation.idl\
  RangeSelectionArguments.idl\
  RangeSelectionEvent.idl\
diff -Npu DEV300/offapi/com/sun/star/sheet/NoConvergenceException.idl offapi/com/sun/star/sheet/NoConvergenceException.idl
--- DEV300/offapi/com/sun/star/sheet/NoConvergenceException.idl 1970-01-01 01:00:00.000000000 +0100
+++ offapi/com/sun/star/sheet/NoConvergenceException.idl 2009-07-09 13:34:35.000000000 +0200
@@ -0,0 +1,54 @@
+/*************************************************************************
+ *
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * Copyright 2008 by Sun Microsystems, Inc.
+ *
+ * OpenOffice.org - a multi-platform office productivity suite
+ *
+ * This file is part of OpenOffice.org.
+ *
+ * OpenOffice.org is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License version 3
+ * only, as published by the Free Software Foundation.
+ *
+ * OpenOffice.org is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License version 3 for more details
+ * (a copy is included in the LICENSE file that accompanied this code).
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * version 3 along with OpenOffice.org.  If not, see
+ * <http://www.openoffice.org/license.html>
+ * for a copy of the LGPLv3 License.
+ *
+ ************************************************************************/
+
+#ifndef __com_sun_star_sheet_NoConvergenceException_idl__
+#define __com_sun_star_sheet_NoConvergenceException_idl__
+
+#ifndef __com_sun_star_uno_Exception_idl__
+#include <com/sun/star/uno/Exception.idl>
+#endif
+
+//=============================================================================
+
+module com { module sun { module star { module sheet {
+
+//=============================================================================
+
+/** Thrown by a Calc Add-In function this exception indicates the
+    function's algorithm did not converge to a meaningful result.
+
+    @since OOo 3.2
+ */
+exception NoConvergenceException : ::com::sun::star::uno::Exception
+{
+};
+
+//=============================================================================
+}; }; }; };
+//=============================================================================
+
+#endif

[Regina Henschel]

Hi Eike, hi Niklas,

Eike Rathke schrieb:
> Hi Regina,
>
> On Thursday, 2009-07-09 12:17:43 +0200, Regina Henschel wrote:
>
>> (1) How do I "introduce a new exception"?
>
> The attached (hopefully not stripped by the mailing list software)patch

I've received it.

> adds the ::com::sun::star::sheet::NoConvergenceException to the offapi
> module. After having applied the patch
[..]
It will take a while to do that all. Thank for your advise.

>> (2) ScUnoAddInCall::ExecuteCallWithArgs()
>
> See also Niklas' reply. Adding a condition
>
>             else if ( rWrapped.TargetException.getValueType().equals(
>                     getCppuType( (sheet::NoConvergenceException*)0 ) ) )
>                 nErrCode = errNoConvergence;
>
> to the
>
>         catch(reflection::InvocationTargetException& rWrapped)
>
> block should do.

I've tried Niklas' hint using 'RuntimeException' and got the desired
error message in the cell. :) So I think, that part will work.

>> (3) I have tried to use the Message of the exception. But there I fail  
>> already in the syntax.
>
> The original exception's Message should be available as
> rWrapped.TargetException.Message

I fail before that place. I do not no, how to write the throw command. A
simple

throw ::com::sun::star::uno::RuntimeException("Konvergenzfehler");

does not compile.

>
> Hope that helps,

I'm confident.

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Regina Henschel]

Hi Eike,

Eike Rathke schrieb:

> Hi Regina,
>
> On Thursday, 2009-07-09 12:17:43 +0200, Regina Henschel wrote:
>
>> (1) How do I "introduce a new exception"?
>
> The attached (hopefully not stripped by the mailing list software) patch
> adds the ::com::sun::star::sheet::NoConvergenceException to the offapi
> module. After having applied the patch, build and deliver the offapi
> module, then build and deliver the offuh module that creates the C++
> header files.

I could not apply the patch with TortoiseSVN automatically. I hope I got
it right, when applying it manually.

I've done all the changes. But I get a build error. Just to be sure, I
start then a build --all, but get the same error:

c:\softwarearchiv2\odff06\scaddins\source\analysis\analysis.hxx(149) :
error C2039: 'NoConvergenceException' : is not a member of
'com::sun::star::sheet'

and

c:\softwarearchiv2\odff06\scaddins\source\analysis\bessel.hxx(35) :
fatal error C1083: Cannot open include file:
'com/sun/star/sheet/NoConvergenceException.hpp': No such file or directory

I see the file NoConvergenceException.hpp in
C:\SoftwareArchiv2\odff06\solver\300\wntmsci12.pro\inc\offuh\com\sun\star\sheet
and in
C:\SoftwareArchiv2\odff06\offuh\wntmsci12.pro\inc\offuh\com\sun\star\sheet

What goes wrong here?

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Niklas Nebel]

Regina Henschel wrote:

> c:\softwarearchiv2\odff06\scaddins\source\analysis\bessel.hxx(35) :
> fatal error C1083: Cannot open include file:
> 'com/sun/star/sheet/NoConvergenceException.hpp': No such file or directory
>
> I see the file NoConvergenceException.hpp in
> C:\SoftwareArchiv2\odff06\solver\300\wntmsci12.pro\inc\offuh\com\sun\star\sheet
>
> and in
> C:\SoftwareArchiv2\odff06\offuh\wntmsci12.pro\inc\offuh\com\sun\star\sheet
>
> What goes wrong here?

The scaddins module doesn't use the headers from offuh, but creates its
own ones. This is done in part to bring it closer to being a pure UNO
component (it isn't really one because it depends on tools for the
resource files), and in part because it's needed for the own interfaces
anyway.

The list of types for which headers are made is in UNOTYPES in
makefile.mk. Just add the new one there.

Niklas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Regina Henschel]

Hi Niklas,

Niklas Nebel schrieb:

> Regina Henschel wrote:
>> c:\softwarearchiv2\odff06\scaddins\source\analysis\bessel.hxx(35) :
>> fatal error C1083: Cannot open include file:
>> 'com/sun/star/sheet/NoConvergenceException.hpp': No such file or
>> directory
>>
>> I see the file NoConvergenceException.hpp in
>> C:\SoftwareArchiv2\odff06\solver\300\wntmsci12.pro\inc\offuh\com\sun\star\sheet
>>
>> and in
>> C:\SoftwareArchiv2\odff06\offuh\wntmsci12.pro\inc\offuh\com\sun\star\sheet
>>
>>
>> What goes wrong here?
>
> The scaddins module doesn't use the headers from offuh, but creates its
> own ones. This is done in part to bring it closer to being a pure UNO
> component (it isn't really one because it depends on tools for the
> resource files), and in part because it's needed for the own interfaces
> anyway.
>
> The list of types for which headers are made is in UNOTYPES in
> makefile.mk. Just add the new one there.

Here?
/scaddins/source/analysis/makefile.mk

Shall I remove it from /offapi/com/sun/star/sheet/makefile.mk ?

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Niklas Nebel]

Regina Henschel wrote:
>> The list of types for which headers are made is in UNOTYPES in
>> makefile.mk. Just add the new one there.
>
> Here?
> /scaddins/source/analysis/makefile.mk

Yes.

> Shall I remove it from /offapi/com/sun/star/sheet/makefile.mk ?

No, that's needed, too, so it is put into the rdb file that's used to
generate the headers in scaddins.

Niklas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Regina,

On Thursday, 2009-07-09 15:47:06 +0200, Regina Henschel wrote:

>>> (3) I have tried to use the Message of the exception. But there I
>>> fail  already in the syntax.
>>
>> The original exception's Message should be available as
>> rWrapped.TargetException.Message
>
> I fail before that place. I do not no, how to write the throw command. A  
> simple
>
> throw ::com::sun::star::uno::RuntimeException("Konvergenzfehler");
>
> does not compile.

Ah, no, there's no automatic conversion from string literals to
OUString. For ASCII strings you may use the module's STRFROMASCII(s)
that is defined in analysisdefs.hxx, so
...Exception(STRFROMASCII("convergence error")) should do.

We'd prefer English messages, even if just for debugging/tracing
purposes ;-)

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.