remove specific object from ArrayList

[A.J. Côté]

Rob Spoor wrote:Also, if a class like Coordinate is to be used as a map key, make sure it's immutable. Making all fields final is a good first step.

Most importantly, it would allow you to cache the hashcode and always return the same field value. That would be fast indeed ;-)

That's what String.hashCode() does (it caches the value in the hash field):

public int hashCode() {
        int h = hash;
        if (h == 0 && value.length > 0) {
            char val[] = value;

            for (int i = 0; i < value.length; i++) {
                h = 31 * h + val[i];
            }
            hash = h;
        }
        return h;
    }

[Winston Gutkowski]

A.J. Côté wrote:Keep in mind the OP use case; he wants to shuffle the coordinate around. If coordinate had final final fields, he would be much more costly to change the coordinate because he would have to create a new object every time thus offsetting the gains because of the load on the garbage collector...

And this is where micro-optimization can get far too "focused". My old Dell, which finally crapped out on me after 9 years, could create 20,000,000 objects with a couple of private members a second; and it wasn't particularly quick, even for its time.

The great advantage of immutable objects is that they can be cached (probably in some kind of HashMap, like an LRU-Map). And even if that doesn't apply, they can often reuse internal structures (like arrays) in ways that mutable objects can't. I like 'em so much that unless I have an object that really does have a 'state', they're what I choose - even if I can't fully justify my decision - because to me, it just makes sense.

And if you really are into the realm where the difference between a shift or a multiply means life or death, the chances are that Java - fast as it is now - is NOT the right tool.

I guess that makes it 4¢ now, :-)

Winston

[Campbell Ritchie]

Rob Spoor wrote: . . .
1) The method is doubleToLongBits.

I was right when I said I had misspelt it

2) The the cast isn't redundant. All of these operators produce longs since at least one argument is a long.

Doesn't += do a widening and narrowing conversion so the result is widened to a long and then narrowed to an int, so you can use it for a hash code method as long as it is deterministic and predictable. It will work without the cast.

. . .
So your code a bit more readable:. . . .

What makes you think I was writing readable code ? I was trying to show how unreadable the Joshua Bloch version of hashCode is. If you look in a book like Horstmann and Cornell, you find they have a much more readable version:-

@Override
public int hashCode()
{
   int hash = text == null ? 0 : text.hashCode(); // or int hash = Objects.hash(text);
   return hash * THIRTY_ONE + (new Long(l)).hashCode();
}

I had forgotten about Objects#hash; thank you for reminding me. I remember a long time ago you said you had written your own version of some of the Objects class' methods, as did lots of other people.

I shall check my Java7 version of H&C to see whether they use Objects#hash.

[Rob Spoor]

Campbell Ritchie wrote:

   return hash * THIRTY_ONE + (new Long(l)).hashCode();

If this was written in the post Java-5.0 era, this is just awful. Even in Java 5.0 through 7 anybody knows that they should use Long.valueOf(l) instead of new Long(l). Java 8 makes the Long object itself unnecessary.

[Campbell Ritchie]

I shall check that. It may have been copied from older versions of the book before valueOf was available.

[Campbell Ritchie]

I looked in my Java7 edition of H&C, pages 234-236 I think. On page 236bit describes the two Objects class methods.
On page 235 there is an example including + new Double(...).hashCode()
So that code has obviously not been updated since Java5 came out.

[Ted Schrey]

hmmmm.... thanks for all the input! Getting back to an ArrayList.... Would parsing the List with a for-each loop and when the object with specific coordinates are found, add that object to another toBeEmptied List work by emptying the second list? Would the object be deleted from the first list too, since both references are just pointing to the object? Am I understanding Object reference right?

[A.J. Côté]

Ted Schrey wrote:hmmmm.... thanks for all the input! Getting back to an ArrayList.... Would parsing the List with a for-each loop and when the object with specific coordinates are found, add that object to another toBeEmptied List work by emptying the second list? Would the object be deleted from the first list too, since both references are just pointing to the object? Am I understanding Object reference right?

How many Objects will be in your collection?

What is the grid size?

[Ted Schrey]

the grid size is open... determined by parameter. Same for number of Objects. For my current purpose, I'd keep grid between 10x10 and 25x25 with no more than a dozen Objects moving in random directions.

[Ted Schrey]

I just did what I asked about in a short test class, and it didn't work, so no need to respond... clearing the second array did just that and only that... it did not "destroy" the object so the first array apparently still was pointing to it.

[Ted Schrey]

Sorry about this... my test code was bad... I did list2.removeAll(List1), but is should be list1.removeAll(list2) where list 2 is the one created to hold the objects I want removed...and it did work, but I get the feeling from your first inquiry that it must be very inefficient?

[Winston Gutkowski]

Ted Schrey wrote:the grid size is open... determined by parameter. Same for number of Objects. For my current purpose, I'd keep grid between 10x10 and 25x25 with no more than a dozen Objects moving in random directions.

And for a grid of that size, if all you need to know is whether the position is "occupied", I'd definitely consider a BitSet, viz:

private final BitSet grid25x25 = new BitSet(25 x 25);

// convert a coordinate to a bit index
private final boolean bitIndex(int x, int y) {
   return (x * 25) + y;
}

...

// returns true if the grid was updated
public final boolean add(int x, int y) {
   int i = bitIndex(x, y);
   if (grid25x25.get(i)) // if x,y is already occupied...
      return false;
   grid25x25.set(i);
   return true;
}

Not sure if it's what you want, but it gives you an idea of what it can do - and it's VERY fast.
It also has a lot of other neat features - including a clear() method.

HIH

Winston

[Campbell Ritchie]

Because you are working with individual bits there is no need to calculate hash codes. You can set a bit with the | (=bitwise OR) operator and unset it with the bitwise AND operator … & ~0x0001_0000

Note the use of the one's complement operator to convert a number with 1 bit set to a number with only that single bit unset.
~0x0001_0000 is 0xfffe_ffff
It has the same precedence as !b -n and ++n, so much higher than AND.