[Rd] How deep can/should lists be nested?
Richard Cotton
richierocks at gmail.com
Sun Oct 14 15:36:29 CEST 2012
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
More information about the R-devel
mailing list