vermaseren / form

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

Crash by replace_(x,0) #105

Closed tueda closed 8 years ago

tueda commented 8 years ago

I hit a crash by the following program:

S x;
V p;
CF f;

L F = f(p.p+x);
*L F = f(p.p*x);  * another example

multiply replace_(x,0);
P;
.end
FORM 4.1 (Jun 21 2016, v4.1-20131025-200-g9720d7f) 64-bits  Run: Wed Jun 22 21:28:44 2016
    S x;
    V p;
    CF f;

    L F = f(p.p+x);
    *L F = f(p.p*x);  * another example

    multiply replace_(x,0);
    P;
    .end
Program terminating at 1.frm Line 9 -->
Segmentation fault (core dumped)

The crash doesn't occur under valgrind. The crash occurs from 29e608e.

vsht commented 4 years ago

Since this bug was fixed, is there a reason why the following

CF f;
V p1,p2;

L exp = f(p1+p2);

multiply replace_(p1,0);

print;

.end

evaluates to replace_(p1,0)*f(p1 + p2) ? Certainly I can do something like

CF f;
V p1,p2;
V zero;

L exp = f(p1+p2);

multiply replace_(p1,zero);
argument;
id zero = 0;
endargument;

print;

.end

but somehow I though that there should be no issues with setting a vector to 0 directly via replace_. I might be wrong, though.

tueda commented 4 years ago

I think FORM distinguishes vectors from symbols. That's why a vector can't be replaced with a symbol. In the fixed example, x is a symbol, not a vector, and 0 times a vector should reduce to 0 in the sorting (ok, this rule may sound weird at a glance).

vsht commented 4 years ago

I see, thanks! Fine, then I'll just stick to my workaround whenever I need to nullify vectors in a function.

vermaseren commented 4 years ago

Actually it is a bit more subtle. 0 is not a vector. Replace_ can only replace vectors by vectorlike objects. In the case of the id statement there is no problem, because there 0 means 'no term’.

I know that this could be fixed in the replace, but it would require quite some hacking to avoid other errors, because replace uses the same routines as the wildcard substitutions and that means there are lots of special cases there already. I would rather not touch it, if it is not really important.

Jos

On 23 Jun 2020, at 15:17, Vladyslav Shtabovenko notifications@github.com wrote:

Since this bug was fixed, is there a reason why the following

CF f; V p1,p2;

L exp = f(p1+p2);

multiply replace_(p1,0);

print;

.end evaluates to replace_(p1,0)*f(p1 + p2) ? Certainly I can do something like

CF f; V p1,p2; V zero;

L exp = f(p1+p2);

multiply replace_(p1,zero); argument; id zero = 0; endargument;

print;

.end but somehow I though that there should be no issues with setting a vector to 0 directly via replace_. I might be wrong, though.

— 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/105#issuecomment-648139995, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJPCERPJSXO6INKC4YE2RDRYCTN7ANCNFSM4CHQRNTA.

vermaseren commented 4 years ago

Sorry, my reply crossed yours.

Jos

On 23 Jun 2020, at 15:29, Takahiro Ueda notifications@github.com wrote:

I think FORM distinguishes vectors from symbols. That's why a vector can't be replaced with a symbol. In the fixed example, x is a symbol, not a vector, and 0 times a vector should reduce to 0 in the sorting (ok, this rule may sound weird at a glance).

— 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/105#issuecomment-648147943, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJPCESOY6P63MAI3QZ5ADLRYCU35ANCNFSM4CHQRNTA.

vsht commented 4 years ago

No problem and thanks for the explanation. I don't think that this necessarily requires some fixing, but perhaps one could somehow mention this in the documentation on replace_. Anyway, as long as there are suitable workarounds, this behavior of replace_ is fine with me.

Cheers, Vladyslav

vermaseren commented 4 years ago

I ran into this problem myself in the past. I did consider building in a null vector, but that causes all kinds of trouble when you have replace(p,null)*f(p) -> f(null_) -> f(0) and suddenly the argument has changed type (number). Hence your zero solution is the same as I came up with. You define your own null vector, say p0, and at a convenient time you put it to 0 with an id statement. I never found anything better.

Cheers

Jos

On 23 Jun 2020, at 15:39, Vladyslav Shtabovenko notifications@github.com wrote:

No problem and thanks for the explanation. I don't think that this necessarily requires some fixing, but perhaps one could somehow mention this in the documentation on replace. Anyway, as long as there are suitable workarounds, this behavior of replace is fine with me.

Cheers, Vladyslav

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/105#issuecomment-648154457, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJPCEV24PYKYHXPGUMU3TDRYCWAZANCNFSM4CHQRNTA.