generics and arrays and multi-class collections

Discussion in 'Java' started by xen, Sep 30, 2007.

  1. xen

    xen Guest

    Yo peoples of the earth,

    What is the proper use of generics when you want to use arrays as
    well?
    Is there anybody out there that writes code that does NOT generate
    unchecked warnings?

    For example, java.util.ArrayList uses an array of Object to store its
    elements, and uses a cast (E)elements to retrieve them, which
    generates an unchecked warning. I myself have wanted to use an array
    of generified sets, so I just create a Set[] and assign it to a
    Set<E>[], which generates a warning. I can trim down on the warnings
    so that I only get "unchecked conversion" and "unchecked cast"
    warnings, but it seems I'll have to live with those.

    My last addition was a Map that can store Lists that store different
    classes that are all decendants of a superclass:

    Map<Class<? extends Feature>, List<? extends Feature>> stores;
    stores = new HashMap<Class<? extends Feature>, List<? extends
    Feature>>();

    I want a method that retrieves each store, and creates one if not
    present.

    public <F extends Feature> List<F> getStore(Class<F> c) {
    List<F> L = (List<F>)stores.get(c); // unchecked cast
    if (L == null) {
    L = new ArrayList<F>();
    stores.put(c, L);
    }
    return L;
    }

    The cast generates an unchecked warning.

    Now given
    class Block extends Feature {}
    I can do
    List<Block> = getStore(Block.class);
    which is what I wanted.

    What are your experiences, any advice?

    greetings, xen.
     
    xen, Sep 30, 2007
    #1
    1. Advertising

  2. xen

    Daniel Pitts Guest

    On Sep 29, 5:38 pm, xen <> wrote:
    > Yo peoples of the earth,
    >
    > What is the proper use of generics when you want to use arrays as
    > well?
    > Is there anybody out there that writes code that does NOT generate
    > unchecked warnings?
    >
    > For example, java.util.ArrayList uses an array of Object to store its
    > elements, and uses a cast (E)elements to retrieve them, which
    > generates an unchecked warning. I myself have wanted to use an array
    > of generified sets, so I just create a Set[] and assign it to a
    > Set<E>[], which generates a warning. I can trim down on the warnings
    > so that I only get "unchecked conversion" and "unchecked cast"
    > warnings, but it seems I'll have to live with those.
    >
    > My last addition was a Map that can store Lists that store different
    > classes that are all decendants of a superclass:
    >
    > Map<Class<? extends Feature>, List<? extends Feature>> stores;
    > stores = new HashMap<Class<? extends Feature>, List<? extends
    > Feature>>();
    >
    > I want a method that retrieves each store, and creates one if not
    > present.
    >
    > public <F extends Feature> List<F> getStore(Class<F> c) {
    > List<F> L = (List<F>)stores.get(c); // unchecked cast
    > if (L == null) {
    > L = new ArrayList<F>();
    > stores.put(c, L);
    > }
    > return L;
    > }
    >
    > The cast generates an unchecked warning.
    >
    > Now given
    > class Block extends Feature {}
    > I can do
    > List<Block> = getStore(Block.class);
    > which is what I wanted.
    >
    > What are your experiences, any advice?
    >
    > greetings, xen.


    In my opinion, using Arrays is akin to the "primative obsession" anti-
    pattern. You'd probably be better off using a List<Set<T>> or simply
    List<T>, depending on your needs.

    The little bit of overhead you incur is *far* outweighed by the
    functionality gained.
     
    Daniel Pitts, Sep 30, 2007
    #2
    1. Advertising

  3. xen

    SadRed Guest

    On Sep 30, 9:38 am, xen <> wrote:
    > Yo peoples of the earth,
    >
    > What is the proper use of generics when you want to use arrays as
    > well?
    > Is there anybody out there that writes code that does NOT generate
    > unchecked warnings?
    >
    > For example, java.util.ArrayList uses an array of Object to store its
    > elements, and uses a cast (E)elements to retrieve them, which
    > generates an unchecked warning. I myself have wanted to use an array
    > of generified sets, so I just create a Set[] and assign it to a
    > Set<E>[], which generates a warning. I can trim down on the warnings
    > so that I only get "unchecked conversion" and "unchecked cast"
    > warnings, but it seems I'll have to live with those.
    >
    > My last addition was a Map that can store Lists that store different
    > classes that are all decendants of a superclass:
    >
    > Map<Class<? extends Feature>, List<? extends Feature>> stores;
    > stores = new HashMap<Class<? extends Feature>, List<? extends
    > Feature>>();
    >
    > I want a method that retrieves each store, and creates one if not
    > present.
    >
    > public <F extends Feature> List<F> getStore(Class<F> c) {
    > List<F> L = (List<F>)stores.get(c); // unchecked cast
    > if (L == null) {
    > L = new ArrayList<F>();
    > stores.put(c, L);
    > }
    > return L;
    > }
    >
    > The cast generates an unchecked warning.
    >
    > Now given
    > class Block extends Feature {}
    > I can do
    > List<Block> = getStore(Block.class);
    > which is what I wanted.
    >
    > What are your experiences, any advice?
    >
    > greetings, xen.


    > I'll have to live with those.

    Yes. And the SuppressWarnings annotation may be our only feeble
    solace. Wisdome is "use Java generics only at its shallowest".
    Anything deeper can become confusing and unworkable.
     
    SadRed, Sep 30, 2007
    #3
  4. xen

    Roedy Green Guest

    On Sat, 29 Sep 2007 17:38:06 -0700, xen <> wrote, quoted
    or indirectly quoted someone who said :

    >Is there anybody out there that writes code that does NOT generate
    >unchecked warnings?


    Have a peek inside the source for ArrayList. You will see Sun could
    not do it without suppressing warnings. I get the idea Sun is going
    to redo generics, perhaps throwing out type erasure and dealing with
    embarrassments like this.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Sep 30, 2007
    #4
  5. xen

    Roedy Green Guest

    On Sun, 30 Sep 2007 04:02:20 -0000, Daniel Pitts
    <> wrote, quoted or indirectly quoted
    someone who said :

    >In my opinion, using Arrays is akin to the "primative obsession" anti-
    >pattern. You'd probably be better off using a List<Set<T>> or simply
    >List<T>, depending on your needs.


    To me the mess is generics. It is overly complicated, does not work
    with sterilisation. It OOKS ugly and tacked on as an after thought.

    For more details see http://mindprod.com/jgloss/serialization.html

    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Sep 30, 2007
    #5
  6. xen

    SadRed Guest

    On Sep 30, 1:48 pm, Roedy Green <>
    wrote:
    > On Sat, 29 Sep 2007 17:38:06 -0700, xen <> wrote, quoted
    > or indirectly quoted someone who said :
    >
    > >Is there anybody out there that writes code that does NOT generate
    > >unchecked warnings?

    >
    > Have a peek inside the source for ArrayList. You will see Sun could
    > not do it without suppressing warnings. I get the idea Sun is going
    > to redo generics, perhaps throwing out type erasure and dealing with
    > embarrassments like this.
    > --
    > Roedy Green Canadian Mind Products
    > The Java Glossaryhttp://mindprod.com


    > Have a peek inside the source for
    > ArrayList. You will see Sun could
    > not do it without suppressing warnings.

    What part of the source do you refer?
     
    SadRed, Sep 30, 2007
    #6
  7. xen

    Roedy Green Guest

    On Sat, 29 Sep 2007 22:36:13 -0700, SadRed <>
    wrote, quoted or indirectly quoted someone who said :

    >What part of the source do you refer?


    code like this:

    public <T> T[] toArray(T[] a) {
    if (a.length < size)
    // Make a new array of a's runtime type, but my contents:
    return (T[]) Arrays.copyOf(elementData, size,
    a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
    a[size] = null;
    return a;
    }

    If you write code like that I think you will get warnings.

    It has been a while. I was trying to allocate arrays of the given
    generic type, and was baffled. I used code similar to what I found in
    Sun's collections and to my surprise discovered it generated warning
    messages. I asked about it on the newsgroups and the wise ones
    assured me this was indeed a limitation of Java's genericity design.

    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Sep 30, 2007
    #7
  8. xen

    SadRed Guest

    On Sep 30, 4:08 pm, Roedy Green <>
    wrote:
    > On Sat, 29 Sep 2007 22:36:13 -0700, SadRed <>
    > wrote, quoted or indirectly quoted someone who said :
    >
    > >What part of the source do you refer?

    >
    > code like this:
    >
    > public <T> T[] toArray(T[] a) {
    > if (a.length < size)
    > // Make a new array of a's runtime type, but my contents:
    > return (T[]) Arrays.copyOf(elementData, size,
    > a.getClass());
    > System.arraycopy(elementData, 0, a, 0, size);
    > if (a.length > size)
    > a[size] = null;
    > return a;
    > }
    >
    > If you write code like that I think you will get warnings.
    >
    > It has been a while. I was trying to allocate arrays of the given
    > generic type, and was baffled. I used code similar to what I found in
    > Sun's collections and to my surprise discovered it generated warning
    > messages. I asked about it on the newsgroups and the wise ones
    > assured me this was indeed a limitation of Java's genericity design.
    >
    > --
    > Roedy Green Canadian Mind Products
    > The Java Glossaryhttp://mindprod.com


    Yes. The code you've mentioned does generate an *unchecked* warning.
    Sun has just ignored it just like us. :):)
     
    SadRed, Sep 30, 2007
    #8
  9. xen

    xen Guest

    On 30 sep, 06:02, Daniel Pitts <> wrote:

    >
    > In my opinion, using Arrays is akin to the "primative obsession" anti-
    > pattern. You'd probably be better off using a List<Set<T>> or simply
    > List<T>, depending on your needs.
    >
    > The little bit of overhead you incur is *far* outweighed by the
    > functionality gained.


    The point is that these arrays are static 2-size arrays that I can
    initialize really quick with a

    Set<Move>[] tempCaptures = new HashSet[] {
    new HashSet<Move>(), new HashSet<Move>()
    };

    There's just no point in using a List. I don't need dynamic expansion.
    I don't need to treat it as a Collection, or get default toString()
    functionality, or use any of those nifty java.util.Collections
    operations.

    And sometimes the overhead is huge. For example, I'm using bitsets to
    represent the occupation of a game board. If I use java.util.BitSet, I
    get lots of built-in functionality. But using somebitset.or(someother)
    takes 10(!) times as much time as using primitive bit operations on a
    long, because it has support for bitsets that span more than one long,
    whereas I need only one, and it does some checks to make sure its own
    operations don't corrupt it. Although I could have created my own
    class specially tailored to my needs, even that I haven't done. It
    would have saved me some debugging time, but I just happen to like
    "long neighbours = (occupation[0] | occupation[1]) & f.neighbourSet()"
    and "long available = emptyFields & ~territory[0] & ~territory[1]" and
    "inters[player] |= 1L << i" --- instead of using more elaborate method
    calls, using (BitSet)bs.clone() everytime I need a copy, etc. I find
    my code to be a lot cleaner.

    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++)"

    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];
    }
    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).
    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. I
    also found that when you do a switch on an enum variable, the compiler
    creates a static inner class with an array indexed by Enum.ordinal()
    and filled with 1,2,3,... and then uses these values as labels for the
    cases, because a switch can only use literal case values and an enum
    is composed of objects...

    Anyway, I don't like them too much. Enums in pascal were much nicer.
    The only advantage is that you can call methods on them, and there is
    the type safety, but you only need that if you have complex methods
    that take different kinds of options in seemingly random order. Now I
    have to call Player.opponent(player) each time instead of
    player.opponent(), although player ^ 1 would also work ;). Yeah I
    could use static imports but I can't use that.

    greets, xen
     
    xen, Sep 30, 2007
    #9
  10. xen

    xen Guest

    On 30 sep, 06:29, SadRed <> wrote:

    > Yes. And the SuppressWarnings annotation may be our only feeble
    > solace. Wisdome is "use Java generics only at its shallowest".
    > Anything deeper can become confusing and unworkable.


    Aight, I find it to be the most complex part of the Java language,
    well, the only complex part. I have been trying endlessly to fix some
    generics code that wouldn't compile, until I read a tutorial and
    discovered that what I wanted couldn't be done. I now understand most
    of it, but I wouldn't be surprised if I get bitten by something unseen
    again.

    For example, what exactly are the properties of

    HashMap<Class<? extends Number>, List<? extends Number>>

    This was the only way to get different kinds of (Lists of) Numbers
    into the Map, but when I get() a List, I can't add anything into it,
    unless I cast it, which generates a warning. Well, now I have *some*
    type safety.
     
    xen, Sep 30, 2007
    #10
  11. xen

    Lew Guest

    xen wrote:
    > For example, what exactly are the properties of
    >
    > HashMap<Class<? extends Number>, List<? extends Number>>


    I assume that that is a question, despite the lack of punctuation indicating
    so. The answer is in
    <http://java.sun.com/docs/books/tutorial/java/generics/wildcards.html>

    --
    Lew
     
    Lew, Sep 30, 2007
    #11
  12. xen

    Lew Guest

    Roedy Green wrote:
    >> It has been a while. I was trying to allocate arrays of the given
    >> generic type, and was baffled. I used code similar to what I found in
    >> Sun's collections and to my surprise discovered it generated warning
    >> messages. I asked about it on the newsgroups and the wise ones
    >> assured me this was indeed a limitation of Java's genericity design.


    The rule of thumb is, "Generics and arrays don't mix."

    --
    Lew
     
    Lew, Sep 30, 2007
    #12
  13. xen

    Daniel Pitts Guest

    On Sep 30, 5:45 am, xen <> wrote:
    > On 30 sep, 06:02, Daniel Pitts <> wrote:
    >
    >
    >
    > > In my opinion, using Arrays is akin to the "primative obsession" anti-
    > > pattern. You'd probably be better off using a List<Set<T>> or simply
    > > List<T>, depending on your needs.

    >
    > > The little bit of overhead you incur is *far* outweighed by the
    > > functionality gained.

    >
    > The point is that these arrays are static 2-size arrays that I can
    > initialize really quick with a
    >
    > Set<Move>[] tempCaptures = new HashSet[] {
    > new HashSet<Move>(), new HashSet<Move>()
    > };

    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
    }
    >
    > There's just no point in using a List. I don't need dynamic expansion.
    > I don't need to treat it as a Collection, or get default toString()
    > functionality, or use any of those nifty java.util.Collections
    > operations.

    For an array that is ALWAYS two sized, I agree, you probably don't
    need a Collection of any sort (unless the Java API finally adds a Pair
    type Collection).
    >
    > 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.
    > If I use java.util.BitSet, I
    > get lots of built-in functionality. But using somebitset.or(someother)
    > takes 10(!) times as much time as using primitive bit operations on a
    > long, because it has support for bitsets that span more than one long,
    > whereas I need only one, and it does some checks to make sure its own
    > operations don't corrupt it. Although I could have created my own
    > class specially tailored to my needs, even that I haven't done. It
    > would have saved me some debugging time, but I just happen to like
    > "long neighbours = (occupation[0] | occupation[1]) & f.neighbourSet()"
    > and "long available = emptyFields & ~territory[0] & ~territory[1]" and
    > "inters[player] |= 1L << i" --- instead of using more elaborate method
    > calls, using (BitSet)bs.clone() everytime I need a copy, etc. I find
    > my code to be a lot cleaner.
    >
    > 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 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();
    }
    > 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.

    > 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;
    }




    > I
    > also found that when you do a switch on an enum variable, the compiler
    > creates a static inner class with an array indexed by Enum.ordinal()
    > and filled with 1,2,3,... and then uses these values as labels for the
    > cases, because a switch can only use literal case values and an enum
    > is composed of objects...

    You usually shouldn't switch on enums, you should use polymorphism
    instead. Again, Don't worry so much about under the hood. This level
    of obsession with minutia tends to create terrible design.
    >
    > 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)
    > The only advantage is that you can call methods on them, and there is
    > the type safety, but you only need that if you have complex methods
    > that take different kinds of options in seemingly random order. Now I
    > have to call Player.opponent(player) each time instead of
    > player.opponent(), although player ^ 1 would also work ;). Yeah I
    > could use static imports but I can't use that.

    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());
    >
    > greets, xen


    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.
     
    Daniel Pitts, Sep 30, 2007
    #13
  14. xen

    xen Guest

    Hey Daniel, thanks for the elaborate reply.

    On 30 sep, 19:08, Daniel Pitts <> 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.
     
    xen, Oct 2, 2007
    #14
  15. xen

    Daniel Pitts Guest

    xen wrote:
    > Hey Daniel, thanks for the elaborate reply.
    >
    > On 30 sep, 19:08, Daniel Pitts <> wrote:
    >> 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.


    I'm not against performance optimizations at all, I'm just saying you
    should do it as a last step after you've created the "perfect" design
    (perfect being relative). And you should only do it with the help of
    profiling tools. In any case, it sounds like you're particular problem
    needs optimization. Is there some form of time-limit?

    > 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.



    Java is a lot of fun to program in :). But whats wrong with C? You can
    write really elegant programs in C if you know what you're doing. Gotta
    love function pointers! :)

    Well, good luck on your bot competition.

    Cheers,
    Daniel.

    P.S. Ever heard of AT-Robots? Its a robot simulation game where you pit
    your robot against other programmers' robots.
     
    Daniel Pitts, Oct 2, 2007
    #15
  16. xen

    Roedy Green Guest

    >The rule of thumb is, "Generics and arrays don't mix."

    Except that every Collection inside usually has some sort of array.
    They might not mix, but you have to use them both anyway.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Oct 2, 2007
    #16
  17. xen

    xen Guest

    On Mon, 01 Oct 2007 20:21:17 -0700, Daniel Pitts
    <> wrote:

    >I'm not against performance optimizations at all, I'm just saying you
    >should do it as a last step after you've created the "perfect" design
    >(perfect being relative). And you should only do it with the help of
    >profiling tools. In any case, it sounds like you're particular problem
    >needs optimization. Is there some form of time-limit?


    Yeah, the program has 30 seconds for the entire game, which can last
    for 200 moves, so I have to fit 100 moves in 30 seconds.

    >Java is a lot of fun to program in :). But whats wrong with C? You can
    >write really elegant programs in C if you know what you're doing. Gotta
    >love function pointers! :)


    Well, I haven't finished the book I was reading on C so my opinion
    might not be final, but....

    I don't like the way the variable declarations have their type mixed
    with the variable name, that is, a pointer is not char* p, but char
    *p, and an array of char ptrs is char *p[], and a ptr to an array is
    char (*p)[], but it kinda makes sense because that's also the way
    you're going to use the variable.

    Also, it's stupid that you dereference by *p instead of p* or p^. I
    think that's the main reason they needed to introduce p->field because
    you get pretty tired of writing (*p).field.

    And then there's the lack of nice basic string manipulation.
    Everything is so bloody low-level. It's like you have to make fire
    with firestones when you're used to using matches. String ought to be
    a type, not a bloody pointer to a piece of memory that may or may not
    have a zero somewhere to terminate it.

    It's quite cool that you can set up dynamic 3-dimensional arrays but
    writing the code is a major headache. I've coded in basic, in pascal,
    in assembler and in java, but i'll never code for fun in C, or even
    C++.


    >Well, good luck on your bot competition.


    Thanks.
     
    xen, Oct 2, 2007
    #17
  18. xen

    xen Guest

    Btw,

    If I hadn't been so busy with optimizing my search algorithm, I
    wouldn't have discovered that there was a huge optimization for it
    which was actually quite well known (90% faster), so that now I can
    search at least 5 ply instead of 4 ply, which is still not very much,
    but anyway, it means that I will have less need for feature extraction
    (previously I couldn't even detect some basic 5-move combo's), so my
    design is actually dependant on my search capabilities.

    Now that I can see no further improvements I can start to focus on my
    heuristics.
     
    xen, Oct 2, 2007
    #18
  19. OT: C declaration syntax Re: generics and arrays and multi-classcollections

    xen wrote:
    > On Mon, 01 Oct 2007 20:21:17 -0700, Daniel Pitts
    > <> wrote:

    ....
    >> Java is a lot of fun to program in :). But whats wrong with C? You can
    >> write really elegant programs in C if you know what you're doing. Gotta
    >> love function pointers! :)

    >
    > Well, I haven't finished the book I was reading on C so my opinion
    > might not be final, but....
    >
    > I don't like the way the variable declarations have their type mixed
    > with the variable name, that is, a pointer is not char* p, but char
    > *p, and an array of char ptrs is char *p[], and a ptr to an array is
    > char (*p)[], but it kinda makes sense because that's also the way
    > you're going to use the variable.
    >
    > Also, it's stupid that you dereference by *p instead of p* or p^. I
    > think that's the main reason they needed to introduce p->field because
    > you get pretty tired of writing (*p).field.


    Take a look at cdecl, e.g. http://www.linuxcommand.org/man_pages/cdecl1.html

    On the one hand, it makes writing C declarations relatively easy. On the
    other hand, the fact that such a program exists implies that C
    declaration syntax is confusing.

    Patricia
     
    Patricia Shanahan, Oct 5, 2007
    #19
  20. xen

    xen Guest

    Re: OT: C declaration syntax Re: generics and arrays and multi-class collections

    On Thu, 04 Oct 2007 16:53:02 -0700, Patricia Shanahan <>
    wrote:

    >xen wrote:
    >> I don't like the way the variable declarations have their type mixed
    >> with the variable name, that is, a pointer is not char* p, but char
    >> *p, and an array of char ptrs is char *p[], and a ptr to an array is
    >> char (*p)[], but it kinda makes sense because that's also the way
    >> you're going to use the variable.
    >>

    >Take a look at cdecl, e.g. http://www.linuxcommand.org/man_pages/cdecl1.html
    >
    >On the one hand, it makes writing C declarations relatively easy. On the
    >other hand, the fact that such a program exists implies that C
    >declaration syntax is confusing.
    >
    >Patricia
    >


    My god, I hadn't even imagined that declarations could be so complex.

    void (*signal(int x, void (*y)(int )))(int ) { }

    But I'm sure they can be much, much complexer.
     
    xen, Oct 5, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Willem Oosthuizen
    Replies:
    1
    Views:
    2,793
    Jonathan Bromley
    Jul 9, 2003
  2. Replies:
    2
    Views:
    8,728
    Jim Lewis
    Mar 21, 2006
  3. Doug Poland
    Replies:
    9
    Views:
    742
    VisionSet
    Sep 27, 2003
  4. Nicolai Henriksen

    Old code, collections and generics warning

    Nicolai Henriksen, Nov 8, 2005, in forum: Java
    Replies:
    14
    Views:
    752
    Nicolai Henriksen
    Nov 11, 2005
  5. mutex
    Replies:
    0
    Views:
    219
    mutex
    Jul 27, 2003
Loading...

Share This Page