@Markiyan Hirnyk Thanks for adding those details and reference to Alec's post. That certainly is a terse way to compute such a thing.

The rendering and performance of the Standard GUI really isn't good for the plots:-densityplot command. If I use that command to make a modest size 600x600 image in this way then it takes Maple 16.01 on a reasonably quick Intel i5 about 1.7 sec to generate the plot structure and then about a further 7.2 sec just to render it.

Whatever the GUI is doing (unnecessary interpolation, resampling!?) while trying to render that plot structure is unfortunate.

One can run the attached worksheet using the `!!!` from the GUI's menubar, to see those kind of timings calculated. (It relies on separate execution blocks.)

mandel.mw

The Standard GUI's memory use also creeps up to over 600MB, if I run it a few times. And it becomes very sluggish to respond to certain menu actions like scrolling of the outout on/off screen, or interecting with the plot output using the mouse and context-menus. And I get messages about exhausted Java heap space in the Linux console from which I launched the GUI.

This kind of performance by the Standard GUI was the motivation for a post about converting the COLOR rtable of the densityplot's returned structure to an Array that ImageTools can handle, and which could be better viewed from a Component Label. Or the Array could be appropriately inserted into a PLOT3D structure (which is what ImageTools:-Preview does) with which th GUI performs better. Or, as in the first link of my Answer, an ImageTools Array could be crafted directly and viewed as an image file, bypassing plots:-densityplot altogether.

@Markiyan Hirnyk Thanks for adding those details and reference to Alec's post. That certainly is a terse way to compute such a thing.

The rendering and performance of the Standard GUI really isn't good for the plots:-densityplot command. If I use that command to make a modest size 600x600 image in this way then it takes Maple 16.01 on a reasonably quick Intel i5 about 1.7 sec to generate the plot structure and then about a further 7.2 sec just to render it.

Whatever the GUI is doing (unnecessary interpolation, resampling!?) while trying to render that plot structure is unfortunate.

One can run the attached worksheet using the `!!!` from the GUI's menubar, to see those kind of timings calculated. (It relies on separate execution blocks.)

mandel.mw

The Standard GUI's memory use also creeps up to over 600MB, if I run it a few times. And it becomes very sluggish to respond to certain menu actions like scrolling of the outout on/off screen, or interecting with the plot output using the mouse and context-menus. And I get messages about exhausted Java heap space in the Linux console from which I launched the GUI.

This kind of performance by the Standard GUI was the motivation for a post about converting the COLOR rtable of the densityplot's returned structure to an Array that ImageTools can handle, and which could be better viewed from a Component Label. Or the Array could be appropriately inserted into a PLOT3D structure (which is what ImageTools:-Preview does) with which th GUI performs better. Or, as in the first link of my Answer, an ImageTools Array could be crafted directly and viewed as an image file, bypassing plots:-densityplot altogether.

@Markiyan Hirnyk Another possibility, similar to A but with lower powers, is,

q*Pi^2*( ( 2*ln(1/(kf2+q)*(q+kf1)) - 1 )*q^2
         + 2*ln(1/kf2*(kf2+q))*kf2^2
         + 2*kf1^2*ln(q/(q+kf1))
         + (2*kf2-2*kf1)*q + kf1^2 );


     2 //          q~ + kf1~ \   2                              2
q~ Pi  ||-1 + 2 ln(---------)| q~  + (2 kf2~ - 2 kf1~) q~ + kf1~
       \\          kf2~ + q~ /


            kf2~ + q~      2         2       q~     \
     + 2 ln(---------) kf2~  + 2 kf1~  ln(---------)|
              kf2~                        q~ + kf1~ /

The leading coefficient of 1/2 in result B can be simplified away, leaving a similar form, with the `normal` command.

> normal(B);

     2      2     2                                        2
q~ Pi  (kf1~  - q~  + 2 q~ kf2~ - 2 q~ kf1~ + 2 ln(q~) kf1~

                      2                       2       2
     - 2 ln(kf2~) kf2~  + 2 ln(kf2~ + q~) kf2~  - 2 q~  ln(kf2~ + q~)

                           2       2
     - 2 ln(q~ + kf1~) kf1~  + 2 q~  ln(q~ + kf1~))

As you say, it's a matter of preference, at some point.

@Markiyan Hirnyk Thank you, that is much more terse a set of commands than the path I had taken. It seems to produce an expression a little longer, without some pairs of ln's finally combined, in my Maple 13 or Maple 16. (Perhaps I transcribed your 2D Math code wrongly.) But the important step of converting the acrtanh's is done.

I see now that there are other short ways to get something similar in length to what I had, eg.

combine(simplify(convert(evalc(R),ln)));

I'm not sure if you are also interested in obtaining smaller representations of this expression. (If not, then sorry.)

If `R` is the original expression then (under your stated assumptions on `kf1`, `q`, and `kf2`) I suspect that `R` is equal to,

q*Pi^2*(   kf1^2*ln(q^2/(q+kf1)^2)
         + kf2^2*ln((kf2+q)^2/kf2^2)
         + ln((q+kf1)^2/(kf2+q)^2)*q^2
         - q^2 + 2*q*kf2 - 2*q*kf1 + kf1^2 );

acer

@Markiyan Hirnyk 

Try it with the `seq` line replaced as,

eqs:=op~({seq(seq([(D@@k)(r)(L)=(D@@k)(f)(L)],k=0..0),L=[2,5,10])});

as per the comment preceding that line.

@Markiyan Hirnyk 

Try it with the `seq` line replaced as,

eqs:=op~({seq(seq([(D@@k)(r)(L)=(D@@k)(f)(L)],k=0..0),L=[2,5,10])});

as per the comment preceding that line.

@stanto As you mention, Maple considers the names to be possibly nonreal here, unless qualified under assumptions.

Compare what you are now asking with the results from,

simplify(e,radical) assuming a::real, Db::real;

and

simplify(e,radical) assuming real;

@stanto As you mention, Maple considers the names to be possibly nonreal here, unless qualified under assumptions.

Compare what you are now asking with the results from,

simplify(e,radical) assuming a::real, Db::real;

and

simplify(e,radical) assuming real;

@majd This is an interesting question, and sorry that I could not respond earlier because of vacation and the recent security lock-out of the site (my valid cookie was expired/clobbered). Presumably this is not something where pdsolve/numeric could be used instead of ArrayInterpolation. It might be possible to compute the finite differences (which fdiff does) oneself, and to apply this in a Compiled procedure after first using ArrayInterpolation to quickly generate the needed subgrids of evaluation points in a fast vectorized manner. Easier for 1D than for the 2D case. I'm afraid that I'll likely be too busy to give it a try, for some weeks.

To get a smoother (ie. not piecewise flat) 2nd derivative from ArrayInterpolation might mean using method=spline and degree=4 or higher. The higher and higher the order used for the spline then the worse might become the 2nd deriv approximations for points farther and farther from the boundary.

@majd This is an interesting question, and sorry that I could not respond earlier because of vacation and the recent security lock-out of the site (my valid cookie was expired/clobbered). Presumably this is not something where pdsolve/numeric could be used instead of ArrayInterpolation. It might be possible to compute the finite differences (which fdiff does) oneself, and to apply this in a Compiled procedure after first using ArrayInterpolation to quickly generate the needed subgrids of evaluation points in a fast vectorized manner. Easier for 1D than for the 2D case. I'm afraid that I'll likely be too busy to give it a try, for some weeks.

To get a smoother (ie. not piecewise flat) 2nd derivative from ArrayInterpolation might mean using method=spline and degree=4 or higher. The higher and higher the order used for the spline then the worse might become the 2nd deriv approximations for points farther and farther from the boundary.

@Markiyan Hirnyk The suggestion to use rhs(sol[1]) instead of eval(k[1],sol) is not so widely reliable, because in older versions of Maple (or in recent Maple if launched with --setsort=0) using rhs(sol[1]) may produce an incorrect answer.

The reason is that in some older Maple versions (or with --setsort=0) the elements of the set sol could be in a session dependent order. The k[2]=... could be sol[1], so sol[1] is not generally reliable as a means to extract the value in the equation k[1]=...

Eg, in Maple 11.02 (or Maple 16.0 launched with --setsort=0) I see,

> restart:
> k[2]: k[2]=666.0: k[1]=5.0:
> sol:={k[1]=5.0,k[2]=666.0};
                       sol := {k[2] = 666.0, k[1] = 5.0}

> rhs(sol[1]);
                                     666.0

> restart:
> sol:={k[1]=5.0,k[2]=666.0};
                       sol := {k[1] = 5.0, k[2] = 666.0}

> rhs(sol[1]);
                                      5.0

@Markiyan Hirnyk The suggestion to use rhs(sol[1]) instead of eval(k[1],sol) is not so widely reliable, because in older versions of Maple (or in recent Maple if launched with --setsort=0) using rhs(sol[1]) may produce an incorrect answer.

The reason is that in some older Maple versions (or with --setsort=0) the elements of the set sol could be in a session dependent order. The k[2]=... could be sol[1], so sol[1] is not generally reliable as a means to extract the value in the equation k[1]=...

Eg, in Maple 11.02 (or Maple 16.0 launched with --setsort=0) I see,

> restart:
> k[2]: k[2]=666.0: k[1]=5.0:
> sol:={k[1]=5.0,k[2]=666.0};
                       sol := {k[2] = 666.0, k[1] = 5.0}

> rhs(sol[1]);
                                     666.0

> restart:
> sol:={k[1]=5.0,k[2]=666.0};
                       sol := {k[1] = 5.0, k[2] = 666.0}

> rhs(sol[1]);
                                      5.0

@dj_gssst You are using sol[1] and sol[2] inappropriately.

Look at what and are.

sol[1];

         k[1] = 0.001637935477698018732276851530308612938004131156280124580147547622858728899732152932156471141157968415

sol[2];

         k[2] = 0.8738880449255668655493761487129800277295707224229803653538821365150932040118518225052273427259289080

Those are both equations, not names or scalar values.

If you want to use the name k[1] then just use it, not sol[1]. If you want to use the value in that equation returned by fsolve then use eval(k[1],sol), and not sol[1].

It's somewhat irritating to wait for this site to load all the image of 2D Math that you've inlined into your posts. It would be quicker and nicer (in future) if you could please just type in your comments here, along with the link to your uploaded worksheets heavy with 2D Math.

@dj_gssst You are using sol[1] and sol[2] inappropriately.

Look at what and are.

sol[1];

         k[1] = 0.001637935477698018732276851530308612938004131156280124580147547622858728899732152932156471141157968415

sol[2];

         k[2] = 0.8738880449255668655493761487129800277295707224229803653538821365150932040118518225052273427259289080

Those are both equations, not names or scalar values.

If you want to use the name k[1] then just use it, not sol[1]. If you want to use the value in that equation returned by fsolve then use eval(k[1],sol), and not sol[1].

It's somewhat irritating to wait for this site to load all the image of 2D Math that you've inlined into your posts. It would be quicker and nicer (in future) if you could please just type in your comments here, along with the link to your uploaded worksheets heavy with 2D Math.