Problems with tform and ModuleOption,sum

[jodavies]

If test contains more than 2 terms, the following does not work properly under tform (even with 1 worker)

#-
Off Statistics;

CFunction f;
Symbol x,y,z;

*Local test = f(1)*x - f(2)*y;
Local test = f(1)*x - f(2)*y + f(3)*z;
Bracket f;
.sort
Keep Brackets;

#$split = 0;
$split = $split + term_;
Print "%w %$", $split;

Bracket f;
ModuleOption sum $split;
.sort

Local split = $split;

#do i = split
    Local [testsplit`i'] = test[`i'];
#enddo

Print +s;
.end

It gives either

   split =
       + f(1)
       + f(2)
      ;

or

   split =
       + f(1)
       + f(3)
      ;

depending on the run.

(As an aside: is there a better way to get bracket contents into local expressions, when you don't know what you're bracketing against?)

Thanks, Josh.

[jodavies]

It is simpler to remove all of the bracketing etc, the issue is already present in

#-
Off Statistics;

Symbol x,y,z;

Local test = x + y + z;
.sort

#$split = 0;
$split = $split + term_;
Print "%w %$", $split;

ModuleOption sum $split;
.sort

#message split = `$split'
.end

which gives split = z+x or split = z+y.

[tueda]

In the manual:

There are more cases that FORM can handle in a parallel environment. These are also options in the moduleoption statement:

ModuleOption,maximum,$a; ModuleOption,minimum,$b; ModuleOption,sum,$c;

Here we say that $a is accumulating a maximum numerical value, $b collects a minimum numerical value and $c is a numerical sum.

I think TFORM assumes they are numbers. ParFORM doesn't have such restrictions.

[vermaseren]

One of the problems with this sum thing is that if you can do this for algebraic objects and you were to use all the regular internal routines as they exist, you would have to sort the terms in the dollar each time you add a term. Add to that the fact that you need to lock things during the addition, it would become extremely slow. You might have a look at the spectator system, as that only does a single sort when you pick up the spectator.

Jos

On 8 Mar 2018, at 17:49, Takahiro Ueda notifications@github.com wrote:

In the manual:

There are more cases that FORM can handle in a parallel environment. These are also options in the moduleoption statement:

ModuleOption,maximum,$a; ModuleOption,minimum,$b; ModuleOption,sum,$c;

Here we say that $a is accumulating a maximum numerical value, $b collects a minimum numerical value and $c is a numerical sum.

I think TFORM assumes they are numbers. ParFORM doesn't have such restrictions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/271#issuecomment-371548112, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEklht3w_jUrtWOXGqlEtgqtGpxViks5tcWEwgaJpZM4Si9k0.

[tueda]

At least any locking is needed if this is implemented by reduction as in ParFORM.

[vermaseren]

One could avoid locking indeed, if you treat sum as local with the extra feature that at the end of the module the local versions are not deleted immediately, but added and the sum is placed in the central administration. This is effectively how ParFORM does things. This seems the most practical if you want it changed. But it could potentially break existing TFORM programs.

Jos

On 8 Mar 2018, at 18:38, Takahiro Ueda notifications@github.com wrote:

At least any locking is needed if this is implemented by reduction https://en.wikipedia.org/wiki/Reduction_Operator as in ParFORM.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/271#issuecomment-371563672, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEsZtpybz1j3Wuu9b4DJwYcS32S2Vks5tcWyJgaJpZM4Si9k0.

[tueda]

I'm not sure why this change could potentially break existing programs... It's like TFORM gives wrong results for non-numbers and ParFORM gives correct results in all cases. I think programs relying on wrong results from TFORM are, if exist, just wrong.

[jodavies]

For my purposes this is an inessential feature, and not performance critical. For my code this can just run in serial.

I didn't think to check the documentation since it seemed to be (partially) working. Perhaps at least an error message and terminate would be more user friendly.

[vermaseren]

How about

……. $sum = $sum + 1; if ( $sum <= 5 ); some code endif;

Nothing wrong with this program, but TFORM and ParForm will give different results. Of course the result might be a bit unpredictable……

Jos

On 8 Mar 2018, at 18:52, Takahiro Ueda notifications@github.com wrote:

I'm not sure why this change could potentially break existing programs... It's like TFORM gives wrong results for non-numbers and ParFORM gives correct results in all cases. I think programs relying on wrong results from TFORM are, if exist, just wrong.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/271#issuecomment-371567917, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEgQZ29a5sqVg3SYMWqTnDs_2DFJQks5tcW_DgaJpZM4Si9k0.

[tueda]

Yes, even in TFORM, the result may depend on subtle timings; in which order the OS distributes a time slice to each thread.