• 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!

Financial Modeling using Matlab/C++/Excel - Any recommendations?

  • Thread starter Thread starter roni
  • Start date Start date
Perl and Fortran communities are quite different. Perl is mainly popular among older Unix users - it was practically first (development started in late eighties) scripting language in widespread use, with text processing facilities as its main strength (especially its excellent built-in regexp engine) that made it to fit very nicely into the Unix programming tool-chain (as textuality is one of main pillars of Unix programs design). Being strong in the text processing made Perl also the main choice for CGI programming, so it was de-facto *the* Web programming language throughout nineties. Also, along the way extremely large number of libraries and modules was developed for handling practically any imaginable kind of programming task, so overall Perl grown up into very strong and versatile general purpose programming language. However, its loose syntax (Mathematica is probably the only one worse, among commonly used programming tools, in that department) and state of limbo with Perl 6 development, that lasts now for more than 10 years, made its popularity to fade sharply, so for new generations of programmers it is probably equally irrelevant as COBOL or Pascal.

I can tell you that the EDA community uses Perl (and TCL) almost as their official language.
Most EDA tools have ASCII inputs thus having a strong , versatile and flexible language as Perl is a huge benefit.

For your personal use I believe it is always more efficient and flexible to use MATLAB when you have both tools in hand(excel and matlab) but sometimes you need to pass the analyzed data to non-users of MATLAB. I also find this as only justification for that.

Matlab can export the data to files so why not just provide them with ready to use data?
 
Matlab provided data kills the cell invocation path in Excel. So what if the end user has to optimize the data using solver for example? Or if he needs to change some cells while keeping the logic to automatically update for the already modified data?
 
Matlab provided data kills the cell invocation path in Excel. So what if the end user has to optimize the data using solver for example? Or if he needs to change some cells while keeping the logic to automatically update for the already modified data?

There is a simple solution, build them a Matlab GUI :) Quite easy...although...Matlab licenses are much more expensive than Excel's so..this might not be a good idea.

BUT you can turn Matlab code into EXE standalone (the flow isn't too solid but it exists) so combining this with a GUI and you have a winner.....or do you ? :confused:
 
I can tell you that the EDA community uses Perl (and TCL) almost as their official language.

You're right: indeed EDA is another niche where Perl still stands strong, albeit I'd say TCL use is even stronger in that domain.

Related note: for alike scripting languages, as well as many general purpose programming languages, it is often very important to be able to wrap lower-level C/C++ code - this is type of task that is often mentioned on this forum, but as far as I remember automated wrapper generation tools, and SWIG in particular, have not been mentioned previously. So I'd like to urge anyone having to approach alike type of task to examine SWIG - it is fantastic tool. (Having TCL mentioned reminded me on this, as TCL is purposely designed to act as "glue" language for lower-level code written in C).
 
You're right: indeed EDA is another niche where Perl still stands strong, albeit I'd say TCL use is even stronger in that domain.

Related note: for alike scripting languages, as well as many general purpose programming languages, it is often very important to be able to wrap lower-level C/C++ code - this is type of task that is often mentioned on this forum, but as far as I remember automated wrapper generation tools, and SWIG in particular, have not been mentioned previously. So I'd like to urge anyone having to approach alike type of task to examine SWIG - it is fantastic tool. (Having TCL mentioned reminded me on this, as TCL is purposely designed to act as "glue" language for lower-level code written in C).

TCL is a shitty language , I have no idea how it became the standard Tool Command Language.
Any language that requires me to "lindex $x 1" just to access a cell in an array is annoying! Too much usage of brackets and other shit!

Perl is used on the users side, TCL is used more on the RD side, but usually both sides know how to handle both in case they need it but each chooses his favorite "weapon" for casual usage.
 
There is a simple solution, build them a Matlab GUI :) Quite easy...although...Matlab licenses are much more expensive than Excel's so..this might not be a good idea.

BUT you can turn Matlab code into EXE standalone (the flow isn't too solid but it exists) so combining this with a GUI and you have a winner.....or do you ? :confused:

Searching for the best solution how to combine Matlab GUI to manipulate Excel cells sometimes comes out to be less efficient (depending on the size and difficulty of the application) than doing the application straight in Excel. I personally have created several C#/VBA GUIs to manipulate Excel cells. This is the best solution if I cannot handle the application logic directly (at least easily) in Excel since I need to use my UDFs in there.
 
How ridiculous. This is supposed to be a thread about languages for finance. You guys are just talking about these languages in general and asserting your own opinions as to how they should be used in finance.

This seems to be a rampant trend lately in QN...
 
Searching for the best solution how to combine Matlab GUI to manipulate Excel cells sometimes comes out to be less efficient (depending on the size and difficulty of the application) than doing the application straight in Excel. I personally have created several C#/VBA GUIs to manipulate Excel cells. This is the best solution if I cannot handle the application logic directly (at least easily) in Excel since I need to use my UDFs in there.

I didn't say you will do Excel operations with the GUI. You can give the user all the Excel properties he needs inside the Matlab GUI.
Obviously this will require some work and acceptance from the end user , but I'm just throwing things that THEORETICALLY can be done :)
 
I didn't say you will do Excel operations with the GUI. You can give the user all the Excel properties he needs inside the Matlab GUI.
Obviously this will require some work and acceptance from the end user , but I'm just throwing things that THEORETICALLY can be done :)

Right. I correctly got it but we started the discussion in condition that the user is not aware of Matlab.
 
Any language that requires me to "lindex $x 1" just to access a cell in an array is annoying!

The last argument of "lindex" command could be actually a list of indices, feature that not that much languages supported back at a time; still I can imagine (I never used TCL much) the pain... Perl is on the other extreme of the spectrum: so many syntactic sugar, so that you type minimally, but when it comes to reading the code - you're doomed.
 
Right. I correctly got it but we started the discussion in condition that the user is not aware of Matlab.

Not aware as in doesn't know it exists or doesn't know how to use it? Once you make the GUI it can be easier to use than Excel since you tailor it for your user with the buttons/functions he needs.

The last argument of "lindex" command could be actually a list of indices, feature that not that much languages supported back at a time; still I can imagine (I never used TCL much) the pain... Perl is on the other extreme of the spectrum: so many syntactic sugar, so that you type minimally, but when it comes to reading the code - you're doomed.

LOL the one-liners of Perl...I hate those, I program in the longest way I can , that way when I come back to the code months later I can understand it in 5minutes instead of 5hours :)
 
Not aware as in doesn't know it exists or doesn't know how to use it? Once you make the GUI it can be easier to use than Excel since you tailor it for your user with the buttons/functions he needs.

We are arguing on one specific issue and there can arise more. Making "kinder" interface is not the justification of using it while he's only aware of Excel. You cannot provide anyone with "buttons/functions/tools he needs" as Microsoft has done (here I mean he might need some system level commands occasionally). I completely agree with your desire to completely throw Excel away and I'm on that opinion too but in my case, I deal with professors who have never heard of other tools than Excel and simple WON'T use anything else. So I'm forced to do the applications in Excel for them rather than providing them with Matlab GUI.
 
We are arguing on one specific issue and there can arise more. Making "kinder" interface is not the justification of using it while he's only aware of Excel. You cannot provide anyone with "buttons/functions/tools he needs" as Microsoft has done (here I mean he might need some system level commands occasionally). I completely agree with your desire to completely throw Excel away and I'm on that opinion too but in my case, I have know who have never heard of other tools then Excel and simple WON'T use anything else. So I'm forced to do the applications in Excel for them rather than providing them with Matlab GUI.

You're still in a better situation than I do, I made my supervisors a super easy to use Matlab GUI and showed them how to use it.
Obviously they never did and just told me how I can make a FEM 3D solver that will give better results than COMSOL in two days.....sure...:rolleyes:
 
I understand, still I use C# GUI attached to Excel when I have defined unique characteristics to that form. This gives them "huge advantage" to manually manage Excel along with defined UDFs in Add-In to make it literally the same as they did before while dealing with only Excel.
 
Back
Top