Closed jodavies closed 6 months ago
@vermaseren this one needs a sanity check, I am not 100% sure of the consequences of this change.
I think you are right. MulArg was added later. Before this was not a problem, and apparently when MulArg was added this problem was not considered. And of course there may be future options.
On 10 May 2024, at 11:22, jodavies @.***> wrote:
@vermaseren https://github.com/vermaseren this one needs a sanity check, I am not 100% sure of the consequences of this change.
— Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/pull/516#issuecomment-2104263217, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJPCERENQNUWK4LEOSMCVDZBSGUVAVCNFSM6AAAAABHQJJW5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUGI3DGMRRG4. You are receiving this because you were mentioned.
It is probably worth mentioning that mularg
can be slow compared to repeated id
statements (which are sorting the arguments each repeat).
This is ready to merge, right?
Since the transform statements are sorting into the workspace, and might have to merge patches, make them use a par=1 EndSort. This commit makes this change for all transform statements, though only mularg is going to produce an explosion of terms here.
This fixes #230 and causes #183 to crash with a useful error (Term too complex during normalization).