Printable View
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.
You could do the following -
And please consider using code tags in the future. It'll keep many of us happier :)Code:int main( void )
{
int num[] = { -1, 0, 1 }, i, max=10;
for ( i=1; i<max; i++ )
{
printf( "%d ", num[i%3] );
}
return 0;
}
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
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.
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
Here's the dependant coding of it - that is, each entry is dependant on the previous entry.
Code: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;
}
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.
@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).
I was also considering a solution that used memoization, but realized that I could just modulate over the computation.Code:int N = 100;
double x[N];
for (int i = 0; i < N; i++) {
int v = (i + 10) % 40;
if (v <= 20) x[i] = (double)(v - 10) / 10.0;
if (v > 20) x[i] = (double)(30 - v) / 10.0;
}
>> @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
Enjoy.Code:int main( void )
{
double i, di = -0.1;
int num=0;
for ( i=-1.0; num<100; i+=di, num++ )
{
printf( "%f ", i );
if ( i<-0.9 || i>0.9 )
di *= -1;
}
return 0;
}
;)Code:#define N 100
double x[N];
Whenever the value reaches 1.0 or -1.0, negate the value of dt (or Vx, one of the two).
There are many threads arguing about which is better:Quote:
Originally Posted by IsmAvatar2
#define N 100
enum { N = 100 };
const int N = 100;
Here's one, though I've changed my opinions since then: http://cboard.cprogramming.com/showthread.php?t=85992
Advantages: The user can override the preprocessor definition at compile-time, without editing the source.Code:#ifndef N
#define N 100
#endif
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.
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."Code:enum { N = 100; }
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.
Advantages: None, really.Code:const int N = 100;
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.
I generally use:
- Named enums for multiple related values, e.g.:
This is because:Code:enum type_t {
TYPE_NUMBER,
TYPE_STRING,
TYPE_LINK,
TYPES
};
- The numbers are incremented automatically, so adding another value is easy.
- 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.- Anonymous enums for constant values, e.g.:
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.Code:enum {
STRING_LEN = BUFSIZ
};
- #defines for strings, e.g.:
That way I can use the preprocessor string concatentation:Code:#define VERSION "program version 1.0.0"
Code:fprintf(stderr, VERSION "\n"
"\nusage: ...\n");
I just knew that this was going to start a debate . . .
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.
It is. ;) It's a minimum of 512 AFAIK, though on some of my computers it's 8192. It's used for setbuf etc. I like to use it as the amount of memory to increase a string by when I run out (see codeform).
[edit] What's that about a double-linked list? (I think it's "double-linked" and not "doubly-linked" BTW. It's like "fine-toothed comb", which is actually "fine tooth-comb"; there was once a fine type of tooth-comb. :D ) [/edit]
I think it's exactly that realization that eventually convinces most people to just use #define :-)Quote:
Originally Posted by twomers
Well, here are the arguments that I'm aware of (for anonymous enums):
FOR
enum values are compile-time constants, so the compiler can give you better error messages if, for example, you try something like this:
Also, debuggers are better with enum values (which is more readable, 10 or X?)Code:enum { X = 10 };
int X = 10; /* whoops */
AGAINST
enums are not supposed to be used in that way, so it could become harder to read or something.
And for #defines:
FOR
#defines are processed by the preprocessor, so you can change their values via the command line and Makefiles etc.
AGAINST
See FOR for enums.
I think I'd prefer to use enums for values like string lengths, but #defines for things like the path to ls (that you might want to change without edited the source).
[edit] Basically a restatement of brewbuck's post above. [/edit]
>> [edit] What's that about a double-linked list? (I think it's "double-linked" and not "doubly-linked" BTW. It's like "fine-toothed comb", which is actually "fine tooth-comb"; there was once a fine type of tooth-comb. ) [/edit]
It was in your first point where it went into 1(a) and 1(b). Very impressive. Two lists. But in one. And I said a doubly listed list. Not linked.
>> It is.
But then why not simply use that instead of your enum? Seems similar to hearing a zebra run!
Sorry, I'm so used to reading "double-linked list" that I see it everywhere . . . but I bet you'd have said "doubly-linked list" if you'd mentioned one. :)Quote:
Originally Posted by twomers
Because I might want to change it.
Code:enum { STRING_LEN = BUFSIZ*2 };
enum { STRING_LEN = USHRT_MAX };
Whaddaya mean?Quote:
Originally Posted by dwks
The preprocessor will turn that into "int 10 = 10;" and the compiler will barf. No problem there.Code:#define X 10
int X = 10;
I actually use "const char *" for constant strings. The problem is this: a string literal has type "char *" (i.e. NOT const), but on most platforms it resides in read-only memory (despite the fact that it isn't known to be "const") I.e.:Quote:
I think I'd prefer to use enums for values like string lengths, but #defines for things like the path to ls (that you might want to change without edited the source).
Whereas if you assign it to a const char * from the get-go:Code:/* This will probably crash. */
char *foo = "Hello";
foo[0] = 'A';
This saves you from the peril of passing a string literal to a function which takes a non-const char pointer, which then tries to modify the string, which then crashes. Instead you get a compile error and go fix the problem.Code:const char *foo = "Hello";
foo[0] = 'A'; /* Compiler throws error */
No, but it will give you an error like "invalid variable name" you you'll think, "what? X? invalid???". Whereas if you have an enum by the same name it will give you a much more palatable error. (I should imagine anyway.)Quote:
The preprocessor will turn that into "int 10 = 10;" and the compiler will barf. No problem there.
I'm aware of the const-ness of string literals. I just use #defines for them because I like inserting them into strings with the preprocessor's string concatenation. :)
Code:fprintf(stderr, PROGRAM " version " VERSION " by " AUTHOR "\n");
That's fine until one day one of the strings has a "%s" or something in it.Quote:
Originally Posted by dwks
Why not just:
Code:fprintf(stderr, "%s version %s by %s\n", PROGRAM, VERSION, AUTHOR);
Because I usually use puts() instead. It's a case of premature optimization. :) You're right, it's not a good idea . . . I think I'll avoid it in the future.
I still like enums though. :) The main reason being that, in C++, you can put them in namespaces etc. No doubt const variables would be a better idea in that case, though.
You could always say a "nested list". :)Quote:
It was in your first point where it went into 1(a) and 1(b). Very impressive. Two lists. But in one.
Well, I agree that string concatenation is a pretty useful thing to do. The problem is really printf-specific -- the format string to printf() should always be a literal in my opinion so that you can SEE what it is and make sure there are no stray conversion specifiers lurking in it. But I use string concatenation all the time when printing out long messages.Quote:
Originally Posted by dwks
Me too, for multiple lines usually. Sometimes I run into a GCC error message to the effect of "string length is longer than the C89 standard of 509 characters". I think that's for 509 chars + 1 NULL + 2 chars for string length to fit into 512 characters, but I'm just guessing.
I have a vague recollection of reading somewhere that the choice of 509 was actually a typo in the original standard, which wasn't considered important enough to fix. But take that with a truck-sized grain of salt.Quote:
Originally Posted by dwks
Have you considered a lookup-table type of thing for the x[]?Quote:
Originally Posted by joerg
Code:#include <stdio.h>
double foo(int i)
{
static const double a[] =
{
+0.0,+0.1,+0.2,+0.3,+0.4,+0.5,+0.6,+0.7,+0.8,+0.9,
+1.0,+0.9,+0.8,+0.7,+0.6,+0.5,+0.4,+0.3,+0.2,+0.1,
+0.0,-0.1,-0.2,-0.3,-0.4,-0.5,-0.6,-0.7,-0.8,-0.9,
-1.0,-0.9,-0.8,-0.7,-0.6,-0.5,-0.4,-0.3,-0.2,-0.1,
};
return a[i % (sizeof a / sizeof *a)];
}
int main(void)
{
int i;
for ( i = 0; i < 1000; ++i )
{
printf("%4g%c", foo(i), i % 10 == 9 ? '\n' : ' ');
}
return 0;
}
Actually that's what I was suggesting with the memoization, but figured it wasn't worth it since the lookup table would be 40 elements. Plus I was using an algorithm to generate the lookup table, which I realized I could just bypass the lookup table and just use that algorithm to calculate the values themselves by modulating them over 40.
What's the "static" do when you say "static const double a[]"? I'm familiar with static from Java, but have never seen it used in my short time with C, since C isn't object oriented, and static from Java is an object-oriented term.
The static causes the array to be allocated statically (like global variables) instead of on the stack. If it were on the stack, the program would have to copy the contents of the array into a new array on the stack for every single call to the lookup function. But because it is static, the array "just exists" and the function refers to it without having to construct it.Quote:
Originally Posted by IsmAvatar2
EDIT: In this case, it means pretty much the same thing as "static" in Java -- the data belongs to the "class" (running program) instead of the "instance" (function invocation). The "static" keyword was taken from C for use in Java, so it's no surprise the idea is similar.
If something is a static global variable, it means something slightly different -- the global variable is exactly like any other module-level variable (e.g. globals) but it cannot be referenced outside the module it is declared in. So "static" means two different things in C.
You can also declare static functions, which can only be referenced from within the source file. This is useful for large projects because it's like rudimentary namespaces.Quote:
If something is a static global variable, it means something slightly different -- the global variable is exactly like any other module-level variable (e.g. globals) but it cannot be referenced outside the module it is declared in. So "static" means two different things in C.