I spent a little while trying to understand how multiple and/or/but not criteria are combined in criteria-groups and the equivalent advanced search. The answer is pretty obvious, but I don’t see it in the help or elsewhere here, so I thought I would share what I have found.
The pretty obvious answer is that RM applies the rules in the order they are listed, from top to bottom. I assume that it creates the intersection or union as appropriate of the first two items, and then the intersection or union of that with the third item, and so on down the list.
I wanted to create a group of people whose ‘living’ status is questionable. I previously had groups for
- Living with any fact earlier than 1926
- Living with marriage earlier than 1946
- Living with death fact
- Living with burial fact and
- Living with probate fact
I wanted to tidy these up in to a single group.
Not seeing any brackets or equivalent to determine the sequence of rules, I first naively assumed that ‘and’ operators might take precedence over ‘or’ operators, which did not give the right results.
In the end, the sequence of rules that worked was
- Event; any fact type is before 1926
- Or, event; marriage fact is before 1946
- Or, event; death fact exists
- Or, event; burial fact exists
- Or, event; probate fact exists
- And, individual attributes; living is true.
I think this means that you can make any combination of three rules work, for example (a and b) or c would be 1. a, and 2. b or 3 c, whereas a or (b and c) would be 1. b and 2 c or 3 b. You could also make any combination of lots of ‘ands’ and a single ‘or’ or vice versa work, but a combination of two ‘ands’ with two ‘ors’ (such as (a and b) or (c and d)) would require some special treatment, such as creating a ‘sub-group.’
I would be interested to hear other users’ experience.
My thought would be AND should NOT be after a set of ‘ORs’
However in you example – most people married before 1946 would be ~100+ and less likely to be living . That said – I would put #6 (living ) before the ORs— it might be coincidence its working for you if you do not have many 100+ people but you also say DEATH Exist so they should not be alive to begin with
[EDIT] however it turns out the AND LIVING being last does work after the ORs which seem counter intuitive – producing 59 in case (if I change order I get 29K results (out of nearly 33K total people)
People where Death exists should certainly not be alive, but there was once a bug in Treeshare (since fixed) which caused this to happen in RM and made a worse mess in Ancestry. I had to check for it then to clean up the mess and have continued to check for it since. (No recent cases).
I would not originally have thought about putting and AND after a series of ORs if I wanted the ORs to be treated as if they were all in brackets, but this seems to be the only approach that works, for the reasons that I hope I have explained - and as I see that you have now discovered.
My reason for posting this was precisely because the approach that seemed to be counter-intuitive did indeed work; I thought it might be useful to share this.
1 Like
well (SHOULD NOT BE) - but if someone either changed flag or if the DEATH fact was create outside of RM then it is possible actually.
yes agree – nice example – might have to play a bit more with this type of scenario – maybe the diff categories (Attributes vs events have something to do with it)
I think the way it really works is as follows.
- The rules are applied in order.
- The first rule is applied. There is not yet any AND or OR logic. The first rule simply creates a selection.
- Each OR is not really an OR in the sense of Boolean logic and Venn diagrams. Rather, it adds the individuals meeting the OR criteria to the selection.
- Each AND is not really an AND in the sense of Boolean logic and Venn diagrams. Rather, it removes from the selection those individuals who do not meet the AND criteria.
So the logic is Boolean Add and Subtract, not Boolean AND and OR. At least that’s the way it seems to me and I could be wrong. I can create Boolean AND and OR to a certain extent from the Boolean Add and Subtract, but it can be a little tricky.
That being said, RM’s current implementation of Advanced Search has a great deal more functionality that previous implementations. For example, what used to be a single criterion associated with an event can now be multiple criteria for a single event - such as Place and Date and Note and Sources, all associated with the same event. For decades, this kind of search criteria simply was not supported, and now it is well supported.
that seems possible/likely – but as you said the current version is the best we have to-date an leaps and bound was we had only a couple years agoand likely they want to avoid the need to understand program logic to use. Family Historian (v7) had very sophisticated search criteria but its not intuitive or easy to use unless you are intermediate plus. I know how to use sqlite and/or power query etc and for most things its quicker easier to use the ADV search / groups
yeah I recall doing a couple scenarios where I ended up doing in sqlite or PQ as I could get the logic the way I wanted – that is NOT to say the logic could not work in RM but was NOT easy for ME to get it the way I wanted/needed
