What is the fast way of getting an index of an element in an array? [duplicate]_问答_开发者

This question already has answers here: How to find the index of an element in an array in Java? (15 answers) Closed 6 years ago.

I was asked this question in an interview. Although the interview was for dot net position, he asked me this question in context to java, because I had mentioned java also in my resume.

How to find the index of an ele开发者_开发技巧ment having value X in an array ?

I said iterating from the first element till last and checking whether the value is X would give the result. He asked about a method involving less number of iterations, I said using binary search but that is only possible for sorted array. I tried saying using IndexOf function in the Array class. But nothing from my side answered that question.

Is there any fast way of getting the index of an element having value X in an array ?

As long as there is no knowledge about the array (is it sorted? ascending or descending? etc etc), there is no way of finding an element without inspecting each one.

Also, that is exactly what indexOf does (when using lists).

How to find the index of an element having value X in an array ?

This would be fast:

int getXIndex(int x){
    myArray[0] = x;
    return 0;
}

A practical way of finding it faster is by parallel processing.

Just divide the array in N parts and assign every part to a thread that iterates through the elements of its part until value is found. N should preferably be the processor's number of cores.

If a binary search isn't possible (beacuse the array isn't sorted) and you don't have some kind of advanced search index, the only way I could think of that isn't O(n) is if the item's position in the array is a function of the item itself (like, if the array is [10, 20, 30, 40], the position of an element n is (n / 10) - 1).

Maybe he wants to test your knowledge about Java.

There is Utility Class called Arrays, this class contains various methods for manipulating arrays (such as sorting and searching)

http://download.oracle.com/javase/6/docs/api/java/util/Arrays.html

In 2 lines you can have a O(n * log n) result:

    Arrays.sort(list); //O(n * log n)
    Arrays.binarySearch(list, 88)); //O(log n)

Puneet - in .net its:

string[] testArray = {"fred", "bill"};
var indexOffset = Array.IndexOf(testArray, "fred");

[edit] - having read the question properly now, :) an alternative in linq would be:

string[] testArray = { "cat", "dog", "banana", "orange" };
int firstItem = testArray.Select((item, index) => new
{
    ItemName = item,
    Position = index

}).Where(i => i.ItemName == "banana")
  .First()
  .Position;

this of course would find the FIRST occurence of the string. subsequent duplicates would require additional logic. but then so would a looped approach.

jim

It's a question about data structures and algorithms (altough a very simple data structure). It goes beyond the language you are using.

If the array is ordered you can get O(log n) using binary search and a modified version of it for border cases (not using always (a+b)/2 as the pivot point, but it's a pretty sophisticated quirk).

If the array is not ordered then... good luck.

He can be asking you about what methods you have in order to find an item in Java. But anyway they're not faster. They can be olny simpler to use (than a for-each - compare - return).

There's another solution that's creating an auxiliary structure to do a faster search (like a hashmap) but, OF COURSE, it's more expensive to create it and use it once than to do a simple linear search.

Take a perfectly unsorted array, just a list of numbers in memory. All the machine can do is look at individual numbers in memory, and check if they are the right number. This is the "password cracker problem". There is no faster way than to search from the beginning until the correct value is hit.

Are you sure about the question? I have got a questions somewhat similar to your question.

Given a sorted array, there is one element "x" whose value is same as its index find the index of that element.

For example:

         //0,1,2,3,4,5,6,7,8,9, 10     
int a[10]={1,3,5,5,6,6,6,8,9,10,11};

at index 6 that value and index are same.

for this array a, answer should be 6.

This is not an answer, in case there was something missed in the original question this would clarify that.

If the only information you have is the fact that it's an unsorted array, with no reletionship between the index and value, and with no auxiliary data structures, then you have to potentially examine every element to see if it holds the information you want.

However, interviews are meant to separate the wheat from the chaff so it's important to realise that they want to see how you approach problems. Hence the idea is to ask questions to see if any more information is (or could be made) available, information that can make your search more efficient.

Questions like:

1/ Does the data change very often?

If not, then you can use an extra data structure.

For example, maintain a dirty flag which is initially true. When you want to find an item and it's true, build that extra structure (sorted array, tree, hash or whatever) which will greatly speed up searches, then set the dirty flag to false, then use that structure to find the item.

If you want to find an item and the dirty flag is false, just use the structure, no need to rebuild it.

Of course, any changes to the data should set the dirty flag to true so that the next search rebuilds the structure.

This will greatly speed up (through amortisation) queries for data that's read far more often than written.

In other words, the first search after a change will be relatively slow but subsequent searches can be much faster.

You'll probably want to wrap the array inside a class so that you can control the dirty flag correctly.

2/ Are we allowed to use a different data structure than a raw array?

This will be similar to the first point given above. If we modify the data structure from an array into an arbitrary class containing the array, you can still get all the advantages such as quick random access to each element.

But we gain the ability to update extra information within the data structure whenever the data changes.

So, rather than using a dirty flag and doing a large update on the next search, we can make small changes to the extra information whenever the array is changed.

This gets rid of the slow response of the first search after a change by amortising the cost across all changes (each change having a small cost).

3. How many items will typically be in the list?

This is actually more important than most people realise.

All talk of optimisation tends to be useless unless your data sets are relatively large and performance is actually important.

For example, if you have a 100-item array, it's quite acceptable to use even the brain-dead bubble sort since the difference in timings between that and the fastest sort you can find tend to be irrelevant (unless you need to do it thousands of times per second of course).

For this case, finding the first index for a given value, it's probably perfectly acceptable to do a sequential search as long as your array stays under a certain size.

The bottom line is that you're there to prove your worth, and the interviewer is (usually) there to guide you. Unless they're sadistic, they're quite happy for you to ask them questions to try an narrow down the scope of the problem.

Ask the questions (as you have for the possibility the data may be sorted. They should be impressed with your approach even if you can't come up with a solution.

In fact (and I've done this in the past), they may reject all your possibile approaches (no, it's not sorted, no, no other data structures are allowed, and so on) just to see how far you get.

And maybe, just maybe, like the Kobayashi Maru, it may not be about winning, it may be how you deal with failure :-)