Length node output type for spreads has a bug

[yar]

preview 2022.5-419

2022.4.12 working fine

[Elias]

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?

[yar]

hmm its weird, I understood

It’s very hard to reproduce

[yar]

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

!:

[gregsn]

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.

[yar]

@gregsn
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

[yar]

And again, caught it quicker than I thought

is reproduced after saving:

_app_gcode.vl (245.9 KB)

[yar]

switching to the IHasMemory version helps, seems to me.

[Elias]

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.

[yar]

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

[Elias]

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.

[yar]

Thanks so much for the explanation!