http://www.mapleprimes.com/posts/95113-Optimization-Workaround-For-Operator-Form en-us 2026 Maplesoft, A Division of Waterloo Maple Inc. Maplesoft Document System Wed, 10 Jun 2026 23:52:54 GMT Wed, 10 Jun 2026 23:52:54 GMT The latest comments added to the Post, Optimization workaround for Operator Form http://www.mapleprimes.com/images/mapleprimeswhite.jpg http://www.mapleprimes.com/posts/95113-Optimization-Workaround-For-Operator-Form http://www.mapleprimes.com/posts/95113-Optimization-Workaround-For-Operator-Form?ref=Feed:MaplePrimes:Optimization workaround for Operator Form:Comments#comment95126 <p>Thanks for posting the workaround, acer. Yes, there seems to be a bug in NLPSolve in this particular situation (operator form, with failure of codegen automatic differentiation routines). Providing your own gradient routine is a good workaround.</p> <p>Paulina</p> The latest comments added to the Post, Optimization workaround for Operator Form 95126 Thu, 15 Jul 2010 14:32:41 Z pchin pchin http://www.mapleprimes.com/posts/95113-Optimization-Workaround-For-Operator-Form?ref=Feed:MaplePrimes:Optimization workaround for Operator Form:Comments#comment126007 <p>Things like this below are worrisome, indicating that codegen[GRADIENT] may be problematic for some innocuous-looking objective procedures.</p> <pre>&gt; restart: &gt; f := proc(x) &gt; x^2; &gt; end proc: &gt; codegen[GRADIENT](f); # ok proc(x) return 2*x end proc; &gt; evalhf( %(4.5) ); 9. &gt; restart: &gt; f := proc(x) &gt; print(f); &gt; x^2; &gt; end proc: &gt; codegen[GRADIENT](f); # ok proc(x) print(f); return 2*x; end proc; &gt; evalhf( %(4.5) ); 4.50000000000000000 9. &gt; restart: &gt; f := proc(x) &gt; []; # just another no-op, you'd imagine &gt; x^2; &gt; end proc: &gt; codegen[GRADIENT](f); # jeepers proc(x) return end proc; &gt; evalhf( %(4.5) ); Float(undefined) </pre> <p>The last example was an objective that itself was non-evalhfable. But the following example is more troublesome, and produces a wrong numeric result for the gradient.</p> <pre>&gt; restart: &gt; f := proc(x) &gt; 5.7; # not an assignment, but also not a return value! &gt; x^2; &gt; end proc: &gt; codegen[GRADIENT](f); proc(x) return 0 end proc &gt; %(4.5); 0 </pre> <p>All this means that `<a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=fdiff">fdiff</a>` may be sometimes be more attractive as a means to get a useful gradient (even if numerical diferentiation is "frowned upon" on stability grounds).</p> <p>The procedure in the top-post could be changed to automatically handle an (indeterminate) variable number of arguments (to the original objective). It could also be altered to supply optional arguments to `<a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=fdiff">fdiff</a>`, such as the 'workprec'=n argument which controls the working precision that `fdiff sets for itself internally. This would help in the case that one wanted `fdiff` to not raise Digits too high (internally, temporarily) when calling the objective procedure for its computation of finite differences. <!--break--></p> <p>acer</p> The latest comments added to the Post, Optimization workaround for Operator Form 126007 Tue, 27 Sep 2011 21:49:59 Z acer acer