Hi Vitaly, We should now use our nifty new issue tracker! ;-) <https://codeberg.org/ginac/ginac/issues/4> On 3/31/26 12:41 AM, Vitaly Magerya wrote:
In my use case there are many variables, all assigned only once, and none are used before assignment (as it would be in e.g. C++), so the subs() from that commit are guaranteed to do nothing... I think I'll need to revert it; the performance penalty is too great.
Surprising to see that many people use ginsh for heavy-lifting!
I do wish there was a way to opt out. I'm not happy about carrying patches. At least for my use case, the "new" behavior from 1.4.4 [1] is the way to go.
Okay, so we agree that this is "just" a performance issue. So, this problem is only in ginsh, which suggests that it should also be fixed in ginsh.
I guess there are two types of assignment: retroactive ("old", aka current, aka Mathematica-style), and scope-inducing ("new", aka reverted in 22716a2cc7). Maybe a compromise would be a separate operator for each? I.e. "=" for one and ":=" for the other? Then two hash tables could be maintained: one for substitutions in newly parsed expressions, and one for patching evaluation results? "=" would add the mapping to both, ":=" would only add to the first? This way I could switch to ":=" and not suffer the performance penalty.
Or maybe it would be possible to introduce the two hash tables, and only add to the first if the symbol being assigned has already been used (which is never the case in my usage)? Then we get the same effect, but no need for new syntax.
Yes, you are going into the right direction. This idea won't cure the behavior in general. But it will boost up your case. Another idea worth pursuing might be to keep a set of symbols contained in the rhs of each assigned symbol together with the assignemnt itself. When assigning a new symbol, and before doing the substitution in all existing assignments, ginsh could check if it makes sense to do the substitution prior to actually calling .subs(). This won't cure the O(N) behavior but it will make the slope much more flat. Or even a combination of both ideas since they address different cases. I don't think this is hard. Feel free to have a stab at it. -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>