RFE: Compare DAT

Wishlist and RFEs
1

(thanks for pointing out the Perform DAT is already there btw)

I have situations where I want to compare two dats, and:
1 - keep only the rows (based on a column comparison) that are in both
2 - keep only the new rows from input #2
3 - keep only the rows in which column 2 is different (after matching names on column 1)

the basic functionality reflect my need to have variables tables that are fed to a COMP which sets/unsets/redefines them based on the input table changes (it currently compares them to a locked Old table, but the whole thing is pretty finecky)

it seems to me that a good compare DAT would be useful - two inputs, and a choice of
what to keep based on rows and columns comparison:

match by row/column [ number ]
compare by row/column [ number ]
compare is true when [ equal, less than, greater than ]
action to take on successful comparison [keep/discard]

something like that.

I’ll still be left with the locked Old DAT to keep track of what was there before (so I can delete vars that disappear from input and know which ones are new) which has all sorts of problems, mainly at creation time (as there’s always problems with touch executing dats right after creation based on OnChange rules - it’s always assuming that there’s no change when in fact there is, and I have to delay execution of initializations to make sure the new comps settle in before things are initialized)

2

I’m with dani on this one. In my case, I need to match the local variables table in a clone to the variables table in the master (their existence, not the values). Here are two RFEs which (at least partly) target the same problem
viewtopic.php?f=17&t=1561
viewtopic.php?f=17&t=1222

Did I get this right dani, you’re also targeting the local variables table? If so, I see a little problem with such a compare DAT. The compare DAT would be located between the set_variables DAT and the variables DAT, which would break the per-variable cooking of local vars >> changing a single variable would cause all nodes which use any of the variables defined in the table to cook (same problem was when you add an evaluate DAT inbetween)

In my setup all UI gadgets store their values as a local variable, so independent cooking is very important. Dunno about your setup, so I wonder if a the first of the above linked RFE’s would work for you as well, i.e. a snap-option for table DAT. Of course with your additional parameters …

3

Actually what I have doesn’t affect the local vars.

I have a Component with two inputs:
1 - a 1x1 dat containing a path
2 - a nx2 dat containing a list of variables and their values

the component’s goal is to basically define the variables where the path points.

I’ve done this to make variable definition for variables that are used down the line more transparent - a sort of “settings” table if you will.

so the goal is also to optimize the definition to only those vars that are needed to be processed.

because of that I have 4 separate outcomes in the component:
1 - new variables to add
2 - old variables to delete (not in “Current” but in the locked “Old” - they are no longer on input)
3 - variables which have had their content changed.
4 - a monitor for path changes (unsets all from old path - sets them to new)

I really didn’t want to mess with /local - I’ve been burned enough times to know better than assume that the internal workings of Derivative’s components will stay the same (as it shouldn’t - that’s what encapsulation is for)

my problem is mainly related to the initialization, because these variable definition components are inside master components which - when I run a “Make” script, get created by the handful in deeply nested hierarchies. And since the input table may itself be relying on other variables that may or may not be defined at the moment of evaluation, I end up having to go through some big hoops - too big as after a day of going crazy on it my “OnVarChanged” script is now executing by looking at a chop that tells it if there are more than 1 row of vars to process: the on DAT changed somehow failed to trigger (I would know because OnVarChanged then basically resets the table its looking at at the end of the script).

That’s because the entire tree is created in one frame, and I believe things like “On DAT changed” get triggered on a frame by frame basis, while “OnCreate” … well… it gets triggered once, but often somewhere in the middle of the tree cooking after its creation, so often the vars are not quite valid, they get processed by the OnCreate, but then they change and since the On Dat changed doesn’t run at creation frame, I’m left with unprocessed triggers.

I don’t think the whole Touch cooking system is intellectually simple and predictable as it should be (although to make it that simple may take years of complicated solutions :slight_smile:).

I mean it’s predictable how things cook, but it doesn’t really apply to the realities of how they need to cook.

For example I have /JOBS/TEST/ZZ/ACTORS which mantains a list of children, and sets a variable under /JOB/TEST/ called $ACTORS, which may be used by /JOBS/TEST/RENDERS - which I believe will cook - when all is created in one frame - before ACTORS. and if RENDERS has a variable definition table in which you have:
RENDER_OBJS $ACTORS
then you can immediately see my problem. OnCreate will define a $RENDER_OBJS which is empty, and the OnDatChanged will not be triggered when the tree is done creating (because again the whole tree is created by the same script).

If you got to this point I apologies… I wrote this mainly to clear my head… hoping that some sort of smart RFE would emerge from it… more like an RFS (Request For Solution) :slight_smile:

in any case I just would need a compare DAT to make the 4 trees faster and cleaner - it would cut my operators in those components by 90% I’m sure.

good night…d

4

Did you find a solution to this?
I find myself in the same boat, I need to compare two tables and return tables containing the difference.

My scenario is this, I have two tables containing integers:
[1 2 3] [1 3 4]
and would like to return two tables:
[2] [4]

5

I managed to solve my issue with nested for loops so I guess I’m not looking for this feature any more.

6

It’s not that there’s no way to do it, but a DAT is MUCH MORE optimized and fast than for loops or multiple operators that have to be chained together to figure it out.

the RFE still stands for me.