# Should DSolve always return solution with constant of integration?

Version 10.0

Clear[y,x];
DSolve[D[y[x], x] - y[x]^2 + y[x]*Sin[x] - Cos[x] == 0, y[x], x,
GeneratedParameters -> C]


or

DSolve[D[y[x], x] - y[x]^2 + y[x]*Sin[x] - Cos[x] == 0, y[x], x]


both return a solution that does not include C[1], the constant of integration.

{{y[x] -> Sin[x]}}


The question is: Should DSolve always return an arbitrary constant? Even though the answer is correct, it is missing C[1] hence this is a particular solution.

If DSolve does not have to generate a constant of integration in the solution of a differential equation, then what caused it not to generate it in this specific case?

Update:

Let me add a solution found by Maple for this, which does include a constant of integration:

Clear[C,y,x];
eq = Derivative[1][y][x] - y[x]^2 + y[x]*Sin[x] - Cos[x] == 0;
eq /. y -> (- Exp[-Cos[#]]/(C[1] + Integrate[ Exp[-Cos[#]], x]) + Sin[#] &);
Simplify[%]
(* True *)


So, the above is a general solution with a constant of integration that solves the same differential equation.

-
In case it helps, this is a Riccati equation - link. –  Stephen Luttrell Jul 18 at 16:23

I think it's a bug.

## Tracing

Tracing the evaluation of DSolve as the following:

eq = D[y[x], x] - y[x]^2 + y[x]*Sin[x] - Cos[x] == 0;

traceRes = Trace[DSolve[eq, y[x], x,
GeneratedParameters -> ThisIsForGeneralC],
{TraceInternal -> True,
TraceOff -> _Message}];


and formatting (using the levelIndentFunc function I mentioned here) and exporting the result (it will be around 200 MByte):

Export["[Trace-result] DSolve.txt", levelIndentFunc @ traceRes, "String"]


Searching the "unique" footprint ThisIsForGeneralC we made on purpose, it's not hard to find where the problem comes from.

## Analysis

Here, from the trace result we can see, MMA eventually arrives a point like:

DSolveDSolveFirstOrderODEDumpf = {{{y[x] -> E^Cos[x]*DSolveDSolveFirstOrderODEDumpconst[2] + E^Cos[x]*Integrate[DSolveDSolveFirstOrderODEDumpconst[1]/E^Cos[K[1]], {K[1], 1, x}]}}}
DSolveDSolveFirstOrderODEDumpf = DSolveDSolveFirstOrderODEDumpf[[1,1,1,2]]; {DSolveDSolveFirstOrderODEDumpf, DSolveDSolveFirstOrderODEDumpg} = {Coefficient[DSolveDSolveFirstOrderODEDumpf, DSolveDSolveFirstOrderODEDumpconst[1]], Coefficient[DSolveDSolveFirstOrderODEDumpf, DSolveDSolveFirstOrderODEDumpconst[2]]}; {{y[x] -> -((ThisIsForGeneralC[1]*D[DSolveDSolveFirstOrderODEDumpf, x] + D[DSolveDSolveFirstOrderODEDumpg, x])/(DSolveDSolveFirstOrderODEDumph*(ThisIsForGeneralC[1]*DSolveDSolveFirstOrderODEDumpf + DSolveDSolveFirstOrderODEDumpg)))}}


which is actually

f = {{{y[x] -> E^Cos[x]*const[2] + E^Cos[x]*Integrate[const[1]/E^Cos[K[1]], {K[1], 1, x}]}}};
f = f[[1, 1, 1, 2]]


{f, g} = {Coefficient[f, const[1]], Coefficient[f, const[2]]}
{{y[x] -> -((ThisIsForGeneralC[1]*D[f, x] + D[g, x])/(h*(ThisIsForGeneralC[1]*f + g)))}}


Note the f = Coefficient[f, const[1]] part, which is incorrectly evaluated to 0! That's the one to blame for our issue!

If we replace f with the correct value:

f = E^Cos[x]*Integrate[E^(-Cos[K[1]]), {K[1], 1, x}];


We'll get effectively the same general solution as the one mentioned in OP:

{{y[x] -> -((ThisIsForGeneralC[1]*D[f, x] + D[g, x])/(h*(ThisIsForGeneralC[1]*f + g)))}}


Some perhaps fixes coming up to my mind include:

1. Introducing new rule for Integrate (Please compare Integrate[a b[x], {x, 0, 1}] and Integrate[a b[x], x]); Or
2. Introducing new rule for Coefficient (Maybe not a good idea); Or
3. Using method other than Coefficient in DSolve.
-
That was very impressive! –  acl Jul 19 at 1:40
@acl Thanks :D Hope one day we'll have a better tool for this kind of debugging! –  Silvia Jul 19 at 5:47

This is a bug in DSolve. The solution to your example should certainly include a constant of integration.

DSolve attempts to solve this Riccati equation by solving the corresponding second order linear ODE. The problem occurs while using the solution of the second order linear ODE, which has an unevaluated integral in it.

Sorry for the confusion and thanks for reporting the problem.

-
Welcome to mathematica.stackexchange! Nice to see you here (We met a few years ago in Champaign :)). –  Artes Jul 18 at 21:22
+1 I took too much time for editing my answer and didn't see yours >_< –  Silvia Jul 18 at 21:55

Heureka! Symbolic solution with constant of integration found. With a little help for MMA from its friend ...

Writing the differential equation as

eq = y'[x] - Cos[x] == y[x] (y[x] - Sin[x]);


we observe that putting (no MMA code)

$$z(t)=y(t)-Sin(t)$$

we obtain a related equation

eq1 = z'[t] == z[t] (z[t] + Sin[t]);


which surprisingly is DSolved readily by MMA

DSolve[eq1, z[t], t]

{{z[t] -> 1/(E^Cos[t]*(C[1] - Integrate[E^(-Cos[K[1]]), {K[1], 1, t}]))}}


and it does contain an arbitrary constant C[1] as it should do. It looks similar to the Maple solution but I have not checked it.

The solution is rather non-trivial as it contains the function

f[t_] := Integrate[Exp[-Cos[u]], {u, 0, t}]


a special function which is not recognized by Mathematica.

Using NIntegrate we can see that it increases "linearly" with a light "wobble". This also means that for t->oo the solution of eq1 approaches a "sinusiodal" oscillation symmetrical about z=0.

I can't tell why Mathematica is not "ingenious" enough to spot the simple substitution by itself.

I'll continue a bit an $f(t)$ but for the moment the question seems to be answered.

Regards, Wolfgang

-
For integer k we have f(k pi)/(k pi) = BesselI[0, 1] ~= 1.2660658777520082 which proves the "linear" increase. –  Dr. Wolfgang Hintze Jul 18 at 21:07
in case you use latex, you can use it here. I've added some markup to your answer. –  acl Jul 18 at 21:18
@acl: thanks for beautifying my text. Looks really good. Unfortunately I don't have latex. –  Dr. Wolfgang Hintze Jul 18 at 21:28