I’ve started learning F# couple weeks ago, but unfortunately after few days I got quite busy and after these days I still know almost exactly nothing about functional programming at all. That’s why I decided I have to look for some challenges and samples I could work on while learning. That’s how I found F# and Machine Learning Dojo slideshow and Digit Recognizer competition on kaggle. I decided to give it a try. Of course, the main goal is to learn F#, not to get 100% correctness in the competition. You should have it in mind while reading the post
I just watched The Future of C# talk by Mads Torgersen recorded at NDC London conference over a month ago. Among all the stuff Mads talked about one really drawn my attention: methods/properties with multiple results. Unfortunately, instead of providing some new, crazy idea how to make it possible in C# he focused on making current usage easier. I think language designers could go much further and create real multiple results experience!
I’ve spent last two days working on my first open source .NET library named CloneExtensions. It gives you a smart way to clone your object instances without implementing any interface writing any additional
Clone method at all. It uses Expression Tree to compile that
Clone method for you right before you’re trying to use
GetClone for given type
T for the first time.
Another blog post inspired by StackOverflow question. This time it’s all about LINQ, performance and a tiny little detail, that really matters. The question itself is about
yield keyword in VB.NET, but there is another, much more interesting part I’d like to examine. The algorithm quoted in the question is the key.
The idea is simple. How to partition a collection into parts with given number of elements in ever part? Algorithm presented in the question is as easy as the questions seems to be:
This time I’ll try to examine how are all search-related methods in
List<T> implemented. Here is quite long list of all these methods:
public bool Exists(Predicate<t> match)
public T Find(Predicate</t><t> match)
public List</t><t> FindAll(Predicate</t><t> match)
public int FindIndex(Predicate</t><t> match)
public int FindIndex(int startIndex, Predicate</t><t> match)
public int FindIndex(int startIndex, int count, Predicate</t><t> match)
public T FindLast(Predicate</t><t> match)
public int FindLastIndex(Predicate</t><t> match)
public int FindLastIndex(int startIndex, Predicate</t><t> match)
public int FindLastIndex(int startIndex, int count, Predicate</t><t> match)
public int IndexOf(T item)
public int IndexOf(T item, int index)
public int IndexOf(T item, int index, int count)
public int LastIndexOf(T item)
public int LastIndexOf(T item, int index)
public int LastIndexOf(T item, int index, int count)</t>
The last part of the series was all about increasing underlying array size. This time, I’ll try to investigate something slightly different. Question is simple: Is the underlying array shrunk when you remove elements from the list? Let’s find that out!
This time on the series I’m gonna examine how
List<T> ensures the underlying array capacity. But because it’s quite interesting topic I decided to focus on adding new elements to the list only, leaving deleting/clearing for the next part.