Comparing a DataTree with another DataTree, given they are the same branch count and data size and type (string)

This is a question in regards to C# in Visual Studio.

I am taking a GH_Structure string input and storing it into a DataTree. Everything works, but I am in need to compare one DataTree to another DataTree.

With this said, to make the job easier, the type for both DataTrees are strings, and they are both equal in branch count and data count.

How do I do it?

Replies to This Discussion

Permalink Reply by David Rutten on March 3, 2014 at 9:02am

I didn't actually test this, but this would be my approach:

public enum TreeSimilarity
{
/// <summary>
/// Trees are completely different.
/// </summary>
Distinct,
/// <summary>
/// Trees have the same paths, but different list lengths.
/// </summary>
Paths,
/// <summary>
/// Trees have the same paths and lists lengths, but different items.
/// </summary>
PathsAndLists,
/// <summary>
/// Trees have the same paths and list length and also the same items.
/// </summary>
PathsAndListsAndItems
}
public static TreeSimilarity CompareTrees<T>(GH_Structure<T> tree1, GH_Structure<T> tree2, Comparison<T> comparer) where T : IGH_Goo
{
if (tree1 == null) throw new ArgumentNullException("tree1");
if (tree2 == null) throw new ArgumentNullException("tree2");

// If trees have different pathcounts, it's a trivial reject.
if (tree1.PathCount != tree2.PathCount)
return TreeSimilarity.Distinct;

// Test all the paths.
for (int p = 0; p < tree1.PathCount; p++)
{
GH_Path p1 = tree1.Paths[p];
GH_Path p2 = tree2.Paths[p];
if (p1 != p2)
return TreeSimilarity.Distinct;
}

// Test all the list lengths.
for (int p = 0; p < tree1.PathCount; p++)
{
int l1 = tree1.Branches[p].Count;
int l2 = tree2.Branches[p].Count;
if (l1 != l2)
return TreeSimilarity.Paths;
}

// If no comparer has been specified, then do not check for item similarity.
if (comparer == null)
return TreeSimilarity.PathsAndLists;

// Test all list items in all lists.
for (int p = 0; p < tree1.PathCount; p++)
{
List<T> l1 = tree1.Branches[p];
List<T> l2 = tree2.Branches[p];

for (int i = 0; i < l1.Count; i++)
{
if (l1 == null)
if (l2 == null)
continue;
else
return TreeSimilarity.PathsAndLists;
else
if (l2 == null)
return TreeSimilarity.PathsAndLists;
else
{
if (comparer(l1[i], l2[i]) != 0)
return TreeSimilarity.PathsAndLists;
}
}
}

// Everything matches up.
return TreeSimilarity.PathsAndListsAndItems;
}

You'll have to supply a delegate for comparing two GH_Strings. Nulls are already handled so you only need to test whether both GH_String instances actually have a string inside of them and, if they do, if those strings are the same.

David Rutten

david@mcneel.com

Permalink Reply by Andrew Heumann on March 5, 2014 at 9:23am

if you're working in visual studio as you describe, I presume you are building components (as opposed to simple scripts in the GH interface directly). If that's the case, you really shouldn't be using DataTrees at all - That's kind of a "lite" version intended for use in scripts. You should build your components to work with GH_Structure from the beginning. Why do you need to use both in your component?

Permalink Reply by David Rutten on March 5, 2014 at 9:58am

GH_Structure was the original datatree. It's the one used by all components and parameters. DataTree is a class that sort of mimics GH_Structure for use in VB/C#/Python components. Note that GH_Structure only works for IGH_Goo derived types whereas DataTree works on all types.

This weird state of affairs is because trees were introduced in the middle of GH1 development and they weren't available right away in scripting components. In GH2 there is a much better class hierarchy between all these classes.

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on March 5, 2014 at 3:44pm

I'm working on both now. GH2 is a long time away as I'm pretty much rewriting it from scratch. In the meantime I've decided to keep on adding small features to GH1 whenever it seems appropriate.

I began GH2 development with the reimplementation of goo and the datatree logic. I'm making sure that all classes derive from each other whenever it makes sense, that conversion is easy, that operations such as grafting, flattening, path mapping, item and branch selection etc. works everywhere with a minimum of effort.

One thing I can say is that components will not work on both versions. There will be substantial changes in the Grasshopper SDK. I do hope that components which do not do anything 'out of the ordinary' will be quickly and easily converted. As I have to convert close to 1000 components myself, I'll be able to see how much work is actually involved and maybe even come up with automated solutions that take care of 90% of the needed changes. It's all pretty much unknown at this stage.

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on March 6, 2014 at 3:59pm

It will still be a Rhino plugin. McNeel is funding the development of GH and the only way to make it economically viable is to either charge for the plugin (which they're luckily not doing at this point in time) or require that people buy Rhino for it to work.

David Rutten

david@mcneel.com

Permalink Reply by Godjenka on May 18, 2016 at 2:16pm