Error: C Stack Usage Is Too Close to the Limit

Error: C stack usage is too close to the limit at R startup

Your user .Rprofile file is loading itself recursively for some reason:

if (file.exists("~/.Rprofile")) {
base::sys.source("~/.Rprofile", envir = environment())
}

From your comments it seems that these lines are inside ~/.Rprofile (~ expands to the user home directory, i.e. /Users/mycomputer in your case, assuming mycomputer is your user name).

Delete these lines (or comment them out), they don’t belong here. In fact, the file looks like it’s a template for a project-specific .Rprofile configuration. It would make sense inside a project directory, but not as the profile-wide user .Rprofile.

The logic for these files is as follows:

  • If there is an .Rprofile file in the current directory, R attempts to load that.
  • Otherwise, if the environment variable R_PROFILE_USER is set to the path of a file, R attempts to load this file.
  • Otherwise, if the file ~/.Rprofile exists, R attempts to load that.

Now, this implies that ~/.Rprofile is not loaded automatically if a projects-specific (= in the current working directory) .Rprofile exists. This is unfortunate, therefore many projects add lines similar to the above to their project-specific .Rprofile files to cause the user-wide ~/.Rprofile to be loaded as well. However, the above implementation ignores the R_PROFILE_USER environment variable. A better implementation would therefore look as follows:

rprofile = Sys.getenv('R_PROFILE_USER', '~/.Rprofile')
if (file.exists(rprofile)) {
base::sys.source(rprofile, envir = environment())
}
rm(rprofile)

C stack usage 7970960 is too close to the limit

You almost certainly have a bogus function called exp in your search path somewhere, which calls itself. It may be in your workspace (global environment), or (less likely but possible) in a package you have loaded. (It's also possible that the infinite recursion is defined in a more complicated way, i.e. rather than exp() calling itself, it calls something that calls it back ...)

The normal, expected result of find("exp") is

[1] "package:base"

Suppose you have defined a recursive exp function in your workspace:

exp <- function(x) exp(x)

Then exp(1) will give

Error: C stack usage 7969716 is too close to the limit

and find("exp") will give

[1] ".GlobalEnv" "package:base"

i.e. there is an exp in the global environment that R will see before it sees the built-in function in the base package.

If you do have something like this going on, starting a new R session will help (unless the object is in a saved workspace that gets restored when the session starts), or rm("exp").

Error: C stack usage when compile R Markdown

I just delete the .Rprofile .-.

Error: C stack usage 7970184 is too close to the limit

Yes, your recursion formulation is bad,
both technically and performance-wise:

While a recursion is known that may help to formulate some problems in a smart way, the core logic is, that it has to have some "bottom" line, where the recursion stops from any diving deeper -- being an easily decideable point -- from which the so far nested recursions start to return back and ( being-on-the-road back to the first caller ) the recursion-returning process assembles the correct answer as a side-effect of this emerging back from the deepest level from that known, easily decideable point of a known return value.

Simply put, this is missing in your algorithmisation.

Your code will try to dive deeper and deeper ( back in time ) even at the very first historical bar of the TimeSeries data.

If you handle this case properly, the code will stop its succsidal habit to dive infinitely deep and will start to assemble a result.

Next comes performance:

Recursion is fine for a one-stop calculus.

Recursion is bad idea for repetitive calculus, if the already calculated "steps" get re-calculated again, if a poor value re-use policy enforces to again and again re-dive all the way back again and again to the very same "terminal point", just due to the original ( preformance not-optimised ) recursion formulation.

Let's show it on factorial.

Using its trivial, simplest ever, form of recursion, for illustration purposes, whereas all the principles are relevant to any more complex recursion-based processing - this one just simply fits on a just one SLOC:

factorial( N ) = ( N == 1 ) ? 1 : N * factorial( N - 1 )

If it were for calculating just once a factorial( 15 ), one cannot object a single word against having to go the whole chain of:

fact15 = ( 15 * 14 * 13 * 12 * 11 * 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1 )

where missing any single step would yield the process not to compute the factorial correctly.

The problem would be seen in a different light, if next comes a duty to compute just the next one -- the factorial( 16 )

a performance-ignorant implementation would go the same lane there and back again:

fact16 = ( 16 * 15 * 14 * 13 * 12 * 11 * 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1 )

whereas a smart, performance-motivated implementation would never repeat the tail-part of the circus, and would just multiply the head-side:

fact16 = ( 16 * fact15 )

never repeating the part, that has been already computed once.

Do you see the impact?

And imagine the scales of this obvious difference as the recursion-depths gotten grown to some remarkable hundreds, thousands, tens of thousands, hundred of thousands, millions of recursion steps ... repeating each of them any next time again and again and again. No. Never.

This is the core logic of all high-performance, low-latency TimeSeries data-processing, RSI being the clear case, that you have met on your own.



Related Topics



Leave a reply



Submit