From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-23 11:55:28 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone1.gnilink.net!spamfinder.gnilink.net!nwrddc04.gnilink.net.POSTED!3b3add26!not-for-mail Message-ID: <3CC5ADC0.1090301@bellatlantic.net> From: Alan Reynolds User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) References: <3CB46975.90408@snafu.de> <3CBAFFEE.2080708@snafu.de> <4519e058.0204171036.6f0a7394@posting.google.com> <3CBDD795.4060706@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <3CC1C6B3.6060306@telepath.com> <3CC21747.5000501@telepath.com> <4519e058.0204220534.2eb33730@posting.go <3CC48F34.5A474E0F@boeing.com> <3CC49C50.485AE213@san.rr.com> <3CC4B5C0.4D16077C@acm.org> <3CC4E9DA.E02BE0DA@san.rr.com> <3CC5582A.1080309@bellatlantic.net> <3CC59034.E0E613AB@san.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 23 Apr 2002 18:55:25 GMT NNTP-Posting-Host: 68.47.133.196 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc04.gnilink.net 1019588125 68.47.133.196 (Tue, 23 Apr 2002 14:55:25 EDT) NNTP-Posting-Date: Tue, 23 Apr 2002 14:55:25 EDT Xref: archiver1.google.com comp.lang.ada:23000 Date: 2002-04-23T18:55:25+00:00 List-Id: Hi Darren, It was a tongue in cheek comment. Often creation (or destruction) is not looked at as an operation but can have a significant cost. A lessen I learned using C++. Ted's requirements steer the implementation right at binary trees. A hash table cannot support sorted traversal in O(n) time. Have fun, Al Darren New wrote: > Alan Reynolds wrote: > >>Darren New wrote: >> >>>I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if >>>all the elements hash to the same value) or how you'd guarantee any >>>particular limit on execution time of inserting a value (for example, in >>>the same case). In contrast, a red-black tree is *never* going to see >>>O(N) time in any operation. >>> >> >>Except for creation :) > > > Well, I think you're misunderstanding what O(N) means here. Red-black > trees don't support a "create the whole tree" operation, and inserting a > single element isn't O(N). I know you're likely joking. (Note that if > you include "creation from scratch and filling it with N items", there's > no algorithm possible that's faster than O(N), as you have to at least > look at all the items.) > > The advantage of a red-black tree (or any other search tree) over a hash > is, of course, that the results are sorted, so iterating over it in > order is simple. Implementing a hash version with the same interface as > either a hash or a tree would lose this nice property. > > It's possible that there's a version of one of these data structures > that's even faster, based on array heaps or something, but I don't > remember what they might be. There's also other forms of trees, like AVL > trees, whose properties I also don't remember offhand. >