Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #106569

Re: ANN: intervalset Was: Set type for datetime intervals

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> (permalink)
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
X-Trace news.uni-berlin.de eKeP+gwOsh2KGTWPqWK0Iwa/aJXmLGo/s9PFZe4Q9/8A==
Return-Path <random832@fastmail.com>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.000
X-Spam-Evidence '*H*': 1.00; '*S*': 0.00; 'continuation': 0.07; 'formatting': 0.07; 'important,': 0.07; 'subject:ANN': 0.07; 'type,': 0.07; 'anymore.': 0.09; 'definition,': 0.09; 'finite': 0.09; 'item,': 0.09; 'iterate': 0.09; 'objects.': 0.09; 'received:internal': 0.09; 'throw': 0.09; 'throws': 0.09; ':-)': 0.12; 'useful,': 0.13; '"end"': 0.16; '*i*': 0.16; '*you*': 0.16; 'attribute,': 0.16; 'certainly.': 0.16; 'describing': 0.16; 'distinction': 0.16; 'element.': 0.16; 'elements,': 0.16; 'fully,': 0.16; 'interval.': 0.16; 'iterating': 0.16; 'iteration': 0.16; 'iterator': 0.16; 'message-id:@webmail.messagingengine.com': 0.16; 'received:10.202': 0.16; 'received:10.202.2': 0.16; 'received:10.202.2.44': 0.16; 'received:66.111': 0.16; 'received:66.111.4': 0.16; 'received:compute4.internal': 0.16; 'received:io': 0.16; 'received:messagingengine.com': 0.16; 'received:psf.io': 0.16; 'sense,': 0.16; 'set,': 0.16; 'set-like': 0.16; 'set-like.': 0.16; 'stuff,': 0.16; 'subject:Was': 0.16; 'subject:type': 0.16; 'uh,': 0.16; 'wrote:': 0.16; 'string': 0.17; 'element': 0.18; 'exists': 0.18; 'string,': 0.18; 'math': 0.20; 'purposes': 0.20; 'posted': 0.21; '(the': 0.22; 'do.': 0.22; 'saying': 0.22; '(by': 0.22; 'parameter': 0.22; 'tuples': 0.22; 'code.': 0.23; 'defined': 0.23; 'elements': 0.23; 'sets': 0.23; 'header:In-Reply-To:1': 0.24; "doesn't": 0.26; 'sense': 0.26; 'earlier': 0.27; 'point.': 0.27; 'error': 0.27; 'not.': 0.27; 'operations,': 0.27; 'yield': 0.27; 'function': 0.28; 'this.': 0.28; 'comparison': 0.29; 'methods.': 0.29; 'notation': 0.29; 'sets.': 0.29; 'sure,': 0.29; 'understand,': 0.29; 'yields': 0.29; 'character': 0.29; 'objects': 0.29; "i'm": 0.30; 'code': 0.30; 'e.g.': 0.30; 'skip:[ 10': 0.31; "i'd": 0.31; 'error.': 0.31; 'operations': 0.31; 'certain': 0.31; 'another': 0.32; '"the': 0.32; 'non': 0.32; 'computer.': 0.32; 'maybe': 0.33; 'point': 0.33; 'useful': 0.33; 'operations.': 0.33; 'right?': 0.33; 'utility': 0.33; 'values.': 0.33; 'view,': 0.33; 'open': 0.33; 'tue,': 0.34; 'that,': 0.34; 'could': 0.35; 'set.': 0.35; 'quite': 0.35; 'something': 0.35; "isn't": 0.35; 'problem.': 0.35; 'supports': 0.35; 'but': 0.36; 'should': 0.36; 'there': 0.36; 'possible': 0.36; 'basic': 0.36; 'beginning': 0.36; 'to:addr :python-list': 0.36; 'subject:: ': 0.37; 'received:10': 0.37; 'being': 0.37; 'method': 0.37; 'thought': 0.37; 'wanted': 0.37; 'no,': 0.38; "won't": 0.38; 'received:66': 0.38; 'different': 0.63; 'you.': 0.64; 'other.': 0.64; 'between': 0.65; 'equals': 0.66; 'was:': 0.66; 'course.': 0.67; 'union': 0.67; 'risk': 0.68; 'design.': 0.72; 'special': 0.73; '"just': 0.84; 'confusing': 0.84; 'nagy': 0.84; 'sets,': 0.84; 'yielded': 0.84; 'reasoning': 0.91; 'subject:Set': 0.91
DKIM-Signature v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=wGqYozxwUvLBRPcCijFX2hZaDsY=; b=1g2ISu mjwitmHV/SdSRY5ffGBcv598C/j4taaPt12tKLlalGYhB/Ij5hiWCE6rntXmiEPz 91HFqmj7ZVFkV60SYqN+FZXnmlgRiMXi4oW1E5UIN7786KfvVjA/6/6eyitdStcw V+sgrosIcGr+Cjfs3d0jCmuiSb4Ks5zwE4xV8=
DKIM-Signature v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=wGqYozxwUvLBRPc CijFX2hZaDsY=; b=IsZEIQwZTyTaNsylTXHduqtjkUdIGHlYGKqTluhiBzA9qZO y3cesn3LmMLxTwAuGL7hHiuMBbVC+MUY+g4aWr7IoyOLcezgr1awDEj/QVq4Yoop Da1iJuACJc4VdI3qUPnJwlqeyeBvHyPR4rfsStg1/8s/AI0BjfEn8Sm3mrAM=
X-Sasl-Enc MxG322JCqCTOUxtNtzPawmDi2LFSmSt6IkatJtUr+2L1 1459945751
X-Mailer MessagingEngine.com Webmail Interface - ajax-6aa5290f
In-Reply-To <57043001.5060802@shopzeus.com>
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.21
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID <1459945751.775469.570632041.367C8E99@webmail.messagingengine.com>
X-Mailman-Original-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>
Xref csiph.com comp.lang.python:106569

Show key headers only | View raw


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.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: ANN: intervalset Was: Set type for datetime intervals Random832 <random832@fastmail.com> - 2016-04-06 08:29 -0400

csiph-web