Dev September 2009

dev@dynare.org

8 participants
36 discussions

[Trac] #39: Make warnings about unitialized params/vars optional
by Trac Dynare 06 Nov '09

06 Nov '09

#39: Make warnings about unitialized params/vars optional --------------------------+------------------------------------------------- Reporter: sebastien | Owner: sebastien Type: bug | Status: new Priority: minor | Milestone: 4.1 Component: Preprocessor | Version: Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/39> Dynare <http://www.dynare.org> The Dynare project

1 1

Re: [DynareDev] C++ DsgeLikelihood
by Michel Juillard 04 Nov '09

04 Nov '09

Dear George, thanks for the message. The issue needs to be discussed carefully. 1) We are trying to get rid of most global variables and to pass oo_, options_ and M_ as arguments. There is no good reason, why this has not been done yet in DsgeLikelihood.m 2) Besides a cleaner more robust code, we learned that accessing global variables in Matlab is expensive, and, most likely it is also true for Mex library 3) DsgeLikelihood++ is not primarily meant for calling from Matlab, but from a C++ version of dynare_estimation_1.m 4) There are only two of these variables that are changed in DsgeLikelihood: - M_.params, but a local version of modified params vector should probably be an argument to dynare_resolve - options_.kalman_algo that passes back the choice of Kalman algorithm. We can probably find another mechanism to pass back this information to Matlab. 5) My preference would be to have one C++ class that contains all the parameters from M_, options_ and bayestopt_ (the latter needs to be rethought), needed by the C++ estimation functions. This class should be initialized at the instanciation of the top class (here dynare_estimation++) from M_ and options_ pointers passed as arguments 6) One needs to think about a similar mechanism for output variables. 7) I have three problems with the current structures that we use *M_ contains parameters describing the model (OK) *oo_ contains output. We may want to distinguish output that is only made available to the user and intermediary output that is meant to be used by other routines such as structure dr. It could make accessing these intermediary results faster * options_ contains both real options_ and information on the current state of Dynare computations (such as kalman_algo here), These should probably be separated * bayestopt_ (and estim_params) is currently a mess and should be reconsidered. It is mainly meant to contained parameters describing the priors that are deduced from user input passed by the preprocessor in estim_params 8) In summary, for now, in DsgeLikelihood++, you should simply refer to a C++ version of these objects that we will build later. Best Michel G. Perendia wrote: > Dear Michel > > Regarding design of the interface with Matlab (and Octave?), there are many > variables from global structures that need to be referred to from various > parts of estimation (and some updated too). > > Is it ok if I make DsgeLikelihood++ system refer to options_, oo_ and other > large structures (and some other variable) using mex functions > mexGetVariable (and, if needed, mexPutVariable for updates) rather than > trying to pass whole structures at the call time and creating C++ instances > of all or (large) subsets of their data. > > e.g. > const mxArray *mexExt = mexGetVariable("base", "mexext"); > or > const mxArray *M_ = mexGetVariable("caller", "M_"); > > That will reduce number of variables that need to be passed on call and > writing code on their breaking down and passing around from mexFunction to > the other modules. > > I can optimise access to read-once only to reduce DLL-Matlab traffic too > using a permanent class on the lines of: > > class MexStruct > { > mxArray* mexStruct; > const char *base; // one of: base, caller, global > const char *structName; > MexStruct( char *sBase, char * mexStructName) > : base(sBase), structName(mexStructName) > { > mexStruct=mexGetVariable(base, structName); > } > mxArray * > getMexStructField(char * field) > { > return mxGetField(mexStruct, 0, field); > } > void > putMexStruct(){mexPutVariable(base, structName, mexStruct);} > void > setMexStructField(char * field, mxArray *newVal) > { > mxArray *fp = mxGetField(mexStruct, 0, field); > mxDestroy(fp) > mxSetField(mexStruct,0,field, newVal); > } > } > > Some global variables in those structures also need to be set so the above > class' methods can pass back updated global variables too at the end of the > DsgaLikelihood. Also, as another advantage of this model, they can be passed > back even in real time when if that may be needed for parallelisation. > > Best regards > > George > Mob. +44(0)7951415480 > artilogica(a)btconnect.com > > ----- Original Message ----- > From: "Michel Juillard" <michel.juillard(a)ens.fr> > To: "G. Perendia" <george(a)perendia.orangehome.co.uk> > Sent: Monday, August 24, 2009 11:15 AM > Subject: Re: C++ DsgeLikelihood > > > >> Hi George, >> >>> Dear Michel >>> >>> 1) Re email below, due to problem of code for calling >>> > <model>dynamic.dll, > >>> needed by estimation but being in the same file with mexFunction in >>> k_order_perturbation.cpp >>> >>> Alternatives: >>> a) I can use (a different) literal, e.g. >>> KORDERPERT_MEX_FILE >>> and compile k_order_perturbation.cpp for k_order_perturbation.dll using >>> -DKORDERPERT_MEX_FILE >>> and for DsgeLIkelihood/estimation without, - probably the easiest >>> > solution > >>> to implement and maintain until situation may change, - or, >>> >>> b) I can split k_order_perturbation.cpp in two - >>> > k_order_perturbation.cpp > >>> with mexFunction and another file for calling <model>dynamic.dll which >>> > will > >>> be placed into korderpertlib.a and linked to DsgeLikelihood/estimation >>> > too - > >>> probably the optimal solution. or, >>> >>> c) copy k_order_perturbation.cpp code for calling >>> > <model>dynamic.dll.into > >>> another file and keep it under DsgeLikelihood/estimation and have >>> DsgeLikelihood refer to k-orderpertlib for the rest - this may duplicate >>> effort on maintaining the dynamic.dll call management code but it is a >>> > clear > >>> cut. >>> >>> >>> >> I prefer 1.b) too >> >>> 2) Shall I treat C++ DsgeLIkelihood >>> a) as an extension of KF or KORDERPERT and put its code in one of those >>> > 2 > >>> mex/source directories, or >>> >>> b) create a new one, e.g. estimation, with its makefiile referring to >>> > the > >>> code and objects in the other two? >>> >>> >>> I suggest 1.b and to treat DsgeLIkelihood as a subdirectory of kalman >>> directory which will refer to korderpertlib and kalman src. >>> >>> >>> >> I prefer 2.b, because DsgeLikelihood calls Kalman code and it is weird >> to have it in a subdirectory of kalman >> >> All the best, >> >> Michel >> >>> Please let me know if that is OK with you. >>> >>> Best regards >>> >>> George >>> >>> ----- Original Message ----- >>> From: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>> To: "Michel Juillard" <michel.juillard(a)ens.fr> >>> Sent: Friday, August 21, 2009 3:50 PM >>> Subject: Re: C++ DsgeLikelihood >>> >>> >>> >>> >>>> Dear Michel >>>> >>>> In k-order-perturbation makefile someone(you?) defined literal >>>> -DMATLAB_MEX_FILE >>>> for several cpp files, some of which do not contain mexFunction, e.g. >>>> >>>> k_order_test_main.o: k_order_test_main.cpp >>>> gcc -DMATLAB_MEX_FILE ... >>>> >>>> k_ord_dynare.o: k_ord_dynare.cpp k_ord_dynare.h >>>> gcc -DMATLAB_MEX_FILE .... >>>> >>>> k_order_perturbation.o: k_order_perturbation.cpp k_order_perturbation.h >>>> gcc -DMATLAB_MEX_FILE .... >>>> >>>> nlsolve.o: $(DYNAREPPDIR)/src/nlsolve.cpp >>>> gcc -DMATLAB_MEX_FILE .... >>>> >>>> whereas only k_order_perturbation.cpp contains mexFunction(). >>>> >>>> What is that switch/literal used for? >>>> >>>> I wandered if it is OK to use that literal and set a switch in >>>> k_order_perturbation.cpp to exclude mexFunction from compilation when >>>> > not > >>>> defined so that the file can be used with other mexFunctions such as >>>> > the > >>> one >>> >>> >>>> for DsgeLikelihood., e.g. >>>> >>>> #ifdef MATLAB_MEX_FILE // exclude mexFunction for other applications >>>> extern "C" { >>>> void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const >>>> > mxArray > >>>> *prhs[]) >>>> { >>>> ... here goes mexFunction .: >>>> } >>>> }; // end of extern C >>>> #endif // ifdef MATLAB_MEX_FILE >>>> >>>> Oterwise I can set another literal. >>>> >>>> Best regards >>>> >>>> George >>>> >>>> ----- Original Message ----- >>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>> Sent: Tuesday, August 18, 2009 12:36 PM >>>> Subject: Re: C++ DsgeLikelihood >>>> >>>> >>>> >>>> >>>>> Hi George, >>>>> >>>>> currently there are 3 different cases: >>>>> >>>>> 1) the steady state is not affected by estimation. This is the case >>>>> > that > >>>>> we are implementing now >>>>> 2) A Matlab function is provided by the user to compute the steady >>>>> > state > >>>>> as a function of model's parameters. >>>>> The implementation is cumbersome for the user and should become a >>>>> feature of the preprocessor. As long as the definitive version is not >>>>> done, there is no point in losing time writing a C interface for that >>>>> 3) The steady state must be solved for by calling a nonlinear equation >>>>> solver. We will need to implement this as well, but it is a lower >>>>> priority. I would like to have the entire estimation chain in C++ >>>>> working first with just a constant steady state. >>>>> >>>>> All the best, >>>>> >>>>> Michel >>>>> >>>>> >>>>> G. Perendia wrote: >>>>> >>>>> >>>>>> Dear Michel >>>>>> >>>>>> Regarding steady state, can you remind me why we can not use ss >>>>>> >>>>>> >>>> calculation >>>> >>>> >>>>>> inside the k-order-perturb ? >>>>>> Can we than instead call Dynare Matlab steady state calculation, >>>>>> >>>>>> >>>> currently >>>> >>>> >>>>>> called from resol.m, from estimate_1.m just before calling the new >>>>>> >>>>>> >>> C++ >>> >>> >>>>>> DsgeLikelihood (or from a new Matlab shell DsgeLikelihood_m.m that is >>>>>> >>>>>> >>>> then >>>> >>>> >>>>>> calling C++ DsgeLikelihood) where new C++ resol will not call ss >>>>>> calculation as the Matlab one does? >>>>>> >>>>>> Best regards >>>>>> >>>>>> George >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk> >>>>>> Sent: Monday, August 17, 2009 8:37 PM >>>>>> Subject: Re: C++ DsgeLikelihood >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi George, >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Should I suppose that the C++ DsgeLikelihood would also include >>>>>>>> > C++ > >>>>>>>> versions of: >>>>>>>> resol.m >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> yes, this mainly calls first order solution in dr1.m >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> kalman_transition_matrix.m >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> yes >>>>>>> >>>>>>> >>>>>>> >>>>>>>> and >>>>>>>> the 1st order part of the k-ord_pert version of dr1.m that will be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> calling >>>>>> >>>>>> >>>>>> >>>>>>>> k-order_perturbation for 1st order only, either as a DLL (as it >>>>>>>> >>>>>>>> >>> does >>> >>> >>>>>> now) >>>>>> >>>>>> >>>>>> >>>>>>>> or incorporating it statically? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> first order solution should be linked statically >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> May I then also assume that >>>>>>>> >>>>>>>> a) set_state_space.m and the kstate preamble will in future be >>>>>>>> >>>>>>>> >>>> performed >>>> >>>> >>>>>>>> before calling DsgeLikelihood, and not repeatedly within dr1 and >>>>>>>> > its > >>>>>>>> >>>>>> future >>>>>> >>>>>> >>>>>> >>>>>>>> C++ version - as I remember has already been planned? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> yes, we will have to implement such a mechanism >>>>>>> >>>>>>> >>>>>>> >>>>>>>> b) Ramsey will not be part of it for now >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> correct >>>>>>> >>>>>>> >>>>>>> >>>>>>>> c) I need to check but I think I may not need to code >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> transition_matrix.m >>>>>> >>>>>> >>>>>> >>>>>>>> and use the info 3/4 test currently in dr1: >>>>>>>> if nba > nyf info(1) = 3; >>>>>>>> elseif nba < nyf info(1) = 4; >>>>>>>> as a similar test already exist in k-ord-pert. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> probably correct >>>>>>> >>>>>>> >>>>>>> >>>>>>>> d) Also, we seem to need a new algorithm to handle exogenous >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> deterministic >>>>>> >>>>>> >>>>>> >>>>>>>> variables i.e. when M_.exo_det_nbr > 0 ? They are not currently >>>>>>>> >>>>>>>> >>>> handled >>>> >>>> >>>>>> for >>>>>> >>>>>> >>>>>> >>>>>>>> k-order perturbation. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> no, there is no estimation with exogenous deterministic variables >>>>>>> >>>>>>> >>>>>>> Best >>>>>>> >>>>>>> Michel >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Michel Juillard" <michel.juillard(a)ens.fr> >>>>>>>> To: "G. Perendia" <george(a)perendia.orangehome.co.uk>; "Joe >>>>>>>> > Pearlman" > >>>>>>>> <j.pearlman(a)londonmet.ac.uk> >>>>>>>> Sent: Friday, July 31, 2009 8:46 AM >>>>>>>> Subject: Re: lyapunov kalman filter options >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks George, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> .... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> For the next steps, I think that you have now all elements to code >>>>>>>>> >>>>>>>>> >>> a >>> >>> >>>>>> C++ >>>>>> >>>>>> >>>>>> >>>>>>>>> version of DsgeLikelihood.m Of course you should restrict it to >>>>>>>>> > the > >>>>>>>>> >>>>>> case >>>>>> >>>>>> >>>>>> >>>>>>>>> of stationary models. >>>>>>>>> >>>>>>>>> As we haven't solved yet the issue around computing the steady >>>>>>>>> >>>>>>>>> >>> state, >>> >>> >>>>>>>>> for the time being, limit yourself to the case where the steady >>>>>>>>> >>>>>>>>> >>> state >>> >>> >>>>>>>>> doesn't change throughout estimation. >>>>>>>>> >>>>>>>>> Best >>>>>>>>> >>>>>>>>> Michel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >>> >>> >> > > > > >

3 17

[Trac] #41: bug in resid.m that reset initial values when used after ENDVAL
by Trac Dynare 29 Oct '09

29 Oct '09

#41: bug in resid.m that reset initial values when used after ENDVAL --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: critical | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- resid shouldn't modify oo_ or any global variables Maybe it should check against <fname>_static rather than <fname>_dynamic -- Ticket URL: <https://www.dynare.org/trac/ticket/41> Dynare <http://www.dynare.org> The Dynare project

1 2

New identification files
by Sébastien Villemot 15 Oct '09

15 Oct '09

Hi Marco, Thanks for your identification routines. Just to remind you that you need to add copyright notices at the top of your new files, as explained on: http://www.dynare.org/DynareWiki/CodingStandards#Copyrightnotice-1 Best, -- Sébastien Villemot

3 8

Re: [DynareDev] operators
by Michel Juillard 08 Oct '09

08 Oct '09

houtan wrote: > Dear Sébastien and Michel, > > I have made the requested changes but have a few minor questions. > > 1) As we are outputing the tsid as opposed to a variable name, I have > created oLatexDynamicSteadyStateOperator but allowed it to perform the > same operation as oMatlabDynamicSteadyStateOperator. Is this OK? > > 2) Though it is not in the specification on the Operator web page, I > have implemented oMatlabDynamicSteadyStateOperator for eExogenousDet. > In this case, it writes "oo_.exo_det_steady_state(...)". > > 3) Having made the changes, I gave it a first test with example1.mod, > placing the steady_state operater in different places to see if it was > parsing correctly. Though it seems to be parsing as per the rules > discussed on the web page, in Matlab I did continually encounter the > errors of the form: > ??? Undefined variable "oo_" or class "oo_.exo_steady_state". > ??? Undefined variable "oo_" or class "oo_.steady_state". > > I just wanted to bring this to your attention. > Thanks Houtan, you are right, there is a flaw in the specification: oo_ is not know to function <fname>_dynamic.m There are two solutions: 1) add steady_state to the list of arguments of this function. This is probably more elegant. The drawback is that we increase the number of arguments of the function for a rarely used feature 2) call Matlab global variable oo_ from inside <fname>_dynamic.m. The preprocessor can add the code only for those models that actually use the STEADY_STATE operator. In this case, it will be slower than 1), but the code doesn't change for the majority of cases. What do you think, everybody? Note that what we choose will need to be also implemented in the evaluator of the bytecode. Best Michel > I think that's it. Otherwise, the changes were pretty straightforward. > I have uploaded it to svn. > > Best, > Houtan > > > > > > 2009/9/10 Sébastien Villemot <sebastien.villemot(a)ens.fr > <mailto:sebastien.villemot@ens.fr>> > > Le mercredi 09 septembre 2009 à 19:47 -0400, houtan a écrit : > > For me, the only way we could have the desired output for a dynamic > > model (using the proposed procedure of modifying only > > UnaryOpNode::writeOutput() and dropping datatree.isDynamic()) is by > > using a modified version of IDEA 4 (shown below). In other words, I > > don't see how changing the output_type from dynamic to static will > > produce the dynamic model output (oo_.(exo_)steady_state(...)), > which > > is only located under case oMatlabOutsideModel. > > You're perfectly right, for the moment oMatlabOutsideModel is the only > one which creates the right output for Matlab code. It is my mistake, > sorry for creating confusion and for not having read carefully your > message. > > I think that we should create new types in the ExprOutputType > enumeration. For example we could create something like > oMatlabDynamicSteadyStateOperator, which would be used when > encountering > a steady state operator in the dynamic model. It might end up to do > exactly the same than oMatlabOutsideModel, but it is probably more > readable to use a different name since it's a different > functionnality. > > We also need to deal with three other types of output: > * C output in oCDynamicModel: since we are going to drop C output > in the > near future, if you encounter a steady state operator in that > mode, just > exit the preprocessor with a message like "not implemented" > * Matlab output for sparse model (oMatlabDynamicModelSparse): I > need to > discuss with Ferhat on how to deal with that: for the moment, just > exit > with a "not implemented" message > * Latex output for dynamic model (oLatexDynamicModel): here again we > should create a new output type (such as > oLatexDynamicSteadyStateOperator), which would add bars over variable > names (for variable $x$, it could write $\bar{x}$) > * Bytecode output: you need not to modify UnaryOpNode::compile(). We > should however modify the bytecode interpreter (bytecode DLL in > mex/sources/bytecode). I also need to discuss that with Ferhat, > just do > nothing for the moment about that. > > > > Also, might we still need the isDynamic method to use in > > UnaryOpNode::composeDerivatives()? > > You're probably right, I think you can't escape using this method at > this point. > > > As you can see, implementing operator is not so straightforward, so > don't worry if it takes times to converge to the best solution. > > Best, > > -- > Sébastien Villemot > > >

4 11

New build system
by Sébastien Villemot 07 Oct '09

07 Oct '09

Hi everyone, I have finished the new build system for Dynare. With a single "make" command you can now build Dynare preprocessor, MEX files for MATLAB and Octave, Dynare++, all the documentation. The procedure is described on: http://www.dynare.org/DynareWiki/BuildingDynareFromSource I would like to get your feedback about this, both in terms of functionality and of documentation. Two more platforms still need to be tested and documented: * Windows 64-bit, using MinGW64 * MacOS I will take care of Windows 64-bit. Houtan: when you have the time, could you test the procedure on MacOS? Maybe you could also write a section on the wiki page when you have finished. I will soon integrate the k-order DLL to that build system. Best, -- Sébastien Villemot

3 18

[Trac] #42: Fix problem of order 2 with leads of two or more
by Trac Dynare 07 Oct '09

07 Oct '09

#42: Fix problem of order 2 with leads of two or more --------------------------+------------------------------------------------- Reporter: sebastien | Owner: michel Type: bug | Status: new Priority: blocker | Milestone: 4.1 Component: Core M-files | Version: 4.0.4 Keywords: | --------------------------+------------------------------------------------- -- Ticket URL: <https://www.dynare.org/trac/ticket/42> Dynare <http://www.dynare.org> The Dynare project

1 2

Leads and lags of 2 or more
by Sébastien Villemot 06 Oct '09

06 Oct '09

Hi all, I have made an important change in the preprocessor, which should fix an important bug that Michel has discovered. It turns out that Dynare gives a wrong result for stochastic approximation at order 2 for models with leads of 2 or more. In order to fix that bug, the preprocessor now removes all leads and lags >=2 for a stochastic model. It does so by creating auxiliary variables and equations, so that the model has only one lead and one lag. This is the strategy used by Dynare++, and it is the easiest way to fix that bug. So don't be surprised if Dynare reports more equations than you declared, and if some variables called "AUXLEAD..." and "AUXLAG..." appear. You can examine the result of the transformation by using the "write_latex_dynamic_model" command (see http://www.dynare.org/DynareWiki/ModelLatexOutput ) The bug should now be fixed (although I now have a crash on GIMF in dr1.m). What remains to be done is the adaptation of the output routines, so that the output remains the same than before (instead of having the auxiliary variables in it). Houtan: for the auxiliary variables related to the expectation operator, you can reuse the framework that I have setup. * in SymbolTable.hh, add a new enum to aux_var_t, a new method for adding your type of aux var, and if needed new fields to AuxVarInfo * add a new method to class DynamicModel (similar to those for substituting leads and lags) * call that new method from ModFile::transformPass(), *before* the methods substituting leads and lags * for the initialization of new aux variables (since they are not declared in the "initval" block, the preprocessor needs to give an initial value to them): you need to add your new auxiliary equations to ModelTree::aux_equations; this should suffice, the mechanism that I have setup in DynamicModel::fillEvalContext() and StaticModel::writeAuxInitval() should take care of it Best, -- Sébastien Villemot

3 5

[Trac] #43: bug in 2nd order approximation
by Trac Dynare 25 Sep '09

25 Sep '09

#43: bug in 2nd order approximation --------------------------+------------------------------------------------- Reporter: michel | Owner: michel Type: bug | Status: new Priority: critical | Milestone: 4.1 Component: Core M-files | Version: Keywords: | --------------------------+------------------------------------------------- Change in the order of declaration of endogenous variables affects 2nd order approximation. Bug reported by Huixin 9/21 -- Ticket URL: <https://www.dynare.org/trac/ticket/43> Dynare <http://www.dynare.org> The Dynare project

1 2

pdf generators in C
by G. Perendia 22 Sep '09

22 Sep '09

Hi Does anyone know of good source code for pdf generators that is available in C/C++ for beta, gamma etc distributions? Best regards George

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev September 2009