Page MenuHome

GHash - Add 'set' operations & checks
AbandonedPublic

Authored by Bastien Montagne (mont29) on Mar 13 2015, 1:19 PM.

Details

Summary

Based on D1178

Not much to say here, this is pretty straight forward.

Note that we are “cool” with operations which only affect the first item (intersections and differences), and allow in those cases all other args to be gsets, even if first one is ghash. Reason here is that you may want to 'trim' a ghash based on some gset’s content…

Diff Detail

Repository
rB Blender

Event Timeline

Bastien Montagne (mont29) retitled this revision from to GHash - Add 'set' operations & checks.
Bastien Montagne (mont29) updated this object.
Bastien Montagne (mont29) set the repository for this revision to rB Blender.
Campbell Barton (campbellbarton) requested changes to this revision.Mar 18 2015, 3:42 PM
Campbell Barton (campbellbarton) edited edge metadata.

Having set operations (union/subset) GHash I dont think makes so much sense and is even misleading. union for example needs to select values from one of the GHash's. So would prefer just to call this merge (then option if you want values from left/right).

This is request to remove quite some code but would really to start off this patch by adding utility gset operations on sets and add extra utility functions later.

This revision now requires changes to proceed.Mar 18 2015, 3:42 PM

I really disagree here… :)

GHash is gset with data, so I do not see why we would not want to be able to perform the same operations as on gset. Especially since it adds virtually no more code (just the few bits needed to copy or free values in addition to keys), the 'hard' part (i.e. the operation itself) is exactly the same for both types.

Actually, even with gset, Union is also a merge, since we have to decide whether we keep keys from left or right side. This is pure semantic stuff, still prefer to keep same naming on both gset and ghash, it enforces the fact that they use same code in the end, and also makes using those operations simpler/clearer imho.

Bastien Montagne (mont29) edited edge metadata.
Bastien Montagne (mont29) updated this object.

Updated from master, and removed public GHash API for union/inter/diff/symmdiff.

Dead easy to add them back (with those 'setops' names or others like merge & co)
later, anyway. Core code remains unchanged.

Note I kept pure key checks (isdisjoint, etc.) for ghashes, those are not an issue
at all (I hope :p ), it's equivalent to performing setops on dict.keys() views in py...

eeeh, well seems we have to agree to really disagree :S

In general the checking functions make some sense to have bothe ghash/gset functions - since they dont create new data, BLI_ghash_is_subset_keys, BLI_ghash_is_equal_keys - for eg.

But functions which create new data - these should only have set versions - (subset, union, intersection - etc).

If one day we need a ghash version of a set function, we can check on having one then.

source/blender/blenlib/intern/BLI_ghash.c
606–610

Would rather just call this a ghash_merge or ghash_update

1230

There could be a fast-path here, if both have the same number of buckets (which isn't so unlikely seeing as they are the same size).

Also goes for other functions here.

tests/gtests/blenlib/BLI_ghash_test.cc
258 ↗(On Diff #3784)

should call gset, Union?, same for Difference

source/blender/blenlib/intern/BLI_ghash.c
1743

minor note regarding var-args.
We could avoid using va args and instead use a macro...

#define BLI_gset_union(keycopyfp, ...) \
{ \
    GSet *gset_arr[] = {__VA_ARGS__}; \
    _bli_gset_union(keycopyfp, gset_arr, ARRAY_SIZE(gset_arr)); \
} (void)0

This way its type-safe ans no need for a NULL terminator arg.

Bastien Montagne (mont29) edited edge metadata.
  • Some improvements/tweaks from review.
  • Get rid of varargs in union & co functions (using variadic macros instead).
This revision was automatically updated to reflect the committed changes.

<known sentence>

some mixup happened on update, this is a sequencer patch

  • Some improvements/tweaks from review.
  • Get rid of varargs in union & co functions (using variadic macros instead).

That indeed seems a bit weird to have set operations on hash, it's just asking for problems and confusion in the future. For example, is {key: 1, value: foo} equals to {key 1:, value: bar}? Such things are really an easy way to shoot self into own foot.

Would just leave those functions aside for until we really need them and wouldn't add functions just because they seems easy to add, hoping they'll become handy and clear in the future.

This revision was automatically updated to reflect the committed changes.

Let’s curse the bots…