Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9450 > unrolled thread

iteration blues

Back to article view | Back to comp.lang.java.programmer

Contents

  iteration blues bob <bob@coolgroups.com> - 2011-11-03 08:37 -0700
    Re: iteration blues Knute Johnson <nospam@knutejohnson.com> - 2011-11-03 08:51 -0700
      Re: iteration blues Lew <lewbloch@gmail.com> - 2011-11-03 09:32 -0700
        Re: iteration blues Arne Vajhøj <arne@vajhoej.dk> - 2011-11-04 21:00 -0400
          Re: iteration blues spk <jhic@speak.invalid> - 2011-11-05 07:48 -0400
    Re: iteration blues Henk van Voorthuijsen <voorth@xs4all.nl> - 2011-11-03 09:31 -0700
      Re: iteration blues Lew <lewbloch@gmail.com> - 2011-11-03 13:50 -0700
        Re: iteration blues Henk van Voorthuijsen <voorth@xs4all.nl> - 2011-11-04 08:07 -0700
      Re: iteration blues Arne Vajhøj <arne@vajhoej.dk> - 2011-11-04 21:02 -0400
    Re: iteration blues Roedy Green <see_website@mindprod.com.invalid> - 2011-11-03 10:08 -0700
    Re: iteration blues Travers Naran <tnaran@gmail.com> - 2011-11-03 22:22 -0700
    Re: iteration blues Robert Klemme <shortcutter@googlemail.com> - 2011-11-04 10:34 +0100
      Re: iteration blues Lew <lewbloch@gmail.com> - 2011-11-04 10:46 -0700
        Re: iteration blues Robert Klemme <shortcutter@googlemail.com> - 2011-11-04 23:55 +0100
          Re: iteration blues Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-04 21:06 -0400
          Re: iteration blues Lew <lewbloch@gmail.com> - 2011-11-04 20:30 -0700
          Re: iteration blues bob <bob@coolgroups.com> - 2011-11-05 12:40 -0700
            Re: iteration blues Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 16:14 -0400
              Re: iteration blues Lew <lewbloch@gmail.com> - 2011-11-05 13:41 -0700
      Re: iteration blues bob <bob@coolgroups.com> - 2011-11-04 13:42 -0700

#9450 — iteration blues

So, I wrote this code for some particle effects:

package com.coolfone.particles;

import java.util.Iterator;
import java.util.Vector;

import javax.microedition.khronos.opengles.GL10;

public class FireManager {
	static Vector<Particle> particles = new Vector<Particle>();

	public static void startfire(float x, float y) {
		for (int ctr = 0; ctr < 100; ctr++) {
			Particle p = new Particle();
			p.x = (float) (x + Math.random()-.5);
			p.y = (float) (y + Math.random()-.5);
			p.dx = (float) (Math.random()-.5)/4f;
			p.dy = (float) (Math.random()-.5)/4f;
			p.timeleft = (int) (Math.random() * 50 + 50);
			particles.add(p);
		}
	}

	public static void burnfire() {
		Iterator<Particle> i = particles.iterator();
		Vector<Particle> removelist = new Vector<Particle>();
		while (i.hasNext()) {
			Particle p = i.next();
			p.move();
			p.timeleft--;
			if (p.timeleft == 0) removelist.add(p);

		}
		particles.removeAll(removelist);

	}

	public static void drawfire(GL10 gl) {
		Iterator<Particle> i = particles.iterator();
		while (i.hasNext()) {
			Particle p = i.next();
			p.draw(gl);
		}
	}

}

I'm concerned about inefficiency in the burnfire function.  Does
anyone know how to rewrite this quickly if particles was a linked
list?  The main issue is that I'm not sure if removing items during
iteration messes up the iterator.

[toc] | [next] | [standalone]

#9451

On 11/3/2011 8:37 AM, bob wrote:
> So, I wrote this code for some particle effects:
>
> package com.coolfone.particles;
>
> import java.util.Iterator;
> import java.util.Vector;
>
> import javax.microedition.khronos.opengles.GL10;
>
> public class FireManager {
> 	static Vector<Particle>  particles = new Vector<Particle>();
>
> 	public static void startfire(float x, float y) {
> 		for (int ctr = 0; ctr<  100; ctr++) {
> 			Particle p = new Particle();
> 			p.x = (float) (x + Math.random()-.5);
> 			p.y = (float) (y + Math.random()-.5);
> 			p.dx = (float) (Math.random()-.5)/4f;
> 			p.dy = (float) (Math.random()-.5)/4f;
> 			p.timeleft = (int) (Math.random() * 50 + 50);
> 			particles.add(p);
> 		}
> 	}
>
> 	public static void burnfire() {
> 		Iterator<Particle>  i = particles.iterator();
> 		Vector<Particle>  removelist = new Vector<Particle>();
> 		while (i.hasNext()) {
> 			Particle p = i.next();
> 			p.move();
> 			p.timeleft--;
> 			if (p.timeleft == 0) removelist.add(p);
>
> 		}
> 		particles.removeAll(removelist);
>
> 	}
>
> 	public static void drawfire(GL10 gl) {
> 		Iterator<Particle>  i = particles.iterator();
> 		while (i.hasNext()) {
> 			Particle p = i.next();
> 			p.draw(gl);
> 		}
> 	}
>
> }
>
> I'm concerned about inefficiency in the burnfire function.  Does
> anyone know how to rewrite this quickly if particles was a linked
> list?  The main issue is that I'm not sure if removing items during
> iteration messes up the iterator.

while (i.hasNext()) {
 > 			Particle p = i.next();
 > 			p.move();
 > 			p.timeleft--;

             while (--p.timeleft >= 0)
                 p.remove();

 > 			if (p.timeleft == 0) removelist.add(p);


I have a game at http://rabbitbrush.frazmtn.com/asteroids.html that 
demonstrates this code.  I think it is plenty quick for the type of 
animation that is being done.  See the source code on the link at the 
bottom of the page.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#9453

Knute Johnson wrote:
> bob wrote:
>> So, I wrote this code for some particle effects:
>>
>> package com.coolfone.particles;
>>
>> import java.util.Iterator;
>> import java.util.Vector;
>>
>> import javax.microedition.khronos.opengles.GL10;
>>
>> public class FireManager {
>> 	static Vector<Particle>  particles = new Vector<Particle>();

PLEASE DO NOT INDENT WITH THE TAB CHARACTER FOR USENET!

>> 	public static void startfire(float x, float y) {
>> 		for (int ctr = 0; ctr<  100; ctr++) {
>> 			Particle p = new Particle();
>> 			p.x = (float) (x + Math.random()-.5);
>> 			p.y = (float) (y + Math.random()-.5);
>> 			p.dx = (float) (Math.random()-.5)/4f;
>> 			p.dy = (float) (Math.random()-.5)/4f;
>> 			p.timeleft = (int) (Math.random() * 50 + 50);
>> 			particles.add(p);
>> 		}
>> 	}
>>
>> 	public static void burnfire() {
>> 		Iterator<Particle>  i = particles.iterator();
>> 		Vector<Particle>  removelist = new Vector<Particle>();
>> 		while (i.hasNext()) {
>> 			Particle p = i.next();
>> 			p.move();
>> 			p.timeleft--;
>> 			if (p.timeleft == 0) removelist.add(p);
>>
>> 		}
>> 		particles.removeAll(removelist);
>>
>> 	}
>>
>> 	public static void drawfire(GL10 gl) {
>> 		Iterator<Particle>  i = particles.iterator();
>> 		while (i.hasNext()) {
>> 			Particle p = i.next();
>> 			p.draw(gl);
>> 		}
>> 	}
>>
>> }
>>
>> I'm concerned about inefficiency in the burnfire function.  Does

Why use 'Vector', then?  Isn't 'ArrayList' available in that environment?

>> anyone know how to rewrite this quickly if particles was a linked
>> list?  The main issue is that I'm not sure if removing items during
>> iteration messes up the iterator.

Not if you use the iterator, but OTOH removing things from the middle of a large list can be slow, depending on the list implementation.  Wouldn't a 'Set' work for this?
 
> while (i.hasNext()) {
>> 			Particle p = i.next();
>> 			p.move();
>> 			p.timeleft--;
> 
>              while (--p.timeleft >= 0)
>                  p.remove();
> 
>> 			if (p.timeleft == 0) removelist.add(p);
> 
> I have a game at http://rabbitbrush.frazmtn.com/asteroids.html that 
> demonstrates this code.  I think it is plenty quick for the type of 
> animation that is being done.  See the source code on the link at the 
> bottom of the page.

The collections Javadocs indicate the big-O for different operations, generally.  Pick one that has characteristics that match your use case.

I doubt that the synchronization inherent in 'Vector' will tie up too much time, but there's no noeed for it, is there?  Aren't other 'List' implementations available?  In the desktop world 'Vector' has been obsolete since 1998.

1998!

Since Java 1.2!

Thirteen years!  That's 91 years in software years ("dog years").

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9548

On 11/3/2011 12:32 PM, Lew wrote:
> Knute Johnson wrote:
>> bob wrote:
>>> So, I wrote this code for some particle effects:
>>>
>>> package com.coolfone.particles;
>>>
>>> import java.util.Iterator;
>>> import java.util.Vector;
>>>
>>> import javax.microedition.khronos.opengles.GL10;
>>>
>>> public class FireManager {
>>> 	static Vector<Particle>   particles = new Vector<Particle>();

> Why use 'Vector', then?  Isn't 'ArrayList' available in that environment?

I believe ArrayList is available for ME CDC but not for ME CLDC.

But Iterator is also only available for CDC, so ArrayList
should be there.

> I doubt that the synchronization inherent in 'Vector' will tie up too much time, but there's no noeed for it, is there?  Aren't other 'List' implementations available?  In the desktop world 'Vector' has been obsolete since 1998.
>
> 1998!
>
> Since Java 1.2!
>
> Thirteen years!  That's 91 years in software years ("dog years").

For ME it is not so much a matter of years but of profile/config.

Arne

[toc] | [prev] | [next] | [standalone]

#9567

<4eb48ac4$0$286$14726298@news.sunsite.dk>,Arne Vajhøj <arne@vajhoej.dk>,
wrote:

>On 11/3/2011 12:32 PM, Lew wrote:
>> Knute Johnson wrote:
>>> bob wrote:
>>>> So, I wrote this code for some particle effects:
>>>>
>>>> package com.coolfone.particles;
>>>>
>>>> import java.util.Iterator;
>>>> import java.util.Vector;
>>>>
>>>> import javax.microedition.khronos.opengles.GL10;
>>>>
>>>> public class FireManager {
>>>> 	static Vector<Particle>   particles = new Vector<Particle>();
>
>> Why use 'Vector', then?  Isn't 'ArrayList' available in that environment?
>
>I believe ArrayList is available for ME CDC but not for ME CLDC.
>
>But Iterator is also only available for CDC, so ArrayList
>should be there.
>
>> I doubt that the synchronization inherent in 'Vector' will tie up too much time, but there's no noeed for it, is there?  Aren't other 'List' implementations available?  In the desktop world 'Vector' has been obsolete since 1998.
>>
>> 1998!
>>
>> Since Java 1.2!
>>
>> Thirteen years!  That's 91 years in software years ("dog years").
>
>For ME it is not so much a matter of years but of profile/config.
>
>Arne
>
how come seen to brains fallow sense?
Derbyshire codes yo ass. Period [hic]

[toc] | [prev] | [next] | [standalone]

#9452

On Nov 3, 4:37 pm, bob <b...@coolgroups.com> wrote:
> So, I wrote this code for some particle effects:
>
> package com.coolfone.particles;
>
> import java.util.Iterator;
> import java.util.Vector;
>
> import javax.microedition.khronos.opengles.GL10;
>
> public class FireManager {
>         static Vector<Particle> particles = new Vector<Particle>();
>
>         public static void startfire(float x, float y) {
>                 for (int ctr = 0; ctr < 100; ctr++) {
>                         Particle p = new Particle();
>                         p.x = (float) (x + Math.random()-.5);
>                         p.y = (float) (y + Math.random()-.5);
>                         p.dx = (float) (Math.random()-.5)/4f;
>                         p.dy = (float) (Math.random()-.5)/4f;
>                         p.timeleft = (int) (Math.random() * 50 + 50);
>                         particles.add(p);
>                 }
>         }
>
>         public static void burnfire() {
>                 Iterator<Particle> i = particles.iterator();
>                 Vector<Particle> removelist = new Vector<Particle>();
>                 while (i.hasNext()) {
>                         Particle p = i.next();
>                         p.move();
>                         p.timeleft--;
>                         if (p.timeleft == 0) removelist.add(p);
>
>                 }
>                 particles.removeAll(removelist);
>
>         }
>
>         public static void drawfire(GL10 gl) {
>                 Iterator<Particle> i = particles.iterator();
>                 while (i.hasNext()) {
>                         Particle p = i.next();
>                         p.draw(gl);
>                 }
>         }
>
> }
>
> I'm concerned about inefficiency in the burnfire function.  Does
> anyone know how to rewrite this quickly if particles was a linked
> list?  The main issue is that I'm not sure if removing items during
> iteration messes up the iterator.

all Vectors should be LinkedLists, I think. Since you're only adding
to the end of the list or terating over it, performance shouldn't be
an issue.

BTW, while loops over an iterator are obsolete since Java 1.5 came
out.
Consider using the enhanced for loop:
  public static void drawfire(GL10 gl) {
    for ( Particle p: particles ) {
      p.draw(gl);
    }
  }

No need to expose the iterator anymore...

[toc] | [prev] | [next] | [standalone]

#9464

Henk van Voorthuijsen wrote:
> bob wrote:
>> So, I wrote this code for some particle effects:
>>
>> package com.coolfone.particles;
>>
>> import java.util.Iterator;
>> import java.util.Vector;
>>
>> import javax.microedition.khronos.opengles.GL10;
>>
>> public class FireManager {
>>         static Vector<Particle> particles = new Vector<Particle>();
>> ... [snip]
>>         public static void drawfire(GL10 gl) {
>>                 Iterator<Particle> i = particles.iterator();
>>                 while (i.hasNext()) {
>>                         Particle p = i.next();
>>                         p.draw(gl);
>>                 }
>>         }
>>
>> }
>>
>> I'm concerned about inefficiency in the burnfire function.  Does

Why?  What do your measurements tell you?  What is not working because of the time this method takes?

>> anyone know how to rewrite this quickly if particles was a linked
>> list?  The main issue is that I'm not sure if removing items during
> > iteration messes up the iterator.
> 
> all Vectors should be LinkedLists, I think. Since you're only adding
> to the end of the list or terating over it, performance shouldn't be
> an issue.
> 
> BTW, while loops over an iterator are obsolete since Java 1.5 came
> out.
> Consider using the enhanced for loop:
>   public static void drawfire(GL10 gl) {
>     for ( Particle p: particles ) {
>       p.draw(gl);
>     }
>   }
> 
> No need to expose the iterator anymore...

That is not true.  There are all kinds of scenarios that require one to expose the iterator.  It looks like the OP's scenario, for one, requires him to expose the iterator.

the issue is removal of items from the list as each is processed.  If your algorithm is (pseudocoded):

  for each item in collection
    process item
    delete item from collection

you will need the iterator.  If your algorithm is:

  for each item in collection
    process items
  empty the collection

then you will not need the iterator.

Talking in a single-threaded world here.  I'm not going to delve into concurrency issues yet.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9515

On Nov 3, 9:50 pm, Lew <lewbl...@gmail.com> wrote:
> Henk van Voorthuijsen wrote:
> > bob wrote:
> >> So, I wrote this code for some particle effects:
>
> >> package com.coolfone.particles;
>
> >> import java.util.Iterator;
> >> import java.util.Vector;
>
> >> import javax.microedition.khronos.opengles.GL10;
>
> >> public class FireManager {
> >>         static Vector<Particle> particles = new Vector<Particle>();
> >> ... [snip]
> >>         public static void drawfire(GL10 gl) {
> >>                 Iterator<Particle> i = particles.iterator();
> >>                 while (i.hasNext()) {
> >>                         Particle p = i.next();
> >>                         p.draw(gl);
> >>                 }
> >>         }
>
> >> }
>
> >> I'm concerned about inefficiency in the burnfire function.  Does
>
> Why?  What do your measurements tell you?  What is not working because of the time this method takes?
>
>
>
>
>
>
>
>
>
> >> anyone know how to rewrite this quickly if particles was a linked
> >> list?  The main issue is that I'm not sure if removing items during
> > > iteration messes up the iterator.
>
> > all Vectors should be LinkedLists, I think. Since you're only adding
> > to the end of the list or terating over it, performance shouldn't be
> > an issue.
>
> > BTW, while loops over an iterator are obsolete since Java 1.5 came
> > out.
> > Consider using the enhanced for loop:
> >   public static void drawfire(GL10 gl) {
> >     for ( Particle p: particles ) {
> >       p.draw(gl);
> >     }
> >   }
>
> > No need to expose the iterator anymore...
>
> That is not true.  There are all kinds of scenarios that require one to expose the iterator.  It looks like the OP's scenario, for one, requires him to expose the iterator.
>
> the issue is removal of items from the list as each is processed.  If your algorithm is (pseudocoded):
>
>   for each item in collection
>     process item
>     delete item from collection
>
> you will need the iterator.

Granted. But this was not the case with the OP's code snippet.

 If your algorithm is:
>
>   for each item in collection
>     process items
>   empty the collection
>
> then you will not need the iterator.

Exactly.

[toc] | [prev] | [next] | [standalone]

#9549

On 11/3/2011 12:31 PM, Henk van Voorthuijsen wrote:
> On Nov 3, 4:37 pm, bob<b...@coolgroups.com>  wrote:
>> So, I wrote this code for some particle effects:
>>
>> package com.coolfone.particles;
>>
>> import java.util.Iterator;
>> import java.util.Vector;
>>
>> import javax.microedition.khronos.opengles.GL10;
>>
>> public class FireManager {
>>          static Vector<Particle>  particles = new Vector<Particle>();

> all Vectors should be LinkedLists, I think. Since you're only adding
> to the end of the list or terating over it, performance shouldn't be
> an issue.
>
> BTW, while loops over an iterator are obsolete since Java 1.5 came
> out.
> Consider using the enhanced for loop:
>    public static void drawfire(GL10 gl) {
>      for ( Particle p: particles ) {
>        p.draw(gl);
>      }
>    }
>
> No need to expose the iterator anymore...

Is the enhanced for loop available in ME?

Arne

[toc] | [prev] | [next] | [standalone]

#9455

On Thu, 3 Nov 2011 08:37:39 -0700 (PDT), bob <bob@coolgroups.com>
wrote, quoted or indirectly quoted someone who said :

>import java.util.Vector;

Vectors are obsolete.Use ArrayList.  See
http://mindprod.com/jgloss/arraylist.html

you can iterate over an array list with

for ( Item a : someList );

See http://mindprod.com/jgloss/iterator.html
for how you can insert/delete while iterating.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and 
faster each year, but the focus on money makes software manufacturers 
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore 
ignored. The manufacturer focuses on cheap gimicks like dancing paper 
clips to dazzle naive first-time buyers. The needs of existing 
experienced users are almost irrelevant. I see software rental as the 
best remedy.

[toc] | [prev] | [next] | [standalone]

#9508

On 03/11/2011 8:37 AM, bob wrote:
 >
 >   public static void burnfire() {
 >     Iterator<Particle>  i = particles.iterator();
 >     Vector<Particle>  removelist = new Vector<Particle>();
 >     while (i.hasNext()) {
 >       Particle p = i.next();
 >       p.move();
 >       p.timeleft--;
 >       if (p.timeleft == 0) removelist.add(p);
 >
 >     }
 >     particles.removeAll(removelist);
 >
 >   }
 >
 > I'm concerned about inefficiency in the burnfire function.  Does
 > anyone know how to rewrite this quickly if particles was a linked
 > list?  The main issue is that I'm not sure if removing items during
 > iteration messes up the iterator.

What percentage of elements are removed each loop?

If it's like 1 or 2 out of 1000's, then just your method will be OK.

If you are eliminating like 50% of more per iteration, simply copy the 
value:

ArrayList<Particle> newParticleList = new 
ArrayList<Particle>(particles.size());

for (Particle p : particles) {
   // Process p
   if (p.timeLeft > 0)
     newParticeList.add(p);
}

Another approach would be "buckets".  You create a bucket for each life 
span so you know when you've reached nth iteration, the nth bucket 
particles are done.

Pseudocode:

   ArrayList<ArrayList<Particle>> buckets = new 
ArrayList<ArrayList<Particle>>(MAX_LIFETIME);

   roundRobin =  0;
   for each frame do
     buckets.set(roundRobin, createNewParticles(n));
     animate particles
     roundRobin = (roundRobin + 1) % MAX_LIFETIME;

The reference to the ArrayList<Particle> in slot n should disappear and 
the garbage collector can manage the rest.  If your concerned about 
allocation/deallocation overhead, you can change createNewParticle to 
accept the old array list and let it "refresh" the list reusing not just 
the ArrayList<Particle> but the actual Particle objects themselves.

If the lifetimes are far more random with large gaps between groups of 
extinguishing particles (a sparse array), you could use a 
PriorityQueue<Particle> with a comparitor sorting the particle's age up. 
  Removing extinguished particles is O(log(n)) which is better than 
removing items one at a time from an ArrayList (which is O(n)).

[toc] | [prev] | [next] | [standalone]

#9511

On 11/03/2011 04:37 PM, bob wrote:
> So, I wrote this code for some particle effects:
>
> package com.coolfone.particles;
>
> import java.util.Iterator;
> import java.util.Vector;
>
> import javax.microedition.khronos.opengles.GL10;
>
> public class FireManager {
> 	static Vector<Particle>  particles = new Vector<Particle>();
>
> 	public static void startfire(float x, float y) {
> 		for (int ctr = 0; ctr<  100; ctr++) {
> 			Particle p = new Particle();
> 			p.x = (float) (x + Math.random()-.5);
> 			p.y = (float) (y + Math.random()-.5);
> 			p.dx = (float) (Math.random()-.5)/4f;
> 			p.dy = (float) (Math.random()-.5)/4f;
> 			p.timeleft = (int) (Math.random() * 50 + 50);
> 			particles.add(p);
> 		}
> 	}
>
> 	public static void burnfire() {
> 		Iterator<Particle>  i = particles.iterator();
> 		Vector<Particle>  removelist = new Vector<Particle>();
> 		while (i.hasNext()) {
> 			Particle p = i.next();
> 			p.move();
> 			p.timeleft--;
> 			if (p.timeleft == 0) removelist.add(p);
>
> 		}
> 		particles.removeAll(removelist);
>
> 	}
>
> 	public static void drawfire(GL10 gl) {
> 		Iterator<Particle>  i = particles.iterator();
> 		while (i.hasNext()) {
> 			Particle p = i.next();
> 			p.draw(gl);
> 		}
> 	}
>
> }
>
> I'm concerned about inefficiency in the burnfire function.  Does
> anyone know how to rewrite this quickly if particles was a linked
> list?  The main issue is that I'm not sure if removing items during
> iteration messes up the iterator.

I'm surprised nobody seems to mention Iterator.remove().

public static void burnfire() {
   for (final Iterator<Particle> i = particles.iterator(); i.hasNext();) {
     final Particle p = i.next();
     p.move();
     p.timeleft--;  // Direct access to member, bad!

     if (p.timeleft == 0) {
       iter.remove();
     }
   }
}

This can be used regardless of container type.  Efficiency depends on 
the ratio of removed elements.  If you remove much and do not need 
indexed access (i.e. via List.get(int)) you can use a LinkedList. 
Otherwise use ArrayList as indicated already.  There is no point in 
using Vector these days any more.

And btw, do not be concerned about performance, measure it.  Results may 
be surprising.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#9524

Robert Klemme wrote:
> I'm surprised nobody seems to mention Iterator.remove().

You must have missed:
>> If your algorithm is (pseudocoded): 
>> 
>>   for each item in collection 
>>     process item 
>>     delete item from collection 
>> 
>> you will need the iterator. 

All right, yeah, it *did* require that one be at least minimally familiar with 'java.util.Iterator' to understand exactly why "you will need the iterator", but every Java programmer from beginner onward surely is aware of 'Iterator#remove()', right?  Surely no one calling themselves a Java programmer could be ignorant of such a basic, fundamental, early concept in Java?  Could they?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9539

On 04.11.2011 18:46, Lew wrote:
> Robert Klemme wrote:
>> I'm surprised nobody seems to mention Iterator.remove().
>
> You must have missed:
>>> If your algorithm is (pseudocoded):
>>>
>>> for each item in collection process item delete item from
>>> collection
>>>
>>> you will need the iterator.
>
> All right, yeah, it *did* require that one be at least minimally
> familiar with 'java.util.Iterator' to understand exactly why "you
> will need the iterator", but every Java programmer from beginner
> onward surely is aware of 'Iterator#remove()', right?  Surely no one
> calling themselves a Java programmer could be ignorant of such a
> basic, fundamental, early concept in Java?  Could they?

Well...  Judging from my experience Iterator.remove() seems to be less 
known than the other methods of that interface - although not as much as 
methods (and even the existence) of ListIterator. :-)  I would consider 
this pretty basic knowledge as you did - probably in the same area as 
the ternary operator - but empiricism often proves our assumptions 
wrong. :-)

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#9550

On 11/4/2011 6:55 PM, Robert Klemme wrote:
> On 04.11.2011 18:46, Lew wrote:
>> Robert Klemme wrote:
>>> I'm surprised nobody seems to mention Iterator.remove().
>>
>> You must have missed:
>>>> If your algorithm is (pseudocoded):
>>>>
>>>> for each item in collection process item delete item from
>>>> collection
>>>>
>>>> you will need the iterator.
>>
>> All right, yeah, it *did* require that one be at least minimally
>> familiar with 'java.util.Iterator' to understand exactly why "you
>> will need the iterator", but every Java programmer from beginner
>> onward surely is aware of 'Iterator#remove()', right? Surely no one
>> calling themselves a Java programmer could be ignorant of such a
>> basic, fundamental, early concept in Java? Could they?
>
> Well... Judging from my experience Iterator.remove() seems to be less
> known than the other methods of that interface[...]

     True.  Java's designers ought to have known better than to
bloat an interface with *three* methods.  That's at least one too
many for today's programmers to grasp.  Maybe two too many, or
even more.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9562

Robert Klemme wrote:
> Lew wrote:
> > All right, yeah, it *did* require that one be at least minimally
> > familiar with 'java.util.Iterator' to understand exactly why "you
> > will need the iterator", but every Java programmer from beginner
> > onward surely is aware of 'Iterator#remove()', right?  Surely no one
> > calling themselves a Java programmer could be ignorant of such a
> > basic, fundamental, early concept in Java?  Could they?
> 
> Well...  Judging from my experience Iterator.remove() seems to be less 
> known than the other methods of that interface - although not as much as 
> methods (and even the existence) of ListIterator. :-)  I would consider 
> this pretty basic knowledge as you did - probably in the same area as 
> the ternary operator - but empiricism often proves our assumptions 
> wrong. :-)

Just because ignorance is widespread doesn't mean that it's excusable.  It's basic knowledge whether people bothered to learn their craft or not.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9592

On Nov 4, 3:55 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 04.11.2011 18:46, Lew wrote:
>
>
>
>
>
>
>
>
>
> > Robert Klemme wrote:
> >> I'm surprised nobody seems to mention Iterator.remove().
>
> > You must have missed:
> >>> If your algorithm is (pseudocoded):
>
> >>> for each item in collection process item delete item from
> >>> collection
>
> >>> you will need the iterator.
>
> > All right, yeah, it *did* require that one be at least minimally
> > familiar with 'java.util.Iterator' to understand exactly why "you
> > will need the iterator", but every Java programmer from beginner
> > onward surely is aware of 'Iterator#remove()', right?  Surely no one
> > calling themselves a Java programmer could be ignorant of such a
> > basic, fundamental, early concept in Java?  Could they?
>
> Well...  Judging from my experience Iterator.remove() seems to be less
> known than the other methods of that interface - although not as much as
> methods (and even the existence) of ListIterator. :-)  I would consider
> this pretty basic knowledge as you did - probably in the same area as
> the ternary operator - but empiricism often proves our assumptions
> wrong. :-)
>
> Cheers
>
>         robert
>
> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/

Iterator.remove() is probably not well-known because it's an optional
operation.  Also, I see no easy way to tell if a given container type
supports it other than to try it.

[toc] | [prev] | [next] | [standalone]

#9597

On 11/5/2011 3:40 PM, bob wrote:
>
> Iterator.remove() is probably not well-known because it's an optional
> operation.  Also, I see no easy way to tell if a given container type
> supports it other than to try it.

     The same could be said for List.add().

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#9609

Eric Sosman wrote:
> bob wrote:
>>
>> Iterator.remove() is probably not well-known because it's an optional
>> operation.  Also, I see no easy way to tell if a given container type
>> supports it other than to try it.
>
>      The same could be said for List.add().

Indeed, and for both cases there is a ridiculously easy way to tell if a given container type supports the operation: read the friggin' Javadocs!

If the container doesn't support the operation you need, don't use it.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#9526

On Nov 4, 2:34 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 11/03/2011 04:37 PM, bob wrote:
>
>
>
>
>
>
>
>
>
> > So, I wrote this code for some particle effects:
>
> > package com.coolfone.particles;
>
> > import java.util.Iterator;
> > import java.util.Vector;
>
> > import javax.microedition.khronos.opengles.GL10;
>
> > public class FireManager {
> >    static Vector<Particle>  particles = new Vector<Particle>();
>
> >    public static void startfire(float x, float y) {
> >            for (int ctr = 0; ctr<  100; ctr++) {
> >                    Particle p = new Particle();
> >                    p.x = (float) (x + Math.random()-.5);
> >                    p.y = (float) (y + Math.random()-.5);
> >                    p.dx = (float) (Math.random()-.5)/4f;
> >                    p.dy = (float) (Math.random()-.5)/4f;
> >                    p.timeleft = (int) (Math.random() * 50 + 50);
> >                    particles.add(p);
> >            }
> >    }
>
> >    public static void burnfire() {
> >            Iterator<Particle>  i = particles.iterator();
> >            Vector<Particle>  removelist = new Vector<Particle>();
> >            while (i.hasNext()) {
> >                    Particle p = i.next();
> >                    p.move();
> >                    p.timeleft--;
> >                    if (p.timeleft == 0) removelist.add(p);
>
> >            }
> >            particles.removeAll(removelist);
>
> >    }
>
> >    public static void drawfire(GL10 gl) {
> >            Iterator<Particle>  i = particles.iterator();
> >            while (i.hasNext()) {
> >                    Particle p = i.next();
> >                    p.draw(gl);
> >            }
> >    }
>
> > }
>
> > I'm concerned about inefficiency in the burnfire function.  Does
> > anyone know how to rewrite this quickly if particles was a linked
> > list?  The main issue is that I'm not sure if removing items during
> > iteration messes up the iterator.
>
> I'm surprised nobody seems to mention Iterator.remove().
>
> public static void burnfire() {
>    for (final Iterator<Particle> i = particles.iterator(); i.hasNext();) {
>      final Particle p = i.next();
>      p.move();
>      p.timeleft--;  // Direct access to member, bad!
>
>      if (p.timeleft == 0) {
>        iter.remove();
>      }
>    }
>
> }
>
> This can be used regardless of container type.  Efficiency depends on
> the ratio of removed elements.  If you remove much and do not need
> indexed access (i.e. via List.get(int)) you can use a LinkedList.
> Otherwise use ArrayList as indicated already.  There is no point in
> using Vector these days any more.
>
> And btw, do not be concerned about performance, measure it.  Results may
> be surprising.
>
> Kind regards
>
>         robert

Just what I needed.  Thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web