Re: [Rd] How deep can/should lists be nested?

From: Richard Cotton <richierocks_at_gmail.com>
Date: Sun, 14 Oct 2012 14:36:29 +0100

I agree that real-world uses of nesting this deep are rare enough to not worry about fixing code (unless there is something extremely trivial that can done).

My main concern is that it doesn't seem to be documented how much nesting is possible, and I couldn't even guess the order of magnitude without trying it.

This was why I thought setting the value to getOption("expressions") might be beneficial - at least the user knows when they have to stop. The simpler alternative may just be to add a line to the documentation to say something like "although lists can theoretically be nested indefinitely, in practice allocation is limited by memory and stack size, typically to tens of thousands of levels".

The obvious place to put such a message would be in ?list, though at the moment there are no nesting examples on the page.

On 14 October 2012 13:39, Prof Brian Ripley <ripley_at_stats.ox.ac.uk> wrote:

> On 14/10/2012 12:53, Duncan Murdoch wrote:

>>
>> On 12-10-14 7:06 AM, Richard Cotton wrote:
>>>
>>> I started idly wondering how deeply lists could be nested, and
>>> couldn't find an explicit limit in the documentation. With this
>>> simple test
>>>
>>> a_list <- list()
>>> count <- 0
>>> repeat
>>> {
>>> a_list[[1]] <- a_list
>>> count <- count + 1
>>> }
>>>
>>> my (Win7, R-2.16.0 devel) machine threw an error when count got close
>>> to 25000.
>>>
>>> The error that stopped it was
>>>
>>> Error: protect(): protection stack overflow
>>>
>>> I don't know how easy it would be to stop such an error occuring, and
>>> it probably isn't that useful to be able to nest lists any further. I
>>> do think it might be useful for users to be able to know how deeply
>>> they can nest lists though.
>>>
>>> Perhaps it would be better to limit nesting to the value of
>>> getOption("expressions"). Does anyone have any strong feelings on
>>> what the correct behaviour should be?
>>
>>
>> There should be no limit other than memory. That overflow you saw is a
>> bug. Not sure it's worth fixing, since 25000 is far beyond any sensible
>> nesting level, but I'll take a look.
>
>
> I'm not so sure it is a bug.  There have to be limits other than the total
> amount of memory (the C stack size is another one): one was reached and the
> computation was stopped cleanly.  We even allow the size of the ppstack to
> be changed in the extremely rare cases where this might matter.
>
> But the real point is that that limit is not on the nesting of lists but on
> that particular way to create a deeply nested list.  We know that some code
> to copy lists is sub-optimal, but we've not been shown a real-world example
> where it mattered enough to prioritize looking into.
>

>>
>> Duncan Murdoch
>
>
>
> --
> Brian D. Ripley,                  ripley_at_stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595



-- 
Regards,
Richie

live-analytics.com
4dpiecharts.com

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Sun 14 Oct 2012 - 13:39:16 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Mon 15 Oct 2012 - 10:50:47 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive