On Tue, Apr 5, 2016, at 17:37, Nagy László Zsolt wrote: > > >> 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.
My mistake, I'd confused this with a continuation of your earlier "just move it back one for open intervals" stuff, and I thought you'd said 0..2, 3..4. > > 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. :-) It's conceptual blurriness. It makes it confusing what type is being used at a given point in the code. > >> 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? Well, I was saying that iterating over the set should yield interval objects... there's just no reason interval objects should be _at all_ set-like. There's no reason to use an interval object for any purpose other than basic utility stuff like iterating. > 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. (???) I think that's one reasonable way to do it. > >> 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? I wonder, what operations require iteration over the set? Formatting as a string, sure, and there's a limited number of comparison operations you can do. Maybe these should just all be built-in methods. > 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? Whether they use tuples or an interval type isn't important, I just think either way the "begin/end pair type" should either not be something that supports set operations, _or_ it should be a full set. Having a type with a union method but that method can only be used in certain specific circumstances makes it hard to follow what's going on in code that uses it. I just think that anything that supports a union/intersect/etc method should support them fully, because otherwise there's the risk that someone won't understand what's going on when they change a place where it's used and it doesn't work anymore. -- https://mail.python.org/mailman/listinfo/python-list
