Length node output type for spreads has a bug

preview 2022.5-419



2022.4.12 working fine


We can’t really determine what the exact problem is from the screenshots alone, they also show different patches - could you upload a patch showing the issue please?

hmm its weird, I understood

It’s very hard to reproduce

aaand I recreated “<=” node and all start to work perfect

but I should mention that I decided to write at the forum because I encountered the same problem in third time. Very hard to reproduce, I usually solve it by adding conversion nodes



Try to help the type inference by

  • double-clicking the <= node and choosing the integer version or
  • double-clicking the Length node and choosing the IHasMemory version

Please keep the original problematic patch and upload here, so that we can tell whether we have to consider it a bug.

I’ve lost that part for the moment, also I’m not sure if it would show up after a restart.
But if I run into it again, I’ll be definitely bringing it here.

As I remember the integer version didn’t want to connect and compare nodes, and everything was in the “IHasMemory” version.

on last screenshot “<=” absolutley the same

And again, caught it quicker than I thought


is reproduced after saving:

_app_gcode.vl (245.9 KB)

switching to the IHasMemory version helps, seems to me.


Ok I think I understand your confusion. You should use the node Count to get the number for items in a spread and not Length. Length is meant for vectors and such and therefor outputs a float, while Count is meant for collections and should always output an integer.


Thanks! I will only use “Count” from now on

But “Length” is working!)
So there is ambiguity that cause unpredictable error — sometimes working, sometimes not. Or did I misunderstand something?



It feels like at one moment something breaks right inside the node

The Length node is adaptive, our system tries to find an implementation based on the value connected to it. If you place it without connecting it, you’ll see it outputs a Float32. Here we see its original intent, that the input should be some sort of vector. Unfortunately in case of a Spread it finds a “fitting” implementation through the IHasMemory interface the spread implements. To make things worse that selected implementation returns an integer and NOT a float, leading to issues you’re experiencing that it seems to behave different from patch to patch.

To address this properly we will need to fine-tune some rules how adaptive candidates are found / matched.

1 Like

Thanks so much for the explanation!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.