I tried prototyping, but I clearly don’t understand something and I’m not doing it quite right. Anyway, it was long time coming that there should be a region that tracks IsAssigned instead of the VERY often repeated construct with IF.
upd: this version is actually better, but there is still room for improvement.
IsAssignedRegionUpdate.vl (33.9 KB)
Would be cool if there was an option to provide defaults using dynamicpins. But it’s really hard to work with synchronization and not sure I can achieve it alone.
IsAssignedRegionUpdate3.vl (63.1 KB)
Impressive!
Nice ideas here, adding input pins for each output border control point… Also the warnings on the region. Good stuff.
So the region shall ensure that the outgoing data is assigned, either by using the input or if some are not assigned utilizing the stuff coming from inside the region?
Maybe the better name is EnsureAssigned?
Or did I get this wrong and it’s about IfAssigned, again ensuring that the outgoing data is assigned, but the other around? Calling the region when all the inputs are assigned and if not routing the defaults to all of them.
Those two regions feel a bit like binary operators - like And and Or - maybe those two should also be offered as regions. And only calls its region body if the input is already true. It will then run the region to check “the second part of the expression” and only output true if this one is true. Or only calls the region body if the input is false and tests for the “second part of the expression”.
Either way. It feels that all of the envisioned regions have one thing in common. They might have different rules when to call the body, but if they do, they route the data from inside the region to the outside.
So
I think currently you only route data to the outside from the inside of the region.
But if the region is not executed you should switch to using what is connected to the input group?
I just think it’s possible to replace this structure with something more convenient. I’m a bit wary that this structure is much more efficient and replacing it with a custom region might create too much overhead.
The hardest part is figuring out how to synchronise inputs and outputs if something is not IsAssigned. Well, I just wired these inputs, yes. Now you can get a dictionary of input pins. Cool, but honestly, it doesn’t look like I’ve figured out how to map outputs to these inputs normally yet. Any ideas?
Maybe I’m wasting time and we should make it easier? In any case, the Dynamic Pins don’t work very well, appearing delayed and giving an odd impression in operation. By the way, I can confirm that using a large number of nodes with dynamic inputs over a long period of time will eventually lead to stable glitches in the interface.
IsAssignedRegionUpdate4.vl (77.1 KB)
“IfAssigned” is good, but probably better to use “IsAssigned” just for two main reasons: easy to remember how to find (it’s just the same name that you probably remember to use when you encounter this type of situation), easy to understand (“probably, do the same thing”).
I think I have made the best version of it
Maybe, just maybe, it could be possible to rework the ‘if’ region right in the source so that it just accepts not booleans but checks isAssigned? Unless of course this region is arranged exactly the same way (In the sense of creating a more efficient new region)
IsAssignedRegionUpdate5.vl (30.6 KB)
But in the right case, I couldn’t get the outputs to work the way I wanted them to - to produce default values as in the left example, but without the ability to set them.
IsAssignedRegionUpdate6.vl (66.6 KB)
I’ve always missed the null check on the cache region. @Elias any ideas or concerns if that s could be added to the input control points of the cache region?
Maybe just a simple flag “Null Check Inputs” like “Dispose Cached Ouptus” that also checks for null on all inputs, instead of having it for each one individually. The region would then only execute if all inputs are assigned.
@tonfilm But what about the outputs then? Wouldn’t that just post-pone the “issue” and downstream nodes would now have to deal with null/defaults/meaningless data?
Great stuff!
Accumulators feel very natural and yes version 5 is exactly behaving like an If Region that just happens to test for IsAssigned instead of taking a boolean.
Still had a look at version 3 as well and managed to route from inputs to the outputs in case of not assigned.
IsAssignedRegionUpdate3_fix.vl (69.1 KB)
Here is a version of the spectral using vl defaults per output BCP as a cache region would do.
IsAssignedRegionUpdate6_spectral_vldefaults.vl (70.8 KB)
@gregsn It feels almost perfect and has some interesting nodes I wasn’t aware of.
Maybe we can add some verbosity to the warning? Type of object, some details (for reason to take some information from behind, if the node is deep in the patch) For example, in the Spectral version (still not sure if that’s a good name, to be honest), is it worth specifying which input IsNotAssigned? Maybe it’s worth keeping it simple.
I think it should do the warning as I suggested in the isAssigned regions. And it should just do ‘default values’ on the outputs or last valid value (in case of cache it seems reasanoble)
The idea is not to use bypassing null values as a good practice, rather just to speed up development. But with the presence of a warning is quite possible and workable and in case of need.
I think overloading the Cache region with functionality is a controversial strategy, but it could work.
Verbosity sounds nice. We could even alow the user to specify a message. That way you’d see meaningful messages while debugging.
Maybe there could be even more helper nodes that help with developing.
Regions like IsAssigned actually do stuff and as byproduct can be helpful when debugging, but there might also be nodes that you only put in for debugging purposes.
Like double-click on a link and insert an Assert node where you can specify a value that you’d expect and a message that should appear when it’s not that value. The message could again be fed by the user in order to get the message on a higher level, make it more meaningful than “expected 0, actual value 1”. Same probabaly is true for IsAssigned.
In theory we could even show differenet warnings on different levels. On the node itself could be a different warning than one level outwards stackwise. The patch that has the node inside could show a different warning that has more context, but seldomly you’d be willing to enter all these messages. Just saying it’s possible.
Here you see how the Warn node sends out the same message to all levels of the surrounding nodes/patches:
I don’t think the whole verbosity thing makes much sense, because it would require redesigning the way warnings are sent. The original node has “pre-recorded on create” messages, and making it ‘interactive’ would require just as much effort. I like it as it is, I’ve thought “I wish there was a node like this” a few times while patching.
Would you consider adding this to the main API?
IsAssignedRegionUpdate7.vl (67.8 KB)
I like the Assert idea a lot
Something flashing on creation worries me a bit (I guess I have to put the region entry at the end?)
Yes, I can imagine adding the one or other region. I will have to discuss with the team regarding naming, but functionality is great already!
btw: this shouldn’t be necessary. You instructed the Cache region to take care of disposal.
