Re: [Scilab-users] modifying a variable changes the value of another variable!!!
Hi Rafael, thank you for your answer. I'm running the code with the minimum variables required for it (positions, radius, number of spheres). it can be some sort of error generating in the output (or in some internal calculation) of calc_D_superp_dobcel, but I don't think it is roundoff, why would that change when defining a different variable or adding a command with no connection? superp0 and superp1, as you told me to define them, are the same (superp0-superp1=0), so the error is not produced in those lines, it is something less direct. I'm not expert, but I guess what is happenning here is that, using a section of the RAM, the stack, the space where variables are stored, or whatever it is, is sligthly modifying OTHER sections of the RAM or wathever. Some bug of scilab, or maybe it is a common thing in every program but usually goes unnoticed (which would be understandable, it is a 1e-15 error, most of the times it will be not significant). Right after writting this, and remembering some issues like the division by zero... I had an idea (is epiphany too pretencious?), and I ran it on ubuntu... the problem is gone! There is no error under ubuntu. So the problem is in Windows (it is Windows server, I can check Windows Vista in a few days...). the question is: Is it a Windows bug, or a Scilab-for-Windows bug? By the way, the obvious solution for me would not work. I cannot run my simulations in my ubuntu machine, we have the workstation for large calculations so we don't overload our personal computers, and the worstations runs with Windows server... Well, I can test my control system in my ubuntu machine, but not run the real thing... On 28/01/13 21:50, Rafael Guerra wrote: From the code excerpt provided it is difficult to see from where errors of magnitude~=1e-15 might come from. Could they be due to some round-off errors in the function: calc_D_superp_dobcel? Please check the function details. Have you run the code with a clear at the beginning of the program to clean all variables? // Could you please define before your 3rd control system: superp0= superp; // and after your 3rd control system: superp1= superp; printf(%i...delta(superp) = %e, control, max(abs(superp1-superp0)) ) // and tell us what values do you get? Do the errors of 1e-15 magnitude occur and at which control iterations? // Non related to your problem, herebelow are some suggestions, if you will, to make your code more easy to read: //define additional variables to simplify the code: m = int(control/max_mov*20); N = length(sup_2); s = sum(superp); // write: while max(superp)tol control=max_mov // moving control=control+1 to the end of the while loop PS: sumsupant // this variable is not defined in the code excerpt, looks like =sum(superp) Regards, Rafael G. -- View this message in context: http://mailinglists.scilab.org/modifying-a-variable-changes-the-value-of-another-variable-tp4025762p4025819.html Sent from the Scilab users - Mailing Lists Archives mailing list archive at Nabble.com. ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] modifying a variable changes the value of another variable!!!
Hello, Now, if I define another variable, the number of iterations to converge changes! [...] the problem is that this difference propagates exponentially Maybe you could send us a minimal script reproducing the problem? Regards -- Christophe Dang Ngoc Chan Mechanical calculation engineer This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] modifying a variable changes the value of another variable!!!
The algorithm essentially starts with a set of spheres in random positions and in a relatively dense state, and runs an iterative process where the spheres are moved in each iteration in order to reduce the overlaps. The core of the script is more or less like this superp=calc_D_superp_dobcel(pos); //this line uses an external function to calculate a matrix with the overlap between paritcles, defined as superp(i,j)=max(R(i)+R(j)-D(i,j),0) . D(i,j) is the distance between the spheres and R is the radius. pos is a 3-colum matrix containging the coordinates of the position of each sphere control=0;//number of iterationssup_2(int(control/max_mov*20)+1)=sumsupant/max_mov*20; // this defines a third control system as will be described bellow. ** while max(superp)tol // the maximum value of superp controls when the system is considered overlap-free and the algorithm is finished ... // Several lines where the positions of each sphere are modified, acording to the values of the matrix superp ... superp=calc_D_superp_dobcel(pos); //matrix superp is re-calculated with the new positions control=control+1; if controlmax_mov then break; end // control by maximum number of iterations //the following belongs to the third control system: if length(sup_2)==int(control/max_mov*20) then sup_2(int(control/max_mov*20)+1)=sum(superp)/max_mov*20;//** else//** sup_2(int(control/max_mov*20)+1)=sup_2(int(control/max_mov*20)+1) + sum(superp)/max_mov*20; //** end //** if length(sup_2)4.5 then//** if sup_2($-1)0.85*sup_2($-2) sup_2($-2)0.85*sup_2($-3) then break; end //** if sup_2($-1)0.7*sup_2($-2) sup_2($-2)0.7*sup_2($-3) sup_2($-3)0.6*sup_2($-4) then break; end//** end //** end //ends while loop The third control system essentially controls if the overlap is decreasing as the iterations proceed. It defines a new variable, sup_2, that stores the average value of sum(superp) in max_mov/20 iterations. If this average does not decrease fast enough (15% decrease in two or 30%decrease in three consecutive groups of max_mov/20 iterations), it considers that it will not converge and breaks. Now, this third control system seems to be problem. As you can see, non of its lines (marked with ** for more clarity), affects the values of superp (at least, it shouldn´t). But still, the value of superp is modified when I include this control system. The other problem I had was with a similar algorithm, without the third control system, but just adding a pause rigth after the last end. This will also modify the values of superp and the number of iterations. As I said, the error in superp is not important (it is in the order of 1.d-15), but this difference propagates exponentially through the iterations and can significantly modify (like a 30%) the total number of iterations (I was trying to evaluate if the third control really worked, but I couldn´t do it because the algortihm CONVERGES with a different number of iterations...) ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] modifying a variable changes the value of another variable!!!
If the initial position of your sphere are randomly set, it can be normal than you do not have the same number of iteration from one simulation to an other one. can you check using rand(seed,0) to force identical initial points for your various tests. Serge Steer Le 28/01/2013 16:18, Ezequiel Soulé a écrit : The algorithm essentially starts with a set of spheres in random positions and in a relatively dense state, and runs an iterative process where the spheres are moved in each iteration in order to reduce the overlaps. The core of the script is more or less like this superp=calc_D_superp_dobcel(pos); //this line uses an external function to calculate a matrix with the overlap between paritcles, defined as superp(i,j)=max(R(i)+R(j)-D(i,j),0) . D(i,j) is the distance between the spheres and R is the radius. pos is a 3-colum matrix containging the coordinates of the position of each sphere control=0; //number of iterations sup_2(int(control/max_mov*20)+1)=sumsupant/max_mov*20; // this defines a third control system as will be described bellow. ** while max(superp)tol // the maximum value of superp controls when the system is considered overlap-free and the algorithm is finished ... // Several lines where the positions of each sphere are modified, acording to the values of the matrix superp ... superp=calc_D_superp_dobcel(pos); //matrix superp is re-calculated with the new positions control=control+1; if controlmax_mov then break; end// control by maximum number of iterations //the following belongs to the third control system: if length(sup_2)==int(control/max_mov*20) then sup_2(int(control/max_mov*20)+1)=sum(superp)/max_mov*20; //** else//** sup_2(int(control/max_mov*20)+1)=sup_2(int(control/max_mov*20)+1) + sum(superp)/max_mov*20;//** end //** if length(sup_2)4.5 then //** if sup_2($-1)0.85*sup_2($-2)sup_2($-2)0.85*sup_2($-3) then break; end //** if sup_2($-1)0.7*sup_2($-2)sup_2($-2)0.7*sup_2($-3) sup_2($-3)0.6*sup_2($-4) then break; end //** end //** end//ends while loop The third control system essentially controls if the overlap is decreasing as the iterations proceed. It defines a new variable, sup_2, that stores the average value of sum(superp) in max_mov/20 iterations. If this average does not decrease fast enough (15% decrease in two or 30%decrease in three consecutive groups of max_mov/20 iterations), it considers that it will not converge and breaks. Now, this third control system seems to be problem. As you can see, non of its lines (marked with ** for more clarity), affects the values of superp (at least, it shouldn´t). But still, the value of superp is modified when I include this control system. The other problem I had was with a similar algorithm, without the third control system, but just adding a pause rigth after the last end. This will also modify the values of superp and the number of iterations. As I said, the error in superp is not important (it is in the order of 1.d-15), but this difference propagates exponentially through the iterations and can significantly modify (like a 30%) the total number of iterations (I was trying to evaluate if the third control really worked, but I couldn´t do it because the algortihm CONVERGES with a different number of iterations...) ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] modifying a variable changes the value of another variable!!!
Sorry I didn't clarify that: I define the initial random positions, I store them in a variable, say pos_in, and then I call the functions (the different versions) with pos_in as input, so the initial positions are the same in every case. On 28/01/13 14:07, Serge Steer wrote: If the initial position of your sphere are randomly set, it can be normal than you do not have the same number of iteration from one simulation to an other one. can you check using rand(seed,0) to force identical initial points for your various tests. Serge Steer Le 28/01/2013 16:18, Ezequiel Soulé a écrit : The algorithm essentially starts with a set of spheres in random positions and in a relatively dense state, and runs an iterative process where the spheres are moved in each iteration in order to reduce the overlaps. The core of the script is more or less like this superp=calc_D_superp_dobcel(pos); //this line uses an external function to calculate a matrix with the overlap between paritcles, defined as superp(i,j)=max(R(i)+R(j)-D(i,j),0) . D(i,j) is the distance between the spheres and R is the radius. pos is a 3-colum matrix containging the coordinates of the position of each sphere control=0; //number of iterations sup_2(int(control/max_mov*20)+1)=sumsupant/max_mov*20; // this defines a third control system as will be described bellow. ** while max(superp)tol // the maximum value of superp controls when the system is considered overlap-free and the algorithm is finished ... // Several lines where the positions of each sphere are modified, acording to the values of the matrix superp ... superp=calc_D_superp_dobcel(pos); //matrix superp is re-calculated with the new positions control=control+1; if controlmax_mov then break; end// control by maximum number of iterations //the following belongs to the third control system: if length(sup_2)==int(control/max_mov*20) then sup_2(int(control/max_mov*20)+1)=sum(superp)/max_mov*20; //** else//** sup_2(int(control/max_mov*20)+1)=sup_2(int(control/max_mov*20)+1) + sum(superp)/max_mov*20;//** end //** if length(sup_2)4.5 then //** if sup_2($-1)0.85*sup_2($-2)sup_2($-2)0.85*sup_2($-3) then break; end //** if sup_2($-1)0.7*sup_2($-2)sup_2($-2)0.7 span styl e=color:rgb(92,92,92)*sup_2($-3)sup_2($-3)0.6*sup_2($-4) then break; end //** end //** end//ends while loop The third control system essentially controls if the overlap is decreasing as the iterations proceed. It defines a new variable, sup_2, that stores the average value of sum(superp) in max_mov/20 iterations. If this average does not decrease fast enough (15% decrease in two or 30%decrease in three consecutive groups of max_mov/20 iterations), it considers that it will not converge and breaks. Now, this third control system seems to be problem. As you can see, non of its lines (marked with ** for more clarity), affects the values of superp (at least, it shouldn´t). But still, the value of superp is modified when I include this control system. The other problem I had was with a similar algorithm, without the third control system, but just adding a pause rigth after the last end. This will also modify the values of superp and the number of iterations. As I said, the error in superp is not important (it is in the order of 1.d-15), but this difference propagates exponentially through the iterations and can significantly modify (like a 30%) the total number of iterations (I was trying to evaluate if the third control really worked, but I couldn´t do it because the algortihm CONVERGES with a different number of iterations...) ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
