Populate the FORM Cookbook

[benruijl]

I've started the Form Cookbook that contains useful recipes (and workarounds for some shortcomings) that may be hard to come up with for new users. I encourage all users to also submit snippets, so that we get a more comprehensive documentation.

[vsht]

Great idea! Is there some moderation procedure for the submitted snippets?

I also have a collection of private snippets, but I'm not sure that those are that efficient/useful as compared to what FORM devs would use.

[benruijl]

Since it's a bit hard to accept pull requests on the wiki, I propose that contributors post their snippets here and we can integrate them into the wiki if it's suitable.

Don't hesitate to post any snippets! If we find a better way to achieve the same result, we can discuss that here and we all learn :slightly_smiling_face:

[jodavies]

https://github.com/vermaseren/form/wiki/FORM-Cookbook#loops-with-sorts-inside=

This one won't run in parallel with tform unless you use a construction like https://www.nikhef.nl/~form/maindir/documentation/reference/online/online.html#SECTION001930000000000000000

(Or rather, not run efficiently -- in practice I never found much difference, but the user manual mentions it explicitly.)

It's a good idea, I'll try to collect some snippets at some point!

[tueda]

This one won't run in parallel with tform unless you use a construction like https://www.nikhef.nl/~form/maindir/documentation/reference/online/online.html#SECTION001930000000000000000

I found what the reference manual says for ParFORM may be misleading...

Indeed, for the TYPEREDEFPRE virtual machine code, TFORM uses a lock for the critical session to really redefine a preprocessor variable, while ParFORM delays the redefinition until the end of the execution of the module and performs the reduction operation.

So, the sentence "the variable has to be sent to the master process (PARFORM)" is correct but only once and the parallelization must work well with ParFORM.

On the other hand, assigning $-variables in TFORM also uses locks. Each lock is only for one variable so that the averaged collision rate becomes smaller when many variables are randomly accessed. But if there is only one variable that will be redefined by many threads, as in this example, I don't see much advantage over the redefine statement (except the fact that the PutPreVar function is rather complicated and may be slow)...

[benruijl]

It's a bit weird that TFORM uses locks to assign to dollar variables that are thread-local.

[tueda]

In the current implementation, DollarList is in the P_const struct, which means $-variables are all "global" variables (like preprocessor variables). To the user, they appear to be "local" variables, thanks to the locks.

[tueda]

OK, I was a bit wrong. For the "local" $-variables (ModuleOption local), thread-local storage is used. But this is not the case for other types of $-variables.

[tueda]

Loops with sorts inside

It just crossed my mind that there are undocumented preprocessor variables UNCHANGED_ , UNCHANGED_<expr>, ZERO_ and ZERO_<expr>. They check the global flag AR.expflags or the flag for each expression Expressions[expr_number].vflags to see whether expressions are unchanged or zero. Their values are 1 or 0.

With UNCHANGED_, this case can be written as

S x;
CF f;
Local F = f(30);
#do i = 1,1
  id f(x?{>1}) = f(x - 1) + f(x - 2);
  .sort
  #if `UNCHANGED_' == 0
    #redefine i "0"
  #endif
#enddo
Print +s;
.end

Though these preprocessor variables are undocumented and so maybe deprecated, I think the use of them should not cause any slowdown in parallelization (the flags are always updated anyway).

[jodavies]

I didn't know about UNCHANGED actually, but I use ZERO_ every now and then.