dsa Forum Rss Feed

New Post: How should a new node with the same value be inserted?

antonyd — Mon, 26 Nov 2012 00:55:41 GMT

Say a tree has an existing node with value 1. If another node of same value is to be added , which side should it go?

Your document states to go RIGHT : " where the left subtree of x contains nodes with values < x and the right subtree contains nodes whose values are >= x ."

Whereas an article from Stanford states to go LEFT : "all elements in its left subtree are less-or-equal to the node (<=), and all the elements in its right subtree are greater than the node (>)."

Provided code sample ignores duplicates. I am not sure which side to take?

New Post: Why does ICommonBinaryTreeNode have a TNode generic parameter?

antonyd — Sun, 25 Nov 2012 18:15:36 GMT

Also, CommonBinaryTree<TNode,TValue> restricts the use of TNode to a ICommonBinaryTreeNode, i.e the node should ONLY have LEFT and RIGHT children. This also means that I cannot implement any generic node say TOP,BOTTOM and hence I am still wondering the rationale behind TNode in ICommonBinaryTreeNode<TNode,TValue>. Hope I am making some sense , please correct my understanding.

New Post: Why does ICommonBinaryTreeNode have a TNode generic parameter?

antonyd — Sun, 25 Nov 2012 17:12:42 GMT

A relatively easier implementation of this interface could be

public interface ICommonBinaryTreeNode<T>
    {
        ICommonBinaryTreeNode<T> Left { get; set; }

        ICommonBinaryTreeNode<T> Right { get; set; }

        TValue Value { get; set; }
    }

But, I understand the intention of the authors that the Left & Right children could a node of any other type. Can you cite an tree example that could take advantage of the generic parameter <Tnode> ?

New Post: Error loading Dsa.test.csproj project in monodevelop.

antonyd — Sun, 25 Nov 2012 00:14:26 GMT

If you are trying to see the code using monodevelop, then you could most likely run into an error when loading Dsa.test.csproj. This is because of a projectguid reference to mstest (though all projects are Nunit based). To overcome this problem , remove this line from Dsa.Test.csproj

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4....

Just thought someone might benefit

New Post: Boundary conditions

justINcoder — Thu, 21 Oct 2010 15:06:12 GMT

Hi moderators

I was going through your code project. I started with Algorithms/Numbers.cs. Some of the boundary cases have not been checked. Please go through the list and consider applying them.

I am enlisting a few here. More to come.

1. Fibonacci, GCD, Tobinary, ToOctal methods have to check for integer overflow if given the max value of integer.

2. ToBinary, ToOctal methods need to check what will happen if the number is zero (0).

Thanks

New Post: The base class is missing.

lukadt — Thu, 11 Sep 2008 12:51:00 GMT

Sorry for the inconvenience, it has been fixed...

New Post: The base class is missing.

yuren1978 — Sat, 30 Aug 2008 13:20:40 GMT

I downloaded the latest code, and it complains that the base class is missing.

New Post: It is already in .net?

gbarnett — Sun, 27 Jul 2008 20:58:48 GMT

Quicksort is used in Array.Sort but our quicksort can be used on anything that implements IList<T>.

As for doubly linked list, I think it does use a different implementation - it is there probably because it was one of the first data structures in there. I did some perf testing a while back and our doubly linked list was faster than LinkedList<T>.

For now it will stay, unless we find a reason to get rid of it.

New Post: It is already in .net?

genbox — Sun, 27 Jul 2008 19:16:13 GMT

According to the front page: "Data Structures and Algorithms (DSA) features implementations of data structures and algorithms that are not implemented in any version of .NET."

But DoublyLinkedList is already implemented in .net? Or is it because it has a different implementation that would cause one to use DoublyLinkedList instead of LinkedList<T>?

Also, the Quick sort algorithm is also already implemented in .net in the form of Array.Sort(). It uses a unstable quick sort if I remember correctly.

New Post: A question about Fibonacci's numbers generator

lukadt — Mon, 23 Jun 2008 14:27:37 GMT

Hi Gianluca, i'm glad you are giving us interesting feedback and focus on Fibonacci complexity. Binet's formula it's very surprising and interesting at the same time but in real world there are some built-in limits for the number of decimal places one can accurately compute (floating point limited precision). Sometimes these inaccuracies will make numbers round to the wrong values and carry to inappropriate result. The approach we adopted improves the classical algorithm definition using the memory during the computation in such a way that the values of two consecutive terms of the Fibonacci sequence are always stored in the memory thus avoiding unnecessary computing...
Hear you soon, Luca

New Post: A question about Fibonacci's numbers generator

GianlucaGhettini — Sun, 22 Jun 2008 13:19:28 GMT

I looked at the Fibonacci's generator and I would ask a question about it: why did you choose to implement the generator using the iterative formula instead of the closed form version? With the iterative formula f(n)=f(n-1)+f(n-2) one has to do 'n' passes to get the n-th fibonacci's number and in this case the complexity is obviously O(n). However, the iterative formula can be "rolled up" and rewritten in closed form (the so called Binet's formula), so it is required only the 'n' to get the n-th number and the complexity drops to O(1) (a constant time!).

Here is the Binet's closed formula of the Fibonacci's series:
f(n) = floor((1/2)+((g^n)/sqrt(5))); where 'g' is the golden ratio equal to g=(1+sqrt(5))/2;

Bye!
Gianluca

New Post: Stability of sorting algorithms...

gbarnett — Sun, 22 Jun 2008 11:29:37 GMT

GianlucaGhettini wrote:
Yes, IComparable interface allows deeper control over sorting. In fact I use to reimplement this interface to get the right behavior from my sorting algorithm (i.e. sorting again over equal key objects to break the tie). However, I think that the stability is a very basic property of a sorting algorithm and it should not be left to reimplement over and over again.

Gianluca

There is a fine line between giving the programmer more control, and providing generalised solutions - all I can say is that we will look at it.

Thanks for your feedback!

Granville

New Post: Stability of sorting algorithms...

GianlucaGhettini — Sun, 22 Jun 2008 08:52:55 GMT

Yes, IComparable interface allows deeper control over sorting. In fact I use to reimplement this interface to get the right behavior from my sorting algorithm (i.e. sorting again over equal key objects to break the tie). However, I think that the stability is a very basic property of a sorting algorithm and it should not be left to reimplement over and over again.

Gianluca

New Post: Stability of sorting algorithms...

gbarnett — Sat, 21 Jun 2008 16:29:53 GMT

Hi Gianluca,

For now what I will say is that we will look into it BUT you can actually take a more atomic approach over sorting by implementing the IComparable interface on the complex types, this is what DSA sorting algorithms use to verify who is larger than who, less than etc.

Thanks for the comment and I will add it to our unofficial to-look-at list.

Thanks,

Granville

New Post: Stability of sorting algorithms...

GianlucaGhettini — Fri, 20 Jun 2008 13:55:51 GMT

Hi, good job!!!
I'm a Luca's friend and I'm currently programming in .NET (sometimes with Luca, at university).

.NET is a very powerful and interesting framework, but IHMO I think it
lacks control over sorting algorithms. What I'm trying to point out is
about stability of a sorting algorithm.
A sorting algorithm is stable if maintains the relative order of records
with equal keys (i.e., values). That is, a sorting algorithm is stable
if whenever there are two records R and S with the same key and with R
appearing before S in the original list, R will appear before S in the
sorted list.
This property isn't critical when you are dealing with base types like
integers or strings, but can be very useful when you are sorting more
complex objects. I mean, suppose you have a simple array of integers,
like this:
[6 5 2 5 1 7 1]
sorting it is straigthforward, we always obtain:
[1 1 2 5 5 6 7]
The first two integers of the sorted array are 1 1. Reversing the order
of this two integers doesn't change the array. So, for example, when you
are sorting a random array that contains two 1's, the 1 1 sequence
appearing in the sorted array will always be the same, no matter if the
algorithm you are using is stable or not.
Now think you have an array of animals, and that you are sorting by
number of legs. Now stability makes the difference:
To figure out why, suppose you have this two arrays:

[cow, snake, dog, cat, chicken, ant]

and:

[dog, ant, chicken, cow, cat]

with an unstable algorithm you can obtain:

[snake, chicken, cow, dog, cat, ant]

and:

[chicken, dog, cow, cat, ant]

with a stable algorithm:

[snake, chicken, cow, dog, cat, ant]

and:

[chicken, cow, dog, cat, ant]

As you can see, the stable version of the algorithm always preserves the
order of the sequence [cow, dog, cat] (although this order is arbitrary)
in every array containings these animals, while the other MAY not.
.NET doesn't allow the programmer to know if the sorting algorithm
he/she's using is stable or not (some algorithms can be either stable or
unstable).
I'd like to deal with a stability-aware DSA framework!!! :)

NEW POST: Comments about Set implementation

gbarnett — Fri, 22 Feb 2008 12:07:50 GMT

I'll look into it

Thanks,

Granville

mstrobel wrote:
Hi there,

I have some observations about the Set<T> class. First, a Set<T> wraps some other CollectionBase<T>, which it takes as a constructor parameter. Since there is no guarantee that the wrapped collection is a set of unique entities (it may be populated with several duplicates), then there is no guarantee that any Set<T> is actually a unique set. However, since Set<T> already implements CollectionBase<T>, I don't see why it's necessary to wrap another collection at all. Since all of the collection manipulation methods (Add, Remove, etc.) operate directly on the wrapped set, then why not simply have Set<T> extend a fully-functional collection type (e.g. a BinarySearchTree<T> with an IComparer<T> implementation that compares hashcodes) and override the Add method to include a uniqueness check?

Cheers,
Mike

NEW POST: Comments about Set implementation

mstrobel — Fri, 22 Feb 2008 02:10:41 GMT

Hi there,

I have some observations about the Set<T> class. First, a Set<T> wraps some other CollectionBase<T>, which it takes as a constructor parameter. Since there is no guarantee that the wrapped collection is a set of unique entities (it may be populated with several duplicates), then there is no guarantee that any Set<T> is actually a unique set. However, since Set<T> already implements CollectionBase<T>, I don't see why it's necessary to wrap another collection at all. Since all of the collection manipulation methods (Add, Remove, etc.) operate directly on the wrapped set, then why not simply have Set<T> extend a fully-functional collection type (e.g. a BinarySearchTree<T> with an IComparer<T> implementation that compares hashcodes) and override the Add method to include a uniqueness check?

Cheers,
Mike

NEW POST: Extension methods or static methods?

gbarnett — Thu, 21 Feb 2008 19:47:12 GMT

True. I'll admit I didn't actually try the normal route until a week or so after starting this thread - but I would encourage the ext method way as it increases the synergy between the BCL and DSA.

Thanks Mike!

mstrobel wrote:
Hi Granville,

I fully embrace extension methods. Not only do they allow for the same invocation style as instance methods, but they can also be called in the same way as regular static methods, like so:

public static class Algorithms
{
public static IList<T> BubbleSort<T>(this IList<T> source) { ... }
}

var myList = new List<T> { 5, 2, 7, 1, 8 };
var sortedList1 = myList.BubbleSort();
var sortedList2 = Algorithms.BubbleSort(myList);

Since you get the best of both worlds, it makes little sense not to use extension methods :).

Cheers,
Mike

NEW POST: Efficiency of Heap.Remove

gbarnett — Thu, 21 Feb 2008 19:45:38 GMT

Good catch. I actually added all that stuff the other day off the top of my head so bare with me on that as its sort of a skim at the moment.

Thanks for the catch.

p.s. if you find any others that are inaccurate please let me know, like I said it was skim through the source but I think the addition of this is pretty decent.

mstrobel wrote:
Hi there,

Great work on the library, and I like the addition of the new extension methods :).

I noticed that the documentation for the Heap.Remove method claims an asymptotic upper bound of O(log n). However, the first line of the method is a call to Array.IndexOf, which I believe is O(n), which is faster growing than O(log n). I haven't analyzed the method in detail, but removing that call should improve the efficiency of the method so that it actually is O(log n). I haven't looked at the efficiency of any other methods--this just happened to catch my eye as I was perusing the source code :).

Cheers,
Mike

NEW POST: Extension methods or static methods?

mstrobel — Thu, 21 Feb 2008 17:34:13 GMT

Hi Granville,

I fully embrace extension methods. Not only do they allow for the same invocation style as instance methods, but they can also be called in the same way as regular static methods, like so:

public static class Algorithms
{
public static IList<T> BubbleSort<T>(this IList<T> source) { ... }
}

var myList = new List<T> { 5, 2, 7, 1, 8 };
var sortedList1 = myList.BubbleSort();
var sortedList2 = Algorithms.BubbleSort(myList);

Since you get the best of both worlds, it makes little sense not to use extension methods :).

Cheers,
Mike