>> It is blurred by design. There is an interpretation where an interval >> between [0..4] equals to a set of intervals ([0..2],[2..4]). > No, because 2.5 is in one and not the other. My notation was: 0..4 for any number between 0 and 4. And 2..4 for any number between 2 and 4. So yes, 2.5 is in both of them.
> Floats are orderable with > ints, so it's not reasonable to say "this is an int intervalset so no > floats are contained in it". But that's another discussion. I did not say such thing. > > But why would you want to use [0..4] directly instead of ([0..4])? I did not say that I want to use it. I just said that ([0..2], [2..4]) and ([0..4]) contains exactly the same values, and I wanted to have a single well defined representation. >> Actually, >> you can ask: "is an element within the interval?" The same question can >> be asked for an Interval set. So the same type of value can be >> "contained" within an interval and also witin an interval set. In the >> current implementation, if you try to create a set with these two >> intervals [0..2] and [2..4], then they are unified into a single element >> on purpose: to make sure that there is only a single official >> representation of it. E.g. ([0..2],[2..4]) is not a valid set, only >> ([0..4]) is. > Uh, exactly. I don't understand why any of this makes it useful to have > these operations on interval objects. It doesn't make it a problem. :-) > >> By definition, a set is given with its elements, e.g. for any possible >> item, you can tell if it is part of the set or not. So if >> ([0..2],[2..4]) and ([0..4]) have exactly the same elements (by the >> given definition), then they are not just equal: they are the same set. >> The same reasoning is used in math when they say: there cannot be >> multiple empty sets. There exists a single empty set. It happens that we >> can only represent a finite number of elements in any set on a computer. >> I wanted to have a well defined single way to represent any given set. > What? *I* am the one who wants a well defined single way to represent a > given set. *You* are the one who wants to make [0..4] a set-like object > that is different from ([0..4]) and doesn't quite support the same > operations. Are you suggesting, that iterating over a set should yield sets? Just like iterating over a string yields single character strings? To make it useful, we must be able to access the begin and end value of such yielded sets. > >> I can also see your point. From another point a view, a set and a set of >> sets is not the same type. > I'm saying an interval is _not_ a set. It is merely part of the way of > describing the set. Just like the word "of" isn't a set just because > "the set of all even numbers" is a set. > > You could consider "the set of [dates|numbers|etc] in a single interval" > to be a type of set, certainly. But there's no reason to have such a set > _not_ fully support set operations even when those operations will not > return a set of a single interval. Okay, I hope I'm beginning to understand you. Analogy: the ord() function has a string parameter but it must be of length 1. Simiarily, when you iterate over a set, the yielded items will be sets with a "begin" and "end" attribute, wich can only be used when the set has a single element. Otherwise it should throw an error. The same way my Interval type throws an error when you try to unify it with a non overlapping interval. (???) > >> However, I do not share this view, because if >> we start thinking this way, then operations like the one below does not >> make sense: >> >> [0..4]) - (1..2] == [0..1] | [2..4] >> >> If you make a strinct distinction between intervals and interval sets, >> then the above equation does not make sense, because you cannot remove >> an element from a set that is not an "element" of it. The above equation >> makes sense only if the "intervalset" is a general representation of >> possible values, and the "interval" type is a special representation of >> (the same) possible values. > I don't understand why you want to let the user use the "interval" type > for purposes other than adding to an intervalset in the first place > Nothing you've posted has explained this. For iteration over the set and accessing begin/end values, of course. But then again: we could use simple tuples for that, right? As far as I understand, you recommend to throw out the Interval type, let the user use simple tuples in the IntervalSet constructor, and let the iterator iterate over tuples. Right? -- https://mail.python.org/mailman/listinfo/python-list
