Incorrect result when doing division with uneven branches

Hello all!

I ran into a problem trying to do division in Grasshopper. The problem seemed to be present both with the Functions component and the Division component. The idea was to have two values (a, b) and divide them both by three values (x, y, z) resulting in six numbers (a/x, b/x, a/y, b/y, a/z, b/z).

To achieve this, I tried branching them up. I was expecting the operation to look something like this:

:{0;0} a b


:{0;0;0} x
:{0;0;1} y
:{0;0;2} z

:{0;0;0} a/x b/x
:{0;0;1} a/y b/y
:{0;0;2} a/z b/z

This worked fine with only one set (meaning, one branch {0;n} and the corresponding branches {0;n;i}). However, when I tried adding more than one set, the results came out all wrong in multiple ways.

First, the branches did not match up as expected. This image is from a file where I tried replicating the issue:

Based on the idea above, I thought my items in branch {0;0} would divide by each item in branches {0;0;0}-{0;0;2}, and the items in branch {0;1} would then divide by each item in {0;1;0}-{0;1;2}. However, the results show that the component divided branch {0;0} with {0;0;0}, then for some reason chose {0;1} to divide with {0;0;1}, and the continued to use {0;1} to divide with every subsequent branch.

Second, the results changed when more sets were added. Here is a series of images from a similar test:

Two sets:

Three sets:

Four sets:

Notice, for example, how the results on branches {0;0;2}, {0;1;0}, {0;1;1} and {0;1;2} changes every time a new set is added.

In another setting, I found that the more sets I added, the more sets at the end the sets became identical. Here is a picture of this:

Notice how the sets for Fx branch {0;20}-{0;23} have different Fx values, meaning they should yield different results, however branches {0;20;0}-{0;20;2} are identical to the branches of the other sets, repeating the same pattern. In this example I have 24 sets total, and the last 16 are identical.

Is this a bug, or am I just doing something wrong? Perhaps division in Grasshopper isn’t meant to work this way? Any and all help is welcome.

My sample files:
Larger sample division bug (25.8 KB)
Simple division bug (7.1 KB)

The fact that DataTrees have a nested path structure that emerges as complexity is added to them (either through operations on the canvas, or by the user adding new information) can make it appear that different path indices should align in certain ways.

For example, it may seem logical that if you have two trees:



…when performing an operation between them, that they should organize themselves like so:

{0;0} → {0;0;0}
{0;0} → {0;0;1}
{0;1} → {0;1;0}
{0;1} → {0;1;1}

But they don’t. In fact what happens is this:

{0;0} → {0;0;0}
{0;1} → {0;0;1}
{0;1} → {0;1;0}
{0;1} → {0;1;1}

The reason for this is that although the path indices for each branch suggest a method for linking different trees, Grasshopper almost never tries to match the path structure itself when performing operations between two data trees: they are treated just as lists of lists. So what you are seeing is a “longest list” behavior, where your first tree has fewer branches, and so the last branch of it is being used to complete all calculations in the additional lists contained in the second tree.

It can definitely be confusing.

If you are open to using external plug-ins, there’s one called Treesloth that has several components for taking advantage of the path structure itself for aligning multiple trees together. It has one that should help you solve your problem here called “Propagate Ancestors”. This component takes two trees that share initial index structures, and then duplicates the values of the less “complex” tree so that the user can operate between the more complex tree and the less complex one:

If you instead want to see a workaround using native components, one looks like this:

I’ve attached the definition…if you are interested to install Treesloth, then you’ll have to do it yourself from Food4Rhino, as it isn’t available through Yak.

Hope this helps!

Larger sample division bug (24.2 KB)

1 Like