Set operations

[d98762625]

#236
Set operations are working as described in the example. Item delimiter respected in the output from all operations.

This gives an example of how an operation can be written as a class - it's got minimal difference to the interface with the rest of the app - just the bind in the module config. We can start thinking about declaring the operation class, inheriting from this and including metadata into the class somewhere.

Some things to make sure are OK with this PR:

• Cartesian product - mismatched lengths are allowed but the pairs are just matched with undefined. For example, 1,2,3 a,b gives (1,a),(2,b),(3,undefined).
• Cartesian product - the delimiter is not respected inside the cartesian product, but it is between the products. For example, 1-2 a-b gives (1,a)-(2,b)
• Power set - Item delimiter is respected between items, but each new set is separated simply by \n.

Looking forward to any comments you have.

[n1474335]

Looks good. We can add this after the ESM branch has been merged.

[n1474335]

Typo - should be a lowercase 'p'

[n1474335]

I'd probably rename this file to SetOps.js to fit with the convention (e.g. BitwiseOps.js)

[n1474335]

I think it would make more sense to have separate operations for each function (i.e. one op for 'Union', one for 'Intersection', one for 'Set Difference'...). This is what we've done for the arithmetic ops ('Sum', 'Mean' etc.).

[n1474335]

I'd add these operations to the 'Arithmetic/Logic' category.

[n1474335]

Neat! I might start using this notation in other ops.

[n1474335]

Not sure why this is html? It looks like your output is always just a simple string.

[d98762625]

I've edited these operations to the new ESM format.

Each operation is now in it's own file.

[d98762625]

@n1474335 Generally do you think we should .gitignore the auto-generated files? It would make these PRs cleaner.

[n1474335]

Yes, that would make sense.

[n1474335]

Awesome work, this will close #236 when we merge the ESM branch.

The 'Cartesian Product' op was incorrect, but that was entirely down to me specifying it wrong in #236. I've fixed it, as well as a few other bits and pieces.