@Christopher2222 Regarding your side question: see wikipedia on Sturm's Theorem and some of the cross-references listed at the end, like for Descarte's Rule of Signs and some properties of polynomial roots.

@Christopher2222 Regarding your side question: see wikipedia on Sturm's Theorem and some of the cross-references listed at the end, like for Descarte's Rule of Signs and some properties of polynomial roots.

@Christopher2222 The GUI uses several hundred MB (not reported by kernelopts or the status bar). Your machine may be swapped out, and thus taking longer than optimal.

You can use densityplot for some of these things. Excepot that it doesn't accept a discont=true option and so you can get spurious bright lines where the color changes sharply, due to roundoff.

This took my machine about 5 seconds, using the commandline interface.

restart:
plotsetup(gif,plotoutput="expinv.gif");                                        

st:=time():

plots:-densityplot((a,b)->evalhf(arctan(-sin(b/(a^2+b^2)),
                                        cos(b/(a^2+b^2)))),
                   -0.25..0.25,-0.25..0.25,colorstyle=HUE,
                   style=patchnogrid,scaletorange=-Pi..Pi,
                   grid=[1500,1500],axes=none);

time()-st;

Or,

restart:
plotsetup(gif,plotoutput="expinv.gif");     

plots:-densityplot(argument(exp(1/(a+b*I))),a=-0.25..0.25,b=-0.25..0.25,
                   colorstyle=HUE, style=patchnogrid,scaletorange=-Pi..Pi,
                   grid=[1500,1500],axes=none);

Those unwanted lines don't appear with all these sorts of plots, of course. So for some things you could try it as an alternative. It seems to use less memory (combined).

The plot Markiyan showed looked nice as screenshot. But its right-click export looked dark and dull, on my Win XP

.

@Christopher2222 The GUI uses several hundred MB (not reported by kernelopts or the status bar). Your machine may be swapped out, and thus taking longer than optimal.

You can use densityplot for some of these things. Excepot that it doesn't accept a discont=true option and so you can get spurious bright lines where the color changes sharply, due to roundoff.

This took my machine about 5 seconds, using the commandline interface.

restart:
plotsetup(gif,plotoutput="expinv.gif");                                        

st:=time():

plots:-densityplot((a,b)->evalhf(arctan(-sin(b/(a^2+b^2)),
                                        cos(b/(a^2+b^2)))),
                   -0.25..0.25,-0.25..0.25,colorstyle=HUE,
                   style=patchnogrid,scaletorange=-Pi..Pi,
                   grid=[1500,1500],axes=none);

time()-st;

Or,

restart:
plotsetup(gif,plotoutput="expinv.gif");     

plots:-densityplot(argument(exp(1/(a+b*I))),a=-0.25..0.25,b=-0.25..0.25,
                   colorstyle=HUE, style=patchnogrid,scaletorange=-Pi..Pi,
                   grid=[1500,1500],axes=none);

Those unwanted lines don't appear with all these sorts of plots, of course. So for some things you could try it as an alternative. It seems to use less memory (combined).

The plot Markiyan showed looked nice as screenshot. But its right-click export looked dark and dull, on my Win XP

.

@adiban Thanks for looking at the Commenter badge's pagination bug.

I'm not sure if I was clear before. The Good Answer badge has been hooked up incorrectly to the vote counts on individual Questions instead of on individual Answers. Which would be a Mapleprimes bug.

Rather than fix the icon-description (5 vs 10) mismatch for the Good Answer and Good Question badges by amending the icon to match the actual behaviour, someone has amended the behaviour.

I'd think that it was done that way carefully and deliberately, except for two things.

1) Now this pair are inconsistent with the Good Post badge, which is still set to 10 votes.

2) Some handles have earned the Good Answer badge when in fact they have not submitted any Answers to the site at all. (True. At the time at which I write this.) It's probably a coding muddle, since such handles appear to have gotten 5 votes on a Question.

BTW, right now, page 2 and 3 listing the Commenter badge members are empty when viewed.

It's been mentioned a few times over the years that the images for the Good Answer and Good Question badges are mismatched with their listed requirements.

The requirements for both are described as 10 votes (and appear to be at least 8, in practice), while their images show a picture of the numeral 5.

I just got bitten by the new edit bug. I submitted a comment, in another thread, and it got posted as an empty comment. A little frustrating.

@ToffeeC The Optimization:-Minmize command accepts an `optimalitytolerance` option, and the evalf/Int command accepts an `epsilon` tolerance.

Now, evalf/Int may get faster if you increase its tolerance, eg. 'epsilon'=1e-6 as an example. But if you do so then you might need to also change the optimalitytolerance to something like 1e-5, so that the `Minimize` command is not trying to refine an optimal solution when in fact the underlying objective results from evalf/Int are never that fine!

You might also get faster performance from evalf/Int if you specify a method, eg. 'method'='_d01ajc' but that choice might depend on your integrand (does it oscillate, etc).

Some people have also given examples on this site where evalf/Int gets a speed-up when the integrand is an operator rather than an expression. Eg, evalf(Int(x->F(x,Y),0..Pi/2)) where F is a procedure. It seems that this might avoid some attempt at conversion to elementary functions, and/or some search for discontinuities. Naturally, you'd want to try this only if you are confident that your integrand does not have these issues.

@ToffeeC The Optimization:-Minmize command accepts an `optimalitytolerance` option, and the evalf/Int command accepts an `epsilon` tolerance.

Now, evalf/Int may get faster if you increase its tolerance, eg. 'epsilon'=1e-6 as an example. But if you do so then you might need to also change the optimalitytolerance to something like 1e-5, so that the `Minimize` command is not trying to refine an optimal solution when in fact the underlying objective results from evalf/Int are never that fine!

You might also get faster performance from evalf/Int if you specify a method, eg. 'method'='_d01ajc' but that choice might depend on your integrand (does it oscillate, etc).

Some people have also given examples on this site where evalf/Int gets a speed-up when the integrand is an operator rather than an expression. Eg, evalf(Int(x->F(x,Y),0..Pi/2)) where F is a procedure. It seems that this might avoid some attempt at conversion to elementary functions, and/or some search for discontinuities. Naturally, you'd want to try this only if you are confident that your integrand does not have these issues.

We know you are doing numeric O.D.E.s right now, but it might not be the case for this member, yes?  :)

If the dsolve example is symbolic then Robert's `odetest` suggestion is probably a good first thing to try, and next might be posting the whole problem here to the site. I suspect that it is being solved symbolically, because there was no mention of a particular value of the independent variable (time t, say) when attempts were being made at checking the result inside the original system.

We know you are doing numeric O.D.E.s right now, but it might not be the case for this member, yes?  :)

If the dsolve example is symbolic then Robert's `odetest` suggestion is probably a good first thing to try, and next might be posting the whole problem here to the site. I suspect that it is being solved symbolically, because there was no mention of a particular value of the independent variable (time t, say) when attempts were being made at checking the result inside the original system.

Does new ~ save one character, over `map`?

@Physikuss As mentioned before, you can change the call as follows, to avoid premature evaluation of `ans`

Statistics:-NonlinearFit(ans, TVector, LVector, initialvalues=, output=parametervalues);

That allows it to run (as long as some variables are not "erased" as you phrased it in the worksheet, and have numeric values). But it seems to encounter another problem with the DE numeric solution, if the computed solution becomes complex-valued or singular or if the DE system isn;t set up right.

@Physikuss As mentioned before, you can change the call as follows, to avoid premature evaluation of `ans`

Statistics:-NonlinearFit(ans, TVector, LVector, initialvalues=, output=parametervalues);

That allows it to run (as long as some variables are not "erased" as you phrased it in the worksheet, and have numeric values). But it seems to encounter another problem with the DE numeric solution, if the computed solution becomes complex-valued or singular or if the DE system isn;t set up right.