Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] List/table recursion limits?

OK, the consensus seems to be no recursion limit. Even with dynamic 
allocation, modern software often has practical limits. There have been 
OS recursion bugs where excessive depths caused stack overflows even 
with dynamic memory. But, it probably makes sense to leave this 
implementation dependent.

Just to be concise, it might be good to put a short statement in the 
spec that there is no defined limit.

Thanks,
Joe


Herbert J. Bernstein wrote:
> Function invocations aside, the actual recursive depth for given data file 
> conforming to a set of dictionaries is determined by the types of the 
> list, array and table typed tags in those dictionaries.  At the moment, 
> the worst depth seems to be 2 for import lists and 2-D arrays.  For 
> Fortrans without dynamic array allocation, you do have to preset such 
> depths (with parameter statements).  To detect runaways in the parser, I 
> did a lot of debugging of CIFtbx 4.1.0 with a depth limit of 3, but so as 
> not to have to worry about it in production use, the current limit is set 
> at 20.
> 
> Fortran is not practical for direct method invocation, so some static 
> depth limit greater than or equal to 3 should suffice for the immediate 
> furuter.  For python or C, which are a more appropriate environment for 
> method invocation, there is no need for a specific depth limit, and, as 
> Nick points out, you could end up going very deep, so a hard limit is 
> likely to cause trouble.
> 
> I would suggest not imposing a specific limit, and leave that as a 
> configuration detail for setting up software to be able to deal with 
> specific scientific domains.  Even for Fortran, it is easy enough to 
> change a parameter (in my case MAXDEPTH) when necessary.
> 
> Regards,
>    Herbert
> =====================================================
>   Herbert J. Bernstein, Professor of Computer Science
>     Dowling College, Kramer Science Center, KSC 121
>          Idle Hour Blvd, Oakdale, NY, 11769
> 
>                   +1-631-244-3035
>                   yaya@dowling.edu
> =====================================================
> 
> On Mon, 7 Dec 2009, Nick Spadaccini wrote:
> 
>>
>>
>> On 5/12/09 4:30 AM, "Joe Krahn" <krahn@niehs.nih.gov> wrote:
>>
>>> It may be useful to put practical limits on recursion depth. Maybe 8 is
>>> sufficient? I suspect that most CIF developers want to keep nesting
>>> fairly shallow, given that CIF disallows and STAR loop nesting.
>> Is it necessary to apply a restriction to the recursive depth? As you say
>> humans will keep it fairly shallow anyway to keep things clear, but I can
>> foresee a machine generated data value being quite deep.
>>
>> If I was to output as a CIF2 value (not that I would ever do this) the
>> entire internal representation of a domain dictionary category (and its
>> attributes), including methods and data file values, it would be a deeply
>> recursive compound data structure of significant complexity. But it would
>> all fit in a Table.
>>
>> cheers
>>
>> Nick
>>
>> --------------------------------
>> Associate Professor N. Spadaccini, PhD
>> School of Computer Science & Software Engineering
>>
>> The University of Western Australia    t: +61 (0)8 6488 3452
>> 35 Stirling Highway                    f: +61 (0)8 6488 1089
>> CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nick
>> MBDP  M002
>>
>> CRICOS Provider Code: 00126G
>>
>> e: Nick.Spadaccini@uwa.edu.au
>>
>>
>>
>>
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.