Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Random832 <random832@fastmail.com>
Newsgroups: comp.lang.python
Subject: Re: ANN: intervalset Was: Set type for datetime intervals
Date: Wed, 06 Apr 2016 08:29:11 -0400
Lines: 100
Message-ID: <mailman.127.1459945755.32530.python-list@python.org>
References: <56FE0625.5030901@shopzeus.com> <1459523394.2611014.565840994.593DD99A@webmail.messagingengine.com> <570213CB.8040101@shopzeus.com> <1459782597.3444051.568344234.048046C6@webmail.messagingengine.com> <CAHVvXxRRmJKHq-H8xotY9yF+pzG+7NOSMhOwTbL4qF-N4XjTfQ@mail.gmail.com> <1459784663.3451967.568464658.50905009@webmail.messagingengine.com> <57037318.6050703@shopzeus.com> <1459864776.466447.569580657.1414C457@webmail.messagingengine.com> <57043001.5060802@shopzeus.com> <1459945751.775469.570632041.367C8E99@webmail.messagingengine.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <57043001.5060802@shopzeus.com>
Precedence: list
Xref: csiph.com comp.lang.python:106569

On Tue, Apr 5, 2016, at 17:37, Nagy L=C3=A1szl=C3=B3 Zsolt wrote:
>=20
> >> 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.=20
> 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 compute=
r.
> >> 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 equati=
on
> >> 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.