[Developers] fix inconsistency in treatment of memory inputs?

John Sibert sibert at hawaii.edu
Thu Apr 7 17:40:02 PDT 2011


I agree with Ian here. It would be really nice if all of the memory size 
variables used the same units (bytes, perhaps), but we need to be 
cautious about making changes just for the sake of consistency (Emerson 
had some choice words on the subject). The risk is breaking a lot of 
legacy code and estimation scripts. Perhaps it might be possible to set 
a variable in the TOP_OF_MAIN_SECTION that would specify that the user 
wants to use the legacy version. We could discuss it in Santa Barbara?

John

On 04/06/2011 11:10 AM, Ian Taylor wrote:
>
> Hi Developers,
>
> Here’s one more email about memory settings, but this time I have an 
> idea for how to avoid some of the confusion that has produced to many 
> emails in the past.
>
> In the file /src/nh99/xmodelm3.cpp, the following code deals with the 
> command line inputs for gbs:
>
> nopt=get_option_number("-gbs",
>
> "-gbs option needs positive integer -- ignored",lssz);
>
> if (nopt>-1 && lssz>0) { gradient_structure::set_GRADSTACK_BUFFER_SIZE
>
> (lssz/sizeof(grad_stack_entry));
>
> }
>
> This appears to take the user’s input, “lssz”, and enter it into the 
> function “set_GRADSTACK_BUFFER_SIZE” after first dividing by the 
> “sizeof(grad_stack_entry)”.
>
> However, in the TPL file, if we use the command
>
> gradient_structure::set_GRADSTACK_BUFFER_SIZE(nnn);
>
> this division by the grad stac k size d e same numerical value 
> produces a different result.
>
> Would it be possible to change the set_GRADSTACK_BUFFER_SIZE (in 
> /src/linad99/gs_set.cpp) so that the division by 
> sizeof(grad_stack_entry) occurs inside that function and thus applies 
> equally to inputs on the command line and in the TPL file?
>
> The AUTODIF manual (page 9-1) says “For historical reasons, the actual 
> amount of memory (in bytes) reserved for the buffer is equal to the 
> value of GRADSTACK_BUFFER_SIZE multiplied by the size (in bytes) of an 
> autodif structure, grad_-stack_entry.” However, perhaps those 
> historical reasons wouldn’t keep us from making things more consistent 
> in the future.
>
> -Ian< /p>
>
>
> _______________________________________________
> Developers mailing list
> Developers at admb-project.org
> http://lists.admb-project.org/mailman/listinfo/developers

-- 
John Sibert
Emeritus Researcher, SOEST
University of Hawaii at Manoa

Visit the ADMB project http://admb-project.org/




More information about the Developers mailing list