We do talk about set “minus”. So A \ B is also written A - B and is A union B complement. Although you can properly use the word complement to refer to A \ B, it generally applies to one set. So B complement is the set of elements that don’t belong to A.
Formally, I think what you’re referring to is the analog of “-“ in ordinary arithmetic having meaning as a unary operator and as an infix operator. I tend to use minus for A - B, complement for B complement, and difference for the symmetric difference of A and B (which is (A union B) - (A intersect B)) Best, Daniel > On Mar 29, 2016, at 5:28 AM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > I do believe, if we're going to try to go down the route of correctness, that > A \ B is generally spoken of as the complement of B in A, which I guess could > be written in Swift as `a.complement(of: b)`. However, that doesn't read too > well and I don't think it clarifies anything. > > Alternatively, and this would be a bigger change but would be unambiguous and > correct, we could have it as `b.complement(in: a)`, which has the added but > practically useless virtue that a hypothetical universal complement could be > named in a consistent way as `b.complement()`. > > Difference does seem to be the consensus word among most programming > languages for this method, and in Python it really is just `a.difference(b)`. > I don't think it's ever referred to as "difference from", and I would not > know if `a.formDifference(from: b)` denotes A \ B or B \ A without looking it > up. > > So, I guess, I'd prefer subtract over "difference from", as neither is really > mathematically correct and at least the former is unambiguous. If the core > team is willing to entertain b.complement(in: a), I'd be +1 on that. At the > end of the day, this particular method will have to look different from the > others no matter what because it is unique in not being commutative. > On Mon, Mar 28, 2016 at 9:59 PM Dave via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: >> On Mar 28, 2016, at 7:34 PM, Erica Sadun <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Mar 28, 2016, at 6:19 PM, Dave via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Mar 25, 2016, at 4:45 PM, Dave Abrahams <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> on Fri Mar 25 2016, davesweeris-AT-mac.com >>>> <http://davesweeris-at-mac.com/> wrote: >>>> >>>>> Can we rename `subtract` to `complement`, since that’s the correct >>>>> term? At least, I’m assuming that’s what `subtract` means… if not, I’m >>>>> confused. >>>>> https://en.wikipedia.org/wiki/Set_(mathematics)#Complements >>>>> <https://en.wikipedia.org/wiki/Set_(mathematics)#Complements> >>>> >>>> It's not just “complement,” because that means inverting set membership >>>> of everything in a finite domain. It would have to be “relative >>>> complement.” But “relative complement” lacks the directional >>>> implication that plagues terms like “difference,” but not “subtracting.” >>> >>> Fair points… I accidentally left off the argument label. May I amend my >>> suggestion to "rename `subtract(:)` to `complement(relativeTo:)`”? It just >>> seems to me that if we’re going to claim we’re implementing something, we >>> should adopt as much of its “standard" syntax and terminology as possible. >>> It makes Swift easier to use for those coming from other disciplines, IMHO. >> >> If you took 100 random developers off the street, and showed them code that >> said: >> >> set1.formRelativeComplement(set2) >> >> and >> >> set1.subtracting(set2) >> >> About 99.5% of them would understand the second better than the first on >> first read. >> The other 0.5 of a developer would be living somewhere near Boulder and >> growing >> his own hemi-pharmaceuticals. > > With my amended suggestion, that would read "set1.formComplement(relativeTo: > set2)”. Either way, though, if you’re claiming that “complement(relativeTo:)” > or “complementRelativeTo(:)” shouldn’t be used because it’s too > unrecognizable compared to the roughly-analogous term “subtract", then surely > “union”, intersection”, and especially “symmetricDifference” all fail that > test as well when compared to some very well-known terms: > set1.or(set2) //union > set1.and(set2) //intersection > set1.xor(set2) //symmetric difference > (Plus, they work & play well with non-unicode operators.) > > My issue isn’t so much that the proposal doesn’t implement the “correct” > mathematical notation, it’s that it uses a very formal-sounding name ("Set > Algebra”), and very nearly implements the basic operations of Set Theory > (which sounds very similar to “Set Algebra”), but then falls short by > renaming just one operation. Although, come to think of it, the proposal is > missing `cartesianProduct` as well… Oh well, at least it’s not in there > under a different name. :-) > > > >> The problem with subtraction is that there isn't really a good noun/formNoun >> pair >> for it. > > ... > >> In all my attempts at trying to brainstorm up a better word that would (1) >> retain >> the characteristics of mutating/non-mutating pairing while (2) being easy to >> read >> and understand, I could not come up with better than Dave A's >> subtract/subtracting. >> I may not like it aesthetically but when it comes to offering something >> better, >> I've got nothing. > > I think these two statements have the same root cause: Pretty much everyone > has heard of subtraction, but the closest most people come to formally > thinking about sets is trying to decide who to pick for their fantasy > football team. The concept of operating on sets simply isn’t widespread > enough for english to have a colloquial word which conveys the required > meaning. “Subtract” does come close, but the AFAIK two concepts are only > analogous in that subtraction is often first taught from the POV of “imagine > a set of x elements, take away y of them, and count how many are left over” > (see the first graphic in https://en.wikipedia.org/wiki/Subtraction > <https://en.wikipedia.org/wiki/Subtraction>, if that doesn’t ring a bell). > The analogy doesn’t really work if your sets are, well, sets, as opposed to > visual representations of numbers. The only other “widely-recognized” term > that I can think of is “minus” (which I’d prefer over “subtract” because it > seems less precisely defined to me). Neither one is a noun, though, so they > both break the noun/formNoun pattern. > > Speaking of nouns... >> That means either breaking the pair into two words that aren't well matched >> or using a noun that isn't that amazing, such as difference. >> >> set1.difference(set2) >> set1.formDifference(set2) > > You can gain the requisite “directional implication” Dave Abrahams was > talking about by adding some labels: > set1.difference(from: set2) > set1.formDifference(from: set2) > > > >> That said, I'd really like to see a Swift Doc markup that allows you to mark >> pairs of mutating/nonmutating functions, not from a compiler point of >> view but in doc markup. >> >> /// - nonmutatingVersion: >> /// - mutatingVersion: >> >> What group handles expansion of the markup keywords and how can I file a >> feature request asking for this to be added? >> >> Thanks, >> >> -- E > > +1 :-) > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
