[Developers] Control files and basic MCMC

[Steve Martell]

Dave,
 I was not able to get the source code to compile using:

<INIT_BOUNDED_NUMBER_DEF>({name}\({float_num_exp},{float_num_exp},{num_exp}\))|
<INIT_BOUNDED_NUMBER_DEF>({name}\({name}\)) {

in tpl2cpp.lex

Instead I changed this to:
<INIT_BOUNDED_NUMBER_DEF>({name}\({float_num_exp},{float_num_exp},{num_exp}\)) |
<INIT_BOUNDED_NUMBER_DEF>({name}\({float_num_exp}\)) {

.  Still trying to get an example to compile but so far I get errors of the like in the allocate function:

error: no matching member function for call to 'allocate'
  dummy.allocate(lup,"dummy");

Steve


On Jan 14, 2014, at 10:12 AM, dave fournier <davef at otter-rsch.com> wrote:

> On 14-01-10 12:00 PM, Arni Magnusson wrote:
>
>
> In terms of setting the value of the parameter using the 4th element of the vector
> something like
>
>  void param_init_bounded_number::allocate(const data_vector & v,
>    const char * _s)
>  {
>   int phz=int(v(1));
>   double lb=v(2);
>   double ub=v(3);
>   allocate(lb,ub,phz,_s);   // this will read in the value of the parameter from whatever par file
>   if (v.indexmax()>3) value(*this)=v(4);   // now set the value to what you want
>  }
>
> Difficulty is that it will always set the value the parameter to v(4).  What if you want to
> start from the values in the par file?  Also the order in v has been changed from
> the standard order.  Better might be
>
>
>   double lb=v(1);
>   double ub=v(2);
>   int phz=int(v(3));
>
>
>
>
>
>
>
>> Happy new year to you, core developers!
>>
>> As Johnoel mentions, there is a wishlist item #11 in the Reykjavik Workshop Report that says:
>>
>> "Flag/switch class Simplify the use of control and MCMC files, perhaps MFCL-like object capability"
>>
>> This wishlist item is really about two things:
>>
>> ---
>>
>> (1) Sometimes we want to make ADMB applications general and user-friendly. By user-friendly, I don't mean beginner-friendly, but an efficient interface for running a variety of related models without recompiling. Fixing parameters and setting bounds, phases, and initial values, and various model-specific settings. This is sometimes done inside the main data file and sometimes in a separate control file.
>>
>> Take http://www.hafro.is/~arnima/pella/pella.tpl for example. The data and parameter sections are rather convoluted, in order to provide a PLUI (phase,lower,upper,init) interface for controlling the parameter estimation.
>>
>> Of course the exact implementation will vary from model to model. But writing the PLUI code feels unnecessarily clunky and repetitive. The code for switching to the control file is rather ugly, and and so is the code to set the parameter phases, bounds and inits. Perhaps these tasks are so common and so useful that we can provide some new functionality to make them easier for the ADMB programmer.
>>
>> This example is a tiny model with very few parameters. The importance of this wishlist item becomes greater with dozens of parameters.
>>
>> ---
>>
>> (2) MCMC is an important feature of ADMB. I like telling potential and new users that it's a piece of cake to run MCMC for any ADMB model: you basically just type mymodel -mcmc.
>>
>> Well, sort of.
>>
>> The http://www.hafro.is/~arnima/pella/pella.tpl example shows a common approach. First we have if(mceval_phase()) write_mcmc(); and later we have FUNCTION write_mcmc, with a long workaround to put a header for each column in the MCMC output.
>>
>> Wouldn't it be cool if the user could actually type mymodel -mcmc without all that stuff, and get a text file with column headers, ready to plot. For the most advanced users, the PSV file is just that, but for the majority of users that's not a very intuitive or accessible format. Again, a task that is so common and so useful could be made easier to use.
>>
>> A related idea is an MCMC_SECTION with a stream object that's ready to use, mcmc<<"blah"<<..., much like the report stream object in the REPORT_SECTION.
>>
>> ---
>>
>> As you can tell, I'm interested in both of these wishlist items. They may not be top priority, but potential areas where ADMB could be a bit smoother around the edges. We can revisit them at the next workshop, to decide whether and how some of this could be done. We did not look at this at the Reykjavik workshop, but included it in the report as a reminder of a discussion item after the workshop.
>>
>> All the best,
>>
>> Arni
>>
>>
>>
>> On Fri, 10 Jan 2014, Johnoel Ancheta wrote:
>>
>>> Hi all,
>>>
>>> Happy New Years.
>>>
>>> I looked over the workshop report and noticed a priority task "Flag/Switch class to simplify the use of control and MCMC files..."
>>>
>>> It says someone is working on this, but did not say who?
>>>
>>> Johnoel
>>>
>> _______________________________________________
>> Developers mailing list
>> Developers at admb-project.org
>> http://lists.admb-project.org/mailman/listinfo/developers
>>
>
> _______________________________________________
> Developers mailing list
> Developers at admb-project.org
> http://lists.admb-project.org/mailman/listinfo/developers


________________________________

This internet e-mail message, and any files transmitted with it, contains confidential, privileged information that is intended only for the addressee. If you have received this e-mail message in error, please call us at (206) 634-1838 collect if necessary) and ask to speak to the message sender. Nothing in this e-mail or the act of transmitting it, is to be construed as a waiver of any rights or privileges enjoyed by the sender or the International Pacific Halibut Commission pursuant to the International Organizations Immunities Act, 22 U.S.C. Sec. 288 et seq.