[Trove4j-tracker] [ trove4j-Feature Requests-1631704 ] support Sorted{Set, Map}s

[SourceForge.net <no...@so...>]

Feature Requests item #1631704, was opened at 2007-01-09 10:05
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=424685&aid=1631704&group_id=39235

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Research
Status: Open
Priority: 4
Private: No
Submitted By: Jean-Daniel Fekete (jdfekte)
Assigned to: Rob Eden (robeden)
Summary: support Sorted{Set,Map}s 

Initial Comment:
Are SortedSets and Maps for primitive types planned for a futur version?
I would be interested to have them for my InfoVis Toolkit (ivtk.sourceforge.net).

----------------------------------------------------------------------

Comment By: https://www.google.com/accounts ()
Date: 2012-09-03 23:08

Message:
Any updates on this? Do we have one in 3.x version of Trove?

----------------------------------------------------------------------

Comment By: Rob Eden (robeden)
Date: 2008-12-30 11:08

Message:
I'm going to try to do some playing around to see if I can make this
perform well.

----------------------------------------------------------------------

Comment By: Jean-Daniel Fekete (jdfekte)
Date: 2007-01-10 14:02

Message:
Logged In: YES 
user_id=1042961
Originator: YES

A Toolkit for Information Visualization has to maintain data structures in
memory to allow for fast display and filtering. You can think of it as an
in-memory database, except that the tables are column-oriented instead of
row-oriented because adding a new column (attribute) is frequent.
Just like databases, I need to maintain indexes on the contents of my
columns.  Since range queries are very important, having a sorted indexing
is very important too.  Java red-black trees are almost ok except they
don't support duplicate keys and they use objects as keys, not primitive
types.
As you write, not much speedup could be expected but completeness is
important I think. Otherwise, I'd have to do it by myself. The prefuse
toolkit implemented some of it too (prefuse.sf.net in the utils.collections
package) so it really seems useful for lots of people.

----------------------------------------------------------------------

Comment By: Rob Eden (robeden)
Date: 2007-01-10 13:52

Message:
Logged In: YES 
user_id=888530
Originator: NO

I don't think the performance of these would be all that great because a
good deal of array manipulation would have to take place is we implemented
it in a similar manner to the current sets/maps. However, memory usage
would be better because you wouldn't need all the primitive container
objects. Would this fit your purposes?

I'm hesitant because Trove is supposed to be "*High performance*
collections", but this is a frequent request, so I'll think about it, if
people aren't expecting it to be a lot faster. It's hard to beat a linked
list for sorted structures... but the current method is much nicer on the
garbage collector.

Anyway... maybe if you could talk about your goals for such a structure
more it would be helpful.

----------------------------------------------------------------------

Comment By: Rob Eden (robeden)
Date: 2007-01-10 13:05

Message:
Logged In: YES 
user_id=888530
Originator: NO

Moving to feature requests.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=424685&aid=1631704&group_id=39235