[Developers] return_arrays_increment();

[dave fournier]

John Sibert wrote:

It is because the circular queues are fairly long. (that can be set at
compile time for the libs. so if you don't do a lot of
arithmetic before you use one of them there will not be a problem.

It seems that at present they are
so circular queues are 70 lon and you casn nest up to 25 of them.

int gradient_structure::RETURN_ARRAYS_SIZE = 70;
int gradient_structure::NUM_RETURN_ARRAYS = 25;
> Hi Mark -
>
> A couple of comments on libraries and FUNCTIONS.
>
> I'm not sure what you mean by libraries. A library is simply a file
> containing a bunch of object files. Make in library in linux is
> trivial using ar, and under windows, most compilers provide a tool to
> assemble object files into a library. The header files must also be
> provided, of course, and I would encourage (or perhaps even require)
> people who want to contribute libraries to document the API using
> doxygen.
>
> I'm also confused about the lack of RETURN_ARRAYS_INCREMENT(); and
> RETURN_ARRAYS_DECREMENT(); statements in the FUNCTION examples (and
> indeed in many FUNCTIONs that I have written.) It appears that you can
> get away without them in some applications, but most definitely not in
> others.
>
> Cheers,
> John
>
> Mark Maunder wrote:
>> 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