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

Discussion in 'C Programming' started by Stephan Aspridis, Jan 3, 2004.

  1. 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.planet[0].orbit_distance =
    pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;

    for (p=0;p<orbcount-1;p++){
    x = p+1;
    star.planet[x].orbit_distance =
    star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    if (star.planet[p].orbit_distance>star.orbit_limit)
    break;
    }//end for

    star.number_of_orbits = p;
    ----------------------------------

    "orbcount" is a variable of type int which normally has a value between
    1 and 20. "star.orbit_limit" is an upper limit (type double).

    The general idea was that upon reaching the limit, the loop ends and
    "star.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.planet;
    e = ptr+orbcount;
    d =
    pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;
    while (d<=star.orbit_limit&&ptr<e){
    ptr->orbit_distance = d;
    d *= get_random(1250.0,2500.0)/1000.0;
    ++ptr;
    }//end while
    star.number_of_orbits = ptr-star.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
     
    Stephan Aspridis, Jan 3, 2004
    #1
    1. Advertising

  2. 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.planet[0].orbit_distance =
    > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;


    > for (p=0;p<orbcount-1;p++){
    > x = p+1;
    > star.planet[x].orbit_distance =
    > star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    > if (star.planet[p].orbit_distance>star.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.planet[x].orbit_distance, but comparing
    star.planet[p].orbit_distance? Those are two different variables.

    > }//end for


    > star.number_of_orbits = p;
    > ----------------------------------


    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Stronger, no. More seductive, cunning, crunchier the Dark Side is."
    - Mika P. Nieminen
     
    Joona I Palaste, Jan 3, 2004
    #2
    1. Advertising

  3. "Joona I Palaste" <> wrote in message
    news:bt7b2u$ost$...
    > 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.planet[0].orbit_distance =
    > >

    pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.
    0)/100.0;
    >
    > > for (p=0;p<orbcount-1;p++){
    > > x = p+1;
    > > star.planet[x].orbit_distance =
    > > star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    > > if (star.planet[p].orbit_distance>star.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.planet[x].orbit_distance, but comparing
    > star.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.planet[p].orbit_distance
    is always known at the moments of the comparison...

    Peter
     
    Peter Pichler, Jan 3, 2004
    #3
  4. Peter Pichler <> scribbled the following:
    > "Joona I Palaste" <> wrote in message
    > news:bt7b2u$ost$...
    >> 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.planet[0].orbit_distance =
    >> >

    > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.
    > 0)/100.0;
    >>
    >> > for (p=0;p<orbcount-1;p++){
    >> > x = p+1;
    >> > star.planet[x].orbit_distance =
    >> > star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    >> > if (star.planet[p].orbit_distance>star.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.planet[x].orbit_distance, but comparing
    >> star.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.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 () ------------- 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
     
    Joona I Palaste, Jan 3, 2004
    #4
  5. "Stephan Aspridis" <> wrote in message
    news:bt79ub$a0o$04$-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.planet[0].orbit_distance = pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)
    > *sqrt(star.mass)*get_random(50.0,150.0)/100.0;
    >
    > for (p=0;p<orbcount-1;p++){
    > x = p+1;
    > star.planet[x].orbit_distance = star.planet[p].orbit_distance
    > *get_random(1250.0,2500.0)/1000.0;
    > if (star.planet[p].orbit_distance > star.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.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
     
    Peter Pichler, Jan 3, 2004
    #5
  6. 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[20];
    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[16];
    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[20];
    };
     
    Stephan Aspridis, Jan 3, 2004
    #6
  7. 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.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.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
     
    Stephan Aspridis, Jan 3, 2004
    #7
  8. 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
     
    Stephan Aspridis, Jan 3, 2004
    #8
  9. "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
     
    Peter Pichler, Jan 3, 2004
    #9
  10. Stephan Aspridis

    John L Guest

    "Stephan Aspridis" <> wrote in message news:bt79ub$a0o$04$-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.planet[0].orbit_distance =
    > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;
    >
    > for (p=0;p<orbcount-1;p++){
    > x = p+1;
    > star.planet[x].orbit_distance =
    > star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    > if (star.planet[p].orbit_distance>star.orbit_limit)
    > break;
    > }//end for
    >
    > star.number_of_orbits = p;
    > ----------------------------------
    >
    > "orbcount" is a variable of type int which normally has a value between
    > 1 and 20. "star.orbit_limit" is an upper limit (type double).
    >
    > The general idea was that upon reaching the limit, the loop ends and
    > "star.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.planet;
    > e = ptr+orbcount;
    > d =
    > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;
    > while (d<=star.orbit_limit&&ptr<e){
    > ptr->orbit_distance = d;
    > d *= get_random(1250.0,2500.0)/1000.0;
    > ++ptr;
    > }//end while
    > star.number_of_orbits = ptr-star.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.
     
    John L, Jan 4, 2004
    #10
  11. Stephan Aspridis

    Chris Torek Guest

    In article <bt79ub$a0o$04$-online.com>
    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().)

    The revised version of gronk() -- the function with the troublesome
    loop -- has no functional changes except that it does not write on
    the one-past-last star.planet[p] field. Mostly I just tried
    not to repeat variable names over and over and over and over. :)

    #include <math.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <time.h>

    struct planet_record {
    unsigned char core_type[20];
    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[16];
    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;
    #define MAXPLANETS 20
    struct planet_record planet[MAXPLANETS];
    };

    double get_random(double, double);

    #define MAXSTARS 2
    struct star_record star[2];

    void panic(const char *msg) {
    fprintf(stderr, "panic: %s\n", msg);
    exit(EXIT_FAILURE); /* or abort() */
    }

    #define SOLDENSITY 1.0
    #define EARTHDENSITY 1.0

    #ifdef ORIGINAL
    /* original poster's code */
    void gronk(int s, int orbcount) {
    int p, x;

    if (s < 0 || s >= MAXSTARS)
    panic("star number out of range in gronk()");
    if (orbcount < 1 || orbcount > MAXPLANETS)
    panic("orbit count limit out of range in gronk()");
    star.planet[0].orbit_distance =
    pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*
    sqrt(star.mass)*get_random(50.0,150.0)/100.0;

    for (p=0;p<orbcount-1;p++){
    x = p+1;
    star.planet[x].orbit_distance =
    star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    if (star.planet[p].orbit_distance>star.orbit_limit)
    break;
    }

    star.number_of_orbits = p;
    }
    #else
    /* how I would write gronk(): */
    void gronk(int s, int orbcount) {
    struct star_record *sp;
    int p;
    double dist;

    if (s < 0 || s >= MAXSTARS)
    panic("star number out of range in gronk()");
    sp = &star;
    if (orbcount < 0 || orbcount > MAXPLANETS)
    panic("orbit count limit out of range in gronk()");

    /*
    * Calculate distance of innermost planet (if there is to be one).
    * Deserves a comment as to why we use the cube root, etc.
    */
    dist = pow(SOLDENSITY / EARTHDENSITY, 1.0 / 3.0) *
    sqrt(sp->mass) * get_random(0.5, 1.5);

    /*
    * Place up to orbcount planets in orbit. We have an initial
    * distance; successive planets are between 1.25 and 2.5 times
    * further than each previous planet. We stop when we have
    * filled the requested number, or the next planet to place
    * would be beyond the star's orbit limit.
    */
    for (p = 0; p < orbcount && dist < sp->orbit_limit; p++) {
    sp->planet[p].orbit_distance = dist;
    dist *= get_random(1.25, 2.5);
    }

    sp->number_of_orbits = p;
    }
    #endif

    void setup(int s) {

    /* should verify s value */
    star.mass = 0.689; /* solar mass */
    star.orbit_limit = 4.286; /* AU */
    /* since the rest are not used, I did not initialize them */
    }

    void show(int s) {
    int n;
    struct star_record *sp;

    /* should verify s value */
    sp = &star;
    printf("stellar characteristics of %d\n", s);
    printf(" %-17s : K3 V\n", "type"); /* fake */
    printf(" %-17s : %.3f solar mass\n", "mass", sp->mass);
    printf("...\n");
    printf(" %-17s : %d\n", "number of orbits", sp->number_of_orbits);
    printf(" %-17s : %.3f AU\n", "orbital limit", sp->orbit_limit);
    printf("...\n");
    printf("planets of %d present at:\n", s);
    for (n = 0; n < sp->number_of_orbits; n++)
    printf(" %.3f AU\n", sp->planet[n].orbit_distance);
    }

    /* return a number between lo and hi exclusive of hi */
    double get_random(double lo, double hi) {
    double r;

    if (hi <= lo)
    panic("bad values to get_random()");
    r = (double)rand() / ((double)RAND_MAX + 1.0); /* in [0.0,1.0) */
    r *= hi - lo; /* expand to given range */
    r += lo;
    return r;
    }

    int main(void) {

    srand((unsigned)time(NULL)); /* not quite portable but will serve */
    setup(1);
    gronk(1, MAXPLANETS);
    show(1);
    return 0;
    }
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jan 5, 2004
    #11
  12. Chris Torek wrote:
    > In article <bt79ub$a0o$04$-online.com>
    > 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... ;-))
     
    Stephan Aspridis, Jan 5, 2004
    #12
  13. 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.
     
    Martin Ambuhl, Jan 5, 2004
    #13
  14. Stephan Aspridis

    Bill Guest

    Stephan Aspridis <> wrote in message news:<bt79ub$a0o$04$-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.planet[0].orbit_distance =
    > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;
    >
    > for (p=0;p<orbcount-1;p++){
    > x = p+1;
    > star.planet[x].orbit_distance =
    > star.planet[p].orbit_distance*get_random(1250.0,2500.0)/1000.0;
    > if (star.planet[p].orbit_distance>star.orbit_limit)
    > break;
    > }//end for
    >
    > star.number_of_orbits = p;
    > ----------------------------------
    >
    > "orbcount" is a variable of type int which normally has a value between
    > 1 and 20. "star.orbit_limit" is an upper limit (type double).
    >
    > The general idea was that upon reaching the limit, the loop ends and
    > "star.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.planet;
    > e = ptr+orbcount;
    > d =
    > pow(SOLDENSITY/EARTHDENSITY,1.0/3.0)*sqrt(star.mass)*get_random(50.0,150.0)/100.0;
    > while (d<=star.orbit_limit&&ptr<e){
    > ptr->orbit_distance = d;
    > d *= get_random(1250.0,2500.0)/1000.0;
    > ++ptr;
    > }//end while
    > star.number_of_orbits = ptr-star.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.
     
    Bill, Jan 5, 2004
    #14
  15. 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" as well as "struct planet_record *pp" and "pp =
    &star.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
     
    Stephan Aspridis, Jan 5, 2004
    #15
  16. Stephan Aspridis

    Randy Howard Guest

    In article <btc722$lgd$06$-online.com>,
    says...
    > Works now. But only after I defined "struct star_record *sp" and "sp =
    > &star" as well as "struct planet_record *pp" and "pp =
    > &star.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
     
    Randy Howard, Jan 6, 2004
    #16
  17. [OT, humorous(?) bug story]

    Randy Howard <> spoke thus:

    > 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


    "Hell knows why" is a very bad thing to comfort oneself with, as the
    following story may illustrate:

    Once, in a systems programming class, we had an assignment where we
    were supposed to simulate task switching on computer hardware with C.
    Part of the code involved populating simulated registers and making a
    list of processes from data contained in a file, something resembling
    the following...

    typedef struct process
    {
    ...
    int registers[8];
    } process;

    void do_stuff()
    {
    process *proc;
    int reg_num=0;

    while( more_processes ) { /* pseudo_code */
    proc=malloc( sizeof(*proc) ); /* error check omitted */
    /* get a line from the file, parse, etc... */
    for( each_data_for_registers ) { /* pseudo code */
    proc->registers[reg_num++]=some_int;
    }
    ...
    }
    }

    See what happens when there's more than one process to parse? Hint,
    it leads to UB... the kind of UB where the program will (seemingly)
    run fine under Linux, but will seg fault under Solaris (since Solaris
    actually cares when you access memory that you don't have a right to).
    After many hours searching high and low through a fairly large (for a
    college homework assignment) program, I realized the error was in the
    code posted above. However (here's The Bad Thing), I was so certain
    the above code was correct I just hacked a "solution" (removed the seg
    fault, at least) by doing

    proc=malloc( 15 * sizeof(*proc) ); /* oh, the horror! */

    Different values of n (than 15) sometimes led to seg faults, sometimes
    not. But I was smug - the code executed cleanly (it seemed),
    staving off a 0 on the assignment in consequence of a seg fault. It
    didn't produce correct results, of course - but I was ready to turn it
    in anyway. Then, I got a reprieve - the due date was extended! With
    a fiendish gleam in my eye I vowed to make my code REALLY work.
    Within minutes (in stark contrast to the 8 hours I had spent the day
    before, to no avail), I realized that I should have written

    proc->registers[reg_num++ % 8]=some_int;

    ! It's odd how accessing element 100+ of an 8-element array will lead
    to unpleasant occurrences! The moral of the story is, RESIST the urge
    to do ridiculous things like

    proc=malloc( 15 * sizeof(*proc) );

    to make telling crashes go away... The only good thing about the
    experience was, well, the experience ;)

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Jan 7, 2004
    #17
  18. Stephan Aspridis

    Ben Pfaff Guest

    Re: [OT, humorous(?) bug story]

    Christopher Benson-Manica <> writes:

    > void do_stuff()
    > {
    > process *proc;
    > int reg_num=0;
    >
    > while( more_processes ) { /* pseudo_code */
    > proc=malloc( sizeof(*proc) ); /* error check omitted */
    > /* get a line from the file, parse, etc... */


    reg_num = 0;

    > for( each_data_for_registers ) { /* pseudo code */
    > proc->registers[reg_num++]=some_int;
    > }
    > ...
    > }
    > }


    [...]

    > Within minutes (in stark contrast to the 8 hours I had spent the day
    > before, to no avail), I realized that I should have written
    >
    > proc->registers[reg_num++ % 8]=some_int;


    Wouldn't the above-marked insertion of `reg_num = 0;' be more
    straightforward?
    --
    "When I have to rely on inadequacy, I prefer it to be my own."
    --Richard Heathfield
     
    Ben Pfaff, Jan 7, 2004
    #18
  19. Re: [OT, humorous(?) bug story]

    Ben Pfaff <> spoke thus:

    > Wouldn't the above-marked insertion of `reg_num = 0;' be more
    > straightforward?


    In the code I posted, yes. It seems that there was some reason that I
    didn't do it that way - I think I was using the index as a count of
    items as well - reg_num/8 - or something. Either that or I was
    suffering from delusions when I wrote the code, which was certainly a
    possibility given what I consequently did...

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Jan 7, 2004
    #19
  20. Randy Howard wrote:

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


    Well, I just learned a thing. To sum things up - the error wasn't in
    this loop after all. I should have told all of you that this little
    program doesn't calculate one system, but any number of systems from 1
    to the max number of long int (if you're so inclined). If system nr. 686
    (for example) had 8 orbits and nr. 687 only 5, the remaining three
    orbits of 686 were added. It really was a simple thing of forgetting to
    flush the memory and initializing everything to zero (BTW - are there
    any short and more _elegant_ ways than calling a function that does this
    one by one?)

    regards,
    Stephan
     
    Stephan Aspridis, Jan 11, 2004
    #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. Joe Burnett
    Replies:
    0
    Views:
    2,050
    Joe Burnett
    Sep 7, 2003
  2. Alexey Verkhovsky
    Replies:
    8
    Views:
    167
    Hal Fulton
    Jul 18, 2004
  3. Asfand Yar Qazi
    Replies:
    2
    Views:
    110
    Asfand Yar Qazi
    Jan 19, 2006
  4. Sara

    why doesn't /^$_$/ behave?

    Sara, Nov 18, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    139
    Jeff 'japhy' Pinyan
    Nov 18, 2003
  5. Isaac Won
    Replies:
    9
    Views:
    397
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page