From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.devel Subject: Re: Overlays as an AA-tree Date: Fri, 03 Feb 2017 16:54:12 +0100 Message-ID: <877f575kyj.fsf@hochschule-trier.de> References: <87d1jylv43.fsf@fastmail.com> <87fujv64mn.fsf@hochschule-trier.de> <87fujvpkzc.fsf@fastmail.com> <87vasr5tqd.fsf@hochschule-trier.de> <877f57pdne.fsf@fastmail.com> <87fujv5ncv.fsf@hochschule-trier.de> <87y3xnnvri.fsf@fastmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486138845 28641 195.159.176.226 (3 Feb 2017 16:20:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Feb 2017 16:20:45 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: emacs-devel@gnu.org To: Joakim Jalap Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 03 17:20:42 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZgbH-0006vI-D2 for ged-emacs-devel@m.gmane.org; Fri, 03 Feb 2017 17:20:39 +0100 Original-Received: from localhost ([::1]:35587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZgbH-000280-I5 for ged-emacs-devel@m.gmane.org; Fri, 03 Feb 2017 11:20:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZgC0-0004t3-VA for emacs-devel@gnu.org; Fri, 03 Feb 2017 10:54:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZgBx-0002r1-3G for emacs-devel@gnu.org; Fri, 03 Feb 2017 10:54:33 -0500 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:37551) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cZgBw-0002q6-P2 for emacs-devel@gnu.org; Fri, 03 Feb 2017 10:54:29 -0500 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Original-Received: from localhost (ip5f5bdfbc.dynamic.kabel-deutschland.de [95.91.223.188]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id 6EF2D179ABE5; Fri, 3 Feb 2017 16:54:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1486137253; bh=hsn77xiDKUGtk/32wHcolx5FRkc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=eIsX3G2DCeZZQdRjYKwGEMVLLoVkXTDxTVnBWx9id29QOpigNybF4LvIRFThfGpsI sNOIRx/OG5hMRElEZqdlkqqwR5O8+CB/KK5P7tvyo+ArZkL8UAeKKe8wgxjvM0+2Rp eQ/sRV8bXDlmaL5mRaB+0RkNbDUHs6kICyKOJfWs= In-Reply-To: <87y3xnnvri.fsf@fastmail.com> (Joakim Jalap's message of "Fri, 03 Feb 2017 16:23:29 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-Received-From: 143.93.54.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211937 Archived-At: Joakim Jalap writes: > Andreas Politz writes: >> Well, imagine your AA-Tree, with <= as relation and where you keep >> inserting 1s and nothing else. How will it look ? > > It will be a bunch of 1s, but balanced, I think... :) and ordered as well. > The problem is when we need to delete one of those nodes which has 1 > as key. Well, you just delete the first node you find, which is the root. Since they are all equal it doesn't matter. > How do we find it? When we're at the root (which also has key 1), do > we go to the right or to the left? Neither, since you already found what your looking for. Yes, its an exaggerated example. > > In the tree I have now, we can find the right node, since even if every > overlay starts and ends at 1, they will still be sorted according to > their address. But if you know the memory address of an overlay, then what are you looking for ? I think its dawning in me what you are talking about. You seem to think of nodes as a distinct entity without any ties to the overlays they are representing ? And then you want to solve the problem of matching an overlay with its corresponding node, by searching for it in the tree. Does that sound familiar ? -ap