#3571 Wrong result of integral with ",float" - analytic result is correct

[Michael.Soegtrop]

The integral "integrate(sqrt(1+cos(x)),x,0,2*%pi)" gives wrong results if evaluated with ",float". The analytic result is correct. See the following script:

(%i1)   ratprint:false$
(%i2)   integrate(sqrt(1+cos(x)),x,0,2*%pi);
(%o2)   2^(5/2)
(%i3)   float(integrate(sqrt(1+cos(x)),x,0,2*%pi));
(%o3)   5.656854249492382
(%i4)   integrate(sqrt(1+cos(x)),x,0,2*%pi),float;
(%o4)   0

This was tested on an intermediate version with info:

Please report bugs to:
    https://sourceforge.net/p/maxima/bugs
To report a bug, you must have a Sourceforge account.
Please include the following information with your bug report:
-------------------------------------------------------------
build_info(version="branch_5_43_base_48_gea7b24b8d",timestamp="2019-06-25 23:48:05",host="x86_64-w64-mingw32",lisp_name="SBCL",lisp_version="1.4.14",maxima_userdir="C:/Users/soegtrop/maxima",maxima_tempdir="C:/Users/soegtrop/AppData/Local/Temp",maxima_objdir="C:/Users/soegtrop/maxima/binary/branch_5_43_base_48_gea7b24b8d/sbcl/1_4_14",maxima_frontend="wxMaxima",maxima_frontend_version="19.05.7-DevelopmentSnapshot")
-------------------------------------------------------------
The above information is also reported by the function 'build_info()'.

[Robert Dodier]

I think several examples of problems for which integrate fails when the integrand contains floats have been observed. My own opinion is that integrate should substitute rationals for floats always (ignoring keepfloat, float, numer or anything else which introduces floats).

[Gunter Königsmann]

solve() already converts floats to rationals before trying to find a solution, which in 99% of the cases is the optimum solution, at least for the problems I try to use it for => I am all for making integrate do the same.

[Michael.Soegtrop]

Since this is not an issue with marginal precision I would say that this is simply a bug which should be fixed. I don't see why such a computation should fail with floats.

[Robert Dodier]

I agree this is a bug and it should be fixed. The difficulty is that Maxima handles floats in symbolic expressions very poorly; there are numerous known bugs related to that. The idea for a solution which I suggested above is modify the integration code to convert any floats to rationals and then to adjust the relevant flags to prevent any more floats from entering the picture.

Another approach is to substitute a gensym for each distinct float value, carry out the integration, then substitute the corresponding float value for each gensym at the end, potentially making declarations about each gensym to match the float value. I don't know, without trying it, whether that's a plausible solution.

[Robert Dodier]

To add to the examples already posted, I've observed the following.

(%i12) :lisp (trace $defint)
;; Tracing function $DEFINT.
($DEFINT)
(%i12) 'integrate(sqrt(1+cos(x)),x,0,2*%pi),float;
                     2 %pi
                    /
                    [                  0.5
(%o12)              I      (cos(x) + 1)    dx
                    ]
                    /
                     0
(%i13) %,nouns;
1. Trace: ($DEFINT '((MEXPT SIMP) ((MPLUS SIMP) 1 ((%COS SIMP) $X)) 0.5) '$X '0 '((MTIMES SIMP) 2 $%PI))
rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193
1. Trace: $DEFINT ==> ((RAT SIMP) 22619537 3998607)
                            22619537
(%o13)                      --------
                            3998607
(%i14) float(%);
(%o14)                  5.656854249492386
(%i15) 'integrate(sqrt(1+cos(x)),x,0,2*%pi),float;
                     2 %pi
                    /
                    [                  0.5
(%o15)              I      (cos(x) + 1)    dx
                    ]
                    /
                     0
(%i16) %,nouns,float;
1. Trace: ($DEFINT '((MEXPT SIMP) ((MPLUS SIMP) 1 ((%COS SIMP) $X)) 0.5) '$X '0 '((MTIMES SIMP) 2 $%PI))
rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced -0.5 by -1/2 = -0.5

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced -0.5 by -1/2 = -0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced 0.5 by 1/2 = 0.5

rat: replaced -1.0 by -1/1 = -1.0

rat: replaced -1.0 by -1/1 = -1.0

rat: replaced 1.0 by 1/1 = 1.0

rat: replaced 1.0 by 1/1 = 1.0

rat: replaced -0.5 by -1/2 = -0.5

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193

rat: replaced -0.5 by -1/2 = -0.5

rat: replaced 2.82842712474619 by 22619537/7997214 = 2.828427124746193
1. Trace: $DEFINT ==> 0
(%o16)                          0

From this it appears it's not just the presence of the floating point value 0.5 in the integrand, but that the float flag is enabled while evaluating the integral (via defint which is the function to handle definite integrals).

The messages about converting floats to rationals within defint are different in each case, which suggests that defint is going down a different path when float is enabled. The next thing to investigate is what is defint doing differently when float is enabled.

[Gunter Königsmann]

I personally would opt for automatically running rat () on floats: Some integrals give drastically different results depending on the range some numbers in the input term are in. And if we replace floats by symbols their value is temporarily lost. Additionally solve rationalizing numbers never has caused someone to complain to me.