Folks,
Given a set of sorted values (perhaps in a List<T>, SortedList<T,K>, etc.) what's the best way to go about evaluating inequalities (greater-than, less-than, greater-than-or-equal-to, less-than-or-equal-to a given value)? Possible with any of the standard .net types? Or easily coded up? Any pointers are greatly appreciated.
EDIT - of course I'm trying to make this as fast as possible. needs to be highly performant
If you mean something like the good-old lower_bound/upper_bound functions on C++ map<>, AFAIK there's nothing built-in in C#.
On List<T> there's a BinarySearch method implemented, but it works on exact matching only.
Anyway, you can easily implement it by yourself, peraphs using the code in this question as an example:
Is there a Lower Bound function on a SortedList<K ,V>?
Related
When using List.AddRange(), is there any difference in performance between adding a List or Array.
MyList.AddRange(MyArrayof1000ComplexElements);
VS
MyList.AddRange(MyListof1000ComplexElements);
or is there no difference?
Since an array and a list both implement ICollection<T>, it uses the same code.
It resolves to a call to Array.Copy(...)
http://referencesource.microsoft.com/#mscorlib/system/collections/generic/list.cs#e569d850a66a1771#references
There is no difference between List<T> and T[] - AddRange uses the same handling for anything implementing ICollection<T>, which both of those do.
Both Array and List implement the ICollection<T> interface. Therefore, the implementation of List.AddRange that is used will be identical and will offer the same performance.
In the future, you can either test something like this yourself with a simple program using the Stopwatch class for timing or download a tool like JetBrain's dotPeek to inspect the framework code yourself.
This is a more interesting question than some of the comments might suggest.
As it happens, for this specific list/array implementation the answer is: no difference. Both rely on the same collection interface.
But it doesn't have to be that way. If a list is implemented as a doubly-linked list (which it is in many other cases) then appending one list to another is O(1) while appending an array to a list is O(n).
And I would not start by benchmarking to resolve this question. Benchmarking is time-consuming to do well and can easily produce results susceptible to misinterpretation. In this case a careful study of the implementation and the underlying source code (easily available through a .NET disassembler) will answer the question faster. Then benchmark to confirm, if it matters enough.
Please note that the specific O(1) optimisation that applies here is only available if MyListof1000ComplexElements too is a List. If it some kind of enumerator or linked list then the performance will be O(n).
In response to those who have criticised this answer, please note that it has been written with the intention of highlighting that the other answers given are based on a specific interpretation of the question. They fail to point out how narrowly they have interpreted the question and how narrowly their answers apply. Another reader might easily miss the fact that this answer only applies to this specific circumstance if they don't say so. My aim is simply to point out that in many other closely related situations, this is an O(n) operation rather than O(1).
i am developing a data access layer in c# which will retrive data from multiple datasources. And i want to use the same DAL layer for the java version of my project.
i wonder the point that i should care about to achive this. For the first, i want to know which type i should use for returning a list of objects. Should i consider using List, ArrayList or Array in c# to achive an easy way of converting from c# to java?
Thanks.
(From your comments) It doesn't matter what the most common list type is. Your DAL should return a type that suits the needs of the consuming code. If you are just going to port the code from C# to Java then you don't need to think about 'what is the easiest type to convert'. You just need to use the type which most accurately serves your needs in each language.
Don't let 'ease of porting the code' influence your decision. This may unnecessarily distort your code in both places. IMHO it's more valuable for the code to make sense in each place and spend a little extra effort in porting the code. Having said that, the choice of return type in each case is unlikely to change the effort required to port the code very much at all.
Even if you are going to attempt some kind of communication between C# and Java then the return type from your DAL should still be driven by the above logic and your communication layer should do any necessary translation into interoperable types.
It depends on what you are doing:
for custom code, IList<T> interface is ok
For api exposed, ICollection<T> is more suitable.
You could use a List<T>. ArrayList is deprecated. The return type of your method could also be be IEnumerable<T> so that it won't matter which type of collection, array or list you're returning.
The title pretty much sums it up. Now that we have List<T>'s why would anyone want to use an ArrayList instead? The only reason I can think of is if you are forced to use an old version of .NET before List<T> was implemented?
As you said, if for some reason you are stuck with .Net 1.1 then you don't have a choice.
Your question seems to indicate that there is a choice. So then there is no reason to userArrayList. Anything that ArrayList can do, List<T> can do as well, if not better.
Short answer, no. ArrayList was from when .NET didn't support generics. List is the more flexible (generic) way to handle lists. In fact, I don't think Silverlight even supports ArrayLists at all.
ArrayList is mostly for backward compatibility. In a project when there is a deadline, you may have the time to convert everything from ArrayList to generic List.
Another reason is that you may be using a library that is written in .NET 1.1. So you may force to use ArrayList in your code, and most likely convert it to a generic List for easy coding.
However, there are some differences and you may want to read this:
.NET: ArrayList vs List
You said it yourself: backwards compatibility. There's no use for it any more, but it clearly can't be removed from the BCL as it'd break existing code that for whatever reason must be compiled against .NET 1.1.
The only time I've ever used an ArrayList since .Net 2.0 was for use with the built-in My.Settings feature in vb.net, and I've since learned I probably could have shoehorned a generic list in there.
This may be a silly question (with MSDN and all), but maybe some of you will be able to help me sift through amazing amounts of information.
I need to know the specifics of the implementations of common data structures and algorithms in C#. That is, for example, I need to know, say, how Linked Lists are handled and represented, how they and their methods are defined.
Is there a good centralized source of documentation for this (with code), or should I just reconstruct it? Have you ever had to know the specifics of these things to decide what to use?
Regards, and thanks.
Scott Mitchell has a great 6-part article that covers many .NET data structures:
An Extensive Examination of Data Structures
For an algorithmic overview of data structures, I suggest reading the algorithm textbook: "Introduction to Algorithms" by Cormen, et al..
For details on each .NET data structure the MSDN page on that specific class is good.
When all of them fail to address issues, Reflector is always there. You can use it to dig through the actual source and see things for yourself.
If you really want to learn it, try making your own.
Googling for linked lists will give you a lot of hits and sample code to go off of. Wikipedia will also be a good resource.
Depends on the language. Most languages have the very basics now pre-built with them, but that doesn't mean their implementations are the same. The same named object--LinkedList in C# is completely different than the LinkedList in Java or C++. Even the String library is different. C# for instance is known to create a new String object every time you assign a string a new value...this becomes something you learn quickly when it brings your program to a crashing halt when you're working with substrings in C# for the first time.
So the answer to your question is massively complicated because I don't know quite what you're after. If you're just going to be teaching a class what a generic version of these algorithms and data structures are, you can present them without getting into the problems I mentioned above. You'll just need to select, lookup, read about a particular type of implementation of them. Like for LinkedList you need to be able to instantiate the list, destroy the list, copy the list, add to the list somewhere (usually front/back), remove from the list, etc. You could get fancy and add as many methods as you want.
I want to be able to create a fixed size hashmap of say 100 buckets, and if I need to store over 100 items then collisions and overwriting will just have to happen. The hashtable class has a IsFixedSize property however it is readonly.
Am I thinking about this completely wrongly, or is there a solution to this?
Collections in the .NET framework don't allow for a lot of fine-tuning. Although you might find one efficient enough for your needs. Try some viable ones out before optimizing.
If you don't roll your own then you might find a 3rd party alternative that has more fine-grained controls. For example, see The C5 Generic Collection Library
for C# and CLI as a possible start. Check into the various Hash* classes on their documentation page.
If you decide to roll your own then you'll want to implement some of the standard interfaces for collections and/or lists, enumerations, etc so they work as expected with C# foreach and language and .NET features.
You might also take an efficient C++ implementation if you have one and there are ways of using it in C#/.NET. It might take a bit of finagling but there are answers on SO about how to accomplish this kind of thing.