Re: generics and arrays and multi-class collections
Hey Daniel, thanks for the elaborate reply.
On 30 sep, 19:08, Daniel Pitts <googlegrou...@coloraura.com> wrote:
Let me guess, you use something like "tempCaptures[playerNumber]"
You could always "wrap" your sets with a more meaningful and specific
class:
class PlayerData {
? ?private Collection<Move> tempCaptures = new HashSet<Move>();
? ?// other player specific data and methods}
Yes I could do that but these two objects exists only during the
execution of some set of methods that use it to communicate results,
it would make no sense to make anything persistent out of it.
You are right that I use playerNumber to index the arrays. Most of
these arrays exist only during the duration of a method call or even a
code block.
And sometimes the overhead is huge. For example, I'm using bitsets to
represent the occupation of a game board.
Why? Did you run out of memory when you did it the other way? Was it
too slow? ?Sometimes programmers (including me) optimize WAY too
soon. ?Most experienced OO programmers will start with using objects
and classes for everything, and then optimize -- with the help of
profiler -- down to using primitives and other hacks.
I'm not using the bitsets as the main representation. I'm using a
Board composed of Fields that probably should contain Stones (now an
int attribute). I'm using the bitsets only as a computational tool,
because creating Sets of Fields would be many many MANY times slower.
I update the bitsets on each move perform and undo, and use them for
territory analysis and such, and to select between different
variations of algorithms that tend to perform better in some
situations and worse in others.
Btw, I find that also to be a major drawback of java enumerations. In
my current project I have a couple of enumerations that I need to
iterate on, but often not on all of the values. So I started using
"for (int i = Player.WHITE.ordinal(); i <= Player.BLACK.ordinal(); i+
+) {}" which caused significant overhead compared to "for (int i =
WHITE; i <= BLACK; i++)"
Why are you dealing with the ordinals at all? That will break things
if you change the order, or add new players. (Also, it sounds more
like an PlayerColor enum, rather than a Player enum)
enum PlayerColor {
? ?White,
? ?Black;
}
for (PlayerColor playerColor: PlayerColor.values()) {
? ?System.out.println(playerColor);
}
I'll never have to change the colors, or the order. Actually its not
Player but Stone, and Stone has WHITE, BLACK, NONE due to the fact
that I don't use Stone objects (may start using them though, but I'd
get field.stone().color instead of field.stone() - there is no other
use for the existance of a Stone object than to hold a color so it
only makes conceptual sense).
An Enum with only two values would indeed allow me to do a foreach on
them, which I need to do a lot.
I also needed to convert one enum constant into another. I couldn't
make them refer to each other at creation time, because when
Direction.N is created, Direction.S does not exist yet. If I create a
method opposite() I get
? ? ? ? Direction opposite() {
? ? ? ? ? ? ? ? return values()[ordinal() ^ 4];
? ? ? ? }
How about:
enum Direction {
? ? NORTH {
? ? ? ? public Direction opposite() {
? ? ? ? ? ?return SOUTH;
? ? ? ? }
? ? },
? ? SOUTH, {
? ? ? ? public Direction opposite() {
? ? ? ? ? ?return NORTH;
? ? ? ? }
? ? },
? ? EAST, {
? ? ? ? public Direction opposite() {
? ? ? ? ? ?return WEST;
? ? ? ? }
? ? },
? ? WEST, {
? ? ? ? public Direction opposite() {
? ? ? ? ? ?return EAST;
? ? ? ? }
? ? },
? ? public abstract Direction opposite();}
Ah! I hadn't thought of that. I had tried to use constructors with
paramters like
NORTH(SOUTH), SOUTH(NORTH), ...
Direction(Direction op) {
this.opposite = op
}
which didn't work.
which is two extra method calls and an array access for a method that
is called zillions of times (well this one isn't, but another one is).
Don't be so obsessed with the underlying mechanics UNTIL it becomes a
problem.
Well, you see, at first I did use Enumerations. For example, the
Direction Enum was used in two methods that in current implementation
take up about 37% of processing time. Then I wanted to know what the
incurred overhead was. I changed the lines
for (Direction d: Direction.values())
into
for (int d = 0; d < 8; d++)
and made sure that the methods called on d also accepted ints.
Then I measured execution times. I found that the performance gain was
significant.
Changing these lines back again just now causes a 15% increase in
execution time. That means that for those methods it meant an increase
of 41% in execution time. 41%!!! (This also entails a call to
ordinal() in getAdjacent()). Granted, the inner loop only contains 13
lines of code, but this is massive overhead. Right now, these methods
comprise a larger part of execution time than they probably will in
the future, but they will only be surpasses by methods that also make
extensive use of these kind of loops. 15% is unacceptable.
Btw, the generated code is this:
Direction arr$[] = Direction.values();
int len$ = arr$.length;
for(int i$ = 0; i$ < len$; i$++)
{
Direction d = arr$[i$];
So the overhead is basically a method call, an array indexing, and two
more method calls in the body of the loop. That's why I don't want
"just a couple of calls" inside any inner loop in this program.
I'm also using the Direction constants to index an adjacency table, to
quickly get the neighbouring fields of a field. Using a table is twice
as fast as calculating the indeces each time. (And Field.getAdjacent()
makes up 17% of processing time). What would you suggest I do? Create
a HashMap that retrieves neighbours based on Directions for each
field? I would expect access times at least to quadruple. So I need
these ordinal values. The order isn't going to change anyway. And I
need the ordinal values of the player colors because I'm not about to
create a Map each time I need an array of 2. (Although the most
efficient special purpose Map might have some advantage because it can
just do
V get(K k) { return k == Color.WHITE ? value1 : value2; }
And then you have the fact that you can't have the enum constants be
part of the namespace of the class that declared the enum, so you end
up using Move.Type.NORMAL instead of Move.NORMAL every freakin time.
Java attempted to do that, how would this work:
class MyClass {
? ?enum Foo { JOE, BOB, CHARLES }
? ?enum Bar { JOSEPH, ROBERT, CHARLES }
? ?public static void handle(Foo foo) {}
? ?public static void handle(Bar bar) {}
}
MyClass.handle(MyClass.CHARLES); // Whoops, ambiguity!
Why would it be the namespace of the owning class anyway, since enums
actually can live on their own:
-- MyEnum.java --
public enum MyEnum {
? ?A, B, C}
-- OtherClass.java --
public class OtherClass {
? ?public MyEnum value = MyEnum.A;
It doesn't have to be default. Just some kind of within-class import
static feature. The reason I can't use static imports is because I
need to distribute the complete source of the program in one file
(it's a bot programming competition). Right now I all have different
files, but to submit I have to junk everything in one file with one
public class. Static imports would only make things worse, because I'd
have to refit every occurence with the class name. (But I could be
wrong. Is there a way to use static imports in one and the same file?)
You usually shouldn't switch on enums, you should use polymorphism
instead. ?
What do you mean?
Anyway, I don't like them too much. Enums in pascal were much nicer.
No they weren't. They were much less OO (which is what you seem to
have a hard time with)
OO isn't the magical solution for every possible situation. At least
with pascal or C enums you could create high performance code.
You could use static imports, but you can't use that? That doesn't
make sense...
Why can't you have player.oppenent()?
enum PlayerColor {
? ?White {
? ? ?public PlayerColor opponent() {
? ? ? ?return Black;
? ? ?}
? ?},
? ?Black {
? ? ?public PlayerColor opponent() {
? ? ? ?return White;
? ? ?}
? ?};
? ?public abstract PlayerColor opponent();
}
PlayerColor player = PlayerColor.Black;
System.out.println(player.opponent());
Yes, now I see that I could. Probably not gonna do it though. I'd win
some nice syntax but lose some performance (albeit small) and I'd have
to write Color.Black.ordinal() all over the place. After tens of
array[Color.Black.ordinal()] = object.get(Color.Black.ordinal()) *
value
array[Color.White.ordinal()] = object.get(Color.White.ordinal()) *
value
I tend to get a bit tired of this syntax.
array[BLACK] = object.get(BLACK) * value
array[WHITE] = object.get(WHITE) * value
Aaah! Don't you just love concise syntax? I do! :) :) :). Uppercase
words within square brackets are just beautiful ;).
I hope this makes sense to you, and that you find it helpful. ?I was
once like you, trying to make sure that my code was as optimized as
possible all the way through. ? I spent more time creating the
program, and the program usually ended up SLOWER and BUGGIER than when
I followed good OO design principals.
Yes it was helpful. It's not like I'm this performance oriented in
every application I write. It's just that this particular program is
very performance sensitive. I think I'm at an disadvantage already
because I use Java, although I tend to profit from the knowhow
embedded in methods such as BitMap.nextSetBit() and Long.bitCount()
and the clear data model. Other than that, I'm simply not familiar
with the FreePascal environment and there's no way I'm gonna use C. I
don't like C ;). And Java is quite nice to program in.
grtz, xen.