Marching coordinates

[joerg]

x[0]=0;
y[0]=0;

for(i=0;i<N-1;i++)
{
if(x[i]<1) x[i+1]=x[i]+Vx*dt;
else x[i+1]=x[i]-Vx*dt;

Help! I want the coordinates x[i] change from 0 over +1 to -1 and back as often as i<N. The program counts from 0 up to 1 - O.K. - but then oscillates from 1 to 0.9 and so on.

[twomers]

You could do the following -

int main( void )
{
    int num[] = { -1, 0, 1 }, i, max=10;

    for ( i=1; i<max; i++ )
    {
        printf( "&#37;d ", num[i%3] );
    }

    return 0;
}

And please consider using code tags in the future. It'll keep many of us happier

[joerg]

Thank you, but I forgot to mention, that the x[i] are real numbers, ranging over [-1:1]
I want to create something like 0.0, 0.1, ...,0.9 , 1.0 , 0.9 , ... ,0.0 , -0.9 , -0.8 , ... , -1.0 , -0.9 ,... and so on as far as i<N

Wlii i get another chance ?

joerg

[IsmAvatar2]

Could you please clarify the last part of the oscillation? You say:
0.0 , -0.9 , -0.8 , ... , -1.0 , -0.9
But there's a bit of a skip from 0.0 to -0.9, and similarly, you cannot count up from -0.9 and hope to reach -1.0.

[joerg]

I beg your pardon!

It has to look like this: 0.0, 0.1 ,... ,1.0 ,0.9 ,...0.1 , 0.0 ,-0.1 ,-0.2 ,... ,-1.0 ,-0.9 ,-0.8 ,... ans so on.

thank you for your reply anyway!

Is there a third chance for me ?

joerg

[IsmAvatar2]

Here's the dependant coding of it - that is, each entry is dependant on the previous entry.

double val = 0.0
double inc = 0.1
int N = 100;
double x[N];

for (int i = 0; i < N; i++) {
  val += inc; //increase oscillation position
  if ((val == 1.0) || (val == -1.0)) inc = -inc; //reverse direction
  x[i] = val;
}

[twomers]

Do you understand looping? If so this should be trivial.

First things first - try to get your program to count from 0 to 1 in steps of 0.1. When you have that try to modify your code to get it to work from -1 to +1. Then worry about making it over and over and over again.

[IsmAvatar2]

@twomers: that won't work, because then it won't oscillate, it will only modulate. Once it counts up to +1, it needs to start counting back down again.

@joerg: Here's a more dynamic solution. It's independant of previous entries, meaning that you can just plug in any value and it will dynamically compute it without having to go back through the entire list, so it has a runtime of O(1), rather than my previous solution, which had a runtime of O(n).

int N = 100;
double x[N];
for (int i = 0; i < N; i++) {
  int v = (i + 10) &#37; 40;
  if (v <= 20) x[i] = (double)(v - 10) / 10.0;
  if (v > 20) x[i] = (double)(30 - v) / 10.0;
}

I was also considering a solution that used memoization, but realized that I could just modulate over the computation.

[twomers]

>> @twomers: that won't work, because then it won't oscillate, it will only modulate. Once it counts up to +1, it needs to start counting back down again.

I understand. The OP is probably a beginner at programming, so he has to get his mind into doing things in steps and building on what he has written! I was trying to encourage him to do it himself, and hence to become a better programmer.

edit
>>int N = 100;
>>double x[N];

<nvm that>

sigh

int main( void )
{
    double i, di = -0.1;
    int num=0;

    for ( i=-1.0; num<100; i+=di, num++ )
    {
        printf( "&#37;f ", i );
        
        if ( i<-0.9 || i>0.9 )
            di *= -1;
    }

    return 0;
}

Enjoy.

[IsmAvatar2]

#define N 100
double x[N];

[brewbuck]

Whenever the value reaches 1.0 or -1.0, negate the value of dt (or Vx, one of the two).

[dwks]

#define N 100
double x[N];

There are many threads arguing about which is better:

1. #define N 100

2. enum { N = 100 };

3. const int N = 100;

Here's one, though I've changed my opinions since then: http://cboard.cprogramming.com/showthread.php?t=85992

[brewbuck]

#ifndef N
#define N 100
#endif

Advantages: The user can override the preprocessor definition at compile-time, without editing the source.
Disadvantages: Literal substitution of macros can cause weird effects in certain situations. The debugger (usually) has no idea about defined values, so debugging is harder.

enum { N = 100; }

Advantages: An enum is a real type, so the compiler can do type checking. The debugger can display the symbolic values, provided you've given everything an appropriate type instead of just "int."
Disadvantages: An enumeration really shouldn't be used unless there are multiple related values to declare. Goes against intended use of enum, and might be obfuscatory.

const int N = 100;

Advantages: None, really.
Disadvantages: The variable is "real," meaning you can take its address. This means you can coerce the type to non-const, and then change the supposedly "constant" value at runtime (that is, if it doesn't crash). NOTE: big difference from what it means in C++!

I tend to go with #define. The ability to override the constants at compile time is just too convenient most of the time.

[dwks]

I generally use:

1. Named enums for multiple related values, e.g.:
   

   enum type_t {
       TYPE_NUMBER,
       TYPE_STRING,
       TYPE_LINK,
       TYPES
   };

   This is because:
   
   1. The numbers are incremented automatically, so adding another value is easy.
   2. You can add a variable at the end which is a count of all the preceding values.
   
   Note that this is the intended use of enums.
2. Anonymous enums for constant values, e.g.:
   

   enum {
       STRING_LEN = BUFSIZ
   };

   This is the controversial usage of enum. I use enum instead of #defines because the compiler checks the values rather than the preprocessor, which is rather blind. I suppose I could use constant values, but -- force of habit.
3. #defines for strings, e.g.:
   

   #define VERSION "program version 1.0.0"

   That way I can use the preprocessor string concatentation:
   

   fprintf(stderr, VERSION "\n"
       "\nusage: ...\n");

I just knew that this was going to start a debate . . .

[twomers]

Wow. A doubly listed list! You should be proud, dwks!

>> STRING_LEN = BUFSIZ
Is BUFSIZ a #define ... ? I would be very amused if it was.