Serving the Quantitative Finance Community

 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

matlab interface

October 17th, 2011, 9:09 pm

Wow, this is great!I'm wondering, can we make it more even more user-friendly using enums rather than "Use 0 for price, 1 delta, 2 gamma, 3 vega, 4 theta, 5 rho"? (At least on C++-code site it'd be nice)Perhaps an alternative is to use multi-character constants on both the C++- and call-site:http://stackoverflow.com/questions/1322 ... 2#132702As for the way the functions are called -- qfcl_interface with a name of function qfcl_interface('gbm_vanilla_option', ...) and then run-time dispatch via if (function_name == "gbm_vanilla_option") -- I understand the rationale for this is to have a nice, compact binary MEX. However, wouldn't it be more efficient (w.r.t. run-time) to have a bunch of MEX files each generated for the given function, where one directly calls gbm_vanilla_option(...) from MATLAB calling the code in the respective MEX file? Unless we don't care about efficiency because it's non-primary use-case for MATLAB and/or prefer to have a single MEX file rather than a lot of them (essentially, willing to trade-off run-time overhead for filesystem overhead)?
 
User avatar
Polter
Posts: 1
Joined: April 29th, 2008, 4:55 pm

matlab interface

October 17th, 2011, 9:25 pm

QuoteOriginally posted by: outrunYes, we'll have to test both cases (1 vs multiple MEX files). Good point. It's easy to generate multiple interface / interface variants!We can then also get rid of the m file, but I thing it's nice to have the description in there. Personally I'm not worried about this nanosec overhead for dispatching, the idea is that most of the time is spend in the actual numerical stuff instead of the call dispatching. Enums is C++, the users doesn't see that, but internally that should be done indeed. For the user I would prefer strings.Yes, enums solely on the C++ side.As for the call-site (e.g., MATLAB code), what about an int that translates to a multi-char literal (constant) -- see my link.I suppose on MATLAB side we could have a bunch of global variables or a lookup table (using either MATLAB struct or cell array) to basically emulate enums.So, basically, what's YadaYadaYada::Gamma in C++ (enum) could be just called YadaYadaYada.Gamma in MATLAB (struct) (thus preserving some scoping structure) with a lookup table (for instance) serving as translation (preferably this lookup table should be static, hard-generated variable in the MEX file).However, perhaps that's not necessary -- I'm guessing that the passing of strings from MATLAB to MEX is done by address, not by value, so we won't have any unnecessary overhead either way (and can probably use the static lookup/translation from MATLAB string to C++ enum in the MEX just as well -- other than perhaps having to use more comparison ops for this)?Although it's also worth noting that string seem to be the idiomatic way of doing parameters in MATLAB...However, in other languages it isn't, and it could be nice to have a universal way that could work for all the client code.Just thinking out loud, let me know what you think...
Last edited by Polter on October 16th, 2011, 10:00 pm, edited 1 time in total.