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

# #include <math.h>

 P: n/a Hi, I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code. Your help would be appreciated. Thanks! * Genetic Algorithm module * */ #include #include #include #include #include "string.h" /* GetSD * * This function returns the standard deviation of the feature vectors * in a dataT * array. */ static double GetSD(dataT *dataArr[], int data_size, int features[], double mean[]) { int i, j; double data_vect[GENES_PER_CHROM], data_sum, mean_sum, ang_sum, dotprod, data_norm, mean_norm, angle; double sd; ang_sum = 0; for(i = 0; i < data_size; i++) { for(j = 0; j < GENES_PER_CHROM; j++) { data_vect[j] = dataArr[i]->val[(features[j])]; } // get dot product of the two vectors dotprod = 0; for(j = 0; j < GENES_PER_CHROM; j++) { dotprod += data_vect[j] * mean[j]; } // get the norms data_sum = 0; mean_sum = 0; for(j = 0; j < GENES_PER_CHROM; j++) { data_sum += pow(data_vect[j], 2); mean_sum += pow(mean[j], 2); } data_norm = sqrt(data_sum); mean_norm = sqrt(mean_sum); // compute the angle angle = acos(dotprod/(data_norm * mean_norm)); ang_sum += pow(angle, 2); } sd = sqrt(ang_sum / (data_size - 1)); return sd; } Nov 13 '05 #1
33 Replies

 P: n/a Darius Fatakia wrote: Hi, I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code. You are most likely having a linking problem. Read your system documentation to find out how to link in the math library. Appending -lm to your compile line might work. Alex Nov 13 '05 #2

 P: n/a Darius Fatakia wrote: I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code. cat gam.c typedef struct dataT { double* val; } dataT; #define GENES_PER_CHROM 1024 /* * Genetic Algorithm module */ #include #include #include #include #include "string.h" /* GetSD * * This function returns the standard deviation * of the feature vectors in a dataT* array. */ static double GetSD(dataT* dataArr[], int data_size, int features[], double mean[]) { double data_vect[GENES_PER_CHROM]; double ang_sum = 0.0; for(int i = 0; i < data_size; ++i) { for(int j = 0; j < GENES_PER_CHROM; ++j) { data_vect[j] = dataArr[i]->val[(features[j])]; } // get dot product of the two vectors double dotprod = 0.0; for(int j = 0; j < GENES_PER_CHROM; ++j) { dotprod += data_vect[j]*mean[j]; } // get the norms double data_sum = 0.0; double mean_sum = 0.0; for(int j = 0; j < GENES_PER_CHROM; ++j) { data_sum += pow(data_vect[j], 2); mean_sum += pow(mean[j], 2); } double data_norm = sqrt(data_sum); double mean_norm = sqrt(mean_sum); // compute the angle double angle = acos(dotprod/(data_norm*mean_norm)); ang_sum += pow(angle, 2); } return sqrt(ang_sum/(data_size - 1)); } int main(int argc, char* argv[]) { dataT* dataArr[GENES_PER_CHROM]; int data_size = 1024; int features[1024]; double mean[GENES_PER_CHROM]; GetSD(dataArr, data_size, features, mean); return 0; } gcc -Wall -std=c99 -pedantic -o gam gam.c -lm If you include math.h, you need to link in libm.a with the -lm option. Nov 13 '05 #3

 P: n/a On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote: Hi, I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code. Sounds like a linker error - are you linking the math libraries? There's a certain, popular compiler, especially widely used in the Linux world, which has the terminally brain-dead habit of not including the math libraries by default. Assuming you're using this compiler, try something like this: gcc -lm file.c Nov 13 '05 #4

 P: n/a I wonder how many HUNDREDS of times I have seen this question pop up. Are there any gcc fans out here? Wouldn't it be time to include that library as a default library???? eh? !!! This bug is similar to the make utility bug. Tabs are used as separator in "make", and the makefile will not work if they are substituted by spaces! This makes every novice spend hours trying to find out why two makefiles that look the same do not work. Nov 13 '05 #5

 P: n/a In Kelsey Bjarnason writes: On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote: I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code.Sounds like a linker error - are you linking the math libraries? There'sa certain, popular compiler, especially widely used in the Linux world,which has the terminally brain-dead habit of not including the mathlibraries by default. Assuming you're using this compiler, try somethinglike this:gcc -lm file.c gcc merely follows the common Unix convention, established by a certain Dennis M. Ritchie. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #6

 P: n/a In "jacob navia" writes: I wonder how many HUNDREDS of times I have seen this questionpop up.Are there any gcc fans out here? Why should gcc behave differently than most other Unix compilers? Wouldn't it be time to include that library as a default library???? Nope, but it would be high time to include the contents of libm.a into libc.a and provide an empty libm.a, for backward compatibility purposes. The *good* reasons for keeping it separate have no longer been valid for the last 15 years or so. Which has precisely zilch to do with gcc or any other Unix compiler. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #7

 P: n/a On Tue, 25 Nov 2003 10:51:38 +0100, in comp.lang.c , "jacob navia" wrote: I wonder how many HUNDREDS of times I have seen this questionpop up. thats why its a FAQ.... -- Mark McIntyre CLC FAQ CLC readme: Nov 13 '05 #8

 P: n/a On Mon, 24 Nov 2003 16:52:07 -0800, in comp.lang.c , "Darius Fatakia" wrote: "undefined reference to 'pow'" error. This is a FAQ. Please read the FAQs -- Mark McIntyre CLC FAQ CLC readme: Nov 13 '05 #9

 P: n/a jacob navia wrote: [ snip ] This bug is similar to the make utility bug. Tabs are used as separator in "make", and the makefile will not work if they are substituted by spaces! This makes every novice spend hours trying to find out why two makefiles that look the same do not work. I'm not sure I agree that it's a bug but it is annoying. make simply uses TAB as a separator between the Rule and the Command portions of a statement. As I use edit.com with tabs set to 3 this annoyed the hell out of me too. Reading the info file on make one day (I'm surprised how little I do this and how much I should) I read that ';' semicolon is also a Rule / Command separator. How 'bout this.. # Use GNU make to build an executable for testing GE. cc=gcc obj=ge.o main.o exe=main.exe opt=-W -Wall -ansi -pedantic -O2 -c # Note that semicolon (not TAB) separates Rule from Command on a line. \$(exe) : \$(obj) ; \$(cc) -s \$(obj) -o \$(exe) ge.o : ge.c ; \$(cc) \$(opt) ge.c main.o : main.c ge.h ; \$(cc) \$(opt) main.c Live and learn. -- Joe Wright http://www.jw-wright.com "Everything should be made as simple as possible, but not simpler." --- Albert Einstein --- Nov 13 '05 #10

 P: n/a In <3F*********@earthlink.net> Joe Wright writes: out of me too. Reading the info file on make one day (I'm surprised howlittle I do this and how much I should) I read that ';' semicolon isalso a Rule / Command separator. But is this a make feature or a GNU make feature? Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #11

 P: n/a In article , Da*****@cern.ch says... In <3F*********@earthlink.net> Joe Wright writes:out of me too. Reading the info file on make one day (I'm surprised howlittle I do this and how much I should) I read that ';' semicolon isalso a Rule / Command separator. But is this a make feature or a GNU make feature? Dan Is there an ANSI standard on Make and makefiles? Or, are we free to assume that GNU make is the "one true make" and proceed thusly? -- Randy Howard _o 2reply remove FOOBAR \<, ______________________()/ ()______________________________________________ SCO Spam-magnet: po********@sco.com Nov 13 '05 #12

 P: n/a Groovy hepcat Darius Fatakia was jivin' on Mon, 24 Nov 2003 16:52:07 -0800 in comp.lang.c. #include 's a cool scene! Dig it! I seem to be having trouble with some of my math functions (pow, sqrt,acos). They're the only ones I use in my code and they prevent the programfrom compiling. I get a "undefined reference to 'pow'" error. Here is therelevant portion of my code. It is the height of rudeness to post to a newsgroup without doing both of the following: 1) read all posts in the newsgroup for a month or two, and 2) read the newsgroup's FAQ. Please do these two things before posting again. -- Dig the even newer still, yet more improved, sig! http://alphalink.com.au/~phaywood/ "Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker. I know it's not "technically correct" English; but since when was rock & roll "technically correct"? Nov 13 '05 #13

 P: n/a On Wed, 26 Nov 2003 13:27:04 -0600, in comp.lang.c , Randy Howard wrote:Is there an ANSI standard on Make and makefiles? Or, are we free toassume that GNU make is the "one true make" and proceed thusly? Its a great assumption. It will work perfectly. Right up to the point at which you port your makefile to some other compiler environment. Heck, ISTR that makefiles from the C compiler shipped with SunOS 4.1.3 didn't work with the Sparc C++ compiler. -- Mark McIntyre CLC FAQ CLC readme: ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =--- Nov 13 '05 #14

 P: n/a Dan Pop wrote: In <3F*********@earthlink.net> Joe Wright writes:out of me too. Reading the info file on make one day (I'm surprised howlittle I do this and how much I should) I read that ';' semicolon isalso a Rule / Command separator. But is this a make feature or a GNU make feature? Certainly GNU make because I read it there and tried it and it worked. I cannot know and don't care much about all other make programs. By the same token I don't know that TAB is the separator other make programs. To the extent that TAB was chosen by make's original author (Who?) it seems arbitrary and badly chosen. -- Joe Wright http://www.jw-wright.com "Everything should be made as simple as possible, but not simpler." --- Albert Einstein --- Nov 13 '05 #15

 P: n/a In article , ma**********@spamcop.net says... On Wed, 26 Nov 2003 13:27:04 -0600, in comp.lang.c , Randy Howard wrote:Is there an ANSI standard on Make and makefiles? Or, are we free toassume that GNU make is the "one true make" and proceed thusly? Its a great assumption. It will work perfectly. Right up to the point at which you port your makefile to some other compiler environment. Heck, ISTR that makefiles from the C compiler shipped with SunOS 4.1.3 didn't work with the Sparc C++ compiler. Seems that would be easy enough to solve. Open Source, shouldn't be hard to port to just about any modern platform that can support a make of its own. -- Randy Howard _o 2reply remove FOOBAR \<, ______________________()/ ()______________________________________________ SCO Spam-magnet: po********@sco.com Nov 13 '05 #16

 P: n/a Kelsey Bjarnason wrote in message news:... On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote: Hi, I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code. Sounds like a linker error - are you linking the math libraries? There's a certain, popular compiler, especially widely used in the Linux world, which has the terminally brain-dead habit of not including the math libraries by default. Assuming you're using this compiler, try something like this: gcc -lm file.c Out of interest and for the benefit of the OP, does the standard have anything to say about linkage? Nov 13 '05 #17

 P: n/a gs****@mailcity.com (gswork) wrote: Kelsey Bjarnason wrote in message news:... On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote: I seem to be having trouble with some of my math functions (pow, sqrt, acos). They're the only ones I use in my code and they prevent the program from compiling. I get a "undefined reference to 'pow'" error. Here is the relevant portion of my code. Sounds like a linker error - are you linking the math libraries? There's a certain, popular compiler, especially widely used in the Linux world, which has the terminally brain-dead habit of not including the math libraries by default. Assuming you're using this compiler, try something like this: gcc -lm file.c Out of interest and for the benefit of the OP, does the standard have anything to say about linkage? About /linking/ refer to ISO/IEC 9899:1999 5.1.1.2#8. About /linkage/ refer to 6.2.2., 6.7, 6.7.4, 6.7.5.2, 6.9, 6.9.2, 6.11.2, ... HTH Regards -- Irrwahn (ir*******@freenet.de) Nov 13 '05 #18

 P: n/a In Randy Howard writes: In article , Da*****@cern.ch says... In <3F*********@earthlink.net> Joe Wright writes: >out of me too. Reading the info file on make one day (I'm surprised how >little I do this and how much I should) I read that ';' semicolon is >also a Rule / Command separator. But is this a make feature or a GNU make feature? DanIs there an ANSI standard on Make and makefiles? Or, are we free toassume that GNU make is the "one true make" and proceed thusly? Why does it have to be an ANSI standard? C99 is an ANSI standard, yet C99 code is extremely non-portable, due to lack of implementations. According to the HP-UX man page: STANDARDS CONFORMANCE make: SVID2, SVID3, XPG2, XPG3, XPG4, POSIX.2 Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #19

 P: n/a In Randy Howard writes: In article ,ma**********@spamcop.net says... On Wed, 26 Nov 2003 13:27:04 -0600, in comp.lang.c , Randy Howard wrote: > >Is there an ANSI standard on Make and makefiles? Or, are we free to >assume that GNU make is the "one true make" and proceed thusly? Its a great assumption. It will work perfectly. Right up to the point at which you port your makefile to some other compiler environment. Heck, ISTR that makefiles from the C compiler shipped with SunOS 4.1.3 didn't work with the Sparc C++ compiler.Seems that would be easy enough to solve. Open Source, shouldn'tbe hard to port to just about any modern platform that can supporta make of its own. "Shouldn't be hard to port" and "isn't hard to port" are two completely different things. Between merely having to compile and install gnu make and writing portable makefiles I'll choose the latter without a second's hesitation. I had no problem using well written Unix makefiles with Microsoft's NMAKE when I had to port the project to Windows + the VC++ toolchain. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #20

 P: n/a In <81**************************@posting.google.com > gs****@mailcity.com (gswork) writes: Out of interest and for the benefit of the OP, does the standard haveanything to say about linkage? Quite a lot. But it is quite quiet about linking. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #21

 P: n/a Joe Wright wrote: Dan Pop wrote: In <3F*********@earthlink.net> Joe Wright writes:out of me too. Reading the info file on make one day (I'm surprised howlittle I do this and how much I should) I read that ';' semicolon isalso a Rule / Command separator. But is this a make feature or a GNU make feature? Certainly GNU make because I read it there and tried it and it worked. I cannot know and don't care much about all other make programs. By the same token I don't know that TAB is the separator other make programs. To the extent that TAB was chosen by make's original author (Who?) Richard Stallman. it seems arbitrary and badly chosen. It's a way. Python seems to have reinvented this "error". -- Joe Wright http://www.jw-wright.com "Everything should be made as simple as possible, but not simpler." --- Albert Einstein --- -- Les Cargill Nov 13 '05 #22

 P: n/a Les Cargill wrote: Joe Wright wrote: By the same token I don't know that TAB is the separator other make programs. To the extent that TAB was chosen by make's original author (Who?) it seems arbitrary and badly chosen. It's a way. Python seems to have reinvented this "error". Python accepts both tabs and spaces as indentation. There's no need to use tabs if you don't want to. Jeremy. Nov 13 '05 #23

 P: n/a Jeremy Yallop wrote: Les Cargill wrote: Joe Wright wrote: By the same token I don't know that TAB is the separator other make programs. To the extent that TAB was chosen by make's original author (Who?) it seems arbitrary and badly chosen. It's a way. Python seems to have reinvented this "error". Python accepts both tabs and spaces as indentation. There's no need to use tabs if you don't want to. Right! I meant it's still indentation-based, which is odd in this day and age. Jeremy. -- Les Cargill Nov 13 '05 #24

 P: n/a Les Cargill wrote in message news:<3F***************@worldnet.att.net>... Jeremy Yallop wrote: Les Cargill wrote: Joe Wright wrote:> By the same token I don't know that TAB is the separator other make> programs. To the extent that TAB was chosen by make's original> author (Who?) it seems arbitrary and badly chosen. It's a way. Python seems to have reinvented this "error". Python accepts both tabs and spaces as indentation. There's no need to use tabs if you don't want to. Right! I meant it's still indentation-based, which is odd in this day and age. But Python's indentation rules follow the informal format of all other Algol-based languages. What you are forced to do in Python is merely what you should be doing in C and Pascal and such anyway. If you absolutely despise whitespace, one space character works just fine. There's no concept of sacred columns that Fortran and other punch-card-based languages plagued us all with Back In The Day. A small example: def my_abs(x): if x <= 0: return x else: return -x There. Done. That's as obnoxious as the rules get. Emacs even does it for you (the newline key is electric in Python mode, so Emacs will auto-indent whenever you end a line). Nov 13 '05 #25

 P: n/a Irrwahn Grausewitz wrote in message news:. .. gs****@mailcity.com (gswork) wrote: Kelsey Bjarnason wrote in message news:... On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote: > I seem to be having trouble with some of my math functions (pow, sqrt, > acos). They're the only ones I use in my code and they prevent the program > from compiling. I get a "undefined reference to 'pow'" error. Here is the > relevant portion of my code. Sounds like a linker error - are you linking the math libraries? There's a certain, popular compiler, especially widely used in the Linux world, which has the terminally brain-dead habit of not including the math libraries by default. Assuming you're using this compiler, try something like this: gcc -lm file.c Out of interest and for the benefit of the OP, does the standard have anything to say about linkage? About /linking/ refer to ISO/IEC 9899:1999 5.1.1.2#8. About /linkage/ refer to 6.2.2., 6.7, 6.7.4, 6.7.5.2, 6.9, 6.9.2, 6.11.2, ... HTH Regards Thanks for the references Nov 13 '05 #26

 P: n/a li***************@yahoo.com (August Derleth) wrote: Les Cargill wrote in message news:<3F***************@worldnet.att.net>... Jeremy Yallop wrote: Python accepts both tabs and spaces as indentation. There's no need to use tabs if you don't want to. Right! I meant it's still indentation-based, which is odd in this day and age. But Python's indentation rules follow the informal format of all other Algol-based languages. What you are forced to do in Python is merely what you should be doing in C and Pascal and such anyway. No, it isn't. I'm not sure if Python's equivalent of this is legal... int function(struct object * const first_source, struct object * const second_source, struct object * destination) { /* Do something */ } ....but Python's equivalent of this certainly isn't... if (first_object ->wibble_counter > maximum_wibbles || second_object->wibble_counter > maximum_wibbles) return -1; ....and if a language doesn't allow me to make my code more readable by being creative with indentation like that, it goes into the bin for being too uppity for its own good. One of the reasons why I like C is that, if _I_ decide something is more legible the way I like it, the language doesn't stop me from maintaining my code in a year or two. Richard Nov 13 '05 #27

 P: n/a Richard Bos wrote: I'm not sure if Python's equivalent of this is legal... int function(struct object * const first_source, struct object * const second_source, struct object * destination) { /* Do something */ } You can certainly write something equivalent to that in Python, since most objects are mutable, and calling a function passes references to arguments by value. By this I mean that when you pass an argument to a function the object (e.g. the "struct") is bound to the parameter name within the function body. Consequently, the object is available for modification within the function, but if the parameter name appears on the left side of an assignment expression then the name is simply rebound and the object is not modified. It's rather similar to what you have above: the effects of assignments to destination->foo are visible outside the function, but assignments to destination itself are not. class Foo: def __init__(self, val): self.value = val # set the value of `output' to the sum of the values of # `first_source' and `second_source'. Return half of the final # value of `output' def function(first_source, second_source, output): # modify the object to which `output' is bound. output.value = first_source.value + second_source.value return output.value / 2 # Probably not what was intended def function_2(first_source, second_source, output): # rebind output within `function_2'. No effect once the # function returns output = first_source, second_source ...but Python's equivalent of this certainly isn't... if (first_object ->wibble_counter > maximum_wibbles || second_object->wibble_counter > maximum_wibbles) return -1; This is written if (first_object .wibble_counter > maximum_wibbles or second_object.wibble_counter > maximum_wibbles): return -1 Jeremy. Nov 13 '05 #28

 P: n/a August Derleth wrote: Les Cargill wrote in message news:<3F***************@worldnet.att.net>... Jeremy Yallop wrote: Les Cargill wrote: > Joe Wright wrote: >> By the same token I don't know that TAB is the separator other make >> programs. To the extent that TAB was chosen by make's original >> author (Who?) it seems arbitrary and badly chosen. > > It's a way. Python seems to have reinvented this "error". Python accepts both tabs and spaces as indentation. There's no need to use tabs if you don't want to. Right! I meant it's still indentation-based, which is odd in this day and age. But Python's indentation rules follow the informal format of all other Algol-based languages. What you are forced to do in Python is merely what you should be doing in C and Pascal and such anyway. That doesn't matter. It's like designing a TV video section that can only support PAL and not NTSC - it's an unnecessary constraint. In this day and age of language design tools, it's unnecessary. Any resonance with card image formatting is archaic. If you absolutely despise whitespace, I don't, and that is not the point at all. Curly braces are cheap, explicit and very visible. They make fine delimiters. one space character works just fine. There's no concept of sacred columns that Fortran and other punch-card-based languages plagued us all with Back In The Day. A small example: def my_abs(x): if x <= 0: return x else: return -x There. Done. That's as obnoxious as the rules get. It's not that onerous, but the fine details add up. Emacs even does it for you (the newline key is electric in Python mode, so Emacs will auto-indent whenever you end a line). -- Les Cargill Nov 13 '05 #29

 P: n/a Jeremy Yallop wrote: Richard Bos wrote: I'm not sure if Python's equivalent of this is legal... int function(struct object * const first_source, struct object * const second_source, struct object * destination) { /* Do something */ } You can certainly write something equivalent to that in Python, since most objects are mutable, and calling a function passes references to arguments by value. I wasn't talking about the semantics, merely about the indentation. ...but Python's equivalent of this certainly isn't... if (first_object ->wibble_counter > maximum_wibbles || second_object->wibble_counter > maximum_wibbles) return -1; This is written if (first_object .wibble_counter > maximum_wibbles or second_object.wibble_counter > maximum_wibbles): return -1 Like bloody hell it is. That is _not_ as legible. In fact, it isn't even in the same ballpark. And that's even without considering three levels of indentation. Richard Nov 13 '05 #30

 P: n/a Richard Bos wrote: Jeremy Yallop wrote: Richard Bos wrote: > I'm not sure if Python's equivalent of this is legal... > > int function(struct object * const first_source, > struct object * const second_source, > struct object * destination) > { > /* Do something */ > } You can certainly write something equivalent to that in Python, since most objects are mutable, and calling a function passes references to arguments by value. I wasn't talking about the semantics, merely about the indentation. Okay. def function(first_source, second_source, destination): # do something There's no *need* to write like this in Python, though: the signature doesn't include all the type information, so the parameter list is shorter. It's sometimes useful for comments about each parameter: def function(first_source, # some comment second_source, # something else destination): # and some more # do something but I can't imagine many other situations where it would be used. Still, if you want to indent your code like that, nobody will stop you. > ...but Python's equivalent of this certainly isn't... > > if (first_object ->wibble_counter > maximum_wibbles || > second_object->wibble_counter > maximum_wibbles) > return -1; This is written if (first_object .wibble_counter > maximum_wibbles or second_object.wibble_counter > maximum_wibbles): return -1 Like bloody hell it is. That is _not_ as legible. If you want, you change the indentation of the return statement. There's no need to lose your temper. if (first_object .wibble_counter > maximum_wibbles or second_object.wibble_counter > maximum_wibbles): return -1 is fine, too. Jeremy. Nov 13 '05 #31

 P: n/a Jeremy Yallop wrote: If you want, you change the indentation of the return statement. There's no need to lose your temper. if (first_object .wibble_counter > maximum_wibbles or second_object.wibble_counter > maximum_wibbles): return -1 is fine, too. Not in any version of Python I've used. Richard Nov 13 '05 #32

 P: n/a Richard Bos wrote: Jeremy Yallop wrote: If you want, you change the indentation of the return statement. There's no need to lose your temper. if (first_object .wibble_counter > maximum_wibbles or second_object.wibble_counter > maximum_wibbles): return -1 is fine, too. Not in any version of Python I've used. I tried it on various versions of Python, from 1.0.1 (February 1994) to 2.3 (October 2003) and they all accepted it without problems. Jeremy. Nov 13 '05 #33

 P: n/a On Wed, 26 Nov 2003 21:49:28 -0600, in comp.lang.c , Randy Howard wrote: In article ,ma**********@spamcop.net says... On Wed, 26 Nov 2003 13:27:04 -0600, in comp.lang.c , Randy Howard wrote: > >Is there an ANSI standard on Make and makefiles? Or, are we free to >assume that GNU make is the "one true make" and proceed thusly? Its a great assumption. It will work perfectly. Right up to the point at which you port your makefile to some other compiler environment. Heck, ISTR that makefiles from the C compiler shipped with SunOS 4.1.3 didn't work with the Sparc C++ compiler.Seems that would be easy enough to solve. Open Source, Sure, but that wasn't the question was it? -- Mark McIntyre CLC FAQ CLC readme: ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =--- Nov 13 '05 #34

### This discussion thread is closed

Replies have been disabled for this discussion.