<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" version="2.0">
  <channel>
    <title>MaplePrimes - answers and comments on Question, Please help me optimize code</title>
    <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code</link>
    <language>en-us</language>
    <copyright>2026 Maplesoft, A Division of Waterloo Maple Inc.</copyright>
    <generator>Maplesoft Document System</generator>
    <lastBuildDate>Tue, 09 Jun 2026 11:12:59 GMT</lastBuildDate>
    <pubDate>Tue, 09 Jun 2026 11:12:59 GMT</pubDate>
    <itunes:subtitle />
    <itunes:summary />
    <description>The latest answers and comments added to the Question, Please help me optimize code</description>
    <image>
      <url>http://www.mapleprimes.com/images/mapleprimeswhite.jpg</url>
      <title>MaplePrimes - answers and comments on Question, Please help me optimize code</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code</link>
    </image>
    <item>
      <title>revision</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code?ref=Feed:MaplePrimes:Please help me optimize code:Comments#answer127458</link>
      <itunes:summary>&lt;p&gt;The solution seems simple, but you may not like to hear it. The repeated nesting of unapply, function application, and evalf@simplify is unnecessary and is causing your code to be thousands of times less efficient than it ought to be.&lt;br&gt;&lt;br&gt;Rewrite the entire worksheet and completely change your methodology. Forbid yourself from creating operators or procedures, altogether. Forbid yourself from using `unapply`. Forbid yourself from calling `evalf` on a symbolic expression which you then subsequently pass to `simplify`.&lt;/p&gt;
&lt;p&gt;Use expressions instead of operators, function calls, and unapply. Call simplifiy sparingly. Never call evalf on a symbolic expression which is not expected to produce a purely numeric nonsymbolic result. Never call `simplify` on a symbolic expression with floating-point coefficients within it (and hopefully never create such expressions).&lt;/p&gt;
&lt;p&gt;If you are bent on using some procedure, then let it be just a one procedure which would take as its arguments value for parameters ymin, yman, amin, amax, eps, etc. This would wrap around almost the whole sheet. Possibly, just possibly, consider having another inner procedure which might take as its arguments numeric values for y, a, d, etc. But that would be for moving the whole computation entirely to pure numerics -- and I don't know whether you want that or not, so investigate whether you want the symbolic approach first, done efficiently.&lt;/p&gt;
&lt;p&gt;The define_external call assigned to `init` is unusual. It passes the 'MAPLE' option (as if it were calling a custom wrapper which did all its own argument processing), but also passes all the typed parameters for the external function (as if it were utilizing wrapperless external calling). Usually a define_external call has either one of those or the other, but not both. I could be wrong, but my guess is that you don't want/need the 'MAPLE' option for `init`, while you do for `FindZerosOfFirstAndSecondDerivatives` which is more obviously a custom wrapper.&lt;/p&gt;
&lt;!--break--&gt;
&lt;p&gt;acer&lt;/p&gt;</itunes:summary>
      <description>&lt;p&gt;The solution seems simple, but you may not like to hear it. The repeated nesting of unapply, function application, and evalf@simplify is unnecessary and is causing your code to be thousands of times less efficient than it ought to be.&lt;br&gt;&lt;br&gt;Rewrite the entire worksheet and completely change your methodology. Forbid yourself from creating operators or procedures, altogether. Forbid yourself from using `unapply`. Forbid yourself from calling `evalf` on a symbolic expression which you then subsequently pass to `simplify`.&lt;/p&gt;
&lt;p&gt;Use expressions instead of operators, function calls, and unapply. Call simplifiy sparingly. Never call evalf on a symbolic expression which is not expected to produce a purely numeric nonsymbolic result. Never call `simplify` on a symbolic expression with floating-point coefficients within it (and hopefully never create such expressions).&lt;/p&gt;
&lt;p&gt;If you are bent on using some procedure, then let it be just a one procedure which would take as its arguments value for parameters ymin, yman, amin, amax, eps, etc. This would wrap around almost the whole sheet. Possibly, just possibly, consider having another inner procedure which might take as its arguments numeric values for y, a, d, etc. But that would be for moving the whole computation entirely to pure numerics -- and I don't know whether you want that or not, so investigate whether you want the symbolic approach first, done efficiently.&lt;/p&gt;
&lt;p&gt;The define_external call assigned to `init` is unusual. It passes the 'MAPLE' option (as if it were calling a custom wrapper which did all its own argument processing), but also passes all the typed parameters for the external function (as if it were utilizing wrapperless external calling). Usually a define_external call has either one of those or the other, but not both. I could be wrong, but my guess is that you don't want/need the 'MAPLE' option for `init`, while you do for `FindZerosOfFirstAndSecondDerivatives` which is more obviously a custom wrapper.&lt;/p&gt;
&lt;!--break--&gt;
&lt;p&gt;acer&lt;/p&gt;</description>
      <guid>127458</guid>
      <pubDate>Mon, 07 Nov 2011 09:09:47 Z</pubDate>
      <itunes:author>acer</itunes:author>
      <author>acer</author>
    </item>
    <item>
      <title>side remarks</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code?ref=Feed:MaplePrimes:Please help me optimize code:Comments#answer127504</link>
      <itunes:summary>&lt;p&gt;1. I would prefer to see the code. Not the cryptic thing in your post.&lt;/p&gt;
&lt;p&gt;2. Some times ago I did such stuff (replicating Maple commands in C).&lt;br&gt;It is not so much fun. But it only makes sense (for me), if one has done&lt;br&gt;the work in Maple first (= have a good code working in Maple) and after&lt;br&gt;that go that painful route.&lt;/p&gt;
&lt;p&gt;3. It may be worth to put all the Maple code into some proc, which&lt;br&gt;then is being called from C (if ever needed)&lt;/p&gt;
&lt;p&gt;4. Maintaining such is a pain.&lt;/p&gt;
&lt;p&gt;Why and for what do you you need it?&lt;/p&gt;</itunes:summary>
      <description>&lt;p&gt;1. I would prefer to see the code. Not the cryptic thing in your post.&lt;/p&gt;
&lt;p&gt;2. Some times ago I did such stuff (replicating Maple commands in C).&lt;br&gt;It is not so much fun. But it only makes sense (for me), if one has done&lt;br&gt;the work in Maple first (= have a good code working in Maple) and after&lt;br&gt;that go that painful route.&lt;/p&gt;
&lt;p&gt;3. It may be worth to put all the Maple code into some proc, which&lt;br&gt;then is being called from C (if ever needed)&lt;/p&gt;
&lt;p&gt;4. Maintaining such is a pain.&lt;/p&gt;
&lt;p&gt;Why and for what do you you need it?&lt;/p&gt;</description>
      <guid>127504</guid>
      <pubDate>Tue, 08 Nov 2011 02:02:55 Z</pubDate>
      <itunes:author>Axel Vogt</itunes:author>
      <author>Axel Vogt</author>
    </item>
    <item>
      <title>Found!</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code?ref=Feed:MaplePrimes:Please help me optimize code:Comments#answer127525</link>
      <itunes:summary>&lt;p&gt;MainFDerivativeAS := diff(MainFS, a); MainFDerivativeAI := unapply(MainFDerivativeAS, y, a, b); &lt;br&gt;MainFDerivativeA := proc (u, v, w) options operator, arrow; eval(MainFDerivativeAI(u, v, w)) end proc;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Only such syntax both fast (due only S-suffix expressions in diff presented) in symbolic calc and evaluable via evalhf (MainFDerivativeA is evaluable). Intermadiate one more + eval.&lt;/p&gt;</itunes:summary>
      <description>&lt;p&gt;MainFDerivativeAS := diff(MainFS, a); MainFDerivativeAI := unapply(MainFDerivativeAS, y, a, b); &lt;br&gt;MainFDerivativeA := proc (u, v, w) options operator, arrow; eval(MainFDerivativeAI(u, v, w)) end proc;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Only such syntax both fast (due only S-suffix expressions in diff presented) in symbolic calc and evaluable via evalhf (MainFDerivativeA is evaluable). Intermadiate one more + eval.&lt;/p&gt;</description>
      <guid>127525</guid>
      <pubDate>Tue, 08 Nov 2011 19:51:33 Z</pubDate>
      <itunes:author>icegood</itunes:author>
      <author>icegood</author>
    </item>
    <item>
      <title>About external call</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code?ref=Feed:MaplePrimes:Please help me optimize code:Comments#comment127471</link>
      <itunes:summary>&lt;p&gt;I really use a custom wrapper. And i understand that defining of arguments is not necessary. I did such syntax for InitInternal only because have many parameters...&lt;/p&gt;</itunes:summary>
      <description>&lt;p&gt;I really use a custom wrapper. And i understand that defining of arguments is not necessary. I did such syntax for InitInternal only because have many parameters...&lt;/p&gt;</description>
      <guid>127471</guid>
      <pubDate>Mon, 07 Nov 2011 17:09:21 Z</pubDate>
      <itunes:author>icegood</itunes:author>
      <author>icegood</author>
    </item>
    <item>
      <title>OK...</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code?ref=Feed:MaplePrimes:Please help me optimize code:Comments#comment127497</link>
      <itunes:summary>&lt;p&gt;I did as you suggested but nevertheless MainFDerivative... should be function calls. But as expressions they refused to calculate numerically from external program. I mean, evalhf doesn't work in sheet itself while evalf works in sheet but EvalMapleProc in c library doesn't work.&lt;/p&gt;
&lt;p&gt;Code of c library call you can find in last answer of: http://www.mapleprimes.com/questions/126686-External-Dll-EvalMapleStatement.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Only for evalf version one line substituted to:&lt;/p&gt;
&lt;p&gt;return (ice_real_TReal)MapleToFloat64(ExternalKernel, EvalMapleProc(ExternalKernel, f, 3, args));&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Now i really want to know in which version of symbolic expressions calculation will work that code. At least in&amp;nbsp; my version of code and EvalhfMapleProc call it works. Preferably want it to work with EvalhfMapleProc i.e. evalhf from sheet.&lt;/p&gt;
&lt;p&gt;Test file is in attach.&lt;/p&gt;
&lt;p&gt;&lt;a href="/view.aspx?sf=127497/424602/test_external.mw"&gt;test_external.mw&lt;/a&gt;&lt;/p&gt;</itunes:summary>
      <description>&lt;p&gt;I did as you suggested but nevertheless MainFDerivative... should be function calls. But as expressions they refused to calculate numerically from external program. I mean, evalhf doesn't work in sheet itself while evalf works in sheet but EvalMapleProc in c library doesn't work.&lt;/p&gt;
&lt;p&gt;Code of c library call you can find in last answer of: http://www.mapleprimes.com/questions/126686-External-Dll-EvalMapleStatement.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Only for evalf version one line substituted to:&lt;/p&gt;
&lt;p&gt;return (ice_real_TReal)MapleToFloat64(ExternalKernel, EvalMapleProc(ExternalKernel, f, 3, args));&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Now i really want to know in which version of symbolic expressions calculation will work that code. At least in&amp;nbsp; my version of code and EvalhfMapleProc call it works. Preferably want it to work with EvalhfMapleProc i.e. evalhf from sheet.&lt;/p&gt;
&lt;p&gt;Test file is in attach.&lt;/p&gt;
&lt;p&gt;&lt;a href="/view.aspx?sf=127497/424602/test_external.mw"&gt;test_external.mw&lt;/a&gt;&lt;/p&gt;</description>
      <guid>127497</guid>
      <pubDate>Tue, 08 Nov 2011 01:20:59 Z</pubDate>
      <itunes:author>icegood</itunes:author>
      <author>icegood</author>
    </item>
    <item>
      <title>please compare</title>
      <link>http://www.mapleprimes.com/questions/127445-Please-Help-Me-Optimize-Code?ref=Feed:MaplePrimes:Please help me optimize code:Comments#comment127510</link>
      <itunes:summary>&lt;p&gt;As an illustration of my points, here is a comparison of two ways to get a 4th derivative as a procedure or operator.&lt;/p&gt;
&lt;p&gt;The first way, obtaining operator `Fxxxx`, is quite similar to what you do in your worksheet. The alternative way involves just using the `diff` command, with `unapply` used on the result just once.&lt;/p&gt;
&lt;p&gt;The alternative way, obtaining operator `otherFxxxx`, takes about 1000 times less time to produce the derivative operator, and evaluates that numerically at a point about 100 times faster than does the original way's `Fxxxx` operator.&lt;/p&gt;
&lt;pre&gt;restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

F:=unapply(expr,x):

Fx:=CodeTools:-Usage( unapply(evalf(simplify(diff(F(x),x))),x) ):
memory used=13.92MiB, alloc change=11.37MiB, cpu time=249.00ms, real time=244.00ms

Fxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fx(x),x))),x) ):
memory used=62.31MiB, alloc change=29.74MiB, cpu time=780.00ms, real time=771.00ms

Fxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxx(x),x))),x) ):
memory used=0.75GiB, alloc change=47.87MiB, cpu time=11.08s, real time=11.09s

Fxxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxxx(x),x))),x) ):
memory used=7.03GiB, alloc change=363.68MiB, cpu time=4.75m, real time=4.76m

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=328.11KiB, alloc change=0 bytes, cpu time=0ns, real time=4.00ms

CodeTools:-Usage( Fxxxx(2.3) );
memory used=89.73MiB, alloc change=0 bytes, cpu time=1.37s, real time=1.38s

                         -0.8163268164

CodeTools:-Usage( otherFxxxx(2.3) );
memory used=1.55MiB, alloc change=0 bytes, cpu time=16.00ms, real time=19.00ms

                         -0.8163268116
&lt;/pre&gt;
&lt;p&gt;The alternative way is so very fast that it could also be used to produce separate operators for each of the 1st, 2nd, 3rd, and 4th derivatives, assign each of those to operators as well. But each subsequent derivative would be produced using `diff` applied to the previous expression rather that function applications, and there would be no dubious `simplify` and `evalf` combined actions going on. Keeping each of the four derivatives, and producing four operators, should only be four times slower than the alternative shown above, not one thousand times slower.&lt;/p&gt;
&lt;p&gt;You can mess around with option `numeric` on all your original `unapply` calls. But I believe that the approach is still fundamentally misguided.&lt;/p&gt;
&lt;p&gt;Especially unfortunate is using `simplify` on a symbolic expression which contains floating-point coefficients, as this often tends to get the opposite effect and produce a much longer expression rather than a simpler one. But for your example, with all those LerchPhi calls, it might even be just `simplify` alone which is the biggest problem.&lt;/p&gt;
&lt;p&gt;Here is generation of distinct operators for all the derivatives from 1st to 4th, but without the evalf@simplify,&lt;/p&gt;
&lt;pre&gt;restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=386.71KiB, alloc change=255.95KiB, cpu time=0ns, real time=8.00ms

st:=time():
F:=unapply(expr,x):
Fx_expr:=diff(F(x),x):
Fx:=unapply(Fx_expr,x): # don't create, if not to be used
Fxx_expr:=diff(Fx(x),x):
Fxx:=unapply(Fxx_expr,x): # don't create, if not to be used
Fxxx_expr:=diff(Fxx(x),x):
Fxxx:=unapply(Fxxx_expr,x): # don't create, if not to be used
Fxxxx_expr:=diff(Fxxx(x),x):
time()-st;
                             0.015

Fxxxx:=CodeTools:-Usage( unapply(Fxxxx_expr,x) ):
memory used=512 bytes, alloc change=0 bytes, cpu time=16.00ms, real time=3.00ms

CodeTools:-Usage( otherFxxxx(2.9) );
memory used=1.57MiB, alloc change=1.25MiB, cpu time=21.00ms, real time=22.00ms

                          -3.567059374

CodeTools:-Usage( Fxxxx(2.9) );
memory used=1.52MiB, alloc change=1.25MiB, cpu time=16.00ms, real time=17.00ms

                          -3.567059374
&lt;/pre&gt;
&lt;!--break--&gt;
&lt;p&gt;acer&lt;/p&gt;</itunes:summary>
      <description>&lt;p&gt;As an illustration of my points, here is a comparison of two ways to get a 4th derivative as a procedure or operator.&lt;/p&gt;
&lt;p&gt;The first way, obtaining operator `Fxxxx`, is quite similar to what you do in your worksheet. The alternative way involves just using the `diff` command, with `unapply` used on the result just once.&lt;/p&gt;
&lt;p&gt;The alternative way, obtaining operator `otherFxxxx`, takes about 1000 times less time to produce the derivative operator, and evaluates that numerically at a point about 100 times faster than does the original way's `Fxxxx` operator.&lt;/p&gt;
&lt;pre&gt;restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

F:=unapply(expr,x):

Fx:=CodeTools:-Usage( unapply(evalf(simplify(diff(F(x),x))),x) ):
memory used=13.92MiB, alloc change=11.37MiB, cpu time=249.00ms, real time=244.00ms

Fxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fx(x),x))),x) ):
memory used=62.31MiB, alloc change=29.74MiB, cpu time=780.00ms, real time=771.00ms

Fxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxx(x),x))),x) ):
memory used=0.75GiB, alloc change=47.87MiB, cpu time=11.08s, real time=11.09s

Fxxxx:=CodeTools:-Usage( unapply(evalf(simplify(diff(Fxxx(x),x))),x) ):
memory used=7.03GiB, alloc change=363.68MiB, cpu time=4.75m, real time=4.76m

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=328.11KiB, alloc change=0 bytes, cpu time=0ns, real time=4.00ms

CodeTools:-Usage( Fxxxx(2.3) );
memory used=89.73MiB, alloc change=0 bytes, cpu time=1.37s, real time=1.38s

                         -0.8163268164

CodeTools:-Usage( otherFxxxx(2.3) );
memory used=1.55MiB, alloc change=0 bytes, cpu time=16.00ms, real time=19.00ms

                         -0.8163268116
&lt;/pre&gt;
&lt;p&gt;The alternative way is so very fast that it could also be used to produce separate operators for each of the 1st, 2nd, 3rd, and 4th derivatives, assign each of those to operators as well. But each subsequent derivative would be produced using `diff` applied to the previous expression rather that function applications, and there would be no dubious `simplify` and `evalf` combined actions going on. Keeping each of the four derivatives, and producing four operators, should only be four times slower than the alternative shown above, not one thousand times slower.&lt;/p&gt;
&lt;p&gt;You can mess around with option `numeric` on all your original `unapply` calls. But I believe that the approach is still fundamentally misguided.&lt;/p&gt;
&lt;p&gt;Especially unfortunate is using `simplify` on a symbolic expression which contains floating-point coefficients, as this often tends to get the opposite effect and produce a much longer expression rather than a simpler one. But for your example, with all those LerchPhi calls, it might even be just `simplify` alone which is the biggest problem.&lt;/p&gt;
&lt;p&gt;Here is generation of distinct operators for all the derivatives from 1st to 4th, but without the evalf@simplify,&lt;/p&gt;
&lt;pre&gt;restart:

expr:=1/7*sin(5/7*x+exp(3/7*x))/exp(2/7*(1/7*sin(5/7*(1/11*sin(5/11*x
      +exp(3/11*x))/exp(2/11*((1/11*sin(5/11*x+exp(3/11*x))/exp(2/11*x)))
      +1/7*ln(3/7*x)))))+1/7*ln(3/7*x)):

otherFxxxx:=CodeTools:-Usage( unapply((diff(expr,x,x,x,x)),x) ):
memory used=386.71KiB, alloc change=255.95KiB, cpu time=0ns, real time=8.00ms

st:=time():
F:=unapply(expr,x):
Fx_expr:=diff(F(x),x):
Fx:=unapply(Fx_expr,x): # don't create, if not to be used
Fxx_expr:=diff(Fx(x),x):
Fxx:=unapply(Fxx_expr,x): # don't create, if not to be used
Fxxx_expr:=diff(Fxx(x),x):
Fxxx:=unapply(Fxxx_expr,x): # don't create, if not to be used
Fxxxx_expr:=diff(Fxxx(x),x):
time()-st;
                             0.015

Fxxxx:=CodeTools:-Usage( unapply(Fxxxx_expr,x) ):
memory used=512 bytes, alloc change=0 bytes, cpu time=16.00ms, real time=3.00ms

CodeTools:-Usage( otherFxxxx(2.9) );
memory used=1.57MiB, alloc change=1.25MiB, cpu time=21.00ms, real time=22.00ms

                          -3.567059374

CodeTools:-Usage( Fxxxx(2.9) );
memory used=1.52MiB, alloc change=1.25MiB, cpu time=16.00ms, real time=17.00ms

                          -3.567059374
&lt;/pre&gt;
&lt;!--break--&gt;
&lt;p&gt;acer&lt;/p&gt;</description>
      <guid>127510</guid>
      <pubDate>Tue, 08 Nov 2011 09:08:58 Z</pubDate>
      <itunes:author>acer</itunes:author>
      <author>acer</author>
    </item>
  </channel>
</rss>