Group Filter - Logic - "undesired"

I attempted to create a group of people that would be alive for 1950 Census but do not have a Census fact for 1950 using following settings. It appeared to contain ALL individuals alive rather than filtering out those who already had 1950 census fact This is not what I would expect. I can do a SQL to get needed results but I was trying to do as Group within RM. Basically it should only “fail” (false) if there is NO 1950 Census rather than all Census have to be of 1950 census. So it appears to filter out those who only have a 1950 census (but not 1940 census etc) Evidently that and/or logic needs to be done in SQL Not sure I can quite classified this as “unexpected” but certainly undesired.

I would expect that to fail unless everyone in your database has a Census fact. I don’t have time to sit down and work through this but I am thinking that the first line is going to be false if Census does not exist, so you might end up with a False and True and True which will be a False.

It’s a classic trap for people to fall into. The Boolean operators do not work within a single fact or event but across all such for a person and you have to think carefully about how you may use Mark and Unmark in sequence.

Your first criterion would be satisfied by any Census event with a date other than 1950 and maybe even for a person with no Census event. Your next two criteria will select those people you have recorded both Birth and Death events who were logically alive in 1950 but misses those for whom you have only one of those events and might reasonably have been alive.

Using RM, you might Mark all people who have any event in 1950; Mark anyone Born after 105 years earlier; Unmark anyone with a Death event before 1950; Unmark anyone with a Birth event after 1950; Unmark anyone with a Census date containing 1950.

Since you are into SQL, have a look at a script I developed some years ago and updated for RM8:
https://sqlitetoolsforrootsmagic.com/census-needed-named-group/

Your strange results are caused by what I personally consider to be a design flaw in RM’s Boolean logic when a particular fact type occurs multiple times for the same person. The design is the same for RM8 as it was for all previous versions of RM.

It’s hard to explain, but let me try. For example, suppose I wish to find all the people with Census facts for 1850 in Texas. Therefore, I might search for Census => Date => Equals 1850 AND Census => Place => Contains => Texas. The problem is that this search will find people who had an 1850 Census fact in Tennessee and an 1860 Census fact in Texas. In other words, the search finds a person with a Census fact in 1850 AND a Census fact in Texas. My person meets both conditions. The conditions are evaluated separately, and there is nothing that required that they apply to the same Census fact.

My solution is to have a 1950 Census fact type and also a 1940 Census fact type etc. I use these facts instead of the standard Census fact. I make the sentence for all the different Census facts the same because the census year is a part of the fact sentence.

1 Like

Another problem is that the search for Census => Date => Does Not Contain => 1950 will also get hits on people with no Census fact at all and for Census facts with no date at all in the unlikely case that you have any such Census facts.

With the year specific Census facts, you can search for things like 1950 Census => Exists => Is False.

Something that is would be considered a work around. and “taking the long way home” (but should work for most people). For me I would seem use SQL with and/or and ‘(’ / ‘)’ where needed. I wanted to make people aware (for those who might not be of potential issues).

It goes beyond its design parameters. (meaning it lacks any sort of advanced and /or logic). This is definitively a (design) limitation… so bringing attention that and asking for feature request for improvement (as many would not want to go with SQL options).

Could you do the first criterion and make a group of the outcomes, then do the second criterion, make a group and so on?? John

That sounds more like an “OR” criterion than an “AND” criterion. John

On other thought it might be nice to use Mark or Un-Mark if the they belong to group – although that might cause some challenges I suspected (Like the data fields)

It would be nice if RM allowed the use of parenthesis to modify the boolean evaluation order.

That would be nice, but that’s not the most serious problem. Here are some more serious problems.

  1. You cannot search for two different pieces of data on the same fact, such as date and place. This problem comes into play for fact types that naturally are used multiple times per person such as the Census fact. This is probably the very worst problem right now.
  2. A Boolean searches cannot be remembered.
  3. Relationships such as “father of”, “spouse of”, and “child of” cannot be searched.
  4. Group membership cannot be searched.
  5. Relationships such as “second great grandfather of” or “second cousin of” cannot be searched.