Two design questions about quantlib

[David Eaves-2]

(html didn't post well before, re-posting both quantlib-dev and quantlib-users)
 
I've been writing quant software for almost 20 years, and this is my first look at quantlib. It's very impressive, but I have two design questions that I wanted to float in the quantlib-dev list, and see what kind of thoughtful responses there might be. No need to respond instantly: I'd like to hear considered responses.

This is all descended from the Observer design pattern, plus some other support. Which is nice, I did a bunch of event-driven systems back in the 1990s, very cool. And it scales reasonably well, within a single OS and machine.

1) Poll: How many users/developers have ever wanted to use this product without the Observer design pattern, which I find impedes distributed computing, general transparency, and audit?

2) Has anybody thought about how one might implement the subject matter independently, as Singleton, and embed it within a design pattern of ones own choosing? E.g. I'd like to be able to use these methods in a Command/Visitor context, but see a rewrite as codebase divergence, a big no-no for me.

Thanks,

Dave Eaves


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hi David,
    apologies for the delay.

You've put your finger on a sore spot.  It has been bugging me for a
while that it's just not possible to get a simple price without
instantiating an instrument and a pricing engine.  And of course, all
this comes from the pervasiveness of Observer.  Like the Vorlons in
Babylon 5, we thought we were doing good but ended up meddling with
people...

I have been thinking of trying to extract the functional core, so that
the basic pricing functions are available as functions (which is, I
guess, what you're driving at when you talk of implementing them as
Singletons) and the pricing-engine classes call the functions and take
care of observability.  For simple functionality, this could be done
in a backward-compatible way as to avoid code divergence.  I'm not
sure how this would work out in more complex cases, where the event
chains are more tangled.  And while this would be simple for engines,
I've a feeling that it would be difficult to do for things like term
structures, where it's more difficult to extract the functionality
from the object responding to events.

Another possibility would be to allow one to choose whether any given
object should listen to events or not.  But this can get messy very
quickly.

I guess what I'm trying to say is that I don't have a clear picture of
where to go :)
If anybody wants to weigh in, please do so.  I'd be nice to have a bit
of discussion on this.

Later,
    Luigi


On Mon, Sep 3, 2012 at 10:22 PM, David Eaves <[hidden email]> wrote:

> (html didn't post well before, re-posting both quantlib-dev and quantlib-users)
>
> I've been writing quant software for almost 20 years, and this is my first look at quantlib. It's very impressive, but I have two design questions that I wanted to float in the quantlib-dev list, and see what kind of thoughtful responses there might be. No need to respond instantly: I'd like to hear considered responses.
>
> This is all descended from the Observer design pattern, plus some other support. Which is nice, I did a bunch of event-driven systems back in the 1990s, very cool. And it scales reasonably well, within a single OS and machine.
>
> 1) Poll: How many users/developers have ever wanted to use this product without the Observer design pattern, which I find impedes distributed computing, general transparency, and audit?
>
> 2) Has anybody thought about how one might implement the subject matter independently, as Singleton, and embed it within a design pattern of ones own choosing? E.g. I'd like to be able to use these methods in a Command/Visitor context, but see a rewrite as codebase divergence, a big no-no for me.
>
> Thanks,
>
> Dave Eaves
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[David Eaves-2]

I'm trying to use Command and Chain of Responsibility interfaces to isolate the subject-matter specific finance from the implementation pattern. That way, all finance could use singleton access (i.e. know about finance-specific classes and methods), while the implementation pattern could go through streaming and dispatch methods, which would provide generic interfaces, like xml text, or maybe name-value maps.

 

So I'll "pollute" the finance space with streaming and dispatch interfaces, but nothing functionally intrusive. I view that as the finance subject matter being required to hold itself accountable, which seems reasonable. That would double as builtin support for debugging and swig. It would require a complete refactoring, so for proof of concept I'll write a few simple classes from scratch.

 

Users could write their own base implementation patterns, or use the default Observable. Implementation patterns would inherit from CofC and Command, and the dispatch methods would be called generically by the pattern's active function method, e.g. onNotify(), or visit(). Automake macros could insert base class references to patterns for however you wanted to build it. You'd build a couple of separate sos or dlls, and the core lib/libs would only use singleton types in their interfaces.

 

As soon as I have a Visitor-based proof of concept for the first part I'll distribute a gzip. We'll see if anybody thinks it makes sense to use this idea. I think there's enough finance-specific material to make it worthwhile.

 

Dave Eaves

From: Luigi Ballabio <[hidden email]>
To: David Eaves <[hidden email]>
Cc: [hidden email]; "[hidden email]" <[hidden email]>
Sent: Monday, September 24, 2012 1:36 AM
Subject: Re: [Quantlib-users] Two design questions about quantlib

Hi David,
    apologies for the delay.

You've put your finger on a sore spot.  It has been bugging me for a
while that it's just not possible to get a simple price without
instantiating an instrument and a pricing engine.  And of course, all
this comes from the pervasiveness of Observer.  Like the Vorlons in
Babylon 5, we thought we were doing good but ended up meddling with
people...

I have been thinking of trying to extract the functional core, so that
the basic pricing functions are available as functions (which is, I
guess, what you're driving at when you talk of implementing them as
Singletons) and the pricing-engine classes call the functions and take
care of observability.  For simple functionality, this could be done
in a backward-compatible way as to avoid code divergence.  I'm not
sure how this would work out in more complex cases, where the event
chains are more tangled.  And while this would be simple for engines,
I've a feeling that it would be difficult to do for things like term
structures, where it's more difficult to extract the functionality
from the object responding to events.

Another possibility would be to allow one to choose whether any given
object should listen to events or not.  But this can get messy very
quickly.

I guess what I'm trying to say is that I don't have a clear picture of
where to go :)
If anybody wants to weigh in, please do so.  I'd be nice to have a bit
of discussion on this.

Later,
    Luigi


On Mon, Sep 3, 2012 at 10:22 PM, David Eaves <[hidden email]> wrote:

> (html didn't post well before, re-posting both quantlib-dev and quantlib-users)
>
> I've been writing quant software for almost 20 years, and this is my first look at quantlib. It's very impressive, but I have two design questions that I wanted to float in the quantlib-dev list, and see what kind of thoughtful responses there might be. No need to respond instantly: I'd like to hear considered responses.
>
> This is all descended from the Observer design pattern, plus some other support. Which is nice, I did a bunch of event-driven systems back in the 1990s, very cool. And it scales reasonably well, within a single OS and machine.
>
> 1) Poll: How many users/developers have ever wanted to use this product without the Observer design pattern, which I find impedes distributed computing, general transparency, and audit?
>
> 2) Has anybody thought about how one might implement the subject matter independently, as Singleton, and embed it within a design pattern of ones own choosing? E.g. I'd like to be able to use these methods in a Command/Visitor context, but see a rewrite as codebase divergence, a big no-no for me.
>
> Thanks,
>
> Dave Eaves
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users