Bugs & Feature Suggestions • Re: [ERROR] Parsing Error: Maximum number of variable replacements reached (1000) in string

Alright, I checked the log files you posted, though I do have something to say here. It seems that you think the error is because of the nested variables or the amount of operations going on which is illustrated by the size of the log - but it's not.

...

EDIT: Or maybe I just misunderstood / misread what you said, if you referrred simply to the [&*...*] as the "nested style variables".

I probably wasn't clear enough. I wasn't trying to detail the "direct" cause to the error, I was trying to do was illustrate the "process" the parser is taking, and "why" there is a hard limit - which was initial question asked. I also wasn't trying to spot problems with code, as nothing you posted was "wrong", it just a limitation of the process. As you can see, it is doing A LOT of processing, but still does it relatively fast.

---

The second point I wanted to convey in one of my (again, too long) previous messages was that even though there are indeed over 1000 occurrences of [&***Magnitude***] and [&***RayN***] "variables" (actually, measures as variables), it's only 89 such unique occurrences, i.e. Magnitude and Ray0, Ray1, ... Ray87, so well below 1000, the rest of them being duplicates of those - it seems strange to count those duplicates as separate "variable replacements" (in other words, I could even have ([&***ThisSingleMeasure***]+[&***ThisSingleMeasure***]+...+[&***ThisSingleMeasure***]) repeated over 1000 times and would throw the error, even though, well, it would be just a single measure / variable / value / whatever, repeated more than 1000 times, if you know what I mean).

I get what you are saying (I think), but that is just how parsing works. It doesn't "remember" that you just replaced the same variable again and again. It's just going through each variable, replacing it one by one (which can be complicated with complex nesting), and stopping when no more variables are to be replaced or if a hard limit is reached to prevent infinite loops (with speed considerations).

---

One more thing, before I forget - even if one way or another I'll eventually find a solution to avoid this error in my particular case no matter how long it will take, I still believe this limitation should be mentioned and briefly explained in the manual, hence posting this in the Bugs and Suggestions section of the forum. Sure, this one is jsmorley's area, I'm just saying.

I'm not opposed to this. We may wait until I can do a bit more testing to see if the hard limit can be increased to a reasonable amount.

-Brian

Statistics: Posted by Brian — Yesterday, 6:04 am

---