446,171 Members | 1,037 Online Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

# Loop doesn't behave the way it's supposed to.

 P: n/a Hi folks, a happy new year. I have a little problem with a program I am writing at the moment. A loop doesn't behave the way I'd like to (namely, the "break" is ignored). This is the code in question: ---------------------------------- star[s].planet.orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; for (p=0;pstar[s].orbit_limit) break; }//end for star[s].number_of_orbits = p; ---------------------------------- "orbcount" is a variable of type int which normally has a value between 1 and 20. "star[s].orbit_limit" is an upper limit (type double). The general idea was that upon reaching the limit, the loop ends and "star[s].number_of_orbits" gets the last value of "p". I asked the same question in de.comp.lang.c and the folks there came up with this solution: ---------------------------------- ptr = star[s].planet; e = ptr+orbcount; d = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; while (d<=star[s].orbit_limit&&ptrorbit_distance = d; d *= get_random(1250.0,2500.0)/1000.0; ++ptr; }//end while star[s].number_of_orbits = ptr-star[s].planet; ---------------------------------- Problem is: It doesn't work either. I get the same error. To illustrate what I mean here is an example of a system generated with this program: ------------------------------- stellar characteristics of 1 type : K3 V mass : 0.689 solar mass luminosity : 0.225 solar lum temperature : 4518 K peak wavelength : 596 nm diameter : 1081470 km gravity : 31.519 G lifespan : 30.581 billion years rotational period : 193.5 hours axial inclination : 18.0 deg. number of orbits : 13 orbital limit : 4.286 AU <------ this is the limit... eco zone -inner boundary : 0.463 AU -outer boundary : 0.743 AU % planets of 1 present at: 0.549 AU 1.208 AU 2.257 AU 5.395 AU <----- ...that is ignored 11.480 AU 14.862 AU 35.608 AU 51.075 AU 113.629 AU 224.052 AU 445.400 AU 765.494 AU 1840.211 AU ------------------------------- Any idea anyone? I use lcc-win32 and gcc, so it probably isn't the compiler. hoping for answers, regards, Stephan Nov 14 '05 #1
19 Replies

 P: n/a Stephan Aspridis scribbled the following: Hi folks, a happy new year. I have a little problem with a program I am writing at the moment. A loop doesn't behave the way I'd like to (namely, the "break" is ignored). This is the code in question: ---------------------------------- star[s].planet.orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; for (p=0;pstar[s].orbit_limit) break; Probably stupid question, since I was too lazy to work out the mathematical algorithm, but are you sure it isn't because you are assigning to star[s].planet[x].orbit_distance, but comparing star[s].planet[p].orbit_distance? Those are two different variables. }//end for star[s].number_of_orbits = p; ---------------------------------- -- /-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\ \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/ "Stronger, no. More seductive, cunning, crunchier the Dark Side is." - Mika P. Nieminen Nov 14 '05 #2

 P: n/a "Joona I Palaste" wrote in message news:bt**********@oravannahka.helsinki.fi... Stephan Aspridis scribbled the following: Hi folks, a happy new year. I have a little problem with a program I am writing at the moment. A loop doesn't behave the way I'd like to (namely, the "break" is ignored). This is the code in question: ---------------------------------- star[s].planet.orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150. 0)/100.0; for (p=0;pstar[s].orbit_limit) break; Probably stupid question, since I was too lazy to work out the mathematical algorithm, but are you sure it isn't because you are assigning to star[s].planet[x].orbit_distance, but comparing star[s].planet[p].orbit_distance? Those are two different variables. I noticed that too, but shouldn't that only result in unnecessarily calculating one too many orbits? start[s].planet[p].orbit_distance is always known at the moments of the comparison... Peter Nov 14 '05 #3

 P: n/a Peter Pichler scribbled the following: "Joona I Palaste" wrote in message news:bt**********@oravannahka.helsinki.fi... Stephan Aspridis scribbled the following: > Hi folks, > a happy new year. I have a little problem with a program I am writing at > the moment. A loop doesn't behave the way I'd like to (namely, the > "break" is ignored). This is the code in question: > ---------------------------------- > star[s].planet.orbit_distance = > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150. 0)/100.0; > for (p=0;p x = p+1; > star[s].planet[x].orbit_distance = > star[s].planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0; > if (star[s].planet[p].orbit_distance>star[s].orbit_limit) > break; Probably stupid question, since I was too lazy to work out the mathematical algorithm, but are you sure it isn't because you are assigning to star[s].planet[x].orbit_distance, but comparing star[s].planet[p].orbit_distance? Those are two different variables. I noticed that too, but shouldn't that only result in unnecessarily calculating one too many orbits? start[s].planet[p].orbit_distance is always known at the moments of the comparison... You are right. Well, the only thing *I* can figure is that maybe the orbit_distance field rolls over, and thus can never become bigger than the orbit_limit field. As the OP hasn't shown us the definition of the structures in question, I'm just shooting in the dark here. -- /-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\ \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/ "A computer program does what you tell it to do, not what you want it to do." - Anon Nov 14 '05 #4

 P: n/a "Stephan Aspridis" wrote in message news:bt*************@news.t-online.com... Hi folks, a happy new year. I have a little problem with a program I am writing at the moment. A loop doesn't behave the way I'd like to (namely, the "break" is ignored). This is the code in question: ---------------------------------- star[s].planet.orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0) *sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; for (p=0;p star[s].orbit_limit) break; }//end for So, the next planet's orbit distance is between 1.5 and 2.5 times the current distance, right? And you want to break the loop based on the limit, but only after calculating the next orbit distance, right? planets of 1 present at: 0.549 AU 1.208 AU 2.257 AU 5.395 AU <----- ...that is ignored 11.480 AU .... Unless I am missing something blatantly obvious, you should be calculating orbits up to this point. In addition to what Joona said, I can come up with two possible explanations: 1) you initialize star[s].orbit_limit too late or 2) you have some kind of an order-of-magnitude problem (initializing orbit limit to 4000 rather than 4, for example) ;-) Peter Nov 14 '05 #5

 P: n/a Joona I Palaste wrote: You are right. Well, the only thing *I* can figure is that maybe the orbit_distance field rolls over, and thus can never become bigger than the orbit_limit field. As the OP hasn't shown us the definition of the structures in question, I'm just shooting in the dark here. Here are the structures: struct planet_record{ unsigned char core_type; short int ident; short int orbit_zone; short int core_ident; short int number_of_rings; short int number_of_small_moons; short int number_of_large_moons; double orbit_distance; double orbit_eccentricity; double orbit_inclination; double orbit_period; double orbit_velocity; double orbit_temperature; double orbit_temperature_add; double exosphere_temperature; double max_temperature; double min_temperature; double perihel_add; double aphel_sub; double diameter; double density; double width; double mass; double surface; double gravity; double escape_velocity; double base_temp; double axial_inclination; double rotation; double geosync_orbit; double horizon_at_eye_level; double horizon_at_10m; double horizon_at_100m; double magnetic_field; }; struct star_record{ unsigned char type; short int ident; short int number_of_orbits; double mass; double inclination; double rotation; double main_sequence_life; double luminosity; double main_sequence_radius; double radius; double temperature; double main_sequence_temperature; double diameter; double gravity; double lambda_max; double period1_2; double period12_3; double period12_34; double period3_4; double mean_separation1_2; double mean_separation12_3; double mean_separation12_34; double mean_separation3_4; double eco_rad_inner; double eco_rad_outer; double orbit_limit; struct planet_record planet; }; Nov 14 '05 #6

 P: n/a Peter Pichler wrote: So, the next planet's orbit distance is between 1.5 and 2.5 times the current distance, right? And you want to break the loop based on the limit, but only after calculating the next orbit distance, right? Yes, exactly. planets of 1 present at: 0.549 AU 1.208 AU 2.257 AU 5.395 AU <----- ...that is ignored 11.480 AU ... Unless I am missing something blatantly obvious, you should be calculating orbits up to this point. In addition to what Joona said, I can come up with two possible explanations: 1) you initialize star[s].orbit_limit too late or 2) you have some kind of an order-of-magnitude problem (initializing orbit limit to 4000 rather than 4, for example) ;-) No to your first point. star[s].orbit_limit is initialized before this loop. As for your second point - it gets exactly the value you see in my OP. That were the first things I tried. regards, Stephan Nov 14 '05 #7

 P: n/a Joona I Palaste wrote: You are right. Well, the only thing *I* can figure is that maybe the orbit_distance field rolls over, and thus can never become bigger than the orbit_limit field. How can this happen? regards, Stephan Nov 14 '05 #8

 P: n/a "Stephan Aspridis" wrote: Joona I Palaste wrote: You are right. Well, the only thing *I* can figure is that maybe the orbit_distance field rolls over, and thus can never become bigger than the orbit_limit field. How can this happen? It is very unlikely in your case. Joona didn't see your structures' definitions, so he took a wild guess. Peter Nov 14 '05 #9

 P: n/a "Stephan Aspridis" wrote in message news:bt*************@news.t-online.com... Hi folks, a happy new year. I have a little problem with a program I am writing at the moment. A loop doesn't behave the way I'd like to (namely, the "break" is ignored). This is the code in question: ---------------------------------- star[s].planet.orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; for (p=0;pstar[s].orbit_limit) break; }//end for star[s].number_of_orbits = p; ---------------------------------- "orbcount" is a variable of type int which normally has a value between 1 and 20. "star[s].orbit_limit" is an upper limit (type double). The general idea was that upon reaching the limit, the loop ends and "star[s].number_of_orbits" gets the last value of "p". I asked the same question in de.comp.lang.c and the folks there came up with this solution: ---------------------------------- ptr = star[s].planet; e = ptr+orbcount; d = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; while (d<=star[s].orbit_limit&&ptrorbit_distance = d; d *= get_random(1250.0,2500.0)/1000.0; ++ptr; }//end while star[s].number_of_orbits = ptr-star[s].planet; ---------------------------------- Problem is: It doesn't work either. I get the same error. To illustrate what I mean here is an example of a system generated with this program: ------------------------------- stellar characteristics of 1 type : K3 V mass : 0.689 solar mass luminosity : 0.225 solar lum temperature : 4518 K peak wavelength : 596 nm diameter : 1081470 km gravity : 31.519 G lifespan : 30.581 billion years rotational period : 193.5 hours axial inclination : 18.0 deg. number of orbits : 13 orbital limit : 4.286 AU <------ this is the limit... eco zone -inner boundary : 0.463 AU -outer boundary : 0.743 AU % planets of 1 present at: 0.549 AU 1.208 AU 2.257 AU 5.395 AU <----- ...that is ignored 11.480 AU 14.862 AU 35.608 AU 51.075 AU 113.629 AU 224.052 AU 445.400 AU 765.494 AU 1840.211 AU ------------------------------- Any idea anyone? I use lcc-win32 and gcc, so it probably isn't the compiler. If the loop is OK, and if there is no problem anywhere else, then is number of orbits == 13 because orbcount == 13 or is orbit_limit an order of magnitude out? John. Nov 14 '05 #10

 P: n/a Chris Torek wrote: In article Stephan Aspridis writes: [pretty much entirely snipped] By not posting a complete program, or even a compile-able snippet, you make it difficult to give much help. Using the data structures you posted later, along with the code you included, I came up with the code below, which appears to work fine. (Note that I just put in 1.0 for both sun and earth density factors. I also made some assumptions about get_random().) Thanks for the help. I knew that it would better to post the entire prog - only that the (commented ;-) )source code is about 50K, even the compilable snippet is about 24K. I didn't want to spam the group with large, uninteresting (to most) text. But I'll try the code you came up with. Stay tuned ;-) regards, Stephan P.S. Why is it that everyone insists on using pointers... ;-)) Nov 14 '05 #12

 P: n/a Stephan Aspridis wrote: Thanks for the help. I knew that it would better to post the entire prog - only that the (commented ;-) )source code is about 50K, even the compilable snippet is about 24K. I didn't want to spam the group with large, uninteresting (to most) text. You know, you didn't need those large structures and most of the associated code to post a compilable program illustrating your problem. In fact, most of what you posted was just clutter obstructing the path to answers to your question. Nov 14 '05 #13

 P: n/a Stephan Aspridis wrote in message news:... Hi folks, a happy new year. I have a little problem with a program I am writing at the moment. A loop doesn't behave the way I'd like to (namely, the "break" is ignored). This is the code in question: ---------------------------------- star[s].planet.orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; for (p=0;pstar[s].orbit_limit) break; }//end for star[s].number_of_orbits = p; ---------------------------------- "orbcount" is a variable of type int which normally has a value between 1 and 20. "star[s].orbit_limit" is an upper limit (type double). The general idea was that upon reaching the limit, the loop ends and "star[s].number_of_orbits" gets the last value of "p". I asked the same question in de.comp.lang.c and the folks there came up with this solution: ---------------------------------- ptr = star[s].planet; e = ptr+orbcount; d = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star[s].mass)*get_random(50.0,150.0)/100.0; while (d<=star[s].orbit_limit&&ptrorbit_distance = d; d *= get_random(1250.0,2500.0)/1000.0; ++ptr; }//end while star[s].number_of_orbits = ptr-star[s].planet; ---------------------------------- Problem is: It doesn't work either. I get the same error. To illustrate what I mean here is an example of a system generated with this program: ------------------------------- stellar characteristics of 1 type : K3 V mass : 0.689 solar mass luminosity : 0.225 solar lum temperature : 4518 K peak wavelength : 596 nm diameter : 1081470 km gravity : 31.519 G lifespan : 30.581 billion years rotational period : 193.5 hours axial inclination : 18.0 deg. number of orbits : 13 orbital limit : 4.286 AU <------ this is the limit... eco zone -inner boundary : 0.463 AU -outer boundary : 0.743 AU % planets of 1 present at: 0.549 AU 1.208 AU 2.257 AU 5.395 AU <----- ...that is ignored 11.480 AU 14.862 AU 35.608 AU 51.075 AU 113.629 AU 224.052 AU 445.400 AU 765.494 AU 1840.211 AU ------------------------------- Any idea anyone? I use lcc-win32 and gcc, so it probably isn't the compiler. hoping for answers, regards, Stephan The program seems to working exactly as coded. The for-loop exits early when the computed orbit distance is greater than the orbit limit. This seems to be the case in the data set presented. What obscures this logic error is that the computed orbit distance doesn't exceed the limit until the 13th iteration of the loop. It occurs to me that what you might want to do is set the computed orbit distance equal to the orbit limit iff the computed distance exceeds the limit. Nov 14 '05 #14

 P: n/a Stephan Aspridis wrote: But I'll try the code you came up with. Stay tuned ;-) Works now. But only after I defined "struct star_record *sp" and "sp = &star[s]" as well as "struct planet_record *pp" and "pp = &star[s].planet[p]" for the entire program. Hell knows why. But thanks for pointing (no pun intended ;-) ) me in the right direction. P.S. Why is it that everyone insists on using pointers... ;-)) I know think because they work... ;-) reagrds, Stephan Nov 14 '05 #15

 P: n/a In article , s.********@t-online.de says... Works now. But only after I defined "struct star_record *sp" and "sp = &star[s]" as well as "struct planet_record *pp" and "pp = &star[s].planet[p]" for the entire program. Hell knows why. But thanks for pointing (no pun intended ;-) ) me in the right direction. One thing to consider is that taking the above attitude "Hell knows why" and not bird-dogging it until you understand it completely on your own will be a major obstacle in your learning curve. This is a huge mistake that I see frequently with relatively "young" (in terms of experience) programmers that simply makes the path that much harder. Never accept the idea that something is accidentally, or magically working. You don't learn anything at all that way and in fact often times jump to incorrect conclusions that will come back to haunt you later. P.S. Why is it that everyone insists on using pointers... ;-)) I know think because they work... ;-) Here is another example. :-) -- Randy Howard 2reply remove FOOBAR Nov 14 '05 #16 