Is there an error in Mathematica 9.0.1 integral?

Questions
,
1

Hi All

Can you please help with the following

Solving the following first order ODE

DSolve[D[H[t], t] + 2 H[t]^2 - c == 0, H[t], t]

gives rise to the following solution

(Sqrt[c] Tanh[Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] C[1]])/Sqrt[2]

However, although the integration constant appears, the latter isn’t the most general solution of the differential equation above. In fact, the following is a different solution of the same equation (which cannot be obtained by different choices of the integration constant), and which have been overlooked by Mathematica

H[t_] := (Sqrt[c] Coth[Sqrt[2] Sqrt[c] t])/Sqrt[2].

As far as I see, Mathematica for some reason restricted the relative sign between the exponents.

How could I convince Mathematica to return the most general solution?
Thanks

2

Oh how I hate branch cuts. This is a problem with branch cuts. Anytime you see inverse trig/hyperbolic trig functions and something unintuitive, you can bet that it’s something to do with branch cuts.

To begin, let’s compare your answer and Mathematica’s answer:

(Sqrt[c] Tanh[Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] C[1]])/Sqrt[2]
(Sqrt[c] Coth[Sqrt[2] Sqrt[c] t])/Sqrt[2]

To simplify things, let’s factor a Sqrt/Sqrt[2] out of both of these:

Tanh[Sqrt[2] Sqrt[c] t + Sqrt[2] C[1]]
Coth[Sqrt[2] Sqrt[c] t]

We now want to see if there’s a constant value of C[1] such that these are equal. Let’s use Solve to see what this might be:

Solve[ Tanh[Sqrt[2] Sqrt[c] t + Sqrt[2]  C[1]] == Coth[Sqrt[2] Sqrt[c] t], C[1]]

The result is:

C[1] -> 1/2 (-2 Sqrt[c] t + Sqrt[2] ArcTanh[Coth[Sqrt[2] Sqrt[c] t]])

ArcTanh[Coth] is a complicated thing, but it’s basically equal to either x+I Pi/2 or x-I Pi/2 depending on what your needs are. You or the computer have to choose the right branch of the function to take. With either of those values though C[1] is a complex constant.

So… Mathematica’s solution does include your solution if you choose a complex value for C[1] and somehow manage to take the branch cuts correctly in calculating the result. I hope this kinda explains what DSolve is likely thinking. Humans tend to be very good at guessing what the correct branch to take based on what they know an equation to mean or how it will be applied. This isn’t the case with computers of course so it becomes a problem.

3

Hello and thank you very much for your answer.

The closed form general solution for the equation has the following form (I also verify that in fact it satisfies the differential equation).

H[t_] := ( 

  Sqrt[c] (\[Alpha] Exp[

       Sqrt[2] Sqrt[c] t] - \[Beta] Exp[-Sqrt[2] Sqrt[c] t]))/(

  Sqrt[2] (\[Alpha] Exp[

       Sqrt[2] Sqrt[c] t] + \[Beta] Exp[-Sqrt[2] Sqrt[c] t]));

Here \alpha and \beta are arbitrary constants. We can easily verify that in fact it is a soluiton by substituting back into the original differential equation

Simplify[D[H[t], t] + 2 H[t]^2 - c]

Out[30]= 0

Why Mathematica doesn’t give this solution, and why does it fixe the relative signs of \alpha and \beta?

For completeness here is the correct solution Mathematica missed

(Sqrt[c] Coth[Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] C[1]])/Sqrt[2]

(Mistakenly the third equation of my previous post, which still doesn’t change the fact that there is a problem, is wrong.)

This may or may not affect your previous answer.

Thanks

4

Both,

(Sqrt[c] Coth[Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] C[1]])/Sqrt[2]

And

(Sqrt[c]*Tanh[Sqrt[2]*Sqrt[c]*t + Sqrt[2]*Sqrt[c]*C[1]])/Sqrt[2]

Are sets of solutions parameterized by a constant. The question is whether they parameterize the same set of functions. They essentially seem to do that.

Replacing C[1] with FirstEquationsConstant and C[2] with SecondEquationsConstant, we can see if there’s a straightforward relationship between them:

Solve[(Sqrt[c]*
     Tanh[Sqrt[2]*Sqrt[c]*t + 
       Sqrt[2]*Sqrt[c]*FirstEquationsConstant])/
   Sqrt[2] == (Sqrt[c] Coth[
      Sqrt[2] Sqrt[c] t + Sqrt[2] Sqrt[c] SecondEquationsConstant])/
   Sqrt[2], SecondEquationsConstant]

If we again say that ArcTanh[Coth] or ArcCoth[Tanh] is x + I Pi/2, or x - I Pi/2 or another valid branch cut we get the following relation

secondEquationsConstant = FirstEquationsConstant + (I \[Pi] (1 + 2 C[1]))/(2 Sqrt[2] Sqrt[c])

Where C[1] here is another constant caused by a branch cut that can take an integer value.

So I’m not sure it’s really a bug as much as the pain and suffering brought to us by complex branch cuts.

It’s best to have some kind of context for how “Smart” a solver can be with branch cuts. Consider this DSolve statement:

DSolve[Sqrt[D[f[x], x]] == -x, f[x], x]

The result it gives is x^3/3 + C[1]. Is this correct? It doesn’t even solve the original equation unless we manage to take the right branch cuts, which aren’t the principal ones. Then again it’s also the result we’d see from NDSolve or a numeric solver.

If you ever believe you have found an issue, forward it to support@wolfram.com along with your activation key or license number. They can in many circumstances state whether something is an issue or just unexpected. Otherwise, they can make sure a developer looks into the issue for a future release. But it’s also very possible when working with inverse trig functions that the problem you are seeing isn’t exactly a problem with the solver, but something bigger. It can take a lot of effort to determine which is which sometimes.