Factor doesn't factor out a common multiplier; a feature or a bug?

Question

It's usual that Factor extracts a common multiplier:

1.512080625457108*^21 + 3.06237456725561*^20*x - 5.6448211439959745*^19*x^2 // Factor

(* -5.64482*10^19 (-8.55592 + 1. x) (3.13082 + 1. x) *)

This doesn't seem to always work, though. Consider following carefully picked polynomials:

{-4.627573651832992*^26 + 1.2080145470422454*^27*x - 5.963005423058937*^26*x^2, 
 -7.023191604602253*^25 + 2.3914405755063114*^25*x - 1.2176143437609178*^24*x^2, 
 3.917815028990508*^26 + 5.635303072532717*^25*x - 1.3273075954855617*^25*x^2, 
 -9.598625545617204*^25 + 2.8233044513990762*^25*x - 2.0725025122730105*^24*x^2, 
 -8.057893949471401*^25 + 2.053438258009868*^25*x - 1.3072226910287313*^24*x^2}

Results for these are quite different, and no shared multiplier can be observed:

% // Factor

(* {-(-3.69437*10^13 + 2.44193*10^13 x) (-1.2526*10^13 + 2.44193*10^13 x),
    -(-1.77056*10^13 + 1.10346*10^12 x) (-3.96664*10^12 + 1.10346*10^12 x),
    -(-2.89847*10^13 + 3.64322*10^12 x) (1.35168*10^13 + 3.64322*10^12 x),
    -(-1.02134*10^13 + 1.43962*10^12 x) (-9.39806*10^12 + 1.43962*10^12 x),
    -(-9.22832*10^12 + 1.14334*10^12 x) (-8.7317*10^12 + 1.14334*10^12 x)} *)

Should this be considered a feature, or a bug? Factor does work, but its output in these cases is not really useful for Simplify for taking out constants from e.g. square roots. On a quick look it would seem these polynomials are not particularly common, but some intermediate results produce lots of them.

@Feyre Yes, it's possible to replicate this feature using CoefficientList and massage the results on that basis, but I'm somewhat puzzled over some "failure modes" of Factor; are those intentional or not? — kirma, Sep 16 '16 at 16:05
"Factor applies only to the top algebraic level in an expression. You may have to use Map, or apply Factor again, to reach other levels.", see Factor—Wolfram Language Documentation — creidhne, Sep 16 '16 at 16:14
@creidhne Factor is Listable, and it works on some other polynomials (consider my first example) in a different fashion - which in my opinion makes sense. I'm wondering why it doesn't do so on others. It's not about these polynomials enclosed on a list; even individually, Factor fails to extract the common multiplier - for reasons unknown to me. — kirma, Sep 16 '16 at 16:19
Sorry, I misunderstood the problem. It seems at least one term in each example can't be exactly represented at MachinePrecision. Does RealDigits[1.2080145470422454*^27] explain the problem? — creidhne, Sep 16 '16 at 16:38
@creidhne Natural presentation of reals (finite-precision numbers) in Mma is binary. I also wondered what could be the cause for this behaviour; as far as I can tell, it is dependent on something else. The same problem appears even if precision and accuracy is increased beyond MachinePrecision, but at the same time, some of these polynomials behave differently if I divide all coefficients by 2, which is just an exponent term reduction by one on natural format. This is why I'm puzzled about it all. — kirma, Sep 16 '16 at 16:43
Bug fix, actually. The current behavior was put in around March 2009 to improve on a situation wherein factors might be removed in a way that gives rise to numerically bad behavior. A particular manifestation was that coefficients could become zero from application of Chop. This was a source of numerous problems. There are some size heuristics that determine at what point to avoid pulling out numbers, and this might play a role in the different behaviors observed in examples under discussion. — Daniel Lichtblau, Sep 16 '16 at 17:00
@DanielLichtblau Numerical instability was one candidate on my mental list of things. Still I wonder: how to make Factor not do this? I have written some simplistic replacement rules that work around the problem, but I have no idea what would be the correct approach. My primary goal is to get humanly intelligible results, not floating point accuracy. — kirma, Sep 16 '16 at 17:39

score 8 · Accepted Answer · edited Sep 16 '16 at 18:32

This shows a change in behavior that was part of a series of related changes, over a period of some years, with the goal of addressing several related bugs.

The handling of the examples in this thread resulted from changes early on in the series, dating to March 2009. The goal was to improve on a situation wherein factors might be removed in a way that gives rise to numerically bad behavior. A particular manifestation was that coefficients could become zero from application of Chop; this has been a source of numerous problems.

There are some size heuristics that determine at what point to avoid pulling out numbers, and this might play a role in the different behaviors observed in examples under discussion here.

As a general remark, it is quite tricky to mix what are fundamentally exact or symbolic algorithms, such as factorization, with numeric (as in approximate numbers) input. While there is a growing body of work in this area (involving so-called "hybrid symbolic-numeric methods"), it is far from a solved problem or set of problems. I'll be talking about one aspect of this next week, actually, on approximate polynomial GCDs.

Factor doesn't factor out a common multiplier; a feature or a bug?

1 Answers1