9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Benjamin Purcell <benjapurcell@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] New Balanced Search Tree Implementation
Date: Mon, 12 Dec 2016 00:40:38 -0600	[thread overview]
Message-ID: <CAAsuYKcQbM0cpYBpYsBpTjSxeAwCqU4KWhHHzSdQjka7z4_s4g@mail.gmail.com> (raw)
In-Reply-To: <CAOgwaMucegZJC6vW=8=3mGJ0iWs0Njr7t5unW7QVayMo0uKHQg@mail.gmail.com>

I'm giving it a lucent public license

On Mon, Dec 12, 2016 at 12:38 AM, Mehmet Erol Sanliturk
<m.e.sanliturk@gmail.com> wrote:
>
>
> On Sun, Dec 11, 2016 at 10:30 PM, Benjamin Purcell <benjapurcell@gmail.com>
> wrote:
>>
>> I have written a binary search tree C library for Plan 9.  It contains
>> implementations of both left leaning red-black trees and AVL trees.
>> In short, you create an AVL tree with
>>
>> Bsttree *t = bstcreate(AVL, cmp);
>>
>> and an LLRB tree with
>>
>> Bsttree *t = bstcreate(LLRB, cmp);
>>
>> Cmp is a comparison function.  All other implementation details are
>> hidden from the user.
>>
>> I intend to replace libavl with this library for the following reasons
>> (details can be found below):
>>
>> 1. You get a choice of BST with a single API.
>> 2. The AVL implementation is much faster.
>> 3. The AVL implementation is smaller and less complicated.
>> 4. The API is easier to use.
>>
>> Item 1. is self-explanatory.
>>
>> Item 2.
>> Measurements of the new AVL implementation against the old one shows
>> that on average:
>> Insertion is 21.9% faster.
>> Deletion is 23.9% faster.
>> Lookup is 14.95% faster.
>> 10 trials were conducted on random keys.  Sequential keys show similar
>> results.
>>
>> Item 3.
>> As for code size, the new AVL implementation plus walk code -- which
>> is shared with the LLRB tree -- comes to 362 source lines of idiomatic
>> C. The old AVL implementation 436 lines.  The old implementation also
>> contains more functions, and calls many of them unnecessarily.
>> Despite the fact that it has more functions, the individual functions
>> themselves are more complicated.
>>
>> Item 4.
>> The AVL implementation's api has the following signatures expressed as
>> abstract types:
>>
>> Avl *(*)(Avltree*, Avl*);
>> Avl *(*)(Avltree*, Avl*, int);
>> Avl *(*)(Avlwalk*);
>> Avltree *(*)(int(*)(Avl*, Avl*));
>> Avlwalk *(*)(Avltree*);
>> void (*)(Avltree*, Avl*, Avl**);
>> void (*)(Avlwalk*);
>>
>> Duplicate signatures have been removed in the above.  The new bst
>> implementation has the following de-duped signatures:
>>
>> Bst *(*)(Bsttree*);
>> Bsttree *(*)(int, int(*cmp)(Bst*, Bst*));
>> Channel *(*)(Bsttree*, Bst*, Bst*, int);
>>
>> but maintains the same functionality.  Which API would you rather use?
>>
>> The code can be found at the following locations:
>>
>> /n/contrib/spew/libbst
>> https://bitbucket.org/spewspews/libbst
>> https://github.com/spewspews/libbst
>>
>> A full man page is include and various tests are included in src/tests
>> including measurements of AVL vs. LLRB, and the new AVL implementation
>> against the old.
>>
>> If there are no objections I would like to remove libavl and add
>> libbst instead.  Libavl has no usages in the source tree.  If anyone tries
>> to compile a libavl program then tough.  There will be a better
>> implementation available and we can always keep it available in
>> contrib or extra.
>>
>> Spew
>
>
>
>
>
> There is no license information file in
>
> https://github.com/spewspews/libbst
>
>
> means , it can not be used in any way  or manner .
>
>
>
> Thank you very much .
>
>
> Mehmet Erol Sanliturk
>
>
>
>
>


  reply	other threads:[~2016-12-12  6:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-12  6:30 Benjamin Purcell
2016-12-12  6:38 ` [9front] " Mehmet Erol Sanliturk
2016-12-12  6:40   ` Benjamin Purcell [this message]
2016-12-12 14:30 ` cinap_lenrek
2016-12-12 15:36   ` Steve Simon
2016-12-12 16:24     ` Benjamin Purcell
2016-12-12 16:32       ` cinap_lenrek
2016-12-12 16:36       ` cinap_lenrek
2016-12-12 17:18         ` Benjamin Purcell
2016-12-12 18:02           ` Benjamin Purcell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAsuYKcQbM0cpYBpYsBpTjSxeAwCqU4KWhHHzSdQjka7z4_s4g@mail.gmail.com \
    --to=benjapurcell@gmail.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).