Wednesday, October 19, 2005

(Update 2: I've had several iterations with John on his blog post . First, I wish to thank him for his help and the time he's taken to answer my questions. It turns out I was mostly wrong. I always thought (God knows why) that the UI may be created by several threads and that there is no guarantee that a form and its child controls would all be created on the same thread. I was wrong, and there lay the root of what I thought was missing in the SafeInvokeHelper. For all the details of our discussion, I suggest you take a look at the original post and its comments.)

(Updated following John's remark: SafeInvoke and BackgroundWorker don't solve the exact same problem, although in many cases you can choose either one of them. In general, SafeInvoke is much simpler to call and can be used to run just any UI function on a control. However, if you want your code to run asynchronously and get various progress events, you'll probably want to use the BackgroundWorker instead. Another feature I'm missing in the SafeInvokeHelper is the ability to call a non-UI function through the Invoke method of a UI control. In other words, sometimes you centralize several operations on a control in a private method, and you want this method to be executed with the control's Invoke method. This scenario is not currently supported by the SafeInvokeHelper, since it requires the method passed as argument to belong to the control on which it is executed.)A few weeks ago I posted a message about SafeInvoke – an elegant solution to use the correct thread for UI methods (reminder – a control should only be accessed by the thread that created it).Well, in .NET 2.0 they introduced the BackgroundWorker object, which can be used to fix that exact problem (among others). In addition, Juval Löwy has published quite some time ago an article about the BackgroundWorker , how it works and how to work with it. In addition, he developed a similar BackgroundWorker for .NET 1.1, which will allow you to transparently migrate your code from .NET 1.1 to 2.0 (assuming you haven’t done it already…).

Sunday, October 16, 2005

Many people I tell I work on Machine Learning, give a quick nod implying "I know what it is - no need to explain". Then, while the conversation continues, it becomes completely clear that they don't have a clue what I'm talking about, but now they feel a little embarrassed to admit it. When I delve a little further, it becomes apparent that they confused Machine Learning for E-Learning...So what is Machine Learning anyway? Machine Learning is the ability of a computer (program) to learn from experience (i.e. samples or training set) and to generalize its knowledge to handle unseen data. It is an area of Artificial Intelligence, and of course overlaps heavily with statistics. Some of the most commonly known algorithms are: Neural Networks, Bayes Classifiers, Genetic Algorithms, Decision Trees and many more. Machine Learning is very much concerned with complexity of the algorithms - the idea is to come up with an algorithm that performs sufficiently well to be realistic. Therefore, and since the overall best solution is almost always exponential, every Machine Learning algorithm has an Inductive Bias. This bias implies that the algorithm makes all kinds of assumptions about the data and/or the best solution, which limit the size of the search space.And what about Data Mining? Isn't that the same thing?Well, yes and no. The difference between the two is something not everybody agrees about. The most commonly used differentiation is that Data Mining uses Machine Learning algorithms for real-world applications, usually on very large databases. The most important difference, then, is that Data Mining includes process to clean and organize the data such that it would be suitable for the learning algorithm to work with. It may seem only a small difference, but bear in mind that usually this cleaning process takes up 50% of the resources for a project (time, money, etc.).