Services & ResourcesWolfram ForumsMathGroup Archive

[Date Index] [Thread Index] [Author Index]

Re: NMinimize problem: fct minimized uses FindRoot

• To: mathgroup at smc.vnet.net
• Subject: [mg123753] Re: NMinimize problem: fct minimized uses FindRoot
• From: Oliver Ruebenkoenig <ruebenko at wolfram.com>
• Date: Sat, 17 Dec 2011 02:47:13 -0500 (EST)
• Delivered-to: l-mathgroup@mail-archive0.wolfram.com
• References: <201112161047.FAA06783@smc.vnet.net> <alpine.LRH.2.00.1112160525020.26730@wopr.wolfram.com>

On Fri, 16 Dec 2011, Oliver Ruebenkoenig wrote:

>
>
> On Fri, 16 Dec 2011, Oleksandr Rasputinov wrote:
>
>> On Thu, 15 Dec 2011 10:06:01 -0000, Oliver Ruebenkoenig
>> <ruebenko at wolfram.com> wrote:
>> 
>>> 
>>> Just for comepletness sake:
>>> 
>>> this does work
>>> 
>>> cf = Compile[{{n, _Integer}},
>>>    Module[{res = 0}, Do[res += i; If[res > 10, Throw[0, cfe]], {i, n}];
>>>      res]]
>>> 
>>> Catch[cf[111], cfe]
>>> 
>>> 
>>> Related:
>>> http://stackoverflow.com/questions/8184548/do-return-behave-differently-in-compile-why/8194565#8194565
>>> 
>>> Oliver
>>> 
>> 
>> Well, sort of. 
>> cf // InputForm
>> 
>> reveals the MainEvaluate call (opcode 46):
>
> That does not matter - this is evaluated only once; and you want to go back 
> to the evaluator anyways.
>
> Calls to MainEvaluate in compiled code are evil if they appear in a loop.
>
> Needs["CompiledFunctionTools`"]
> CompilePrint[cf]


Ah, and I forgot you can avoid that (insignificant) MainEval call with

cf2 = Compile[{{n, _Integer}},
   Module[{res = 0},
    Do[res += i; If[res > 10, Internal`CompileError[]], {i, n}];
    res],
   "RuntimeOptions" -> {"WarningMessages" -> False,
     "RuntimeErrorHandler" -> Function[Throw[$Failed, cfe]]}
   ]


Oliver

>
>
>> 
>> CompiledFunction[{8, 8., 5468}, {_Integer}, {{2, 0, 0}, {2, 0, 2}}, {{0,
>> {2, 0, 1}}, {10, {2, 0, 5}}}, {1, 7, 0, 0, 0},
>> {{6, 1, 2}, {6, 0, 3}, {6, 1, 4}, {3, 7}, {12, 2, 4, 6}, {6, 6, 2}, {25,
>> 5, 2, 0}, {2, 0, 3},
>> {46, Function[{n}, Throw[0, cfe]], {i, 2, 0, 4, Block}, 2, 0, 0, 6, 0,
>> 17}, {3, 1}, {4, 4, 3, -6}, {1}},
>> Function[{n}, Module[{res = 0}, Do[res += i; If[res > 10, Throw[0, cfe]],
>> {i, n}]; res]], Evaluate]
>> 
>> so the advantage of the two-argument Throw in this case appears limited
>> versus, say,
>> 
>> cf = Compile[{{n, _Integer}},
>>  Catch@Module[{res = 0},
>>   Do[res += i; If[res > 10, Throw[0]], {i, n}];
>>   res
>>  ]
>> ]
>> 
>> which does the same thing without requiring any MainEvaluate calls.
>
> But is less flexible concerning that possibilities where to Catch.
>
>> 
>> Also:
>> 
>> cf2 = Compile[{{n, _Integer}},
>>   Catch[
>>    Module[{res = 0},
>>     Do[res += i; If[res > 10, Throw[0, cfe]], {i, n}];
>>     res
>>    ], cfe
>>   ]
>>  ]
>> 
>> Catch::argx: Catch called with 2 arguments; 1 argument is expected.
>> 
>> cf2 // InputForm
>
> Yes, this seems to me much more of an issue.
>
> I'd cautiously say, that this might be improvable. But I am not sure. I think 
> the issue is that the second arg is a expr, which the compiler does not know 
> how to deal with. But perhaps if a "string" type were added then something 
> like this might work
>
> cf2 = Compile[{{n, _Integer}},
>   Catch[
>    Module[{res = 0},
>     Do[res += i; If[res > 10, Throw[0, "cfe"]], {i, n}];
>     res
>    ], "cfe"
>   ]
>  ]
>
> But this is speculation.
>
>
>> 
>> CompiledFunction[{8, 8., 5468}, {_Integer}, {{2, 0, 0}, {3, 0, 0}}, {},
>> {0, 1, 1, 0, 0},
>> {{46, Function[{n}, Catch[Module[{res = 0}, Do[res += i; If[res > 10,
>> Throw[0, cfe]], {i, n}]; res], cfe]], 2, 0, 0, 3, 0, 0}, {1}},
>> Function[{n}, Catch[Module[{res = 0}, Do[res += i; If[res > 10, Throw[0,
>> cfe]], {i, n}]; res], cfe]], Evaluate]
>> 
>> which is not compiled at all. So neither Throw/Catch nor Return can accept
>> two arguments when used in compiled code proper (i.e. not wrapped in
>> MainEvaluate). The advantage of the latter, of course, is that the
>
> But this is only a problem if you want to Catch inside compile. So I think 
> the way to go is to re-write slow parts of code with compile and then the 
> control structure in top level. Perhaps some else has another idea?
>
>> location it returns to is indicated by context without requiring a second
>> argument to describe it, which is just as well since the locations Return
>> will or will not return to appear to be somewhat arbitrary choices as you
>> point out in your StackOverflow posting. I suppose one can use Label/Goto
>> to replicate the behaviour of two-argument forms in compiled code if
>> absolutely necessary, although this seems fairly anachronistic.
>
> Yes, that might be possible - but hm... ;-)
>

• References:
  • Re: NMinimize problem: fct minimized uses FindRoot
    • From: "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com>