Fix integer powers to return appropriate type instead of QuadExpr

[odow]

Closes #3454

This is technically breaking, since it returns a different type from before, but I'd also argue that it is a bug fix, because x^0 and x^1 should not return a quadratic expression.

Needs:

• https://github.com/jump-dev/JuMP.jl/actions/runs/6042779366

[odow]

There are quite a few failures, but it is't obvious if it's because of this PR.

Here's the latest master: https://github.com/jump-dev/JuMP.jl/actions/runs/6042942250

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (e4d682d) 98.09% compared to head (f64a855) 98.09%.
Report is 6 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3474   +/-   ##
=======================================
  Coverage   98.09%   98.09%           
=======================================
  Files          37       37           
  Lines        5501     5506    +5     
=======================================
+ Hits         5396     5401    +5     
  Misses        105      105           

Files Changed	Coverage Δ
src/operators.jl	96.84% <100.00%> (ø)

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pulsipher]

There are quite a few failures, but it is't obvious if it's because of this PR.

Here's the latest master: https://github.com/jump-dev/JuMP.jl/actions/runs/6042942250

To be clear, this test is the current master without this PR, right? The InfiniteOpt failures are just because a few expressions a slightly different now with the use of move_factors_into_sums and all this is fixed with infiniteopt/InfiniteOpt.jl#308.

For the UnitJuMP and SumOfSquares, it appears the new operator overloading leads to some minor bugs based on assumptions made with the old API.

[odow]

I think this PR is safe to merge.

• PolyJuMP and SumOfSquares are Fix ambiguity arising in SumOfSquares and PolyJuMP JuliaAlgebra/MultivariatePolynomials.jl#273
• UnitJuMP is Type piracy trulsf/UnitJuMP.jl#19

[mlubin]

What about the performance impact of no longer being type stable? Should we add a note on the performance tips page?

[odow]

It's already not type stable because of the case when n > 2. I don't think this needs an explicit callout. I find it hard to believe a bottleneck in someone's code is going to be writing x^2 instead of x * x.

[mlubin]

It's already not type stable because of the case when n > 2.

But it is type stable in JuMP 1.14, right?

[odow]

But it is type stable in JuMP 1.14, right?

Yes. We needed to give up type stability, or else something like x^3 wouldn't work and you'd need to write x^3.0.

For a real-world motivation for this change, see:
https://github.com/lanl-ansi/PowerModels.jl/pull/858/files#diff-7a544f21e32c63ffcff0a5cc9ba4bbf8218aca07ed057b21a238980bbdf4d5fb
I think getting the objective type "correct" is more important than type stability.

x-ref #3106 (comment)

[mlubin]

I think getting the objective type "correct" is more important than type stability.

I agree with the code change. I do expect at least one person to be surprised either about the change in return types or the lack of type stability. It at least warrants an explicit statement in the release notes.

[odow]

It at least warrants an explicit statement in the release notes.

Yip. I think the release notes will need to be quite detailed anyway, because it's quite a big change. Let me start a separate PR for that and we can iterate.

[odow]

I've made a note in #3485 to mention in the changelog.