When I call mydictionary.Add(key, object), can I guarantee that the object is added to the end of the dictionary in the sense that mydictionary.ElementAt(mydictionary.Count - 1) returns that object? I'm asking because I'm used to Java where HashMap doesn't have any order at all.
I'm hoping to use the ordering given by ElementAt as a way of knowing the order in which objects were added to the dictionary without using a separate data structure.
Update: Looks like ElementAt isn't going to be of any use. Is the best way to do this to use a separate data structure to store the ordering that I need?
Thanks
There is no order to a dictionary. The ElementAt method is a linq extension method that iterates over the dictionary using IEnumerable and counts the number of things, there is no relation to the order things were added.
There is a SortedDictionary, which will sort things by key, but will not keep them in the order they were added in.
If the order is really important you could always have two data structures, a list that you add the object to and a dictionary that stores the key to list index mapping. Or put a field inside your object that set from a counter as you add it to the dictionary.
Related
I've got a bunch of ES documents that I'd like to put into "collections". Each document has a unique integer as an ID. Each collection also needs to have a unique integer as an ID.
I need to be able to run queries to get a list of docs in a collection, and easily add an existing doc to a collection.
What would be the most efficient and logical way of approaching this:
An index of collections, which each has an array of document IDs, or
For each document have an array of integers (or a single integer) indicating to which collections it belongs?
Thank you.
I am trying to use an ArrayList that contains custom objects. The array list is sorted. I am using LINQ to objects to search on multiple fields. Will LINQ to objects search use underlying sort, or it will scan through the entire arraylist.
The LINQ extension methods will not take advantage of the underlying sort. These methods are written to work on IEnumerable, and thus cannot assume anything about the underlying collection. From looking at the implementation, some LINQ methods will check if the input is an ICollection and if so call the corresponding method on that (I believe Count() works this way) to possibly avoid doing a linear scan, but in this case there is no way for LINQ to detect that your array is sorted, so it will cannot take advantage of that fact.
Furthermore, if you are doing something like myList.Where(o => o.Prop1 < 2 && o.Prop2 == 3), the Func<> passed to Where() is totally opaque to LINQ, so there's no way that it could figure out which properties are being examined even if it did know that the list was sorted.
I got my lucene index with a field that needs to be sorted on.
I have my query and I can make my Sort object.
If I understand right from the javadoc I should be able to do query.SetSort(). But there seems to be no such method...
Sure I'm missing something vital.
Any suggestions?
There are actually two important points. First, the field must be indexed. Second, pass the Sort object into the overloaded search method.
Last time I looked, the docs didn't do a very good job of pointing out the indexing part, and certainly didn't explain why this is so. It took some digging to find out why.
When a field is sortable, the searcher creates an array with one element for each document in the index. It uses information from the term index to populate this array so that it can perform sorting very quickly. If you have a lot of documents, it can use a lot of memory, so don't make a field sortable unless there is a need.
One more caveat: a sortable field must have no more than one value stored in each field. If there are multiple values, Lucene doesn't know which to use as the sort key.
It looks like the actual method you want is e.g. Searcher.search(Query query, Filter filter, int n, Sort sort). setSort is a method of Sort.
I am looking for an efficient indexed persistent data structure. I typically work in .NET and am aware of FSharp's Map however that implementation and most others I am aware of only provide a single 'index', the left side of the mapping.
Basically here is the scenario
public class MyObject
public int Id { get; }
public int GroupId { get; }
public string Name { get; }
Where the Id of an object will be globally unique set of items added. GroupId may have duplicate values, and I want to be able to query for all values with a matching GroupId and within a GroupId names will be unique but may be duplicated across different GroupId's. This not a situation where I can simply create a composite key of the 3 fields as I need independent access to groups of the items based on particular field values.
I can do this, and have in the past, using dictionaries of dictionaries, which has been recommended in other posts here on STackoverflow...however, I also want the data structure to be
1) Fully Persistent and everything that means
2) efficient in memory - meaning that versions need to share as many nodes as possible
3) efficient in modifcations - I would like it to be fast
I realize that I am asking for quite a bit here but I wanted to ask to avoid even trying to re-invent the wheel if it has already been done.
Thanks
I am not sure why elsewhere, and in existing replies to your question, people recommend to imbricate existing structures. Imbricating structures (maps of maps, maps of lists, dictionaries of dictionaries, ...) only works for two indexes if one is looser than the other (two values having the same index for Index1 implies these two values have the same index for Index2), which is an unnecessary constraint.
I would use a record of maps, as many of them as you want different indexes, and I would maintain the invariant that every value that is present in a map is present in all the others in the same record. Adding a value obviously requires adding it to all maps in the record. Similarly for removal. The invariant can be made impossible to transgress from the outside through encapsulation.
If you worry that the values stored in your data structure would be duplicated, don't. Each map would only contain a pointer. They would all point to the same single representation of the value. Sharing will be as good as it already is with simple single-indexed maps.
Just as you could use a Dictionary of Dictionaries, I expect that e.g. an F# Map of Maps may be what you want, e.g.
Map<int, Map<string, MyObject> > // int is groupid, string is name
maybe? I am unclear if you also need fast access by integer id.
You might also check out Clojure's library; I don't know much about Clojure, but a range of efficient persistent data structures seems to be one of Clojure's strengths.
It seems that you are trying to apply OOP principles to your FP application.
If you think in terms of functions, what is it you are trying to do?
If you use a List, for example, you can just tell it you want to pull all the objects that have a certain group value.
If you need fast access by group you could have a Map of Lists so you can pull up all the objects in a group.
There are different data structures and many functions that work on each, but you should first think about your problem from a functional, not object-oriented, POV.
I got my lucene index with a field that needs to be sorted on.
I have my query and I can make my Sort object.
If I understand right from the javadoc I should be able to do query.SetSort(). But there seems to be no such method...
Sure I'm missing something vital.
Any suggestions?
There are actually two important points. First, the field must be indexed. Second, pass the Sort object into the overloaded search method.
Last time I looked, the docs didn't do a very good job of pointing out the indexing part, and certainly didn't explain why this is so. It took some digging to find out why.
When a field is sortable, the searcher creates an array with one element for each document in the index. It uses information from the term index to populate this array so that it can perform sorting very quickly. If you have a lot of documents, it can use a lot of memory, so don't make a field sortable unless there is a need.
One more caveat: a sortable field must have no more than one value stored in each field. If there are multiple values, Lucene doesn't know which to use as the sort key.
It looks like the actual method you want is e.g. Searcher.search(Query query, Filter filter, int n, Sort sort). setSort is a method of Sort.