DeCons (Generic) doesn't update its outputs properly when fed with nil [beta27.2]

See patch.

DeCons Bug (5.5 kB)

will kind of be fixed for upcoming, since it will be replaced by another native node

Unzip doesn’t seem to have a BinSize, so its behaviour will be different, no?

@velcrome. true, for other categories. there’s the one with bin size in category spreads though. if nobody adds the missing categories i can do it before the release

hey there,

i am sorry to tell you that this is no bug in my opinion. it is more a users’ fault comparable to feeding 0 to the second pin of a / (Value)

here is why i think that:
the structure of a spread of spreads is solely configured by the binsize pin. when feeding one slice into the binsize pin you are already saying that there is one spread. By feeding a 1 you are really saying that this one spread comes with one value and therefore the whole structure looks like this: ( ( x ) ) with x being some value that comes from the first pin. in your case a string.

now what string should that be? taking the value of the last frame is consistent with the behavior of a divide node that struggles with a division by zero.

you could now argue that in case of no data=NIL=( ) at the input pin - and only in this case - the structure of the spread of spread should be calculated differently: not solely by the binsize pin. it now should really just ignore the user specified bin sizes, because it is obvious that you really mean just an empty outer spread ( ) with no inner spreads…(?)

sorrily it is not so obvious.
a user specified binsize of (0,0,0) results in a structure ( ( ), ( ), ( ) ).
a user specified binsize of ( ) results in a structure ( ).
a user specified binsize of (0) results in a structure ( ( ) ).

all of those structures dont consume any values; the inner spreads - if any - are empty = NIL. that means for all of them an empty spread on the first pin would feel right. and thats why you can’t map an empty spread on the first pin to some obvious 2d-spread structure.

you could now argue that just in the case that

  • binsizes would somehow result in a structure that consumes values, like ( (x) ) AND
  • when the input doesn’t offer any values to consume
    something is faulty and we should check that and in this case change the structure to ( ) or ( ( ) ) or something like that. but i would just say it is a users bug.
    it would feel like a hack to me.

what do you think?

To be honest at that time I didn´t put that much thought into it. The node was simply not behaving the way it was necessary in that particular case and I ended up using Stallone which acted like it was needed. In hindsight and after reading your post (thrice :) I mixed up the inner workings of Spread Count and Bin Size. Obviously you are right, but still it feels kind of counterintuitive having to feed the Bin Size with n-times 0 to have all the pins output NIL.