Buffer too small in PasteTerm?

[magv]

Hi, folks. I'm getting this error from the latest tform:

[...]
Buffer too small in PasteTerm

   18  241  5  0  4294967280  357  1  4  89  1  6  5  1771  82003  0  1  2  3

Called from Generator

   18  241  5  0  4294967280  357  1  4  58  82003  6  5  1730  1  0  1  1  3

Called from Generator

   26  241  5  0  4294967280  357  6  13  2  1  0  5  4  3494967100  
   3494967103  5  4  3494967101  3494967102  1  4  58  82003  1  1  3
Called from Generator

   14  241  5  1  4294967280  357  6  5  357  1  2  1  1  3
Called from Generator
Called from ExtraSymFun

   14  241  5  1  4294967280  357  91  5  1  4294967280  357  1  1  3
Called from Generator

   9  6  5  1  1  0  1  1  3
Called from Generator
Error in processing one term in thread 1 in module 59
Program terminating in thread 1 at sort Line 2 --> 

Could you tell me which buffer is too small? What option should I increase?

[vermaseren]

Typically this would be MaxTermSize. One of the problems here is that if you have high powers of an expression it pastes the individual terms together and then later it lets the normalisation routine sort that out. This means that (a*b+c*d)^10 may have temporarily terms like a*b*a*b*a*b*a*b*a*b*a*b*a*b*a*b*a*b*a*b and mixtures. This could be mended by using a special buffer there that can be adjusted, but then, if this does not collapse in the normalisation routine, that routine will crash because after normalisation everything MUST fit inside MaxTermSize. Making MaxTermSize arbitrarily big to avoid all this runs into memory problems. Hence, if just raising MaxTermSize to a reasonable size does not work, one may have to look at the problem again and program things (slightly) differently. In the above example that could be id abcd10 = sum_(j,1,10,a^j*b^j*c^(10-j)*d^(n-j)*binom_(10,j)); or whatever elese may be handy. The above may be rather primitive but it is part of what makes Form fast, although I am not claiming that a bit more thinking here may make it better and not loose speed or make it even faster.

…

On 14 Dec 2021, at 12:18, Vitaly Magerya ***@***.***> wrote: Hi, folks. I'm getting this error from the latest tform: [...] Buffer too small in PasteTerm 18 241 5 0 4294967280 357 1 4 89 1 6 5 1771 82003 0 1 2 3 Called from Generator 18 241 5 0 4294967280 357 1 4 58 82003 6 5 1730 1 0 1 1 3 Called from Generator 26 241 5 0 4294967280 357 6 13 2 1 0 5 4 3494967100 3494967103 5 4 3494967101 3494967102 1 4 58 82003 1 1 3 Called from Generator 14 241 5 1 4294967280 357 6 5 357 1 2 1 1 3 Called from Generator Called from ExtraSymFun 14 241 5 1 4294967280 357 91 5 1 4294967280 357 1 1 3 Called from Generator 9 6 5 1 1 0 1 1 3 Called from Generator Error in processing one term in thread 1 in module 59 Program terminating in thread 1 at sort Line 2 --> Could you tell me which buffer is too small? What option should I increase? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#402>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEXUA6BGUZHTZHC77H3UQ4RYHANCNFSM5KATOZRQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[magv]

It seems this happens even if no binomial expansion is done. This is the minimal example:

S x;
L ex = x^12345;
id x = 1;
.end

Fails with:

FORM 4.2.1 (Oct 21 2021, v4.2.1-32-g07d135f-dirty) 64-bits  Run: Tue Dec 14 13:57:36 2021
    S x;
    L ex = x^12345;
    id x = 1;
    .end
Buffer too small in PasteTerm
Program terminating at x.frm Line 3 --> 
  0.09 sec out of 0.09 sec

This is unexpected, but I can change my code not to use these large exponents. (I used them for tagging terms; I thought that TAG^123 is more efficiently stored than TAG(123)).

[vermaseren]

In this example the id x=1; makes basically 12345 substitutions and pastes those together, because Form does not look into the rhs to decide the strategy. The much more efficient statement is id x^n? = 1; That is just a single operation. You are right that x^123 takes less space than TAG(123).

…

On 14 Dec 2021, at 14:01, Vitaly Magerya ***@***.***> wrote: It seems this happens even if no binomial expansion is done. This is the minimal example: S x; L ex = x^12345; id x = 1; .end Fails with: FORM 4.2.1 (Oct 21 2021, v4.2.1-32-g07d135f-dirty) 64-bits Run: Tue Dec 14 13:57:36 2021 S x; L ex = x^12345; id x = 1; .end Buffer too small in PasteTerm Program terminating at x.frm Line 3 --> 0.09 sec out of 0.09 sec This is unexpected, but I can change my code not to use these large exponents. (I used them for tagging terms; I thought that TAG^123 is more efficiently stored than TAG(123)). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#402 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCERHTW6HJC6HNFSBXFLUQ45ZBANCNFSM5KATOZRQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[magv]

You're right, thanks; I'll use id x^n? = 1;, which solves the problem in my code.

I guess the "Buffer too small in PasteTerm" error message could still use an improvement.