Sorted function argument too long - Called from InFunction

[vsht]

Hi,

I have a problem with the

Sorted function argument too long.
Called from InFunction

error, which seems to occur only when using tablebases.

I have my IBP reduction results prepared as fill statements for a tablebase. The format is the sum of

lsclNum(...)*lsclDen(...)*topologyXYZ(...)

where some denominators can be admittedly quite longish.

The creation of the database goes through without any issues. However, when inserting those rules into my amplitude I get the above-mentioned error for one particular integral.

Here's the code I use to create the tablebase

S lsclEp, u0b, lsclD;
CF topology5534, lsclDen, lsclNum;

Table,sparse,zerofill,strict,tabIBPtopology5534(12);

#include fillStatements.frm #lsclFillStatements
.sort 

TableBase "my.tbl" create;
TableBase "my.tbl" addto tabIBPtopology5534;

.end

The fill statements file is attached. This generates a 22.4 MB large my.tbl file.

fillStatements.zip

Trying to insert the reduction rule for one single integral using this table fails immediately

off statistics;
S lsclEp, u0b, lsclD;
CF topology5534, lsclDen, lsclNum;

L exp = topology5534(1,1,1,1,-3,1,1,1,1,1,1,0);
.sort

TableBase "my.tbl" open;
TableBase "my.tbl" enter;
.sort

id topology5534(?a) = tabIBPtopology5534(?a);
TestUse tabIBPtopology5534;

.sort
Apply;

.sort
.end

as in

TFORM 4.1 (May 15 2023, v4.1-20131025-587-g8a37a42) 0 workers  Run: Wed Jun 12 14:31:33 2024
...
Sorted function argument too long.
Called from InFunction
Program terminating in thread 0 at FORM-test-script.frm Line 16 --> 
  4.55 sec + 0.00 sec: 4.55 sec out of 4.56 sec

Now the weird thing is that if I implement the reduction rule as an id-statement directly in my code, this works without any issues, cf. the attached file

test.zip

Also creating a tablebase containing just the reduction rule for topology5534(1,1,1,1,-3,1,1,1,1,1,1,0) and nothing else works. I tried to play with SubSmallSize or SubTermsInSmal as suggested in Issue #292 but that didn't really help.

Any advice would be highly appreciated.

Cheers, Vlad

[jodavies]

The first thing I wonder, is if it is expected that you get different results from each approach? Your tablebase example I can run by setting a maxtermsize of, eg, 1M.

[vsht]

Your tablebase example I can run by setting a maxtermsize of, eg, 1M.

Many thanks, increasing MaxTermSize indeed helps here. I guess that I was confused by the error message, that doesn't say anything about this particular parameter.

The first thing I wonder, is if it is expected that you get different results from each approach?

The id statement is just the corresponding replacement extracted from fillStatements.frm. So unless I copy-pasted the wrong thing, both results should give the same.

[jodavies]

I think you copy and pasted the wrong thing, so I think that your "id statment version" works is a red herring.

I made an independent "id statement version" and there also I need a larger maxtermsize. I think it is simply the case that your reduction rules require this (it is due to the expansion of the factors inside your Num and Den function arguments).

What I have learned from this, though, is that FORM is not multiplying out these brackets on the RHS of the Fill statements...

[vsht]

I think you copy and pasted the wrong thing, so I think that your "id statment version" works is a red herring.

That might well be, sorry for that.

I think it is simply the case that your reduction rules require this (it is due to the expansion of the factors inside your Num and Den function arguments).

That is fine, but it would be nice to have an error message that points the user into the right direction (MaxTermSize) rather than leaving them somewhat confused.

What I have learned from this, though, is that FORM is not multiplying out these brackets on the RHS of the Fill statements...

I guess that it makes sense. For performance reasons I would also just copy the expressions into the tablebase as they are instead of trying to rewrite them beforehand.

[jodavies]

There is an old PR (#289) which addresses this, which could be revamped and included.

[vsht]

Ok, in any case my initial problem is resolved and doesn't constitute a bug, so I'm closing this.

Thanks a lot to @jodavies for the quick and helpful reply!