You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of PolyForm division relies on DynamicPolynomials.Polynomial, which in turn utilizes MutableArithmetics.jl for type promotion. MutableArithmetics.jl, designed for numerical software such as JuMP, promotes division of two integers to a Float64. This behavior might not be ideal for symbolic computations where preserving integer types is often desired.
Detailed description
If the input expression contains a / operation, simplify and simplify_fractions call simplify_div.
In the last piece of code above, for inferring the resulting type of two Ints with the / operation, it obtains Float64 instead of Int or Rational by essentially executing typeof(Int(0) / Int(1)).
This is reasonable for numerical software, but we might want it to behave differently in our symbolic-focused software.
The text was updated successfully, but these errors were encountered:
I didn't want to force div of polynomials with integer coefficients to be floating point, it was just a case I didn't give much thought on. Indeed, div and rem for polynomials only make sense when the coefficient type is a field. For instance divrem(5x, 3x) should be 5/3 with zero remainder, not 1 with remainder 2x because the leading monomial of the remainder cannot be divisible by the leading monomial of the divisor. There is also pseudo_rem in case you have non-field coefficient like Int. For that reason, I assumed the user that needs to divide polynomials with integer coefficients would promote it to either rational or float in case there was a strong opinion on what the result should be. So there is a quick fix on your end:
julia>functionto_field(p)
T =coefficient_type(p)
if T <:Integerreturnmap_coefficients(c ->Rational{T}(c), p)
elsereturn p
endend
to_field (generic function with 1 method)
julia>to_field(2x +1)
1//1+2//1x
Short description
The current implementation of
PolyForm
division relies onDynamicPolynomials.Polynomial
, which in turn utilizes MutableArithmetics.jl for type promotion. MutableArithmetics.jl, designed for numerical software such as JuMP, promotes division of two integers to aFloat64
. This behavior might not be ideal for symbolic computations where preserving integer types is often desired.Detailed description
If the input expression contains a
/
operation,simplify
andsimplify_fractions
callsimplify_div
.SymbolicUtils.jl/src/simplify.jl
Lines 16 to 43 in 6713fa0
SymbolicUtils.jl/src/polyform.jl
Lines 327 to 337 in 6713fa0
simplify_div
transforms both numerator and denominator toPolyForm
s, and removes their greatest common divisor.SymbolicUtils.jl/src/polyform.jl
Lines 277 to 280 in 6713fa0
rm_gcds
involves the division ofPolyForm
s.SymbolicUtils.jl/src/polyform.jl
Lines 534 to 543 in 6713fa0
SymbolicUtils.jl/src/polyform.jl
Line 86 in 6713fa0
As shown in the above code, our current implementation of
PolyForm
division relies onDynamicPolynomials.Polynomial
division viadiv(x.p, y.p)
.JuliaAlgebra/MultivariatePolynomials.jl uses jump-dev/MutableArithmetics.jl for arithmetic type promotion.
https://github.com/JuliaAlgebra/MultivariatePolynomials.jl/blob/9eb6bf4973e27fdbf6f53d0d2043b476ad2a38c5/src/division.jl#L148-L150
https://github.com/JuliaAlgebra/MultivariatePolynomials.jl/blob/9eb6bf4973e27fdbf6f53d0d2043b476ad2a38c5/src/division.jl#L388-L390
https://github.com/JuliaAlgebra/MultivariatePolynomials.jl/blob/9eb6bf4973e27fdbf6f53d0d2043b476ad2a38c5/src/division.jl#L379-L384
https://github.com/jump-dev/MutableArithmetics.jl/blob/7344c9468072bd663feec7e4cdc1a0e98e34ea19/src/interface.jl#L112-L114
https://github.com/jump-dev/MutableArithmetics.jl/blob/7344c9468072bd663feec7e4cdc1a0e98e34ea19/src/interface.jl#L38-L44
In the last piece of code above, for inferring the resulting type of two
Int
s with the/
operation, it obtainsFloat64
instead ofInt
orRational
by essentially executingtypeof(Int(0) / Int(1))
.This is reasonable for numerical software, but we might want it to behave differently in our symbolic-focused software.
The text was updated successfully, but these errors were encountered: