Is anyone interested in participating in an open-source initiative in q-fin? Anyone who has thought about an interesting aspect of risk/pricing lib programming / GUI using decent languages (no BS please) please, feel free to share ideas, we can then spin them off towards any open collab env like sforge. We can leverage from existing libs ( like the amazing qlnet ) or come up with something entirely new ourselves. Dunno, its all wide open. We could even develop something useful as a learning tool for newjoiners in q-fin ( like me ).Cheers,Serp

QuoteOriginally posted by: SierpinskyJanitorIs anyone interested in participating in an open-source initiative in q-fin? Anyone who has thought about an interesting aspect of risk/pricing lib programming / GUI using decent languages (no BS please) please, feel free to share ideas, we can then spin them off towards any open collab env like sforge. We can leverage from existing libs ( like the amazing qlnet ) or come up with something entirely new ourselves. Dunno, its all wide open. We could even develop something useful as a learning tool for newjoiners in q-fin ( like me ).What about cloning OpenGamma in modern C++?

Sounds interesting, but arent there already APIs for .NET and JAVA? it seems quite an overkill porting it to "modern" C++, btw, we would first need to define what "modern" means in this context ( something which as you now would be polemic, to say the least )... anyway, its a good call and we might ask OpenGamma pros about it, they might use this Forum.

I think people usually take something they are already working on, but which has more general applications than just what they are using it for. They offer it to people who might use it in those other scenarios, to help improve and expand it.Like maybe you are involved in high-speed trading, and you wire a microcontroller right into an ethernet cable, for some kind of fastest-possible order management. You say hmmm, there could be other uses for this code library, such as surveillance, network interfaces for fuel systems in race cars, whatever. So you post it up there and call OpenEther or something.

QuoteOriginally posted by: SierpinskyJanitorIs anyone interested in participating in an open-source initiative in q-fin? Have you looked at nxll and related projects? It is just a start, but I'm pretty happy with xlldatetime and xllpwflat now. You can browse the source code on codeplex to see if that qualifies as modern C++. My approach is to make all the platform independent code either a function, or a very lightweight C++ object. My GUI is Excel, so I have to keep it simple. It makes it easier to integrate into other systems as well.

not sure exactly what you're wanting to attempt, but you may find tradelink useful in your efforts.tradelink is open source under the LGPL, includes : * broker neutral interface http://docs.tradelink.org * very fast live trading (.05ms = 50us) google tradelink speed * very fast historical trading engine (300,000-1million ticks/second, portfolio realistic sims) * supports fx, equities, options and more * 17 different brokers and feed connectors * 3+ years in development, 300+ active developer community http://community.tradelink.orghttp://tradelink.org

It's been a while since I looked at QuantLib's Excel interface. Is it nice? I don't remember it being particularly user friendly... Would suggest an Excel based, practitioner (as opposed to say mathematician) friendly interface for pricing, risk, etc. Nice, well though out function interfaces that perform practical methods like calibrating market data, pricing various instruments, etc. Design choices include leveraging existing Excel interfaces (nxll, XLQ, ExcelDna, etc) and quant toolkits (pluggable?) like Quantlib.

I don't know, but I am guessing there are QuantLib developers wishing they could rewrite it from the ground up. It is very popular and high quality but it is not fun to use. I tried this test: give a fresh install to a smart programmer and asks them to use it to come up with the price of a Black-Scholes, constant vol call option. Say spot 100, rate 1%, vol 20%, strike 100, expiration 0.25 years. He gave up after 45 minutes.It is important to decide up front what any project is *not*. (And apply the discipline to not get sucked into adding just-one-more-feature.) I hope I am not being too presumptuous by making pronouncements about what I think the project should be. Please feel free to shoot down whatever I suggest. Quartz mentioned OpenGamma. It looks like a very high quality product to handle front office/risk mechanics and I wish my small hedge fund clients could have used this 10 years ago. Nobody is opening small hedge funds these days and it would be a crime to use a Java platform. Java was great in it's day, but it does not have a bright future. (I'm sure I'm gonna take some heat on this. I'm just calling it how I see it.)This project should not be a front office/risk system like OpenGamma.Tradelink mentioned, uh, TradeLink. (I see what you are doing there. ) I wish I knew about this 5 years ago when I was setting up a trade execution business for one of my clients that figured out a trading strategy that actually made money. It looks like well written C# code that does what it was designed to do.This project should not be a trade execution system or a language for trading strategies.Let me throw out some thoughts on what I think the project could be. The basic idea is QuantLib light. Lot's of people use that so it seems to be a good idea to focus on the functionality people use from that. None of my clients use QuantLib, but a common refrain I hear from those using FinCad or MBRM are that they are paying a lot of money to use only use a small fraction of what they buy.I like use scenarios. Suppose you are a trader and the first day on the job you have some existing trades and have the sales/marketing guys after you to put more trades on your book. What are the first tools you are going to look for to handle that?Another thought: what could this library provide that OpenGamma and TradeLink could use to enhance their systems?

kimo, your example regarding QuantLib usability is a bit strange, that's pretty much one of the first things that's in the supplied examples (and there aren't that many examples, which is perhaps more important). I dare say that documenting QuantLib could be one of the "open-source collab projects" with a potential to turn out to be actually useful (a lot of the "difficulty" in using an API depends on how well documented it is), but I guess it's always sexier to write a new lib from the scratch rather than write the docs for the existing one...// I do happen to think that QL could use a more lightweight design, but rather from a performance (a lot of dynamic binding & virtuals in multi-level inheritance ain't exactly perf.-friendly) than usability p.o.v. (which could go together, though); that being said, I'm not convinced that should take priority over documentation of what exists today.

QuoteOriginally posted by: Polterkimo, your example regarding QuantLib usability is a bit strange, that's pretty much one of the first things that's in the supplied examples (and there aren't that many examples, which is perhaps more important). I dare say that documenting QuantLib could be one of the "open-source collab projects" with a potential to turn out to be actually useful (a lot of the "difficulty" in using an API depends on how well documented it is), but I guess it's always sexier to write a new lib from the scratch rather than write the docs for the existing one...// I do happen to think that QL could use a more lightweight design, but rather from a performance (a lot of dynamic binding & virtuals in multi-level inheritance ain't exactly perf.-friendly) than usability p.o.v. (which could go together, though); that being said, I'm not convinced that should take priority over documentation of what exists today.Maybe strange to you, but you are making your own point that I entirely agree with. Good documentation is crucial to getting people using your product up to speed. It is easy to forget how hard won knowledge is. Mark Joshi told me that xlw really took off after they made it super simple to use. I took his advice to heart with my nxll library and it seems to be working. Programmers tend to forget that what is simple to them might not be simple to other people.Wishing people will write documentation won?t make it happen. I think the best person to write documentation is the person writing the code. Give them a tool they like and they will do that. C# and VB.Net provide that functionality and programmers seem to use it. Sandcastle even generates intellisense files that other programmers can use to be more productive while writing more code.Was this the example of pricing a simple Black-Scholes option you were referring to?

Yes, that's the example.I guess you have a point regarding the tools, in broader sense I wouldn't mind something like ReSharper (http://www.jetbrains.com/resharper/) for C++, perhaps with stronger focus on this language with the upcoming Windows 8 at Microsoft we'll see some productivity improvements there.Regarding the docs tools, I use Doxygen for my projects (what's annoying is that it isn't really that integrated w/ VS, though I don't use any add-ins for that (not aware of existence thereof)), not familiar w/ Sandcastle, how does it compare (generating intellisense files -- isn't that automatic whenever you include headers of the library in the projects?), is it .NET-only?

QuoteOriginally posted by: PolterYes, that's the example....Regarding the docs tools, I use Doxygen for my projects (what's annoying is that it isn't really that integrated w/ VS, though I don't use any add-ins for that (not aware of existence thereof)), not familiar w/ Sandcastle, how does it compare (generating intellisense files -- isn't that automatic whenever you include headers of the library in the projects?), is it .NET-only?Thanks for clearing up the example Polter. Nobody cares what you or I think. Everyone comes to their own conclusions.Sandcastle was the first open source project Microsoft did. It is what they use to generate their documentation. It seems to be famous for its lack of documentation, go figure. Other people have built tools around it which is how open source is supposed to work, no? Eric Woodruff has the best tool for mere mortals to leverage off of this: Sandcastle Help File Builder. I used his stuff to create the documentation module in my library. It is geared toward .Net, but I can use it with my so-called unmanged C++ to generate documentation that integrates into Excel.

What about an open source risk engine with nice and simple-to-death interface connecting to a local or remote cloud risk engine. The engine would price trades, derivatives and many other products. It could also do coutnerparty etc. What do you think?

Cloud = nightmare; for any big organization.

Quote don't know, but I am guessing there are QuantLib developers wishing they could rewrite it from the ground up. It is very popular and high quality but it is not fun to use.can't quite agree on this one. Every developer ends up refactoring and in more extreme cases code their own versions of well-known APIs, however, rewriting something as well designed and flexible as Quantlib from scratch doesn't quite seem practical nor useful. Also, I do not agree with the assertion that it's not fun to use? Probably you have been exposed to more sophisticated, well-designed, hpc libs, but personally, every time I revisit Quantlib, end-up finding out aspects and details which make me appreciate it even more and deeply regret the fact I can't use it more in prod, especially some of its variants such as qlnet ( and this only happens with narrow-minded IT managers who refuse to even understand what it's all about, most people do like it - not all do "get it" though ). However, and since you brought this issue up, which aspects of Quantlib are worth redesigning from scratch? ( or as you say, this is just a guess ) Dr. Luigi Ballabio will definitely appreciate more insight on this.