Hi
I have some technical design issues (and temporary work-arounds) for n-order perturbation integration into Dynare:
1) Calling <model>_dynamic: there is a mex function mexCallMATLAB() which can call either internal MATLAB functions, .m files and/or, as well, other MEX files, whatever it finds appropriate. Thus, we may be able to call <model>_dynamic mex/dll as currently created by Dynare preporcessor directly from the new mex/dll file This option allows calls to <mod>_dynamic irrespective whether it is, or is not compiled as a mex function.
Although we should be able to improve performance, cut out the MATLAB intermediary overhead and use native .dll (.so) - thought that not tested yet - I suggest the mexCallMATLAB become implemented as a backup alternative used when if mex/dll is not compiled.
2) "mex" compilation (i.e. "to mex or not to mex?"): On my Windows platform and with Matlab v.7.1., compiling & linking <a>.C files (containing mexFunction and linking the mex libs) as DLLs with either MSVC or minGW directly creates a DLL which can be called either with extension .DLL, or simply renamed as <a>.mexXX (e.g. changing extension from .DLL to .mexw32 on Win 32bit platform).
Thus, it seems that this direct approach does not require use of mex command (or the mexopts.bat),and, I wander if anyone tested if this approach works on Linux too(?). For time being I intend to use it at least for the prototyping in Windows (i.e. considering that n-order is not expected to be re-compiled on-the-go for the start at least).
3) Re. MATLAB LAPACK: Thanks for the suggestion to use it too but now I need to resolve some other issues. I.e., Due to MATLAB lapack idiosyncrasies:
a) MathWorks' mwlapack.lib in earlier versions was containing both lapack and blas, but it has later been split into two libraries: mwlapack.lib - without blas - and the blas.lib - this creating some though small, linking problems,
b) lapack functions in windows not having "_" suffix but having it on the Linux platforms!?(%$£"@*), - i.e., this creating some more linking problems and poss some additional changes to the code to allow for the conditional compilation (i.e. some is already present in dynare++ and the current Dynare sylv mex source)
c) apparently, according to MathWorks documentation, on windows, their mwlapack is supported only for MSVC (and I could not get it to link properly with minGW but poss. due to different reasons) !? (ditto.).
Again, as we may not be recompiling n-order on the fly, for a time being it seems that it may be simpler to use minGW and the "native" lapack and atlas libraries for generating n-order .DLL rather than Matlab's LAPACK- again, at least for prototyping and poss. its first release?!.
4) Regarding mxMalloc - Michel was right - it is recommended for all malloc calls within mex files so that Matlab can ensure freeing memory when mex call is finished, but it is not obligatory and, probably not necessary when if the C/C++ code carefully deletes all allocated memory itself (which seems to be the case with both Dynare++ k-order-perturbation and the Markov Switching code but should be checked but I will double check it.)
Please do let me know your thoughts.
Best regards
George