From: Miller, J. V \(Research\) <mil...@cr...> - 2005-10-18 17:09:28
|
A callback solution should work for the use case at hand. If the = optimizers would stick the head up from the sand periodically, say once per = iteration=20 or once per k iterations, they could call a user supplied callback. The user supplied callback can then peek into the event queue and determine whether the UI element to stop the optimization has been selected. If selected, the callback sets an abort flag that the optimizer checks when = it returns from the callback. We have used this methodology in VTK and ITK for 10 years. No threading needed. No exceptions handling needed (exceptions should really be = reserved for truly exceptional events and not for state management). The difficulty is doing this is that many of the netlib routines never stick there up from the sand. So there is no opportunity to call the user supplied callback. A general event mechanism would not only have to be used through vnl but also down into netlib. Jim -----Original Message----- From: vxl...@li... [mailto:vxl...@li...]On Behalf Of Amitha Perera Sent: Tuesday, October 18, 2005 12:52 PM To: Ian Scott Cc: Karthik Krishnan; vxl...@li... Subject: Re: [Vxl-users] VNL Optimizers responding to events I think the issue is more complex than that. What Karthik suggests requires multiple threads in vnl. For the optimizer to stop its iterations, it needs to be told to do so *from its thread*. This could be by toggling a variable that that is monitored at the beginning of each iteration, or by calling a function that will return "continue" or "stop". Somewhere in this will be a variable that will be read from the optimizer thread but will be written to from the GUI thread. This requires mutexes to do it right. Not using mutexes in this case would probably work most of the time, but I think if we are going to add something like this, it should be done correctly. I guess a solution could be to use an indicator function---a function with signature "bool stopnow()"---which is passed in as a parameter to the optimizer. The thread-safety issues would then by the user's responsibility, because he'll have to implement this function. Of course, as Ian wrote, this would only really work when the vnl routine is more than a simple wrapper around netlib. Ian also suggested exceptions. In this case the function could throw an exception instead of returning a bool. However, I think a lot of vnl (and vxl) is unfortunately not exception-safe. Using exceptions is quite likely to leak memory, etc. Also keep in mind that many routines in netlib (and therefore in vnl) are not threadsafe. All in all, I think it's doable, but would require some effort and thinking through some of the issues raised when mixing exceptions and threads with code not written with either in mind. Amitha. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, = discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Vxl-users mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-users |
From: Andrew F. <aw...@mi...> - 2005-10-18 17:54:42
|
Agree with Jim. A "should I stop now?" callback is fine. I thought there was one in lmdif, and can't check now, but take a look at the return value of the function-evaluation callback and see if it examines that. |
From: Karthik K. <Kar...@ki...> - 2005-10-31 13:51:23
Attachments:
vnl_amoeba.cxx
vnl_amoeba.h
|
For a start, here are the patches to support C style callbacks for the amoeba optimizer, so the stop can be set via the callback and it seems to work for my application. It would be nice if they could be committed, (its easier staying on CVS rather than having modified files). [In the end I wonder if the callbacks should instead be added to vnl_cost_function cause every optimizer seems to optimize a vnl_cost_function anyway.] http://www.cs.rpi.edu/research/groups/vxl/Testing/Sites/sabbath/Linux-c++/20051031-0542-Experimental/Test.html Thanks Karthik Andrew Fitzgibbon wrote: >Agree with Jim. A "should I stop now?" callback is fine. I thought >there was one in lmdif, and can't check now, but take a look at the >return value of the function-evaluation callback and see if it examines >that. > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Power Architecture Resource Center: Free content, downloads, discussions, >and more. http://solutions.newsforge.com/ibmarch.tmpl >_______________________________________________ >Vxl-users mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-users > > > |
From: Ian S. <ian...@st...> - 2005-10-18 17:48:52
|
It turns out that exceptions are passed through the netlib code (on MSVC7.1 anyway) See my recent modification to core/vnl/algo/tests/test_levenberg_marquardt.cxx for a demonstration. As for exceptions being inappropriate for state control, whilst I agree in general, I do think that it depends on the context. Using exceptions all the way up to the GUI may be inappropriate, because it isn't exceptional behaviour for the GUI. However for the optimiser, it is exceptional behaviour. Most people don't need such abort behaviour, so it would be inappropriate to complicate the code (even further) to handle it. There should be no significant overheads to using exceptions on modern compilers - or at least not compared to handling the alternative callback-abort situation properly. As for making the code exception-safe, running valgrind over the test I just committed, should find all the relevant leaks in vnl_levenberg_marquardt. I'll admit to being biased in favour of exceptions, because I would like to see some attention paid to the exception safety of the code. However, I do think they are the simplest solution described so far. (Total coding time for the above test - 4 minutes) Ian. Miller, James V (Research) wrote: > A callback solution should work for the use case at hand. If the optimizers > would stick the head up from the sand periodically, say once per iteration > or once per k iterations, they could call a user supplied callback. The > user supplied callback can then peek into the event queue and determine > whether the UI element to stop the optimization has been selected. If > selected, the callback sets an abort flag that the optimizer checks when > it returns from the callback. > > We have used this methodology in VTK and ITK for 10 years. No threading > needed. No exceptions handling needed (exceptions should really be reserved > for truly exceptional events and not for state management). > > The difficulty is doing this is that many of the netlib routines never > stick there up from the sand. So there is no opportunity to call the > user supplied callback. A general event mechanism would not only have to > be used through vnl but also down into netlib. > > Jim > > > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...]On Behalf Of Amitha Perera > Sent: Tuesday, October 18, 2005 12:52 PM > To: Ian Scott > Cc: Karthik Krishnan; vxl...@li... > Subject: Re: [Vxl-users] VNL Optimizers responding to events > > > I think the issue is more complex than that. What Karthik suggests > requires multiple threads in vnl. For the optimizer to stop its > iterations, it needs to be told to do so *from its thread*. This > could be by toggling a variable that that is monitored at the > beginning of each iteration, or by calling a function that will > return "continue" or "stop". Somewhere in this will be a variable > that will be read from the optimizer thread but will be written to > from the GUI thread. This requires mutexes to do it right. > > Not using mutexes in this case would probably work most of the time, > but I think if we are going to add something like this, it should be > done correctly. > > I guess a solution could be to use an indicator function---a function > with signature "bool stopnow()"---which is passed in as a parameter > to the optimizer. The thread-safety issues would then by the user's > responsibility, because he'll have to implement this function. Of > course, as Ian wrote, this would only really work when the vnl > routine is more than a simple wrapper around netlib. > > Ian also suggested exceptions. In this case the function could throw > an exception instead of returning a bool. However, I think a lot of > vnl (and vxl) is unfortunately not exception-safe. Using exceptions is > quite likely to leak memory, etc. > > Also keep in mind that many routines in netlib (and therefore in vnl) > are not threadsafe. > > All in all, I think it's doable, but would require some effort and > thinking through some of the issues raised when mixing exceptions and > threads with code not written with either in mind. > > Amitha. |
From: Peter V. <pet...@ya...> - 2005-10-19 08:55:48
|
> The difficulty is doing this is that many of the netlib routines > never stick there up from the sand. A possible solution to this (or at least, a possible "first step") would be to provide two different implementations in vnl/algo of each algorithm: the one which is there now, which just calls the netlib routine in one go, and one which has the iteration in it at the C++ level, and calls the netlib routine within the loop. The latter will of course be slower, so the user is responsible for choosing either the fast but non-interruptable version or the slower one with the "interrupt" or "stop" callbacks. -- Peter. |