|
Author |
Topic: problem modifying arrays (Read 3648 times) |
|
Steve
|
problem modifying arrays
« on: Nov 3rd, 2003, 11:24pm » |
|
Basically what i want to do at the following page http://p5.stevegh.com/recycle/ is after you click on the recycle logo, it turns to noise, then when you hit a key, it check the position of the noise on the screen, and stores a point in an array for every black pixel, then i want these points to ease from their positions to the positions of the tree. as of now there is no ease because when i have the lines(found in step 3): Code:for(int i = 0;i<xTreePos.length;i++){ xDotPos[i] += (xTreePos[i]-xDotPos[i]); } for(int i = 0;i<yTreePos.length;i++){ yDotPos[i] += (yTreePos[i]-yDotPos[i]); } |
| if i put in something like: Code:for(int i = 0;i<xTreePos.length;i++){ xDotPos[i] += (xTreePos[i]-xDotPos[i])/10;//<- dividing here to get an ease effect } for(int i = 0;i<yTreePos.length;i++){ yDotPos[i] += (yTreePos[i]-yDotPos[i])/10;//<- } |
| the points dont end up in the right place, and they dont appear to start from the same place either. if i move the noise to the top right and press a key the new points appear to come from the bottom left. so if anyone knows why this isnt working i would greatly appreciate any help! sidenote if you are going to play with it the recycle.gif should be in the same dir with the pde. thanks! -steve edit: an example of how wierd it acts is at http://p5.stevegh.com/recycle2/ and in that version you can hit 'r' to restart it after the tree is 'formed'
|
« Last Edit: Nov 4th, 2003, 7:29pm by Steve » |
|
|
|
|
Steve
|
Re: problem modifying arrays
« Reply #1 on: Nov 5th, 2003, 12:12pm » |
|
ok heres what i was helped to find out. i didnt think it would have any effect at the time, but because the array of the tree points is exactly 3666 units long, and when the noise gets scanned it varies from 2000-3400, there are points in that array that dont get defined, and when the array goes to get drawn for the first interpolation between the two, some or the points come from 0,0. so how to fix this? ArrayList(), so i create the array length on the fly, however using this with an ease of the point caused the whole thing to be scaled down, oddly, and it's much too slow. so i propose another option but need some help with syntax to do it. say after the points of noise are scanned and stored into the array thats 3666, but actually only holds 2000-3400 points, that i check to see which points are null(i noticed null turns red in p5, but saw no documentation on in here or at java.sun.com), and then remove those points. then find the difference in the length of the tree points array and this array, and disperse the tree points evenly according to this differece. does this sound feasible? anyone else have any suggestions on why when trying to make the values of an ArrayList ease that the whole array is scaled by the ease value, and why its running so slow? thanks =T -steve
|
|
|
|
toxi
|
Re: problem modifying arrays
« Reply #2 on: Nov 5th, 2003, 1:05pm » |
|
you're using int[] arrays again instead of float[] to store the pixel coordinates. because of that the end result of the interpolation doesn't yield correct values due to all the rounding errors on the way. you had the same problem in a previous thread. also, if you haven't got enough entries (less than 3666) from parsing the noise image, just fill up the list with random points and you don't have to worry about any "special cases" finally, you can slightly speed up the line: xDotPos[i] += (xTreePos[i]-xDotPos[i])/10; by replacing the division by 10 with a multiply *0.1 xDotPos[i] += (xTreePos[i]-xDotPos[i])*0.1;
|
« Last Edit: Nov 5th, 2003, 1:07pm by toxi » |
|
http://toxi.co.uk/
|
|
|
Steve
|
Re: problem modifying arrays
« Reply #3 on: Nov 5th, 2003, 6:11pm » |
|
perfect! thanks that makes sense now.
|
|
|
|
mflux
|
Re: problem modifying arrays
« Reply #4 on: Nov 6th, 2003, 12:19pm » |
|
Toxi: why is division slower than multiplication of a decimal?
|
|
|
|
toxi
|
Re: problem modifying arrays
« Reply #5 on: Nov 6th, 2003, 2:22pm » |
|
mike, that's because even todays CPU's have a harder time with division than with the other calculation modes due to a lack of fast division algorithms known. remember that chips are made of millions of logical circuits only executing binary logic operations like AND, OR, NOT, XOR. everything you want the machine to do is ultimately broken down into such basic constructs. for calculating tasks the beauty is, you often don't need all four basic modes of addition, substraction, multiplication and division - you can express most things with addition and multiplication only. and even multiplication is handled via additions internally. there're many algorithms for doing this. eg. a very CPU friendly version is the russian pesant multiplication. it's "friendly" because it's only based on doubling and halfing numbers, something which can be easily (or in other words "fast"!) executed by the chip as multiplication and division by factors of 2 can be considered special cases. without going into too much detail now (a tutorial about this is in preparation) shifting an integer number one bit to the left equals the number times 2, while a 1bit right shift equals a division by 2. again, note though, this is only true for integers. floats are stored in a totally different format, a trade off between higher precision and less CPU friendlyness. this in short explains why integer math is generally faster and why you should avoid floats for timecritical tasks (although the difference is quite small when using floats wisely). from a speed point of view, numbers of the type "double" and "long" are the worst (at least on current 32bit machines). they're actually 64bit long and have to be processed in two halves/steps. here's a quick test script to see the difference: Code:float x=10000,y; double xd=10000,yd; int xi=10000,yi; int iter=100000000; // double division int t0=millis(); for(int i=0; i<iter; i++) yd=xd/2.0; println("double y=x/2 : "+(millis()-t0)+"ms"); // double multiply t0=millis(); for(int i=0; i<iter; i++) yd=xd*0.5; println("double y=x*0.5 : "+(millis()-t0)+"ms"); // double multiply t0=millis(); for(int i=0; i<iter; i++) yd=xd+2; println("double y=x+2 : "+(millis()-t0)+"ms"); // float division t0=millis(); for(int i=0; i<iter; i++) y=x/2; println("float y=x/2 : "+(millis()-t0)+"ms"); // float multiply t0=millis(); for(int i=0; i<iter; i++) y=x*0.5f; println("float y=x*0.5 : "+(millis()-t0)+"ms"); // float addition t0=millis(); for(int i=0; i<iter; i++) y=x+2; println("float y=x+2 : "+(millis()-t0)+"ms"); // int division t0=millis(); for(int i=0; i<iter; i++) yi=xi/2; println("int y=x/2 : "+(millis()-t0)+"ms"); // int multiply t0=millis(); for(int i=0; i<iter; i++) yi=xi*2; println("int y=x*2 : "+(millis()-t0)+"ms"); // int addition t0=millis(); for(int i=0; i<iter; i++) yi=xi+2; println("int y=x+2 : "+(millis()-t0)+"ms"); // int bitshift right t0=millis(); for(int i=0; i<iter; i++) yi=xi>>1; println("int y=x>>1 : "+(millis()-t0)+"ms"); // int bitshift left t0=millis(); for(int i=0; i<iter; i++) yi=xi<<1; println("int y=x<<1 : "+(millis()-t0)+"ms"); |
| the results on my machine are: double y=x/2 : 2073ms double y=x*0.5 : 210ms double y=x+2 : 351ms float y=x/2 : 1211ms float y=x*0.5 : 211ms float y=x+2 : 200ms int y=x/2 : 310ms int y=x*2 : 171ms int y=x+2 : 150ms int y=x>>1 : 170ms int y=x<<1 : 170ms even though the difference between float and int multiplication seems small, also remember that an animation running at 30 fps only has about 33 milliseconds to prepare and render a frame, but it also has to share this time with other processes running... with interactive projects, writing non-optimized code can, in extreme cases, spoil an entire concept/idea if the response from the programme is too sluggish for the user to accept (not even talking about enjoying!). so even though the above points seem less essential knowledge & very geeky, i always consider them as very important for my own work. ..and i shall stop myself from typing even more at this point...
|
http://toxi.co.uk/
|
|
|
mflux
|
Re: problem modifying arrays
« Reply #6 on: Nov 6th, 2003, 11:39pm » |
|
Thanks Toxi! That is very helpful to know. I've been wanting to ask how fast and well Processing handles floats vs ints. My highschool programs were written using doubles and the programs were horrendously slow. I've learned since to use ints however, because Java is very draconian about variable conversion, it becomes very tedious to convert ints into floats every other command I write. Does converting floats to ints take a lot of time? Often times I find that I need my ints to become floats temporarily for a calculation, but I'm afraid to cast my ints as floats because I'm assuming that that operation takes some time, and the amount of converting I'm using is so much that I might as well just use floats to begin with! Should I not worry about variable casting and just use ints in as many places as I can spare?
|
|
|
|
|