>
> 1. Batch tasks processing, especially in concurrent environments, when
> tasks could have different priorities. Sometimes tasks that are stored in a
> queue are processed in batches. Using today's stdlib of Java,
> acquiring such a batch of tasks from collection would be a O(n * log n)
> comple
Hello!
The example you have provided is indeed a workaround. Such a setup indeed
covers most of the problems, nothing I could get from the top of my head
that can't be accomplished using this.
However, there are a few downsides:
1. Obvious performance and memory overhead. I think no elaboration
Hi IP-24 Oleksandr Rotan',
You can use a Map>. This map stores T as the object
equivalence key, and each Collection in this map stores the values known
to be equal to the key. Since map compares keys by equals, any key in the
collection can be used to find the collection in the Map>.
If you want a
Also, after some research, I found that HashMultisets also have some area
of application in image detection and event simulations
вс, 21 апр. 2024 г. в 01:19, ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com>:
> Sorry for duplicate, I accidentally sent last message only to you
>
> вс, 21 апр. 20
Firstly, about queues. As far as I know, priority queue is implemented as
heap, not tree, so things like subQueue doesn't make much sense in this
context.
About popularity: this is indeed not very popular, might even be negligible
outside of sorted multiset (lets adopt java naming conventions for
Biggest use case is definitely when creating different histograms from the
same dataset. Our friends in sci-py land spend A LOT of time doing this.
Our R friends also use this frequently.
I can imagine this bag implementation would not just be good for
Collections, but would play well with the Col
Let me prefix this by saying that I'm a mathematician, so maybe the lingo I
use is a bit different. A multi set has no structure apart from "counting
duplication", just like a set has no structure at all, ordered set **is not
a set** and ordered multi set **is not a multi set**.
With the clarifica
I won't stop you, but remember, you are not the one maintaining the large
number of collection implementations in the JDK. The ones who are may feel
differently. This FAQ gives a good hint of their opinion, even to your
retorts.
On Sat, Apr 20, 2024, 4:44 PM ІП-24 Олександр Ротань <
rotan.olexa...
Concurrent Bag is something like CopyOnWriteArrayList or Vector, don't we
have it already? (I know vectors aren't optimized). THe whole point of the
bag is to store duplicate elements without preserving order, which allows
things like ordered collections. There could be mutable collections for
conc
By "ordered collection" you mean "unordered collection"?
How common is it to actually use a multiset in general? Of course there are
use cases, and there are areas in which it is used a lot, but I don't
believe it is common enough to be part of the std with the one exception of
concurrent bag.
On
I agree with the point made in the FAQ about the popularity of such
problems. That said, I don't think that it is that unpopular to be ignored.
Regarding Map.values(), this is the case, but, In my experience, one of the
main advantages of using TreeMultiset was O(long n) modification
complexity. C
Your Bag suggestion has been asked so frequently that there is an FAQ entry
in the official Java Docs.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
On Sat, Apr 20, 2024 at 4:25 PM ІП-24 Олександр Ротань <
rotan.olexa...@gmail.com> wrote:
In this letter I would like to express some of my thoughts regarding the
potential Multiset interface.
I, personally, have encountered a few situations where such an interface
could come in handy, mostly when I needed an ordered collection that
permits duplicates. That time I used guava`s TreeMult
13 matches
Mail list logo
