This page was created long, long ago, so I wonder if it is still 'live'?
I have pointed out this thread to a dsolve/numeric expert, let's see if he can work his magic on your DE. I could only get the 0 solution as well (after I fixed the minor typo in your specification for A above).
Any chance you could define D(P)(0) instead of P(8e-8) ?
Without an actual DE, it is very hard to say.
Also, 0 *is* a solution to that DE! Of course, with non-linear DEs, there are multiple solutions, and dsolve/numeric is 'following' the one you don't care about. How to coax it to follow another solution is an interesting question. There are several people here who could help you with that, given something more explicit.
Why not use dsolve with option numeric directly? It implements all sorts of very modern numerical techniques, which are likely to be much more efficient than anything you can develop quickly.
Note that, for cases like this, Maple probably does discretize and use matrix methods! However, it also uses adaptive methods, which are a lot better, but quite difficult to get 'right'.
If you really really want to have an explicit numerical method, your choices are to: 1) find one on the Application Center, 2) implement one from a standard textbook (relatively easy in Maple), or 3) get someone here on primes to help with with #2. It won't be me, I am allergic to that kind of numerical coding...
First note that gamma is a constant in Maple, so it is not a good idea to use it as a 'name'. Changing things produces no answer (in Maple 10 anyways).
Second, you can't really expect to solve a second-order non-linear ODE of such generality in closed-form! That would be an amazing miracle, and that is not saying anything against Maple's DE solver (which is excellent), just that closed-forms require more structure than what you have given.
If you give values for at least some of those unknown functions, there is a chance that a solution can be found.
First, notice how you can change x/T to xx to get a simpler integral which pulls out a factor of T^(3/2). Then change exp(mu/T) (the only remaining constant inside the integral) to say mu[T]. Now, given a value of mu[T], you get a value for the integral, which allows you to solve first for T, then for mu.
Putting that all together, you get a routine that looks like
tau := proc(muT) local ii, T; ii := evalf(Int(xx^(1/2)/(exp(xx)+muT),xx = 0 .. infinity)); T := (ii*muT)^(2/3); [T, T*ln(muT)] end;
which you can use to plot T against mu in this way
plot( [seq(tau(x/10.), x=0..30)]);
(this uses mu[T] from 0..3, which translates to roughly T=0.2..1.3 and mu=-0.5..1.4).
First, notice how you can change x/T to xx to get a simpler integral which pulls out a factor of T^(3/2). Then change exp(mu/T) (the only remaining constant inside the integral) to say mu[T]. Now, given a value of mu[T], you get a value for the integral, which allows you to solve first for T, then for mu.
Putting that all together, you get a routine that looks like
tau := proc(muT) local ii, T; ii := evalf(Int(xx^(1/2)/(exp(xx)+muT),xx = 0 .. infinity)); T := (ii*muT)^(2/3); [T, T*ln(muT)] end;
which you can use to plot T against mu in this way
plot( [seq(tau(x/10.), x=0..30)]);
(this uses mu[T] from 0..3, which translates to roughly T=0.2..1.3 and mu=-0.5..1.4).
That is a print out of the actual code in Maple's own Rank routine! (that is what the cryptic commands and the top do).
What you seem to need is a small Maple implementation of Gaussian Elimination -- take a look on the Application Center, I am fairly sure you'll find at least one there.
That is a print out of the actual code in Maple's own Rank routine! (that is what the cryptic commands and the top do).
What you seem to need is a small Maple implementation of Gaussian Elimination -- take a look on the Application Center, I am fairly sure you'll find at least one there.
I'll send a quick note off to make sure this is noticed by the 'right' person at Maplesoft.
I remember seeing some examples (I have forgotten now) where the 'generic' answer to a problem was empty, but there were all sorts of interesting special-case answers. Also, it is extremely hard to guarantee (when you choose a path to explore) that you will pick what turns out to be the 'interesting' path as far as the user is concerned.
What I have been wanting is more along the lines of lazy, resumable computations. You give the user an output which is (hopefully) the generic ones, but with unevaluated computations for the 'other' branches too. If another branch is needed, then the right computation can be 'restarted' where it left off.
As a matter of fact, I wrote some code to do just that about 5 years ago. Thanks for reminding me, I had forgotten about it! I will have to resurrect that and beef it up, as it could become quite useful.
It is not clear that that is a Maple bug or your input just has a really awful condition number. Note that all your inputs are essentially exact numbers (they are of the form x/5 or y/10), and so are non-trivially related. So it would not be surprising if a very minor jitter of any of a,b,c would cause a minor jitter in z to make things go haywire.
In fact, note that for 2F1, there is a branch-cut from z=1 going to z=infinity, so that you are asking for an evaluation on the cut and right off the cut -- and thus it is not at all surprising that you get wildly different answers!
Really, to know what the 'right' answer is, you have to take the DE for 2F1 and follow it from 0 until your values for z above and see.
This suggestion surprises me. I would have expected Maplesoft's technical support to be pro-active, monitor mapleprimes, and take action as necessary.
This suggestion surprises me. I would have expected Maplesoft's technical support to be pro-active, monitor mapleprimes, and take action as necessary.
These are, unfortunately, rather spottily used in the library. Also, sometimes they are used incorrectly (ie Normalizer(x)=0 instead of the more correct Testzero(x)). I reported such an an occurence (since fixed) in LUDecomposition just last year. I don't quite know why a sweep has a never been done to correct that [other than it is a lot of work].
Actually, writing a program that finds most improper use of Normalizer where Testzero would be quite easy to do. Something like
remove(proc(x) indets(rhs(x), _Inert_EQUATION(_Inert_FUNCTION(_Inert_NAME("Normalizer"), anything), _Inert_INTPOS(0)))={} end, L
where L is a list of name = InertForm (from ToInert) will spot the vast majority.
In fact, I found this intriguing enough that I ran the above on all 13063 named routines in the Maple 10 library, and came up with 13 occurences:
["DEtools/LiouvSols3", "DEtools/kovacicsols/plus_min_expsols", "LREtools/g_p/int_dif", "algcurves/genus1", "algcurves/index2subfield", "algcurves/ratpar", "dsolve/series/single/find_ic", "evala/Subfields/deg4", "series/RootOf/newton", "simplify/wronskian", "type/evenfunc", "type/oddfunc", "type/symmfunc"]
I just love how easy it is to manipulate Maple code with Maple! [Ok, so that is perhaps a minority opinion, but it is really easy, and pretty fast too, it's just one of these things that I find really fun]
