• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

.NET Importance in Quantitative Finance

Joined
1/13/11
Messages
1,362
Points
93
This topic has been discussed in one way or another in separate threads about C# vs C++, the usage of particular programming languages, etc.

I'm embarking on interesting work of creating .NET library for mathematics and statistics. It'd be desirable to hear your opinions about usage of well optimized .NET libraries in quantitative finance. I know C# made codes are less used than C++ (still not sure if this is myth or not, at least I wonder what the trend is). While it's true that well written C# code can be 90% as fast as well written C++ code but "well writing" a C++ code takes more development time. What are your opinions about it? And which fields are using .NET codes much?

Interesting to hear experienced people's opinions about the importance of .NET in quantitative finance. Did the introduction of the platform change (made easier or not) the life of quants?
 
had been using c# for over 4 years.. for various kinds of models to price securities n then risk assesment.. a new teammate was using c# in HFT previously.. though now we use none... would be helpful to built an exhaustive stats package for c#.. i used R with c# using Rconnector and then built a custom wrapper pacakge to run my run regressions in R.. but the performance was not satisfactory when the dataset grew in size.
 
Yeah, I'm more interested in performance issues with dealing with data. BTW, I don't use the dataset at all. You can change the whole data receiving system to LINQ. Makes life pretty easier. Thanks for your answer, would be interested to hear other experiences too. Especially, for HFT field.
 
LINQ to SQL is a performance killer.

It makes life easier. So you prefer using dataset? Did you get the point what I said? I meant using LINQ instead of dataset, so you wholly get rid of dataset.
 
It makes life easier. So you prefer using dataset? Did you get the point what I said? I meant using LINQ instead of dataset, so you wholly get rid of dataset.
Life is not easy when it comes to performance. Every case is different.
 
as opposed to pre-compiled SPs... with a nice execution plan ready...
I can agree with that, and as I said earlier - I am not very fond of L2SQL either. You do know however that you can execute sp's with L2SQL and utilise the execution plan.

Niels
 
I thought with LINQ, I can get away from my SP and move that layers into my C# code. No?
I haven't played much with my code lately as evident with my question.
Yes you can - but that will cause havoc with perf. Therefore you can also use L2SQL to execute store procs, and still get the LINQ goodness. However, if you want to gain the last ounce of performance you probably would like to do your data access more directly.

I can play devils advocate though and argue that the overhead using L2SQL (and other data access /ORM frameworks) is not the big bottleneck when accessing data - the bottleneck is in opening the connection etc.

Niels
 
Cool. Good to know.
In the latest .NET, how is VSTO and making an addin in Excel and distribute them? I last played with .NET 3.0 and Excel 2007 and my experience has been anything but impressive.
I have no idea - I am not doing anything with Excel / MS Office. From what I have heard though, it is better than previous versions.

Niels
 
Cool. Good to know.
In the latest .NET, how is VSTO and making an addin in Excel and distribute them? I last played with .NET 3.0 and Excel 2007 and my experience has been anything but impressive.

Things have been further simplified in .NET4. Office interop in F# is the same as C# - you can use the native COM APIs or the newer, managed Visual Studio Tools for Office libraries. Unfortunately F# doesn't have the UI-designers for creating VSTO add-ins like C#, so the simplest way to do Office interop is to use the COM APIs. In C# itself, interaction with excel is much simpler. I have MS Office 2010 and VS 2010, I find it very easy to create Excel Add-Ins.
 
I love LINQ. I use it all the time.
Yes LINQ is great - but as I have mentioned in previous posts, I would not be using LINQ2SQL as (IMHO), it adds an extra layer on top of other layers to access data. I do however use LINQ2Objects and LINQ2XML extensively.

Niels
 
I have replaced using dataset completely with LINQ, it is simple for interacting with SQL, but as nielsb says it must be harming performance depending on the amount of data manipulated . I haven't tried it for significantly large amount of data to be proceeded though yet.
 
Things have been further simplified in .NET4. Office interop in F# is the same as C# - you can use the native COM APIs or the newer, managed Visual Studio Tools for Office libraries. Unfortunately F# doesn't have the UI-designers for creating VSTO add-ins like C#, so the simplest way to do Office interop is to use the COM APIs. In C# itself, interaction with excel is much simpler. I have MS Office 2010 and VS 2010, I find it very easy to create Excel Add-Ins.
THIS
in .NET 3.5 VSTO add-ins were a tad bit more complicated as everything had to be done manually and you had to build the .xmls yourself... now, making plug-ins is "so easy a caveman can do it" ;)
 
Many things have been simplified with method deifnitions with the introduction of optional and named parameters (not sure if named parameters were introduced in .NET4 though,but I think it was). LINQ makes it easy to interact with SQL with no much scratching head for defining the procedures and functions in SQL program itself.
 
Back
Top