at for most `subset`

, but too a limit I think it could make sense also for: `intersection`

, `difference`

.

can you make examples?

```
{
"uuid": "f048ea53-ae0e-4565-aa81-e758ac882fdd",
"description": "set is a subset of set with duplicates",
"property": "subset",
"input": {
"set1": [1, 2, 3],
"set2": [1, 1, 2, 3]
},
"expected": true
},
```

I think I understand now for subset.

For intersection, I’m still not sure. The `expected`

here is another set, so the way to test this is to compare the result of an intersection with the expected set. Wouldn’t this already be covered by the equality test? Same for difference.

I added a commit with tests for `subset`

:

I’m not sure what that subset test is supposed to accomplish. The unit data is used to initialize the set. If a set initialized with duplicate elements is equal to a set initialized with non dupes, what is the purpose of further tests?

I guess the question is whether a reasonable implementation can pass one test, but not the other? I can’t think of one. @Meatball can you? What implementation can pass the equality test but not the subset test?

I take that as a no.

I removed the subset tests again.

If there are no other objections, might we move ahead with the PR?

Yeah, I thought logically as my brain would calculate it, not as a machine.