quantlib-dev Mailing List for QuantLib (Page 244)

Ok, I confirmed that on my 'Debain testing' laptop: The -pedantic switch
breaks building of RQuantLib, using the Jan 20 CVS snapshot of QL.

Kurt et al: Is that no-no which will prevent it from CRAN inclusion?

QLers: g++-2.95 breaks with -pedantic, g++-3.0 breaks outright (with
-mieee-fp -fPIC).  Ideas?   Those C++ classes make my head spin.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Sorry to pester all of you with this, but it looks as if I have some egg
on my face. The package doesn't seem to compile on the R CRAN archive
maintainer's machine ... with the exact same Debian setup as mine. The one
difference I can think of is that I do not export -pedantic and -Wall. 

Could that make the difference?  If so, could you make it work :->  ?

Dirk

----- Forwarded message from Kurt Hornik <Kur...@wu...> -----

Envelope-to: ed...@ed...
Delivery-date: Tue, 26 Feb 2002 01:20:38 -0600
From: Kurt Hornik <Kur...@wu...>
To: Dirk Eddelbuettel <ed...@de...>
Cc: cr...@r-...
Subject: Re: RQuantLib_0.1.0 in incoming
Reply-To: Kur...@wu...

>>>>> Dirk Eddelbuettel writes:

> I just uploaded RQuantLib into incoming/.

> RQuantLib is an R [ http://www.r-project.org ] package to access the powerful
> QuantLib [ http://quantlib.org ] libraries for quantitative finance.

> The packages passes the R CMD check and build steps on my Debian testing
> systems with libquantlib0 and libquantlib0-dev packages installed.

> RQuantLib is at an early stage: I only defined two basic classes Option and
> ImpliedVolatility with print and summary methods, and European and American
> options on top of them. Binary Options are also available for the option
> calculator.  I opted for (named) lists as input and output types. These
> functions are "scalar" and operate on one option at a time.

> One other cute function is EuropeanOptionArrays which allows for vectors of
> any of the numeric input variables, and returns an appropriate
> multidimensional array of all possible valuation combinations. The example()
> function plots a few combinations.

> The package, and well as a little more documentation, is also at

>     http://dirk.eddelbuettel.com/code/rquantlib.html

Dirk,

I have

hornik@mithrandir:~/src/R/share/perl/R$ dpkg -l "*quantlib*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libquantlib0   0.2.1cvs200201 Quantitative Finance Library -- development 
ii  libquantlib0-d 0.2.1cvs200201 Quantitative Finance Library -- library pack
pn  quantlib-pytho <none>         (no description available)
ii  quantlib-refma 0.2.1-1        Quantitative Finance Library -- reference ma
pn  quantlib-ruby  <none>         (no description available)

and get

hornik@mithrandir:~/tmp/CRAN$ R CMD check RQuantLib
* checking for working latex ... OK
* using log directory `/home/Hornik/tmp/CRAN/RQuantLib.Rcheck'

Installing *source* package `RQuantLib' ...
loading site script /usr/local/etc/config.site
creating cache ./config.cache
checking for quantlib-config... yes
checking for c++... c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking how to run the C++ preprocessor... c++ -E
updating cache ./config.cache
creating ./config.status
creating src/Makevars
Completed configuration and ready to build.
 libs
g++ -I/usr/lib/R/include  -I/usr/local/include -mieee-fp -I/usr/include -fPIC  -
g -O2 -Wall -pedantic -c RQuantLib.cc -o RQuantLib.o
In file included from /usr/include/ql/quantlib.hpp:228,
                 from RQuantLib.cc:25:
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator ++()':
/usr/include/ql/Utilities/combiningiterator.hpp:119: parse error before `='
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator --()':
/usr/include/ql/Utilities/combiningiterator.hpp:135: parse error before `='
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator +=(typename iterator_traits<_Iterator>::diff
erence_type)':
/usr/include/ql/Utilities/combiningiterator.hpp:152: parse error before `='
/usr/include/ql/Utilities/combiningiterator.hpp: In method `class QuantLib::Util
ities::combining_iterator<Iterator,Function> & QuantLib::Utilities::combining_it
erator<Iterator,Function>::operator -=(typename iterator_traits<_Iterator>::diff
erence_type)':
/usr/include/ql/Utilities/combiningiterator.hpp:160: parse error before `='
RQuantLib.cc: In function `struct SEXPREC * QL_EuropeanOption(SEXPREC *)':
RQuantLib.cc:79: warning: `enum QuantLib::Option::Type optionType' might be used
 uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_EuropeanOptionImpliedVolatility(S
EXPREC *)':
RQuantLib.cc:129: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_AmericanOption(SEXPREC *)':
RQuantLib.cc:171: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_AmericanOptionImpliedVolatility(S
EXPREC *)':
RQuantLib.cc:223: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
RQuantLib.cc: In function `struct SEXPREC * QL_BinaryOption(SEXPREC *)':
RQuantLib.cc:270: warning: `enum QuantLib::Option::Type optionType' might be use
d uninitialized in this function
make: *** [RQuantLib.o] Error 1
ERROR: compilation failed for package `RQuantLib'
 ERROR

???

----- End forwarded message -----

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Two more warnings:
1) impliedVol usually fails when the option's value is not attainable with 
any volatility value (e.g. a value less than the intrinsic value for an 
american option)
2) even if a root exists with binary options you're not guaranteed 
impliedVol will find it. This is because contracts with a gamma that 
changes sign have values that are not monotonic in the volatility.

I'm going to add these 2 warning to the Doxygen documentation

ciao -- Nando


At 09:48 AM 2/26/02 +0000, Luigi Ballabio wrote:
>At 09:25 PM 2/25/02 -0600, Dirk Eddelbuettel wrote:
>>Playing with binaries, I noticed that implied Vol calculations abort:
>>I don't understand why. Should somebody comment?
>
>Well, between you and me and the other developers, BinaryOption is _so_ 
>smart (not) that it caches its value and doesn't change it even though its 
>volatility is changed. Of course this makes it kind of difficult to solve 
>for its implied volatility...
>
>I'm going to fix it this morning. Thanks for the report.
>
>Bye,
>         Luigi
>
>
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

At 09:25 PM 2/25/02 -0600, Dirk Eddelbuettel wrote:
>Playing with binaries, I noticed that implied Vol calculations abort:
>I don't understand why. Should somebody comment?

Well, between you and me and the other developers, BinaryOption is _so_ 
smart (not) that it caches its value and doesn't change it even though its 
volatility is changed. Of course this makes it kind of difficult to solve 
for its implied volatility...

I'm going to fix it this morning. Thanks for the report.

Bye,
         Luigi

Playing with binaries, I noticed that implied Vol calculations abort:

edd@homebud:~/misc> cat binary_abrt.cc

#include <ql/quantlib.hpp>

int main(int argc, char* argv[])
{
  using namespace QuantLib;

  using QuantLib::Pricers::BinaryOption;

  try {
    double underlying = 102;
    double strike = 100;
    Spread dividendYield = 0.01;
    Rate riskFreeRate = 0.05;
    Time maturity = 1.0;
    double volatility = 0.60;
    BinaryOption BO = BinaryOption(Option::Call, underlying, strike,
                                   dividendYield, riskFreeRate, maturity,
                                   volatility);
    cout << "value is " << BO.value() << endl;
    double impliedVol = BO.impliedVolatility(1.1*BO.value());
    cout << "implied is " << impliedVol << endl;

  } catch (std::exception& e) {
    std::cout << e.what() << std::endl;

  } catch (...) {
    std::cout << "unknown error" << std::endl;
  }

  exit (0);
}
edd@homebud:~/misc> ./binary_abrt
value is 0.400098
root not bracketed: f[0.0001000000,4.0000000000] -> [0.20004910384016516556,0.20004910384016516556]

I don't understand why. Should somebody comment?

This is on Debian with the 0.3.0a5-20020120 packages.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Hello,

>>>>> In <200...@se...> 
>>>>>	LaMont Jones <la...@hp...> wrote:
> > It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
> > done in the Ruby development branch (Ruby 1.7.something) but not in 
> > the current release (or at least not the one in Woody. I don't know 
> > which version of Ruby you have in... wait, what was the name of the 
> > character now? Well, unstable anyway)
> > It also needs a minor fix in SWIG which has been done in CVS but 
> > wasn't released either.
> > 
> > The bottom line is, we're out in the cold :(
> > Architectures with gcc 3.0.x are ruled out for the time being.
>
> ruby_1.6.6-5 is in sid (which will always be unstable)
>
> Depending on how invasive the fix is, I suppose the ruby maintainer
> could port the fix back to ruby 1.6.6-5, and thereby fix all these
> ruby-dependants.  Akira?

I made a back-port-patch based on results of diffs between 2001-03-27
and 2001-05-03 on *.h, and I attach the patch in this mail. How do you
think about it?  If it is O.K., I will make a new deb-package. (and
will send it to Mr.Matz if it is better to do it by me.)

Thank you.
-- 
 akira yamada <URL:http://arika.org/ruby/>
 (ak...@ar..., ak...@ru... or ak...@li...)


Index: intern.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/intern.h,v
retrieving revision 1.35.2.16
diff -u -r1.35.2.16 intern.h
--- intern.h	13 Feb 2002 09:02:15 -0000	1.35.2.16
+++ intern.h	16 Feb 2002 04:42:15 -0000
@@ -95,13 +95,13 @@
 VALUE rb_class_protected_instance_methods _((int, VALUE*, VALUE));
 VALUE rb_class_private_instance_methods _((int, VALUE*, VALUE));
 VALUE rb_obj_singleton_methods _((VALUE));
-void rb_define_method_id _((VALUE, ID, VALUE (*)(), int));
+void rb_define_method_id _((VALUE, ID, VALUE (*)(ANYARGS), int));
 void rb_frozen_class_p _((VALUE));
 void rb_undef _((VALUE, ID));
-void rb_define_protected_method _((VALUE, const char*, VALUE (*)(), int));
-void rb_define_private_method _((VALUE, const char*, VALUE (*)(), int));
-void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_private_method _((VALUE,const char*,VALUE(*)(),int));
+void rb_define_protected_method _((VALUE, const char*, VALUE (*)(ANYARGS), int));
+void rb_define_private_method _((VALUE, const char*, VALUE (*)(ANYARGS), int));
+void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_private_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
 VALUE rb_singleton_class _((VALUE));
 /* enum.c */
 VALUE rb_enum_length _((VALUE));
@@ -167,13 +167,13 @@
 VALUE rb_thread_stop _((void));
 VALUE rb_thread_wakeup _((VALUE));
 VALUE rb_thread_run _((VALUE));
-VALUE rb_thread_create _((VALUE (*)(), void*));
+VALUE rb_thread_create _((VALUE (*)(ANYARGS), void*));
 int rb_thread_scope_shared_p _((void));
 void rb_thread_interrupt _((void));
 void rb_thread_trap_eval _((VALUE, int));
 void rb_thread_signal_raise _((char*));
-int rb_thread_select();
-void rb_thread_wait_for();
+int rb_thread_select(ANYARGS);
+void rb_thread_wait_for(ANYARGS);
 VALUE rb_thread_current _((void));
 VALUE rb_thread_main _((void));
 VALUE rb_thread_local_aref _((VALUE, ID));
@@ -347,7 +347,7 @@
 VALUE rb_struct_aset _((VALUE, VALUE, VALUE));
 VALUE rb_struct_getmember _((VALUE, ID));
 /* time.c */
-VALUE rb_time_new();
+VALUE rb_time_new(ANYARGS);
 /* variable.c */
 VALUE rb_mod_name _((VALUE));
 VALUE rb_class_path _((VALUE));
Index: node.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/node.h,v
retrieving revision 1.18.2.2
diff -u -r1.18.2.2 node.h
--- node.h	6 Apr 2001 05:42:40 -0000	1.18.2.2
+++ node.h	16 Feb 2002 04:43:03 -0000
@@ -131,7 +131,7 @@
 	struct RNode *node;
 	ID id;
 	VALUE value;
-	VALUE (*cfunc)();
+	VALUE (*cfunc)(ANYARGS);
 	ID *tbl;
     } u1;
     union {
@@ -340,7 +340,7 @@
 NODE *rb_compile_file _((const char*, VALUE, int));
 
 void rb_add_method _((VALUE, ID, NODE *, int));
-NODE *rb_node_newnode();
+NODE *rb_node_newnode(ANYARGS);
 
 struct global_entry *rb_global_entry _((ID));
 VALUE rb_gvar_get _((struct global_entry *));
Index: ruby.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/ruby.h,v
retrieving revision 1.29.2.10
diff -u -r1.29.2.10 ruby.h
--- ruby.h	25 Dec 2001 15:09:05 -0000	1.29.2.10
+++ ruby.h	16 Feb 2002 04:27:48 -0000
@@ -74,6 +74,12 @@
 # define __(args) ()
 #endif
 
+#ifdef __cplusplus
+#define ANYARGS ...
+#else
+#define ANYARGS
+#endif
+ 
 #ifdef HAVE_ATTR_NORETURN
 # define NORETURN __attribute__ ((noreturn))
 #else
@@ -408,8 +414,8 @@
 #define MEMMOVE(p1,p2,type,n) memmove((p1), (p2), sizeof(type)*(n))
 #define MEMCMP(p1,p2,type,n) memcmp((p1), (p2), sizeof(type)*(n))
 
-void rb_glob _((char*,void(*)(),VALUE));
-void rb_globi _((char*,void(*)(),VALUE));
+void rb_glob _((char*,void(*)(const char*,VALUE),VALUE));
+void rb_iglob _((char*,void(*)(const char*,VALUE),VALUE));
 
 VALUE rb_define_class _((const char*,VALUE));
 VALUE rb_define_module _((const char*));
@@ -420,16 +426,16 @@
 void rb_extend_object _((VALUE,VALUE));
 
 void rb_define_variable _((const char*,VALUE*));
-void rb_define_virtual_variable _((const char*,VALUE(*)(),void(*)()));
-void rb_define_hooked_variable _((const char*,VALUE*,VALUE(*)(),void(*)()));
+void rb_define_virtual_variable _((const char*,VALUE(*)(ANYARGS),void(*)(ANYARGS)));
+void rb_define_hooked_variable _((const char*,VALUE*,VALUE(*)(ANYARGS),void(*)(ANYARGS)));
 void rb_define_readonly_variable _((const char*,VALUE*));
 void rb_define_const _((VALUE,const char*,VALUE));
 void rb_define_global_const _((const char*,VALUE));
 
-#define RUBY_METHOD_FUNC(func) ((VALUE (*)__((...)))func)
-void rb_define_method _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_module_function _((VALUE,const char*,VALUE(*)(),int));
-void rb_define_global_function _((const char*,VALUE(*)(),int));
+#define RUBY_METHOD_FUNC(func) ((VALUE (*)(ANYARGS))func)
+void rb_define_method _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_module_function _((VALUE,const char*,VALUE(*)(ANYARGS),int));
+void rb_define_global_function _((const char*,VALUE(*)(ANYARGS),int));
 
 void rb_undef_method _((VALUE,const char*));
 void rb_define_alias _((VALUE,const char*,const char*));
@@ -479,11 +485,11 @@
 VALUE rb_each _((VALUE));
 VALUE rb_yield _((VALUE));
 int rb_block_given_p _((void));
-VALUE rb_iterate _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_rescue _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_rescue2 __((VALUE(*)(),VALUE,VALUE(*)(),VALUE,...));
-VALUE rb_ensure _((VALUE(*)(),VALUE,VALUE(*)(),VALUE));
-VALUE rb_catch _((const char*,VALUE(*)(),VALUE));
+VALUE rb_iterate _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_rescue _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_rescue2 __((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE,...));
+VALUE rb_ensure _((VALUE(*)(ANYARGS),VALUE,VALUE(*)(ANYARGS),VALUE));
+VALUE rb_catch _((const char*,VALUE(*)(ANYARGS),VALUE));
 void rb_throw _((const char*,VALUE)) NORETURN;
 
 VALUE rb_require _((const char*));
Index: rubysig.h
===================================================================
RCS file: /home/akira/cvs/ruby-src/cvs/ruby/rubysig.h,v
retrieving revision 1.6
diff -u -r1.6 rubysig.h
--- rubysig.h	16 Nov 2000 07:24:11 -0000	1.6
+++ rubysig.h	16 Feb 2002 04:43:34 -0000
@@ -57,7 +57,7 @@
 #define ALLOW_INTS {rb_prohibit_interrupt--; CHECK_INTS;}
 #define ENABLE_INTS {rb_prohibit_interrupt--;}
 
-VALUE rb_with_disable_interrupt _((VALUE(*)(),VALUE));
+VALUE rb_with_disable_interrupt _((VALUE(*)(ANYARGS),VALUE));
 
 EXTERN rb_atomic_t rb_trap_pending;
 void rb_trap_restore_mask _((void));

> LaMont:  In a situation like this, is it ok if I actually prevent building
> on hppa and ia64 via an explicit Architecture: tag in debian/control?

Better to leave it without the Architecture tag hack, since it _should_
build.  That way, when it does, you don't have to do anything special.
As it sits, uploading a new verison with the arch change will cause the
buildd to try it again, and, well....

The best thing might be to clone the defect over to ruby, and get the
headers fixed in ruby.  Just reassigning the bug is likely to get you
another bug report after I forget the details of _this_ package, and
that'll only get you annoyed... :-)

lamont

Luigi,

Thanks a big bunch for getting the nasty details out from under the carpet...

On Fri, Feb 15, 2002 at 09:31:06PM +0100, Luigi Ballabio wrote:
> At 7:49 AM -0600 2/15/02, Dirk Eddelbuettel wrote:
> >On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
> >> At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
> >> >Here is another g++-3.0 bug report regarding quantlib, or in particular 
> >> the
> > > >Ruby bindings. I'd appreciate any comments. Luigi?
> 
> Ok, here's the final word from the Ruby gurus.
> 
> It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
> done in the Ruby development branch (Ruby 1.7.something) but not in 
> the current release (or at least not the one in Woody. I don't know 
> which version of Ruby you have in... wait, what was the name of the 
> character now? Well, unstable anyway)

It's called "sid".  There is a ruby1.7_1.7.2.0cvs2002.01.18-1 package.
We could try that.

> It also needs a minor fix in SWIG which has been done in CVS but 
> wasn't released either.

Okay, but as we figured, I don't need, or should, re-run swig anyway. So if
you can get hands on a reworked version, we could try a new QL snapshort of
QuantLib-Ruby. If we want it that badly which maybe we don't.

> The bottom line is, we're out in the cold :(
> Architectures with gcc 3.0.x are ruled out for the time being.

That's probably ok, especially as the fix will be forthcoming.

LaMont:  In a situation like this, is it ok if I actually prevent building
on hppa and ia64 via an explicit Architecture: tag in debian/control?

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

> Ok, here's the final word from the Ruby gurus.
> 
> It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
> done in the Ruby development branch (Ruby 1.7.something) but not in 
> the current release (or at least not the one in Woody. I don't know 
> which version of Ruby you have in... wait, what was the name of the 
> character now? Well, unstable anyway)
> It also needs a minor fix in SWIG which has been done in CVS but 
> wasn't released either.
> 
> The bottom line is, we're out in the cold :(
> Architectures with gcc 3.0.x are ruled out for the time being.

ruby_1.6.6-5 is in sid (which will always be unstable)

Depending on how invasive the fix is, I suppose the ruby maintainer
could port the fix back to ruby 1.6.6-5, and thereby fix all these
ruby-dependants.  Akira?

lamont

At 7:49 AM -0600 2/15/02, Dirk Eddelbuettel wrote:
>On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
>>  At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
>>  >Here is another g++-3.0 bug report regarding quantlib, or in particular the
>  > >Ruby bindings. I'd appreciate any comments. Luigi?

Ok, here's the final word from the Ruby gurus.

It's a bug in the Ruby headers. It needs a fix in Ruby which has been 
done in the Ruby development branch (Ruby 1.7.something) but not in 
the current release (or at least not the one in Woody. I don't know 
which version of Ruby you have in... wait, what was the name of the 
character now? Well, unstable anyway)
It also needs a minor fix in SWIG which has been done in CVS but 
wasn't released either.

The bottom line is, we're out in the cold :(
Architectures with gcc 3.0.x are ruled out for the time being.

Sorry,
	Luigi

-- 

> IIRC, no. On ia64 we can choose between 2.95.* and 3.0.* but for a reason I
> always forget we prefer 3.0.*.

Minor nit: ia64 requires 2.96, not 2.95.

> On the hppa architecture, however, only 3.0.* is supported. 2.95.* simply
> does not exist.

> In the meantime, would it be possible to compile with 2.95.x on hppa?

hppa is not supported in gcc 2.x, gcc 3.0 is required.

lamont

On Fri, Feb 15, 2002 at 10:36:21AM +0000, Luigi Ballabio wrote:
> At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
> >Here is another g++-3.0 bug report regarding quantlib, or in particular the
> >Ruby bindings. I'd appreciate any comments. Luigi?
> 
> Ouch.
> It's not just an hppa problem. It seems like SWIG/Ruby bindings have a big 
> problem with g++ 3.0 - I just reproduced it on i386. Unfortunately it's not 
> our code---it's either the Ruby API or the SWIG-generated wrappers. I just 
> sent a mail to the relevant mailing lists to ask for insight. We'll see.
> 
> In the meantime, would it be possible to compile with 2.95.x on hppa?

IIRC, no. On ia64 we can choose between 2.95.* and 3.0.* but for a reason I
always forget we prefer 3.0.*.

On the hppa architecture, however, only 3.0.* is supported. 2.95.* simply
does not exist.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

At 04:29 PM 2/14/02 -0600, Dirk Eddelbuettel wrote:
>Here is another g++-3.0 bug report regarding quantlib, or in particular the
>Ruby bindings. I'd appreciate any comments. Luigi?

Ouch.
It's not just an hppa problem. It seems like SWIG/Ruby bindings have a big 
problem with g++ 3.0 - I just reproduced it on i386. Unfortunately it's not 
our code---it's either the Ruby API or the SWIG-generated wrappers. I just 
sent a mail to the relevant mailing lists to ask for insight. We'll see.

In the meantime, would it be possible to compile with 2.95.x on hppa?

Bye,
         Luigi

P.S. Dirk: I sent my public key to James Troup for access to sarti about 10 
days ago, but I didn't have any answer. Could you check the thing? Thanks

Folks,

Here is another g++-3.0 bug report regarding quantlib, or in particular the
Ruby bindings. I'd appreciate any comments. Luigi?

Dirk

----- Forwarded message from LaMont Jones <la...@sm...> -----

Envelope-to: ed...@ed...
Delivery-date: Thu, 14 Feb 2002 10:33:09 -0600
Subject: Bug#133913: quantlib-ruby: FTBFS: g++ 3.0 errors (hppa/unstable)
Reply-To: LaMont Jones <la...@sm...>, 13...@bu...
From: LaMont Jones <la...@sm...>
To: su...@bu...

Package: quantlib-ruby
Version: 0.2.1cvs20020120-2
Severity: important

Build fails due to g++ 3.0 errors.  Full build log at:
    http://buildd.debian.org/fetch.php?&pkg=quantlib-ruby&ver=0.2.1cvs20020120-2&arch=hppa&stamp=1011978461&file=log&as=raw

g++ -fPIC -g -O2 -fPIC  -DHAVE_CONFIG_H -I. -I/usr/lib/ruby/1.6/hppa-linux -I. -I/usr/include    -I/usr/local/include -c -o quantlib_wrap.o quantlib_wrap.cpp
quantlib_wrap.cpp: In function `void Init_QuantLibc()':
quantlib_wrap.cpp:18130: cannot convert `VALUE (*)(...)' to `VALUE (*)()' for 
   argument `3' to `void rb_define_singleton_method(long unsigned int, const 
   char*, VALUE (*)(), int)'
...

-- System Information
Debian Release: 3.0
Kernel Version: Linux smallone 2.4.17-64 #1 Wed Jan 30 00:23:46 MST 2002 parisc64 unknown



----- End forwarded message -----

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

You might recall that Luigi debugged QL-Python on alpha.  Lots of other
architectures are still ailing, though.  As

	http://buildd.debian.org/build.php?&pkg=quantlib-python

shows, we currently fail on alpha, hppa, ia64, arm, m68k. As I read the build
logs, a quick summary is

alpha   wrong (0.2.1, not 0.2.1cvs) library installed, not attempted
hppa    needs -ffunction-sections compiler switch [ see below ]
ia64    some compiler warnings, survives few tests, then fails distributions
arm	too small a machine, aborts after 150 mins thinking it failed
m68k    idem, too small / too little memory to cope with the complex C++

I should get the alpha to attempt a recompilation [ though we currently have
hardware problems with our main Alpha box ], and get the timeout increased
for arm and m68k. [1]  That would leave hppa and ia64.  

I actually modified the build script for hppa earlier to add the
"-ffunction-sections" switch for gcc. It now builds, but then fails a few
tests (details below in [2]).  This is based on on the 0.3.0a5 branch from
CVS which I called 0.2.1cvs20020120 [ Debian needs to sort the version nb ]

Luigi: James Troup, who acts as Debian sysadmin for this hppa box, could
create an account for you if you send him your ssh public key.  Could you do
that, and then try to squash the bug there?

Cheers,  Dirk


[1] Or simply prevent it from being built, but that is considered sacrilege
within Debian as everything ought to build everywhere, something I personally
disagree with.

[2] On hppa, the following tests all fail:
american_option.py
barrier_option.py
binary_option.py
cliquet_option.py
distributions.py
european_with_dividends.py
finite_difference_european.py
forwardspreadedcurve.py
implied_volatility.py
montecarlo_pricers.py
old_european_option.py
old_implied_volatility.py
piecewiseflatforward.py
segmentintegral.py
swap.py

Whereas these work fine:
complexmarketelements.py
date.py
daycounters.py
european_option.py
get_covariance.py
mcmultifactorpricers.py
random_generators.py
risk_statistics.py
statistics.py

-- 
Good judgment comes from experience; experience comes from bad judgment. 
							    -- F. Brooks

Bugs item #507850, was opened at 2002-01-23 22:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=507850&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: QuantlibPython IV func crashes python 

Initial Comment:

When the impl vol call is made with a value less
than or equal to parity (which is often the case for 
bids in the marketplace), The Quantlibc.so library
crashes which crashes my python process as well.

This should have some boundary checking and return
0 or -1 if it is outside the boundaries.




----------------------------------------------------------------------

>Comment By: Ferdinando Ametrano (nando)
Date: 2002-01-26 02:35

Message:
Logged In: YES 
user_id=34616

Hi

> >>> opt.impliedVolatility(12, 1e-6, 100)
> Traceback (most recent call last):
>   File "<pyshell#16>", line 1, in ?
>     opt.impliedVolatility(12, 1e-6, 100)
> Exception: root not bracketed: f[0.000100,4.000000] -> [-
> 1.01915488254814870000,-0.72995742951797027000]
>
> I have no idea what the heck the "root not bracketed" 
means 
> though.
It means that the volatility range of 0.01%-400% could not 
bracket the
requested value of 12 (the message is not clear: I agree)

as you can see up to 400% volatility the option value is 
less than 12
>>> import QuantLib
>>> QuantLib.EuropeanOption('Put', 4.0, 15.0, 0.0, 0.0212, 
0.06, 1.6).value()
10.981222948151906
>>> QuantLib.EuropeanOption('Put', 4.0, 15.0, 0.0, 0.0212, 
0.06, 4.0).value()
11.267654249472969

> This should have some boundary checking and return 
> 0 or -1 if it is outside the boundaries. 
It throws a python exception instead

The crash under Red Hat 6.2 is the real problem here.
We have fixed few bugs that could have solved this problem.
Would you mind trying the last CVS snapshot (also 
downloadable from http://www.quantlib.org/snapshot.html) 
and report to us?

thank you very much

ciao - Nando

PS What about the QuantLib-Python test suite? Does it run 
with no problems?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-25 21:33

Message:
Logged In: NO 

I see it on RHat 6.2 but not on Win 98

RHat 6.2:
Python 2.1.1 (#1, Nov 14 2001, 20:43:53)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on 
linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import QuantLib
>>> opt = QuantLib.EuropeanOption('Put', 4.0, 15, 
0.0 ,0.0212, 0.0602739726027,
1.6)
>>> opt.impliedVolatility(12, 1e-6, 100)
Segmentation fault                  

Yet Win 98 has
>>> opt = QuantLib.EuropeanOption('Put', 4.0, 15, 
0.0 ,0.0212, 0.0602739726027, 1.6)
>>> opt.impliedVolatility(12, 1e-6, 100)
Traceback (most recent call last):
  File "<pyshell#16>", line 1, in ?
    opt.impliedVolatility(12, 1e-6, 100)
Exception: root not bracketed: f[0.000100,4.000000] -> [-
1.01915488254814870000,-0.72995742951797027000]


I have no idea what the heck the "root not bracketed" means 
though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=507850&group_id=12740

Bugs item #507850, was opened at 2002-01-23 22:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=507850&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: QuantlibPython IV func crashes python 

Initial Comment:

When the impl vol call is made with a value less
than or equal to parity (which is often the case for 
bids in the marketplace), The Quantlibc.so library
crashes which crashes my python process as well.

This should have some boundary checking and return
0 or -1 if it is outside the boundaries.




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-25 21:33

Message:
Logged In: NO 

I see it on RHat 6.2 but not on Win 98

RHat 6.2:
Python 2.1.1 (#1, Nov 14 2001, 20:43:53)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on 
linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import QuantLib
>>> opt = QuantLib.EuropeanOption('Put', 4.0, 15, 
0.0 ,0.0212, 0.0602739726027,
1.6)
>>> opt.impliedVolatility(12, 1e-6, 100)
Segmentation fault                  

Yet Win 98 has
>>> opt = QuantLib.EuropeanOption('Put', 4.0, 15, 
0.0 ,0.0212, 0.0602739726027, 1.6)
>>> opt.impliedVolatility(12, 1e-6, 100)
Traceback (most recent call last):
  File "<pyshell#16>", line 1, in ?
    opt.impliedVolatility(12, 1e-6, 100)
Exception: root not bracketed: f[0.000100,4.000000] -> [-
1.01915488254814870000,-0.72995742951797027000]


I have no idea what the heck the "root not bracketed" means 
though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=507850&group_id=12740

Bugs item #507850, was opened at 2002-01-23 22:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=507850&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: QuantlibPython IV func crashes python 

Initial Comment:

When the impl vol call is made with a value less
than or equal to parity (which is often the case for 
bids in the marketplace), The Quantlibc.so library
crashes which crashes my python process as well.

This should have some boundary checking and return
0 or -1 if it is outside the boundaries.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=507850&group_id=12740

Bugs item #490527, was opened at 2001-12-07 22:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=490527&group_id=12740

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Liam Herron (leedog)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on impliedVolatility call.

Initial Comment:
In Python:

Python 2.1 (#2, Jun 22 2001, 10:20:42)
[GCC 2.7.2.3] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import QuantLib
>>> opt = QuantLib.EuropeanOption('Call', 44.0, 17.5,
0.0, 0.022, 0.041095890411, 0.89)
>>> opt.value()
26.515814767589454
>>> x = opt.impliedVolatility(28.7, 1e-4, 50)
[liam@optrader RiskManagementSystem]#

It seg faults at this point as well as 
x = opt.impliedVolatility(26, 1e-4, 50)

But it seems to work for:
x = opt.impliedVolatility(opt.value(), 1e-4, 50)
0.89000002

This is a listed ADI 17.5 Dec Call that I am trying to
price.

Any ideas?


----------------------------------------------------------------------

Comment By: Ferdinando Ametrano (nando)
Date: 2001-12-19 08:43

Message:
Logged In: YES 
user_id=34616

Hi Liam

thank you for your report.
I'm sorry for being so late in replying, but because of wrong settings I had no notification of your bug report.

1) a 400% (4.0) volatility would give a 27.87 option value, so to achieve a value of 28.7 one should use a volatility 
greater than 400%: this is currently forbidden in QuantLib. Such a limit might be a bad choice: I will look into it

2) an European call with no dividend has the same value of the equivalent American option, that is its value has to 
be greater of the intrinsic value (44.0-17.5=26.5). So there is no volatility that will give that option a value of 26.

This said I had no crash on my machine (Win32 NT, python 2.1, QuantLib 0.3.0a3), just exceptions:
>>> x= opt.impliedVolatility(26, 1e-4, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Exception: root not bracketed: f[0.0001000000,4.0000000000] -> 
[0.51581476758945399000,1.87072669689047540000]
>>> x = opt.impliedVolatility(28.7, 1e-4, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Exception: root not bracketed: f[0.0001000000,4.0000000000] -> 
[-2.18418523241054530000,-0.82927330310952385000]

I agree these messages are not easy to understand, but they just say that those 2 option values are not possible 
in the [0.01%,400.0%] volatility range. 

The real problem here if the segmentation fault you write about: to investigate this I need to know your Linux 
distribution, configuration, QuantLib version, etc

ciao -- Nando

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112740&aid=490527&group_id=12740

Patches item #502906, was opened at 2002-01-12 20:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312740&aid=502906&group_id=12740

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: edward (tailbert)
Assigned to: Nobody/Anonymous (nobody)
Summary: std::abs in Swap example

Initial Comment:
use `std::abs' explicitly. a number of systems have
abs() predefined (in my case, as abs(int)), in the swap
valuation example under Examples/Swap

patch attached as unified diff from the root directory
on a *unix* system (no carriage returns).

ps. is there a patch generation document?

if not, how about:

cd /path/to/QuantLib
diff -u dir/to/original-file dir/to/corrected-file > patch

great work, people!

edward


----------------------------------------------------------------------

>Comment By: Ferdinando Ametrano (nando)
Date: 2002-01-23 10:08

Message:
Logged In: YES 
user_id=34616

Thank you Edward

we were using QL_FABS everywhere except the swap example.
Thank you for pointing this out

ciao -- Nando

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312740&aid=502906&group_id=12740

Patches item #502906, was opened at 2002-01-12 20:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312740&aid=502906&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: edward (tailbert)
Assigned to: Nobody/Anonymous (nobody)
Summary: std::abs in Swap example

Initial Comment:
use `std::abs' explicitly. a number of systems have
abs() predefined (in my case, as abs(int)), in the swap
valuation example under Examples/Swap

patch attached as unified diff from the root directory
on a *unix* system (no carriage returns).

ps. is there a patch generation document?

if not, how about:

cd /path/to/QuantLib
diff -u dir/to/original-file dir/to/corrected-file > patch

great work, people!

edward


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312740&aid=502906&group_id=12740

>I guess I should grab a
>tarball out of CVS...   Is that against stock QL or do I need a new QL too
I don't know exactly what a stock QL is, anyway you will need a new QL too.
Besides the exp bug, Luigi told me about 1 SWIG interface bug and 1 QL bug.

FYI today or tomorrow I will update the nightly build on quantlib.org, so 
you might take the tarball from the site if you prefer

ciao -- Nando

On Thu, Jan 10, 2002 at 12:09:24PM +0000, Luigi Ballabio wrote:
> 
> >On Tue, Jan 08, 2002 at 04:36:28PM +0100, Ferdinando Ametrano wrote:
> >> Another key issue would be to solve the problems we have on some 
> >platforms,
> >> as Dirk pointed out. I know Luigi is working on that: Luigi please report
> 
> Ok, I just committed some changes which make QuantLib-Python compile and 
> pass all tests on alpha. I hope this will fix the problems on other

Excellent news, and thank you!

> platforms as well.

Probably/hopefully. I guess it is worth trying. I guess I should grab a
tarball out of CVS...   Is that against stock QL or do I need a new QL too

> Dirk: while a couple of bugs were ours only, one seems to be related with 
> some C or C++ library. If you have any idea of who's the maintainer of the 
> corresponding package, you might want to get in touch with him and report.
> The bug can be reproduced on flatline.tdyc.com as follows:
> 
> ballabio@flatline:~$ python
> Python 2.1.1+ (#1, Jan  9 2002, 03:47:01)
> [GCC 2.95.4  (Debian prerelease)] on linux2
> Type "copyright", "credits" or "license" for more information.
> >>> import math
> >>> math.exp(-700)
> 9.8596765437597708e-305
> >>> math.exp(-750)
> 0.0
> >>> math.exp(-720)
> Floating point exception
> ballabio@flatline:~$
> 
> i.e., there is a range of numbers around -720 which causes exp() to abort.
> Also, the same was happening in a calculation inside libQuantLib, so that 
> the problem might be not in Python but rather in some math C or C++ library 
> which both QuantLib and Python link to.

I'm suspect that this leads down to glibc where code like exp() ultimately
resides.

I think we should report this to debian-alpha and/or debian-python. What do
you think?

> I fixed the problem in our code by filtering the call to exp() and just 
> returning 0 if the exponent is below -700 or so, but it might be advisable 
> to report the thing if you have any idea who to report to.

Hack alert :)

Dirk


-- 
Good judgment comes from experience; experience comes from bad judgment. 
							    -- F. Brooks

Hi all,
	QuEP 9 is available at http://quantlib.org/quep.html and open for feedback.

Bye,
	Luigi