PROTECTED]]
Sent: 2002 m. gruod?io 6 d. 20:50
To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED]
Subject: RE: [Collections] [SUBMIT] Trie
> -Original Message-
> From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
> Sent: 6 December 2002 17:15
> To: Jakarta Commons Develop
]]
Sent: 2002 m. gruod?io 6 d. 17:26
To: Jakarta Commons Developers List
Subject: Re: [Collections] [SUBMIT] Trie
As a frequent user of Commons-Collections, I can support the usefulness
of a Trie implementation in Collections.
Most algorithms textbooks use Trie as an advanced data structure for
> -Original Message-
> From: Rich Dougherty [mailto:[EMAIL PROTECTED]]
-8<---
> Ok, I'll jump in and level a few criticisms at the interface
> and implementation I submitted. :-)
>
> --- Trie - is it the right name? ---
>
> I must admit, the more I've looked at this, the more
> uncom
> -Original Message-
> From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
> Sent: 6 December 2002 21:22
> To: Jakarta Commons Developers List
> Subject: RE: [Collections] [SUBMIT] Trie
>
>
> > To me, it looks like a map and acts like a map.
>
> You
> > To me, it looks like a map and acts like a map.
>
> You could squeeze it into a SortedMap, although that is also not
> something I would do. The structure is not used for sorting, is it?
> It's used for fast data retrieval. And returning a Set of Map.Entry
> objects would be just horrible, eve
> I do think there is room for negotiation about the exact naming and
> behaviour of the methods in the interface. Returning a Set of
> Map.Entrys seems to be useful, but returning a Trie would be tie closer
> with the SortedMap interface. I haven't got a strong opinion here but
> it would be nic
<[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
> > Sent: 6 December 2002 17:15
> > To: Jakarta Commons Developers List
> > Subject: Re: [Collections] [SUBMIT] Trie
> >
> >
> > Map
> -Original Message-
> From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
> Sent: 6 December 2002 17:15
> To: Jakarta Commons Developers List
> Subject: Re: [Collections] [SUBMIT] Trie
>
>
> Map isn't appropriate for sure. The point of a trie seems to
> be
rom: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 2002 m. gruodþio 6 d. 14:09
> To: [EMAIL PROTECTED]
> Subject: Re: [Collections] [SUBMIT] Trie
>
>
> Thanks Craig. With two possible Jakarta users, we seem to have a
> justification for inclusion.
>
> So, it is now ab
Map isn't appropriate for sure. The point of a trie seems to be that you have a
flexible indexed
key for each entry-- to add all possible keys for each entry would create the overhead
that a trie
avoids.
Think about it this way: what would be the best way to implement
Object get(Object key)
H
ter converted to the int, bit value 0 1 for
binary trie or Patricia etc.
int getElement(int i);
}
/Pranas
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 2002 m. gruodþio 6 d. 14:09
To: [EMAIL PROTECTED]
Subject: Re: [Collections] [SUBMIT] Trie
Tha
Thanks Craig. With two possible Jakarta users, we seem to have a justification for
inclusion.
So, it is now about practical issues. How does the submitted Trie cope for design and
performance. Do we need a String only Trie, a URL Trie, or does the abstracted Trie
submitted work OK?
The big qu
> Would it be useful to have a trie that would index on the tail ends of
> strings in reverse, for supporting quick searches for stuff 'ending in'?
>
> Are there any situations where it would be valuable to index on all
> n-to-last-character subsequences of entries, or would the overhead just
> be
Yes, I definitely think a trie implementation is a good thing to have. I can see
myself maybe
using it on a project coming up. I am interested in gauging the relative performance
of the first
cut that was submitted vs. a purely String-oriented trie. It seems to me from poking
around the
Web t
FWIW, there are at least two Jakarta products that I'm involved in (Tomcat
and Struts) that have exactly the path-mapping use case that was described
for the Trie class. And, conveniently, they both already dependd on
[collections] so it would be very convenient to have Trie added here.
It will b
Message -
From: "Rich Dougherty" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 05, 2002 1:31 AM
Subject: Re: [Collections] [SUBMIT] Trie
> >> I've written an implementation for a trie which I'd like to
> >> contribute
- Original Message -
From: "Stephen Colebourne" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, December 05, 2002 12:13 AM
Subject: Re: [Collections] [SUBMIT] Trie
> Hi,
> I've taken a quick loo
>> I've written an implementation for a trie which I'd like to
>> contribute. I've attached a simple implementation and a test
>> case.
>
> I've taken a quick look at the code here, and that all looks fine.
>
> Unfortunately, I don't really know what I'm looking at! What I mean is
> that I've never
anks.
Stephen
- Original Message -
From: "Rich Dougherty" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 02, 2002 7:36 AM
Subject: [Collections] [SUBMIT] Trie
> Hi
>
> I've written an implementation for a trie which I'd like t
Hi,
> From: "Rich Dougherty" <[EMAIL PROTECTED]>
> Reply-To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Date: Mon, 2 Dec 2002 20:36:13 +1300 (NZDT)
> To: <[EMAIL PROTECTED]>
> Subject: [Collections] [SUBMIT] Trie
>
> Hi
&g
20 matches
Mail list logo
