Factor fails on a simple expression

Question

Bug introduced in 9.0 and fixed in 11.3.0

Consider the following symbolic expression (all the c's are undefined)

exp = (-4*I)*(-1 + c22)*Pi*c1[c7[c12], c7[Glu5], c7[c9[c1312][0]]]*
c13[{c7[Glu5], c7[c9[c1312][0]]}, c10[c25], c10[c24]]*
c8[c11[c15, c6], c5[l, c6]]*
c4[c5[p2, c6], c6].c4[c5[l, c6], c6].c4[c5[p1, c6], c6]*c40[c15]*
c40[c20] - (4*I)*(-1 + c22)*Pi*
c1[c7[c12], c7[Glu5], c7[c9[c1312][0]]]*
c13[{c7[Glu5], c7[c9[c1312][0]]}, c10[c25], c10[c24]]*
c8[c11[c15, c6], c5[p2, c6]]*
c4[c5[p1, c6], c6].c4[c5[p2, c6], c6]*c40[c14]*c40[c15]*
c40[c20] - (4*I)*(-1 + c22)*Pi*
c1[c7[c12], c7[Glu5], c7[c9[c1312][0]]]*
c13[{c7[Glu5], c7[c9[c1312][0]]}, c10[c25], 
 c10[c24]]*(c8[c5[p1, c6], c5[p1, c6]] - 
  2*c8[c5[p1, c6], c5[p2, c6]] + 
  c8[c5[p2, c6], 
   c5[p2, c6]])*(c4[c5[p1, c6], c6].c4[c5[p1, c6], c6].c4[
    c11[c15, c6], c6] - 
  c4[c5[p2, c6], c6].c4[c5[p1, c6], c6].c4[c11[c15, c6], c6] + 
  c4[c5[p1, c6], c6].c4[c11[c15, c6], c6]*c40[c14] - 
  c4[c5[p2, c6], c6].c4[c11[c15, c6], c6]*c40[c14])*c40[c15]*
c40[c20] + (4*I)*(-1 + c22)*Pi*
c1[c7[c12], c7[Glu5], c7[c9[c1312][0]]]*
c13[{c7[Glu5], c7[c9[c1312][0]]}, c10[c25], c10[c24]]*
c8[c11[c15, c6], 
 c5[p1, c6]]*(c4[c5[p1, c6], c6].c4[c5[p1, c6], c6].c4[c5[p1, c6],
     c6] - c4[c5[p1, c6], c6].c4[c5[p1, c6], c6].c4[c5[p2, c6], 
    c6] - c4[c5[p2, c6], c6].c4[c5[p1, c6], c6].c4[c5[p1, c6], 
    c6] + c4[c5[p2, c6], c6].c4[c5[p1, c6], c6].c4[c5[p2, c6], 
    c6] + c4[c5[p1, c6], c6].c4[c5[p1, c6], c6]*c40[c14] - 
  c4[c5[p1, c6], c6].c4[c5[p2, c6], c6]*c40[c14] - 
  c4[c5[p2, c6], c6].c4[c5[p1, c6], c6]*c40[c14] + 
  c4[c5[p2, c6], c6].c4[c5[p2, c6], c6]*c40[c14])*c40[c15]*
c40[c20];

Now try to evaluate the following code

AbsoluteTiming[res1 = Simplify[exp];]
AbsoluteTiming[res2 = Factor[exp];]
Simplify[res1 - res2]

On Mathematica 8 (Linux version) both Simplify and Factor finish in less than 0.1 seconds. However, with all newer versions (9, 10.3, 11.0) that I have, Factor never finishes, while Simplify is still very fast.

To me this looks like a bug/regression, but may be someone has a sensible explanation for this behavior. I have not reported this to WRI so far, but I'm planning to do so.

Edit:

res1 is

(-4*I)*(-1 + c22)*Pi*c1[c7[c12], c7[Glu5], c7[c9[c1312][0]]]*
 c13[{c7[Glu5], c7[c9[c1312][0]]}, c10[c25], c10[c24]]*c40[c15]*c40[c20]*
 (c40[c14]*c8[c11[c15, c6], c5[p2, c6]]*c4[c5[p1, c6], c6] . 
    c4[c5[p2, c6], c6] + c8[c11[c15, c6], c5[l, c6]]*
   c4[c5[p2, c6], c6] . c4[c5[l, c6], c6] . c4[c5[p1, c6], c6] + 
  (c8[c5[p1, c6], c5[p1, c6]] - 2*c8[c5[p1, c6], c5[p2, c6]] + 
    c8[c5[p2, c6], c5[p2, c6]])*
   (c40[c14]*(c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] - 
      c4[c5[p2, c6], c6] . c4[c11[c15, c6], c6]) + 
    c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] - 
    c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6]) - 
  c8[c11[c15, c6], c5[p1, c6]]*
   (c40[c14]*(c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] - 
      c4[c5[p1, c6], c6] . c4[c5[p2, c6], c6] - c4[c5[p2, c6], c6] . 
       c4[c5[p1, c6], c6] + c4[c5[p2, c6], c6] . c4[c5[p2, c6], c6]) + 
    c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] - 
    c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . c4[c5[p2, c6], c6] - 
    c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] + 
    c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . c4[c5[p2, c6], c6]))

res2 is

(-4*I)*(-1 + c22)*Pi*c1[c7[c12], c7[Glu5], c7[c9[c1312][0]]]*
 c13[{c7[Glu5], c7[c9[c1312][0]]}, c10[c25], c10[c24]]*c40[c15]*c40[c20]*
 (c40[c14]*c8[c5[p1, c6], c5[p1, c6]]*c4[c5[p1, c6], c6] . 
    c4[c11[c15, c6], c6] - 2*c40[c14]*c8[c5[p1, c6], c5[p2, c6]]*
   c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] + 
  c40[c14]*c8[c5[p2, c6], c5[p2, c6]]*c4[c5[p1, c6], c6] . 
    c4[c11[c15, c6], c6] - c40[c14]*c8[c11[c15, c6], c5[p1, c6]]*
   c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] + 
  c40[c14]*c8[c11[c15, c6], c5[p1, c6]]*c4[c5[p1, c6], c6] . 
    c4[c5[p2, c6], c6] + c40[c14]*c8[c11[c15, c6], c5[p2, c6]]*
   c4[c5[p1, c6], c6] . c4[c5[p2, c6], c6] - 
  c40[c14]*c8[c5[p1, c6], c5[p1, c6]]*c4[c5[p2, c6], c6] . 
    c4[c11[c15, c6], c6] + 2*c40[c14]*c8[c5[p1, c6], c5[p2, c6]]*
   c4[c5[p2, c6], c6] . c4[c11[c15, c6], c6] - 
  c40[c14]*c8[c5[p2, c6], c5[p2, c6]]*c4[c5[p2, c6], c6] . 
    c4[c11[c15, c6], c6] + c40[c14]*c8[c11[c15, c6], c5[p1, c6]]*
   c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] - 
  c40[c14]*c8[c11[c15, c6], c5[p1, c6]]*c4[c5[p2, c6], c6] . 
    c4[c5[p2, c6], c6] + c8[c5[p1, c6], c5[p1, c6]]*
   c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] - 
  2*c8[c5[p1, c6], c5[p2, c6]]*c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . 
    c4[c11[c15, c6], c6] + c8[c5[p2, c6], c5[p2, c6]]*
   c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] - 
  c8[c11[c15, c6], c5[p1, c6]]*c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . 
    c4[c5[p1, c6], c6] + c8[c11[c15, c6], c5[p1, c6]]*
   c4[c5[p1, c6], c6] . c4[c5[p1, c6], c6] . c4[c5[p2, c6], c6] + 
  c8[c11[c15, c6], c5[l, c6]]*c4[c5[p2, c6], c6] . c4[c5[l, c6], c6] . 
    c4[c5[p1, c6], c6] - c8[c5[p1, c6], c5[p1, c6]]*
   c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] + 
  2*c8[c5[p1, c6], c5[p2, c6]]*c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . 
    c4[c11[c15, c6], c6] - c8[c5[p2, c6], c5[p2, c6]]*
   c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . c4[c11[c15, c6], c6] + 
  c8[c11[c15, c6], c5[p1, c6]]*c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . 
    c4[c5[p1, c6], c6] - c8[c11[c15, c6], c5[p1, c6]]*
   c4[c5[p2, c6], c6] . c4[c5[p1, c6], c6] . c4[c5[p2, c6], c6])

"Simple" expression? Really? And how could anyone know how "simple" it is when SUNF, SMP, SUNIndes, SUNTF, GaugeXi, LorentzIndex, Momentup, Glu2, and many other terms are not defined? — David G. Stork, Jul 17 '17 at 18:05
In this example all the occurring symbols are undefined. I modified the example to have them just a c a number in the name. However, here it really does not matter what exp means. The point is that this example works perfectly with Mahtematica 8 but not any higher version. I regularly use Factor and Simplify on much more complicated symbolic expressions without any problems. For my standards the given expressions is very simple and it is strange that Factor cannot handle it (although it could in MMA 8). — vsht, Jul 17 '17 at 18:52
Could you show the res1 and res2 you found in version 8? How could Mathematica simplify terms such as c7[c9[c1312][0]] in principle? — David G. Stork, Jul 17 '17 at 18:54
I'll look into this. I think I know what might have happened (change of an underlying method switchover). — Daniel Lichtblau, Jul 17 '17 at 18:57
@DanielLichtblau Thanks. I usually prefer Factor over Simplify for performance reasons, so this example got me really surprised. — vsht, Jul 17 '17 at 19:01
@DavidG.Stork Sure. As I said, I use Mathematica for quantum field theory calculations (often with lots of undefined symbols) on a daily basis, and it does its job pretty well. This particular expression stems from a renormalization calculation in Quantum Chromodynamics. Also, I don't see why Mathematica should have any issues with something like c7[c9[c1312][0]]. It is a symbolic expression that can be treated in the same way as x or y (with some limitations). — vsht, Jul 17 '17 at 19:09
Factor should do better here. This will be treated as a bug. — Daniel Lichtblau, Jul 18 '17 at 00:42
@DanielLichtblau By the way, is there already a case number for this issue? Looks like people for some reason do not like this question (already 3 votes to close it). So if that happens I'd like to have something in a hand to be able to follow the issue with Factor. (Sometimes it takes several releases, before a bug is fixed ;) ) — vsht, Jul 18 '17 at 20:45
I am not aware of any case number. Is that something one would receive by contacting Technical Services? — Daniel Lichtblau, Jul 18 '17 at 22:49
Yes, when one reports a bug to the WRI support and they recognize it as such, they give you a case number. — vsht, Jul 20 '17 at 10:38

score 5 · Accepted Answer · answered Mar 11 '18 at 04:14

5

This bug in Factor has been addressed as of version 11.3.0.

While the example may take some seconds to run, it will not hang

AbsoluteTiming[res1 = Simplify[exp];]
AbsoluteTiming[res2 = Factor[exp];]
Simplify[res1 - res2]

(* {0.060817, Null} *)
(* {13.5211, Null} *)
(* 0 *)

answered Mar 11 '18 at 04:14

ilian

25,474
4
117
186

1

Great, many thanks! I guess there is no simple way to make Factor as fast as in version 8 where it also required much less then a second on this expression? – vsht Mar 12 '18 at 01:50
I have just tried the same example in Mathematica 12.0 on Linux (Fedora 28) and there Factor requires 104 seconds (sic!), while Simplify finishes in less than 0.0002 seconds. Although Factor finishes correctly, the amount of time it spends on this expression as compared to v. 11.3 seems to be way too high. Can this be regarded as a bug? – vsht Apr 24 '19 at 09:07
@vsht I think an order of magnitude slowdown is definitely worth reporting. It may well be a bug (though it could also be a side effect of fixing a different bug). – ilian Apr 24 '19 at 17:23
Ok, I've just reported this regression to the WRI support. Let us see what they will reply. – vsht Apr 25 '19 at 08:37
The performance regression of Factor has been given [CASE:4251515]. Let us hope that it will become fast again in Mathematica 12.1 or so. – vsht Apr 26 '19 at 03:29

score 3 · Answer 2 · answered Jun 01 '19 at 17:11

3

AbsoluteTiming[res2 = exp // FactorTerms // Factor]

gives 0.03 seconds for me using Mathematica 12.0.

answered Jun 01 '19 at 17:11

Rolf Mertig

17,172
1
45
76

Thanks, Rolf. I am looking into the slowdown, but this aspect caught me by surprise. – Daniel Lichtblau Jun 01 '19 at 18:45
You are welcome. Vlad thought he could get rid of my old Factor2 function from FeynCalc, where several heuristic workarounds for old-time deficencies of Factor are collected, but not quite yet. – Rolf Mertig Jun 01 '19 at 22:47
Weirdly enough, there may be examples where the reverse is true: multiplying through by a complex-valued constant could make the factorization faster. (I do not have such an example offhand, but the possibility is there.) – Daniel Lichtblau Jun 02 '19 at 12:09
Rolf is as always superb in finding workarounds when standard functions don't behave as one would like them to. +1 from me. However, the statement is not quite true. I never intended to get rid of Factor2. In most cases it returns "nicer" results than Factor, so it will definitely remain part of FeynCalc. What I wanted to get rid of at some point is Apart1, but this is also currently not feasible. – vsht Jun 03 '19 at 11:02
The reason is that Apart still has some performance problems when the expressions contain complex numbers, cf. https://mathematica.stackexchange.com/questions/112069/performance-of-apart-with-complex-numbers/149466#149466 – vsht Jun 03 '19 at 11:03
I do not understand why Apart or Factor has to be slower when complex numbers are there explicitly. But I am no mathematician and maybe more knowledgable developers like Dan can elucidate. If it is indeed an acknowledged bug by WRI I guess that on a public bug tracker (as suggested here) these slow-down bugs would get a lot of votes by frustrated physicists who are forced to use Maple and FORM these days but would like to return to WL. – Rolf Mertig Jun 03 '19 at 16:10

Factor fails on a simple expression

2 Answers2

Linked