[Developers] return_arrays_increment();

Mark Maunder mmaunder at iattc.org
Sat Sep 19 18:45:46 PDT 2009


I am thinking about putting an article on functions and one on making
libraries in the next ADMB Newsletter. Along with this I want to get a
couple of libraries from existing users to put on the website as a start
to a user created repository of libraries (these would be for use at
your own risk and not official ADMB code). (let me know if you have a
library you would like to contribute) I already have text from Steve
Martell on creating libraries, but I think something on writing
FUNCTIONs in ADMB would be a good companion. If anyone is interested in
writing this let me know. In the mean time, where is all the information
on writing functions in ADMB. The manual uses them a lot including
functions that accept and return variables e.g.

FUNCTION dvariable h(const dvariable& z)
dvariable tmp;
tmp=exp(-.5*z*z + tau*(-1.+exp(-nu*pow(a(a_index),beta)*exp(sigma*z)))
);
return tmp;

The examples don't use the RETURN_ARRAYS_DECREMENT(); commands. Users
also need to know about deep and shallow copies, overloading, ....
(which are probably all C++ commands, but most ADMB users aren't C++
programmers).

Thanks,

Mark



-----Original Message-----
From: developers-bounces at admb-project.org
[mailto:developers-bounces at admb-project.org] On Behalf Of dave fournier
Sent: Tuesday, September 15, 2009 10:04 AM
To: Arni Magnusson
Cc: developers at admb-project.org
Subject: Re: [Developers] return_arrays_increment();

Arni Magnusson wrote:

Well it is not just a matter of sticking a

  RETURN_ARRAYS_DECREMENT();

at the end of the function because there may be a complicated set of
returns in the function.
Interesting that you think of this as low level housekeeping, but R
users are happy to  calculate the derivatives by hand
which strikes me as low level, boring, and error prone.

However the entire return arrays construction is probably not needed any
more.  Compiler optimization may have made it redundant
and even inefficient. You should keep in mind that the code was designed
to run on the first Borland Turbo C++ compiler with 640K under DOS
in 1990.

There are a number of areas where it really shows its age.

> Modellers would be very grateful if they wouldn't have to do this kind
> of low-level housekeeping. Do you think it would be feasible to make
> tpl2cpp insert
>
>   RETURN_ARRAYS_INCREMENT();
>
> and
>
>   RETURN_ARRAYS_DECREMENT();
>
> automatically into the C++ source code, if the return value is of
> dvariable type? This would make ADMB code clearer and much more robust
> to user mistakes.
>
> In terms of backward compatibility, does anyone know if it would be
> okay to repeat the "protective braces" like this,
>
>   RETURN_ARRAYS_INCREMENT();
>   RETURN_ARRAYS_INCREMENT();
>   // code
>   RETURN_ARRAYS_DECREMENT();
>   RETURN_ARRAYS_DECREMENT();
>
> in case the user has also included them in the TPL?
>
> Arni
>
>
>
> On Fri, 4 Sep 2009, Richard Methot wrote:
>
>> There is no mention of this return_arrays queue issue in the ADMB
>> manual. Is there any reason for this being specific to AUTODIF?
>>
>> Rick
>>
>>
>>
>> John Sibert wrote:
>>
>>> Dave provides the "bullet proof" solution. Look near page 3-7 in the
>>> AUTODIF manual.
>>>
>>> John
>>>
>>>
>>>
>>> dave fournier wrote:
>>>
>>>> In this case you can get rid of the error in this way but as I
>>>> already said in general you should read about
>>>>
>>>>    return_arrays_increment();
>>>>    return_arrays_decrement();
>>>>
>>>> if you have functions that return a dvariable object.
>>>
>>
> _______________________________________________
> Developers mailing list
> Developers at admb-project.org
> http://lists.admb-project.org/mailman/listinfo/developers
>


-- 
David A. Fournier
P.O. Box 2040, 
Sidney, B.C. V8l 3S3
Canada
Phone/FAX 250-655-3364
http://otter-rsch.com

_______________________________________________
Developers mailing list
Developers at admb-project.org
http://lists.admb-project.org/mailman/listinfo/developers


More information about the Developers mailing list