vermaseren / form

The FORM project for symbolic manipulation of very big expressions
GNU General Public License v3.0
982 stars 118 forks source link

Puzzling behavior of factarg (freezes etc.) #353

Closed vsht closed 3 years ago

vsht commented 4 years ago

Perhaps it is my lack of understanding of factarg, but I'm wondering why the following simple code

CF f;
S p1,p2;

L exp = f(-p1-p2);

factarg,(0),f;
print;
.end

makes FORM freeze? Modifying the argument slightly

CF f;
S p1,p2;

L exp = f(p1+p2);

factarg,(0),f;

print;

.end

outputs

   exp =
      162000*f*pi_*p1;

which is even more weird. An if p1 and p2 are promoted to vectors, then with

CF f;
V p1,p2;

L exp = f(p1+2*p2);

factarg,(0),f;

print;

.end

I get

!!!This $ variation has not been implemented yet!!!
Called from execarg
Program terminating at /home/vs/Downloads/FORM-test-script.frm 
Line 8 --> 

All these examples work properly if I employ normalize,(0),f; instead of factarg,(0),f; which is also sufficient for what I'm interested in. Still, since the documentation (p.86) says

`(0) Eliminates the coefficient of the term in the argument. Similar to Normalize,(0),....

I though that both statements should produce similar results.

Cheers Vladyslav

jodavies commented 4 years ago

For me your example simply hangs, with nothing useful from valgrind.

Edit: the Vector example, however, does produce some useful valgrind output which is perhaps a clue.

==27642== Conditional jump or move depends on uninitialised value(s)
==27642==    at 0x45DF66: Normalize (normal.c:534)
==27642==    by 0x40B8F7: execarg (argument.c:1704)
==27642==    by 0x4BEDB8: Generator (proces.c:3445)
==27642==    by 0x4BFAA0: Generator (proces.c:3824)
==27642==    by 0x4BFF0A: Generator (proces.c:3992)
==27642==    by 0x4C148A: Processor (proces.c:405)
==27642==    by 0x43B2B4: DoExecute (execute.c:843)
==27642==    by 0x454A84: ExecModule (module.c:274)
==27642==    by 0x4B71F3: PreProcessor (pre.c:967)
==27642==    by 0x4F1C99: main (startup.c:1619)
==27642==
==27642== Conditional jump or move depends on uninitialised value(s)
==27642==    at 0x45DF6B: Normalize (normal.c:542)
==27642==    by 0x40B8F7: execarg (argument.c:1704)
==27642==    by 0x4BEDB8: Generator (proces.c:3445)
==27642==    by 0x4BFAA0: Generator (proces.c:3824)
==27642==    by 0x4BFF0A: Generator (proces.c:3992)
==27642==    by 0x4C148A: Processor (proces.c:405)
==27642==    by 0x43B2B4: DoExecute (execute.c:843)
==27642==    by 0x454A84: ExecModule (module.c:274)
==27642==    by 0x4B71F3: PreProcessor (pre.c:967)
==27642==    by 0x4F1C99: main (startup.c:1619)
==27642==
==27642== Conditional jump or move depends on uninitialised value(s)
==27642==    at 0x45DF70: Normalize (normal.c:578)
==27642==    by 0x40B8F7: execarg (argument.c:1704)
==27642==    by 0x4BEDB8: Generator (proces.c:3445)
==27642==    by 0x4BFAA0: Generator (proces.c:3824)
==27642==    by 0x4BFF0A: Generator (proces.c:3992)
==27642==    by 0x4C148A: Processor (proces.c:405)
==27642==    by 0x43B2B4: DoExecute (execute.c:843)
==27642==    by 0x454A84: ExecModule (module.c:274)
==27642==    by 0x4B71F3: PreProcessor (pre.c:967)
==27642==    by 0x4F1C99: main (startup.c:1619)
==27642==
==27642== Conditional jump or move depends on uninitialised value(s)
==27642==    at 0x45DF79: Normalize (normal.c:587)
==27642==    by 0x40B8F7: execarg (argument.c:1704)
==27642==    by 0x4BEDB8: Generator (proces.c:3445)
==27642==    by 0x4BFAA0: Generator (proces.c:3824)
==27642==    by 0x4BFF0A: Generator (proces.c:3992)
==27642==    by 0x4C148A: Processor (proces.c:405)
==27642==    by 0x43B2B4: DoExecute (execute.c:843)
==27642==    by 0x454A84: ExecModule (module.c:274)
==27642==    by 0x4B71F3: PreProcessor (pre.c:967)
==27642==    by 0x4F1C99: main (startup.c:1619)
==27642==
!!!This $ variation has not been implemented yet!!!
Called from execarg
tueda commented 4 years ago

Your second example (weird pi_) sounds like #140.

tueda commented 4 years ago

Actually, the oldest version form 4.0.0 (FORM 4.0 (Mar 29 2012)) that I can test gives the same results for your 3 examples (freeze, 162000*f*pi_*p1 and !!!This $ variation has not been implemented yet!!!).

vermaseren commented 3 years ago

It seems that the(0) option had never been tested on the case that no factor needed to be divided out. The latest commit should take care of it.

vsht commented 3 years ago

Great, many thanks!

tueda commented 3 years ago

I'm confused; to me, any of the above examples still doesn't work and behaves erroneously, though something seemed to be done in 9b0b89b8d856cd563d72543b04ed5da2c05c60f7... For example:

$ ./vorm test.frm
FORM 4.2.1 (Jul 15 2020, v4.2.1-9-g9b0b89b) 64-bits  Run: Fri Jul 17 18:20:17 2020
    CF f;
    S p1,p2;

    L exp = f(p1+p2);

    factarg,(0),f;

    print;

    .end

Time =       0.00 sec    Generated terms =          1
             exp         Terms in output =          1
                         Bytes used      =         56

   exp =
      162000*f*pi_*p1;

  0.00 sec out of 0.00 sec
vsht commented 3 years ago

Sorry, I didn't have time to check it yesterday and I assumed that if this specific issue was mentioned then the examples will for sure work.

I agree with Takahiro, it seems that all of the original code samples still do not work as they should.

tueda commented 3 years ago

Now it seems to work.