Good try, but wrong types:

1. import java.util.*;
2.  
3. Integer[] numbers = { 1, 2, 3, 4, 5, 5, 3, 2, 1 };
4. HashSet<Integer> mySet = new HashSet<Integer>(Arrays.asList(numbers));
5. println(mySet);

of course,

I kept trying over'n'over until coming up w/ a solution which results an int[] rather than an Integer[]:

import java.util.*;

int[] numbers = {
  -1, 2, 3, -4, 5, 5, 3, 2, -1
};

Collection<String> noDups = new HashSet( Arrays.asList(str(numbers)) );
Arrays.sort(numbers = int( noDups.toArray(new String[noDups.size()]) ));

println(numbers);
exit();

Now a function snippet to removeDups() from an int[] or float[]: 

import java.util.*;

static int[] numbers = {
  -1, 1<<3, 3, -4, 5, 5, 8, 3, #FFFFFF
};

static float[] fractions = {
  5e3, 13f, -.5, 1./-2, 5000, 13
};

final void setup() {
  numbers = removeDups(numbers);
  println(numbers);
  println();

  fractions = removeDups(fractions);
  println(fractions);

  exit();
}

static final int[] removeDups(int[] values) {
  Collection<String> noDups = new HashSet( Arrays.asList(str(values)) );
  Arrays.sort(values = int( noDups.toArray(new String[noDups.size()]) ));
  return values;
}

static final float[] removeDups(float[] values) {
  Collection<String> noDups = new HashSet( Arrays.asList(str(values)) );
  Arrays.sort(values = float( noDups.toArray(new String[noDups.size()]) ));
  return values;
}

this is an interesting approach and it might be better for me since I will need an int array not an integer at the end. I was working on a similar solution as you have, converting to string than back to int, but mine was much clunkier and not as succinct. 

What would be the reason for setting setup() to final...

Just for the fun of it? 
Its tiny effect is that setup() can't be polymorphized by another class which extends PApplet!
In other words, it's useless in Processing! Just forget about it! 

... and why sort the array?

Well, after removing duplicates, the Array becomes shorter and its previous original order is moot.
So, I've just taken the liberty to present the cleaner result neater yet! 

If you want to avoid Integer then I suggest that you might want to avoid String.

Wow! An uncorrupted removeDup/getUniqueValues() solution!

However, HashSet< String> is just a temporary state.
From a caterpillar to a butterfly (or moth) there's also a cocoon! 

Nice trick to Arrays.sort(), so you only need to check previous index for duplicates! 

One of the things to avoid would be type conversion so {int <> String} and {int <> Integer} these would slow down the algorithm.

The last solution will almost certainly be the fastest and probably the most memory efficient.

thanks guys.

Just to close the case, I've managed to optimize quarks' algorithm!
Mine, although much more "succinct", has so many conversions and generates too much memory allocations!
This time, I've done away the need of a temp[] array. And un[] too!
Just the passed scr[] parameter was enough! Check it out:

import java.util.*;

final static int[] numbers = { 
  -1, 1<<3, 3, -4, 5, 5, 8, 3, #FFFFFF
};

final void setup() {
  int[] result = getUniqueValues_Optimized(numbers);
  println(result);
  exit();
}

static final int[] getUniqueValues_Optimized(int[] src) {
  Arrays.sort(src);
  int counter = 1, len = src.length;

  for (int i = 1; i != len; i++)
    if (src[i] != src[i-1])     src[counter++] = src[i];

  return subset(src, 0, counter);
}

An experimental new one w/ 2 less Array readings. Instead, they are cached into current & previous variables.
Dunno whether it's any faster. Nevertheless, here it comes: 

P.S.: Just be aware that my optimized versions obviously "corrupt" the original passed Array!

import java.util.*;

static int[] numbers = { 
  -1, 1<<3, 3, -4, 5, 5, 8, 3, #FFFFFF
};

final void setup() {
  numbers = getUniqueValues_OptimizedMore(numbers);
  println(numbers);
  exit();
}

static final int[] getUniqueValues_OptimizedMore(int[] src) {
  Arrays.sort(src);
  int counter = 1, len = src.length;

  for (int current, previous = src[0], i = 1; i != len;)
    if ( (current = src[i++]) != previous )
      src[counter++] = previous = current;

  return subset(src, 0, counter);
}

here's another way of removing duplicates which hasn't been mentioned yet:

a look-up-table of booleans is created and the src-array values are used as indices. a flag that is set to true, indicates that the element is a duplicate and therefore can be skipped. this seems to be about 10 times faster, ... basically because no sorting is needed, so the original array remains untouched.

 

1.   import java.util.*;
2.  
3.   public void setup(){
4.    
5.     int[] numbers = new int[20000000];
6.    
7.     randomSeed(1);
8.    
9.     for(int i = 0; i < numbers.length; i++){
10.       numbers[i] = (int)random(-1500,1500);
11.     }
12.    
13.     // version 1: sort array, and skip duplicates.
14.     {
15.       long timer = System.currentTimeMillis();
16.       int[] result = getUniqueValues_1(numbers);
17.       timer = System.currentTimeMillis()-timer;
18.       System.out.println("remove dups "+timer+" ms");
19. //      printArray(result);
20.     }
21.    
22.     // version 2: create a look-up-table to skip duplicates.
23.     {
24.       long timer = System.currentTimeMillis();
25.       int[] result = getUniqueValues_2(numbers, true);
26.       timer = System.currentTimeMillis()-timer;
27.       System.out.println("remove dups "+timer+" ms");
28. //      printArray(result);
29.     }
30.    
31.     exit();
32.   }
33.  
34.   void printArray(int[] a){
35.     for(int i = 0; i < a.length; i++) { print(a[i]+", ");} println("");
36.   }
37.  
38.   // version 1: sort array, and skip duplicates.
39.   int[] getUniqueValues_1(int[] src) {
40.     Arrays.sort(src);
41.     int A=0, B=0, END=src.length;
42.     while (++B < END){
43.       if( src[A] != src[B])
44.         src[++A] = src[B];
45.     }
46.     return Arrays.copyOf(src, A+1);
47.   }
48.  
49.  
50.  
51.   // version 2: create a look-up-table to skip duplicates.
52.   int[] getUniqueValues_2(int src[], boolean return_sorted){
53.     int i, j, len = src.length;
54.    
55.     // get min and max values of source-array to get range.
56.     int max = src[0], min = src[0];
57.     for(i = 1; i < len; i++){
58.       if( src[i] > max) max = src[i];
59.       if( src[i] < min) min = src[i];
60.     }
61.     int range = max-min+1;
62.    
63.     boolean[] flags  = new boolean[range]; // LUT for unique values
64.     int[]     unique = new int[range];     // contains unique values
65.    
66.     // save array-value to "unique" if the corresponding flag is not set yet.
67.     for(i = 0, j = 0; i < len; i++){
68.       int val = src[i];
69.       int lut = val-min;
70.       if( !flags[lut] ){
71.         unique[j++] = val;
72.         flags[lut] = true;
73.       }
74.     }
75.    
76.     unique = Arrays.copyOf(unique, j); // array may be smaller than range
77.    
78.     if(return_sorted) Arrays.sort(unique);
79.    
80.     return unique;
81.   }

If it is desired to mantain the original Array, just use .clone() on it when calling the clean-up! 

final void setup() {
  int[] result = getUniqueValues_OptimizedMore( numbers.clone() );
  
  println(numbers);
  println();
  println(result);
  
  exit();
}

" would using a bitarray instead of boolean array, be in any way faster or are bitarrays sort of obsolete at this point?"
A bit array will save some memory, indeed, but you have to check yourself if the speed is similar: it might be slower because you have to do additional bit manipulations.
A compromise might be to use a byte array: smaller than the boolean array (curiously) but with a weaker semantic, you have to check if the memory gain is worth it.

seems like its JVM dependent what size a boolean actually has:
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

but, as discussed here, if using an array of boolean ...
http://stackoverflow.com/questions/1907318/java-boolean-primitive-type-size
each boolean takes 1 byte. if this is true, it might be the best choice.

But more generally about the method ... I think its the fastest way of removing duplicates in an integer array, but can be a bad choice if the src-array is short, but the range of its values is high. in that case a lot of time and memory is wasted on allocating a big array, while only a view indices are used. on the other hand, if the src-array is big, and the range is small, it is optimal. Another case, if the range of the values is higher than 2^32-1 it wont work at all. So in the end, as always, it depends on the application which algorithm to choose.


edit: you could allocate a huge array of boolean and have a look at the taskmanager to see how much memory it takes. this way you should be able to tell how many bytes are used per boolean.

another idea on how to optimize this:

i think the problems i mentioned above can be "broken up into smaller problems".
 meaning: first determining the full range of values, and then running the method in several passes using each time another subset from the range. this way, huge array can be avoided while having a small extracost of some additional iterations using each time the resulting array from the previous iteration.

actually I ended up switching my strategy to another method from previously stated - and now again I need to sort through large arrays.

If your aim is unique numbers, you should consider using a HashSet<Integer>
from the very beginning if possible.

Another consideration, if you're not gonna use methods provided by class PVector,
it's better to make your own class w/ just 2 field variables. You save lotsa memory this way!

hm, not sure if i understood it 100 %, but i have the feeling this can be done a lot easier, using neither of the methods from above.

you have the original pixel array of the image (actually just indices from 0 to number-of-pixels-1), and you have a list of indices from the contour map (i would either convert the arraylist to an array, or use an array in the first place, by allocating the size in a first pass, an fill it in a second pass).


you could then sort the contour-array which will be fast enough on only 20000 points.
next, in one single loop, you shift all elements of the original array that dont appear in the contour array to
the left, and insert the contour array at the new list end. so the original has the same size,
but is divided in 2 sets, having unique index-values in the first half, and the contour-map-indices in the second half. the comparison can be done in the same loop, similar to quars method.
you do pretty much the same, every time, points get picked from the first half. Depending on how many such "splits" you
do, you have to keep for each one an index pointer.
If this is what you need, it can be done at an interactive framerate instead of seconds.

maybe i missunderstood your inital goal, but probably you get the idea and can use something of it.

That's exactly right.

I am not as familiar with HashSets , so that is why I was avoiding them thus far.

Neither am I! You're the one whom proposed its use from the very beginning! 
I believe a HashSet functions just like an ArrayList, but w/ the overhead feature of silently ignoring
any attempts to store a value which it already has!
That's why your int numbers[] array got any repeated numbers erased when it got converted 1st as a String[],
then to a List<String>, and finally, stored into a HashSet<String>:

Collection<String> noDups = new HashSet( Arrays.asList(str(numbers)) );

Apparently, you don't need repeated values. Thus a HashSet makes everything much easier!

Would there be much memory saving in using an arraylist of PVectors as opposed to an arraylist of float Arrays with 3 variables?

I thought I said it might be better to make a class to store the coordinates as variables,
not 1 Array for each 1 of the coordinates!
I'm not so sure about it. I just know that class PVector is reasonably big,
w/ lots of methods, although only 3 float fields.
So, maybe a class w/ just enough fields to store your coordinate data may save RAM and/or performance.
Of course, in case you don't need to use any PVector's methods!

Neither am I! You're the one whom proposed its use from the very beginning!

 

well yeah, but that's because I was under a misguided impression that a more succinct code meant faster processing, was I wrong.

Wow, thanks a lot guys, I was able to cut down the whole process from 40+s to mere 100ms.