I've got a lot recursion relation that takes multiple hours at a time to run. I'm looking for some subtle reasons why it takes so long, and hoping to be able to reduce the time it takes for the more complicated and bigger processes.

My first thought was obviously to do with unnecessary pattern matching, which I've done my best to eliminate. A more seemingly trivial one was how MMA deals with symbols such as x[1] and y[3] etc, vs say x1 and y3. Is it worthwhile swapping from this argument-holding general functions into these mere undefined symbols?

Edit to clarify- Which does MMA process faster - an symbolic function or a symbolic number?

Edit2 - Which of the two above would you use?

  • 1
    $\begingroup$ This is really vague and it is not clear to me what the problem is. Apart from that, it might be worth to try to cast the recursive algorithm into an interative one. Also, one should try to minimize the numbers of list creation and list deletion steps. $\endgroup$ Commented Feb 14, 2019 at 9:35
  • 2
    $\begingroup$ do the recursive definitions evaluate to a correct result? do they terminate? do expressions like x[1] define subvalues for x or is x an expression itself? how are these expressions evaluated? what are the Attributes of related symbols? at this level of generality it's arguably hard to say something concrete; when my code 'takes too long' it is often the case that something supposed to be numeric, somehow became symbolic and/or some condition eg an If somehow got an expression instead of a boolean; in my case 9 times out of 10 I need to check for similar blind-spots in my code $\endgroup$
    – user42582
    Commented Feb 14, 2019 at 10:05
  • $\begingroup$ @HenrikSchumacher I’ve updated my question with a hopefully more clear response. $\endgroup$
    – Brad
    Commented Feb 14, 2019 at 10:06
  • $\begingroup$ @user42582 the results come out fine, it just takes around 2 hours to evaluate. The expressions do not define any further subvalues, and never become numeric (by design). Perhaps my question is too broad in general. $\endgroup$
    – Brad
    Commented Feb 14, 2019 at 10:07
  • 1
    $\begingroup$ Yes, it really needs to be pared to an actual example. For what it's worth, I'd be surprised in use of x[1] vs. x1 made a significant difference in this setting (at least provided there are no rules attached to x, which is unlikely since the result seems to be fine). $\endgroup$ Commented Feb 14, 2019 at 15:29