Introduction

I have been interested in Integrate[], DSolve[], and NDSolve[] for over thirty years, and I have been impressed by their continual improvement. Symbolic solutions are often difficult and tricky. So I was very interested in a blog post in June by Stephen Wolfram. In V15, DSolve[] has a new approach to solving built into it, which was recently discussed in a webinar (15 July 2026, YouTube video). It uses AI to find solutions to differential equations involving elementary functions (only). Naturally, I wondered, “Is this a big step? Or a little step? Or maybe it’s more complicated, a big advance to use AI for symbolic mathematics but only a small advance of DSolve[]’s capabilities?” Nonetheless, it is an advance.
I am not an expert on machine learning, but I recalled seeing a paper by a paper by Lample and Charton (2020), who used a seq2seq transformer to do some symbolic mathematics and claimed, “We achieve results that outperform commercial Computer Algebra Systems such as Matlab or Mathematica.” A paper by D’Ascoli, S. et al. (2022) made a similar claim to outperform FindSequenceFunction[]. Of course, there are other papers, too, but these attracted attention because of the direct comparison to Mathematica. The machine-learning (ML) method in DSolve[] also uses a seq2seq transformer. We can think of this extension of the “classic,” pre-V15 DSolve[] as part of these advances in the area of computational symbolic mathematics. It is worth pointing out that it is not just an academic advance but a new, commercial technology.
Two major points made in the blog are that the ML method can produce simpler results than the classic DSolve[] and that it usually does so faster. Less important are that it solves one a very few number of problems that DSolve[] cannot. It will be seen that the reverse is also true, although I do not have data to claim whether it is few or many problems the ML method does not solve but the classic DSolve[] does. It is apparent that the purpose of the ML method at present is to extend classic DSolve[] methods, not to replace them.
We will look into the ML extension of DSolve[] to gain a better appreciation of its promise and limitations. We will not make an extensive examination, but we will see some limitations that might seem significant. Further exploration of the internal solver, called MLDSolve[], may be found in the Appendix. I do not want to make too much of the limitations. The positive advances are more significant, although it was interesting to explore what the ML method has yet to “learn.”
Aside from the ML extension, we will also be showing how to work with differential equations to find solutions with the help of DSolve[] and Integrate[]. Well, it will show how I do some things, anyway. To shorten the main presentation, the code for some of the technical trials is relegated to the Appendix.
I often include timings, since a claim is that the ML method is sometimes faster than the classic, pre-V15 methods. When DSolve[] is called, as it searches for a solution, it loads internal packages as needed. Consequently, the first run often takes longer than subsequent runs. For instance, the initial loadings add almost 20 sec. to the timing of the second blog example below, ode2. Consequently, I show the timings on the 2nd+ runs, after DSolve[] is fully initialized. Some functions cache results and use the cached values instead of recomputing them. This shortens timings and does not fully account for the computational complexity of solving the problem. Simplify[], for instance, caches results. To address this issue, I use ClearSystemCache[] before each timing. It is possible for some function to use a private cache and not the system cache. If true, I don’t know how to deal with this issue: to load all the packages used by DSolve[] without caching anything.

Four examples

I will examine principally the two examples in the blog post, which are the first and third examples in the July 2026 webinar; the webinar includes two more. V14.3 fails to solve one of the examples but V15 succeeds. For the other three, the V15 solution is simpler than in V14.3 in one or more ways: The leaf count is smaller; instead of an implicit solution, an explicit solution is found; or the V14.3 solution has unsolved integrals that do not appear in the new solution. Maybe because I’ve taught Calc I two dozen times and Calc II a dozen, the “obvious” transformation to try — let u = something inside another function — would allow a motivated calculus student to solve these ODEs by hand. It’s even easier with the help of Mathematica.

Code for the problems

First blog example; webinar example 3
ode1=​​(-1-2x)f[x]Tan1+x-
-61-2x

f[x]
x
+
61+2x

x1-xTan1+x-
-61-2x

f[x]
x
+xTan1+x-
-61-2x

f[x]
x
f'[x]0;
Second blog example; webinar example 1
ode2=​​4-1+
1-
1
2
x
2
x
2
Sec[4(1+x+ArcCsc[x])]
-
1-
1
2
x
2
x
f'[x]0;{int}=SolveValues[ode2,f'[x]];(*integrandformofode2*)
Webinar example 2
ode3=​​2x
1-x
1+x
(1+x)ArcSech[x]^2-
f[x]
ArcSech[x]
E
+
f[x]
ArcSech[x]
E
f[x]-
f[x]
ArcSech[x]
E
+
f[x]
ArcSech[x]
E
x
1-x
1+x
(1+x)ArcSech[x]f'[x]==0;
Webinar example 4
ode4=​​-4+Sinh[12+f[x]]f'[x]==0;

ODE 1: The first blog example and webinar example 3

In V14.3, DSolve[ode1,f[x],x] fails to produce a solution in around 7 sec.; in V15, it succeeds in around 5-7 sec. You can simulate the V14.3 behavior in V15 with DSolve[ode1,f[x],x,Method->"Classic"], if you do not have V14.3.
In ode1, the “obvious” substitution to try is y[x]==1+x-(E^(-61-2 x)f[x])/x, from the argument of Tan[]. DSolveChangeVariables[] is apparently not meant to work with such transformations. In this case, it can be carried out with a simple ReplaceAll[] command. The resulting newDE1 is separable, equivalent to Tan[y[x]]y'[x]==1/x.
See the appendix below for an explanation of DSolveToPureFunction[], which is used to substitute the solution.
Reset for timing the solution
ClearSystemCache[];​​ysub1=y[x]==1+x-
-61-2x

f[x]
x
;​​fsub1=First@Solve[ysub1,f[x]];(*substitutionreplacementrule*)​​newDE1=ode1/.DSolve`DSolveToPureFunction[fsub1];​​dsol1=fsub1/.DSolve[newDE1,y[x],x]//AbsoluteTiming​​CellPrint@ExpressionCell[(*checkdsol1*)​​ode1/.DSolve`DSolveToPureFunction[dsol1]//​​FullSimplify[#,Cases[#,_C∈Integers,Infinity]]&​​,"Output",CellTags->"Check solutions:",ShowCellTags->True];
Out[]=
0.057519,f[x]
61+2x

x1+x+ArcCos
-

1

x
,f[x]
61+2x

x1+x-ArcCos
-

1

x

{True,True}
The first solution of the solution set dsol1 is equivalent to the V15 DSolve[] solution (see “Further remarks...” below on “Complete solutions”):
ClearSystemCache[];​​(dsol1V15=DSolve[ode1,f[x],x])//AbsoluteTiming​​(f[x]/.First@dsol1V15)-(f[x]/.First@dsol1/.C[1]->Log[C[1]])//FullSimplify
Out[]=
{5.20263,{{f[x]
61+2x

2
x
+
61+2x

x(1+ArcSec[x

1
])}}}
Out[]=
0
Note how much time DSolve[] takes on ode1 compared with the substitution/newDE1 code. The code with the substitution does not check that Solve[] and DSolve[] worked; nonetheless, it’s 70-100 times faster than DSolve[], and that’s not because it skips checking.

ODE 2: The second blog example and webinar example 1

We approach the second example in a similar way, substituting the argument u==4(1+x+ArcCsc[x]) of Sec[]. Again, DSolveChangeVariables[] does not convert ode2. This is presumably because Solve[] fails to invert the substitution to get x in terms of u. It’s often not necessary to do that, when a substitution “works.” We can work with the differentials to change variables, as one does in intro calculus. We will put the differential equation in the form
y'=F(x)
before the substitution and use Integrate[] instead of DSolve[]. There is a bit more code because we include a quick way to check the three principal intermediate results.
Reset for timing the solution
ClearSystemCache[];​​Clear[dsol2];​​(*returnsode2ifsolvingfails*)​​(Replace[​​SolveValues[ode2,f'[x]],{(*gettheintegrandf'[x]intermsofx*)​​{sol_}:>(int=sol),​​_:>Return[ode2,CompoundExpression](*$Failed*)​​}];​​{subU,subDU}=(*substitutionsystem*)​​NestList[Dt,4(1+x+ArcCsc[x])==u,1];​​Replace[​​Solve[subDU,Dt[x]],{​​{{sol_Rule}}:>((*subdifferential,thensubu(backwards)*)​​newInt=int*Dt[x]/.​​sol/.(*substituteDt[x]*)​​Rule@@subU(*4(1+x+ArcCsc[x])->u*)//​​Simplify),​​_:>Return[ode2,CompoundExpression](*$Failed*)​​}];​​Replace[​​newInt/.(*integrateit*)​​y_.HoldPattern@Dt[v_]:>Integrate[y,v,GeneratedParameters->C],​​{_Integrate:>Return[ode2,CompoundExpression],(*$Failed*)​​dsol_:>(dsolA=dsol)​​}];​​dsol2=f[x]->dsolA/.Solve[subU,u])//AbsoluteTiming​​(*checksolutionorprint$Failed*)​​CellPrint@ExpressionCell[(*checkdsol2*)​​Replace[​​dsol2,​​{{_Rule}:>(ode2/.DSolve`DSolveToPureFunction[dsol2]//​​FullSimplify[#,Cases[#,_C∈Integers,Infinity]]&),​​_:>$Failed}​​]​​,"Output",CellTags->"Check solution:",ShowCellTags->True]
Out[]=
{0.003348,{f[x]

1
+Tan[4(1+x+ArcCsc[x])]}}
True
The above approach is something like 1200-2000 times as fast as DSolve[] and produces the same solution.

ODE 3: webinar example 1.

The ODE ode3 can also be handled with DSolve[] and one of several substitutions given below by ysub3k[k] for k=0,1,2,…. We give a quick demo (ysub3k[1] is the “obvious” substitution, but ysub3k[2] is fastest).
Reset for timing the solution
ClearSystemCache[];​​ysub3k//ClearAll;​​ysub3k[k_Integer]:=(*
f[x]
ArcSech[x]
,
f[x]
ArcSech[x]

,
f[x]
ArcSech[x]


*)​​NestExp,
f[x]
ArcSech[x]
,k;​​ysub3=y[x]==ysub3k[1];(*
f[x]
ArcSech[x]

*)​​fsub3=First@Solve[ysub3,f[x]]/._C->0;(*nixcomplexbranches*)​​newDE3=ode3/.DSolve`DSolveToPureFunction[fsub3];​​dsol3=fsub3/.DSolve[newDE3,y[x],x]//AbsoluteTiming
Out[]=
{0.057143,{{f[x]ArcSech[x]Log[Log[2x+

1
]]}}}
ClearSystemCache[];​​DSolve[ode3,f[x],x]//AbsoluteTiming
Out[]=
{0.802862,{{f[x]ArcSech[x]Log[Log[2x+

1
]]}}}

ODE 4: webinar example 3.

The ODE ode4 can also be handled with DSolve[] and the “obvious” substitution y[x]==12+f[x].
Of course, ode4 can be directly integrated, even with generalized parameters, and solve to obtain a quite general solution:
The DSolve::ifun message arises in DSolve[ode4] from a 417-leaf classic solution set that is ultimately replaced by the ML solution. DSolve[] catches the Solve::ifun message and relays it as DSolve::ifun, even though it arose in a discarded attempt.

Further remarks about the examples and ML-assisted DSolve[]

Other solution methods

We explore other substitutions in the Appendix, “Other ways to solve the two blog examples.”

Complete solutions

You may have noticed that the V15 solution set dsol1V15 to ode1 has just one solution while the dsol1 set has two solutions. It turns out other branches are missing, too. The remarks in this section address this issue, although it is not particularly about the ML method. Even before V15, such deficiencies in DSolve[] solution sets, while uncommon, were fairly normal. Over time, some get fixed; otherwise, the user may have to deal with them. We do so for ode1 below. Skip this section if your interest in restricted to the ML method.
The first solution of dsol1 was shown to be equivalent to the one in dsol1V15. It is easy to see that the other solution is not (different signs on ArcSec[]):
And if we allow C[1] to represent an arbitrary constant, then the same family of solutions is represented whether we write C[1] or -C[1]. So the modified dsol1 solution set may be represented as follows:
The existence of a negative branch is predicted from newDE1, which is a separable ODE. If we separate the y and x components on opposite sides of an equation, we will be able to see why.
The solution set dsol1a offers even more solutions (see Appendix, “Other ways to solve the two blog examples”, for code to calculate dsol1a):
A drawback of not obtaining a truly general solution is that one cannot solve every IVP. For instance, DSolve[{ode1,ic}] cannot solve an IVP with an IC on a negative branch.
In the following case, the initial condition is at a singular point at which there are two solutions. Only one can found with the ML solution, of course.
The dsol1a solution set contains all branches and can be used to solve any valid IVP, but we have construct the particular solution from the general ourselves.
It is worth pointing out that one can easily convert the ML-method solution dsol1V15 to a complete solution in this case by solving for C[1] and solving back for f[x]. This sort of round trip sometimes works, sometimes not. In this case, one can see that it is likely to work out, since the equation for f[x] is linear in ArcSec[…] and inverting elementary functions is a strength of Mathematica.
This solution set, which we built out from the dsol1V15 solution, may be used to solve any IVP.

Limitations of the ML method

The ML method is trained only on ODEs whose input and output are expressions in terms of elementary functions with exact coefficients. No parameters, no special functions, no piecewise elementary functions. It is invoked when DSolve[] fails, produces an output with a large leaf count, returns an implicit solution, or returns a solution with unsolved integrals. See the 15 Jul 2026 webinar and the Appendix, “Limitations of MLDSolve[].”

Reflections on solving ODEs

Here are some of the things we notice about DSolve[], above and below in the Appendix:
1
.
The ML method solved a problem which the classic DSolve[] did not.
2
.
The ML method found a solution, but not the complete, general solution, which sometimes happens with the classic DSolve[], too. However, the ML method did not warn of possible missing solutions.
3
.
The ML method found simpler, explicit formulas for the solutions, compared to the classic DSolve[], sometimes eliminating unsolved integrals from the classic solution.
4
.
By design, the ML method tries to solve first-order ODEs in terms of elementary functions; it does not solve ODEs with parameters or special functions.
5
.
The ML method is faster than it appears, taking about 0.7 sec. to solve ode1, still much slower than the substitution method; the 6-7 extra seconds it takes DSolve[] seem to be spent on other computations (mostly trying classic methods first). See Appendix, “MLDSolve[]”.
6
.
The ML method can give mathematically inequivalent results from different, mathematically equivalent inputs. DSolve[] can succeed one one input and fail on another, something that probably didn’t happen in versions before V15. See Appendix, “Limitations of MLDSolve[]”.
7
.
Classic DSolve[] methods might have solved the blog/seminar problems (but didn’t). From a human’s point of view (mine, if no one else’s), the choice of method was obvious.
9
.
DSolve[] sometimes uses inverse functions to get a solution and ignores other branches of the inverted function, issuing a warning in the process. The ML method produces a similar solution, but without a warning message.
10
.
We were able to construct the general solution to ode1 from the ML solution. The ease was, I feel, directly related to the simplicity of the ML solution.
11
.
Pasting the code for ode1 into the Smart Search field of Safari, which called Google, yields a step-by-step solution in 8 seconds using substitutions similar to the alternative solution above.

Discussion

The ML method is build on a seq2seq transformer. It seems to recognize the structure of each of the blog/webinar ODEs (which in the human view can be broken down with substitution). Maybe it carries out the substitution procedure, maybe not. I’ve had students who can integrate without carrying out the substitution procedure. The student just kind of sees how it should turn out.
The so-called “obvious” substitution is what the student should try before they claim to be stuck. I also call such a substitution the “rule-of-thumb substitution.” In the case of ode1, I admit it is disappointing that the classic DSolve[] gives up without finding the rule-of-thumb substitution that transforms the ODE into one it can solve.
The LLM response from Googling ode1 (in the “AI Overview”) looks more like doing mathematics, since it breaks down the solution into steps accompanied by explanations of how to think about the transformations being made. If I replace Tan by Log in ode1, the V15 DSolve[] returns an implicit solution. Google made mistake in solving the new ODE. When I asked it, “Didn’t you make a mistake in step 3?”, it identified the mistake, fixed it, and then returned the implicit solution — and it went further. It offered to solve explicitly for f[x] in terms of the Lambert W function (ProductLog[]), something that DSolve[]/Solve[] did not do. A curious thing about the Google AI is that while it’s constructing the solution, it cycles through tiny icons of computer-algebra systems, including the Wolfram app.
In sum, it is interesting that machine learning can enhance a sophisticated mathematical solver like DSolve[]. Given that LLMs seem at least comparable to the ML method and possibly better — more testing might show a greater difference — one might wonder which of the two AIs it might be better to invest more work in.

Areas for future development

I gather that adding or expanding ML methods are being contemplated or explored for other domains, such as for DSolve[], Integrate[], FindSequenceFunction[], etc.
1
.
Perhaps an ML method might someday be able to construct (or guess) a complete solution from a family of solutions found by whatever method in DSolve[].
2
.
Less the dependence on the input form, either by further ML training or by mathematical preprocessing.
3
.
Perhaps an ML method might be developed to optimize the performance of DSolve[] by assisting in the selection of solution algorithms.
4
.
I never noticed (over 30-some years) that DSolve[] does not try substitutions as a strategy.
5
.
Can the ML method become fast? The fastest I found was around 0.05 sec. on a simple problem, and 0.3–0.5 sec. seemed typical.

References

D’Ascoli, S. et al., “Deep Symbolic Regression for Recurrent Sequences”, Proceedings of the 39th International Conference on Machine Learning, Baltimore, Maryland, USA, PMLR 162, 2022. https://proceedings.mlr.press/v162/d-ascoli22a/d-ascoli22a.pdf (Accessed 11 Jul 2026)
Lample, G. and F. Charton, "Deep Learning For Symbolic Mathematics”, ICLR 2020, 2020. https://iclr.cc/virtual_2020/poster_S1eZYeHFDS.html or https://doi.org/10.48550/arXiv.1912.01412 (Accessed 5 Jul 2026)
Wikipedia, Seq2seq, https://en.wikipedia.org/wiki/Seq2seq (Accessed 5 July 2026)
Wolfram Research, Inc., "Neural Networks and Symbolic Differential Equations" [Video], YouTube, 2 Feb 2026, https://www.youtube.com/watch?v=L5ToCzXqWLY& (Accessed 17 Jul 2026)
Wolfram Research, Inc., "Mathematical Computation for the Age of Quantum and AI" [Webinar], Wolfram U, 15 Jul 2026. Link to YouTube recording: DSolve[] is discussed at https://www.youtube.com/live/mAbXD_nr_jc?si=igK60eOO7OwMKurA&t=2953 (Accessed 18 Jul 2026). Link to slides for the DSolve[] discussion: https://amoeba.wolfram.com/index.php/s/JSXo9a2ars89mZE/download?path=%2F&files=WolframU-Slides_aramm_siria_final.nb (Accessed 18 Jul 2026)
Wolfram, S. “Launching Version 15 of Wolfram Language & Mathematica: Built-in (Useful) AI & Lots of New Core Functionality”, “The Corners of DSolve Get a Little Help from AI Methods”, 16 Jun 2026, https://writings.stephenwolfram.com/2026/06/launching-version-15-of-wolfram-language-mathematica-built-in-useful-ai-lots-of-new-core-functionality/#the-corners-of-dsolve-get-a-little-help-from-ai-methods (Accessed 5 July 2026)

CITE THIS NOTEBOOK

A deeper peek at the AI assist to DSolve[]​
by Michael Rogers​
Wolfram Community, STAFF PICKS, July 23, 2026
​https://community.wolfram.com/groups/-/m/t/3766719