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

# malloc and free

 P: n/a If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10); afterward I want to free a number of them, say the first 3 blocks, how do I do so? If I tried free(p), the whole 10 blocks are being freed. Is there a method to free only the first few blocks without having to malloc a new block and copy the remaining ones? Thank you Nov 13 '05 #1
34 Replies

 P: n/a Kelvin Leung wrote: If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10); afterward I want to free a number of them, say the first 3 blocks, how do I do so? If I tried free(p), the whole 10 blocks are being freed. Is there a method to free only the first few blocks without having to malloc a new block and copy the remaining ones? No. -- Er*********@sun.com Nov 13 '05 #2

 P: n/a On Thu, 30 Oct 2003, Kelvin Leung wrote: If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10); char *p = malloc(10 * sizeof *p); is the more idiomatic way to do that. Or for 'char' specifically, if you're actually using the pointer to point to a string (and thus not expecting 'char' to change to 'short' or 'int' in future code reviews), char *p = malloc(10); as I do below. (See the FAQ and Google Groups for reasons why.) afterward I want to free a number of them, say the first 3 blocks, how do I do so? If I tried free(p), the whole 10 blocks are being freed. Is there a method to free only the first few blocks without having to malloc a new block and copy the remaining ones? Nope. Sorry. To free the first three 'char's, write: { char *p = malloc(10); /* NB: sizeof(char) is 1 by definition */ char *temp; if (p == NULL) exit(EXIT_FAILURE); temp = malloc(7); if (temp == NULL) exit(EXIT_FAILURE); memcpy(temp, p, 7); free(p); p = temp; [...] free(p); } HTH, -Arthur Nov 13 '05 #3

 P: n/a Arthur J. O'Dwyer spoke thus: To free the first three 'char's, write: { char *p = malloc(10); /* NB: sizeof(char) is 1 by definition */ char *temp; if (p == NULL) exit(EXIT_FAILURE); temp = malloc(7); if (temp == NULL) exit(EXIT_FAILURE); memcpy(temp, p, 7); free(p); p = temp; [...] free(p); } Is that preferable to the following (untested) code? { const int size=10; char *p=malloc( size ); char *tmp=p; if( !p ) exit( EXIT_FAILURE ); memmove( p, p+3, size-3 ); /* assumes p has at least four members */ if( (tmp=realloc(p,size-3)) == NULL ) { free( p ); /* not strictly necessary */ exit( EXIT_FAILURE ); } ... free( p ); } -- 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. Nov 13 '05 #4

 P: n/a Arthur J. O'Dwyer wrote: is the more idiomatic way to do that. Or for 'char' specifically, if you're actually using the pointer to point to a string (and thus not expecting 'char' to change to 'short' or 'int' in future code reviews), char *p = malloc(10); This is just as bad as using char *p = malloc(10 * sizeof char); You are in both cases explicitly relying on the type of p. In the first case you might be said to implicitly explicitly rely on the type of p. :p -- Thomas. Nov 13 '05 #5

 P: n/a "Kelvin Leung" wrote: If I allocate a block of memorychar *p = (char*)malloc(sizeof(char)*10); Better: char *p = malloc(10); The cast is spurious and may hide errors, and sizeof(char) equals 1 by definition. Even better: char *p = malloc(10 * sizeof *p); This way you don't even have to care about the malloc expression when the type p points to is ever going to change in the future. afterward I want to free a number of them, say the first 3 blocks, how do Ido so? If I tried free(p), the whole 10 blocks are being freed. Is there amethod to free only the first few blocks without having to malloc a newblock and copy the remaining ones? No, but you may use the realloc function to cut off the tail, so to say. Regards -- Irrwahn (ir*******@freenet.de) Nov 13 '05 #6

 P: n/a Irrwahn Grausewitz spoke thus: No, but you may use the realloc function to cut off the tail, so to say. Considering that OP wanted to free the *first* three elements, realloc() can't do the job alone. -- 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. Nov 13 '05 #7

 P: n/a In "Kelvin Leung" writes: If I allocate a block of memorychar *p = (char*)malloc(sizeof(char)*10); The right way of doing it is: char *p = malloc(10); The cast is a bad idea and the size of a char is not going to change from 1 anytime in the foreseeable future. afterward I want to free a number of them, say the first 3 blocks, how do Ido so? If I tried free(p), the whole 10 blocks are being freed. Is there amethod to free only the first few blocks without having to malloc a newblock and copy the remaining ones? They are called "bytes", not "blocks". You can either free the whole block (by calling free()) or the last part of it (by calling realloc()). There is no way of freeing the beginning of the block, while preserving the data at its end. What you can do is use memmove() to move the data at the beginning of the block and free its last part, with a realloc call. Note, however, that if the realloc() call succeeds, the remaining smaller block may be moved to a new address (but its contents is preserved). Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #8

 P: n/a Christopher Benson-Manica writes: Irrwahn Grausewitz spoke thus: No, but you may use the realloc function to cut off the tail, so to say. Considering that OP wanted to free the *first* three elements, realloc() can't do the job alone. Which is probably why Irrwahn's answer started with "No, but". -- Keith Thompson (The_Other_Keith) ks*@cts.com San Diego Supercomputer Center <*> Schroedinger does Shakespeare: "To be *and* not to be" Nov 13 '05 #9

 P: n/a Dan Pop wrote: Kelvin Leung writes: If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10); The right way of doing it is: char *p = malloc(10); The cast is a bad idea and the size of a char is not going to change from 1 anytime in the foreseeable future. This is bad advice if you need to compile with a C++ compiler: cat malloc.c #include #include int main(int argc, char* argv[]) { const int n = 10; int* p = malloc(n*sizeof(int)); for (int j = 0; j < n; ++j) p[j] = j; for (int j = 0; j < n; ++j) fprintf(stdout, "%2d = p[%2d]\n", p[j], j); return 0; } g++ -x c++ -Wall -ansi -pedantic -O2 -o malloc malloc.c malloc.c: In function `int main(int, char**)': malloc.c:7: warning: invalid conversion from `void*' to `int*' Nov 13 '05 #10

 P: n/a On Wed, 29 Oct 2003 12:00:13 -0800, "E. Robert Tisdale" wrote: Dan Pop wrote: Kelvin Leung writes: char *p = (char*)malloc(sizeof(char)*10); The cast is a bad ideaThis is bad advice if you need to compile with a C++ compiler: > cat malloc.c #include #include int main(int argc, char* argv[]) { const int n = 10; int* p = malloc(n*sizeof(int)); for (int j = 0; j < n; ++j) p[j] = j; for (int j = 0; j < n; ++j) fprintf(stdout, "%2d = p[%2d]\n", p[j], j); return 0; } > g++ -x c++ -Wall -ansi -pedantic -O2 -o malloc malloc.c malloc.c: In function `int main(int, char**)': malloc.c:7: warning: invalid conversion from `void*' to `int*' So what? C++ programs should be using the `new' operator anyway. And C++ is offtopic in c.l.c. Nov 13 '05 #11

 P: n/a Christopher Benson-Manica wrote: Arthur J. O'Dwyer spoke thus: Is that preferable to the following (untested) code? { const int size=10; char *p=malloc( size ); char *tmp=p; if( !p ) exit( EXIT_FAILURE ); memmove( p, p+3, size-3 ); /* assumes p has at least four members */ if( (tmp=realloc(p,size-3)) == NULL ) { free( p ); /* not strictly necessary */ exit( EXIT_FAILURE ); } ... free( p ); I'm assuming that here you mean free(tmp); } I havn't been able to make it core dump but shouldn't it? When you realloc to a large enough size that you have to create a whole new area, shouldn't the vm_struct be destroyed and memory be copied on write to the new region? Assuming linux is posix compliant for realloc, then it *should* apply in a similar manner to all other posix compliant os's. I'm not certain about linux's functionality, my book is at home. -- Harrison Caudill | .^ www.hypersphere.org Computer Science & Physics Double Major | | Me*Me=1 Georgia Institute of Technology | '/ I'm just a normal guy Nov 13 '05 #12

 P: n/a rihad wrote: E. Robert Tisdale wrote:Dan Pop wrote:Kelvin Leung writes: char *p = (char*)malloc(sizeof(char)*10);The cast is a bad ideaThis is bad advice if you need to compile with a C++ compiler: > cat malloc.c #include #include int main(int argc, char* argv[]) { const int n = 10; int* p = malloc(n*sizeof(int)); for (int j = 0; j < n; ++j) p[j] = j; for (int j = 0; j < n; ++j) fprintf(stdout, "%2d = p[%2d]\n", p[j], j); return 0; } > g++ -x c++ -Wall -ansi -pedantic -O2 -o malloc malloc.c malloc.c: In function `int main(int, char**)': malloc.c:7: warning: invalid conversion from `void*' to `int*' So what? C++ programs should be using the `new' operator anyway. And C++ is offtopic in c.l.c. I don't want to discuss C++. But *real* C programmers can't afford to ignore C++. They must write C code which can be compiled by C++ compilers as well as by C compilers. Nov 13 '05 #13

 P: n/a E. Robert Tisdale wrote: Dan Pop wrote: The cast is a bad idea and the size of a char is not going to change from 1 anytime in the foreseeable future. This is bad advice if you need to compile with a C++ compiler: If you need to compile with a C++ compiler, you're in the wrong newsgroup. -- Richard Heathfield : bi****@eton.powernet.co.uk "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton Nov 13 '05 #14

 P: n/a E. Robert Tisdale wrote: #include #include int main(int argc, char* argv[]) { const int n = 10; int* p = malloc(n*sizeof(int)); for (int j = 0; j < n; ++j) p[j] = j; for (int j = 0; j < n; ++j) fprintf(stdout, "%2d = p[%2d]\n", p[j], j); return 0; } I made the obvious fix and it _still_ would not compile with my Fortran compiler. To add insult to injury the above is not even valid Perl syntax. And I though any kind of line noise would go in Perl. Well, I guess my multilingual skills are not what they should be. -- Thomas. Nov 13 '05 #15

 P: n/a "E. Robert Tisdale" wrote: I don't want to discuss C++. But *real* C programmers can't afford to ignore C++. *Real* newsgroup trolls can't keep from mentioning it either, apparently. Brian Rodenborn Nov 13 '05 #16

 P: n/a On Wed, 29 Oct 2003, Charles Harrison Caudill wrote: Christopher Benson-Manica wrote: Is that preferable to the following (untested) code? Well, I didn't think of your way, but both ways work. :) I think the use of 'memmove' instead of 'memcpy' is a little more obscure, and I personally try to avoid 'realloc' in general, just because of the contortions through which one has to go in order to do proper error-checking. But your (Chris's) way works, and I bet there are sane people out there who prefer it over mine. { const int size=10; char *p=malloc( size ); char *tmp=p; if( !p ) exit( EXIT_FAILURE ); memmove( p, p+3, size-3 ); /* assumes p has at least four members */ if( (tmp=realloc(p,size-3)) == NULL ) { free( p ); /* not strictly necessary */ exit( EXIT_FAILURE ); } ... free( p ); I'm assuming that here you mean free(tmp); Probably Chris meant to insert an else { p = tmp; } three lines up, instead. } I havn't been able to make it core dump but shouldn't it? Of course not! When you realloc to a large enough size that you have to create a whole new area, Strictly speaking, you may never *ever* have to "create a whole new area." malloc() could just give you these really gi-normous blocks of memory to begin with. :-) shouldn't the vm_struct be destroyed C has no concept of "vm_struct", unless you, the programmer, decide to define one in your own code. and memory be copied on write to the new region? Assuming linux is posix compliant for realloc, Linux is off-topic for c.l.c. So is POSIX. And as far as I know, the behavior of 'realloc' is not defined or extended in any way by POSIX anyway. [No, I *don't* care.] then it *should* apply in a similar manner to all other posix compliant os's. I'm not certain about linux's functionality, my book is at home. Turns out you don't need it in this newsgroup; the Book here is K&R2, and the Final Authority is the ISO standard. You wanna talk POSIX or vm_structs or whatever, go to a newsgroup where people talk about that stuff. HTH, -Arthur Nov 13 '05 #17

 P: n/a On Wed, 29 Oct 2003, Thomas Stegen wrote: Arthur J. O'Dwyer wrote: is the more idiomatic way to do that. Or for 'char' specifically, if you're actually using the pointer to point to a string (and thus not expecting 'char' to change to 'short' or 'int' in future code reviews), char *p = malloc(10); This is just as bad as using char *p = malloc(10 * sizeof char); Not quite as bad, because it's less verbose. (Also, because it does compile; but I'm sure you meant to add parentheses around 'char' in your example. If you really didn't, then I would strongly disagree that my version is "as bad." ;-) You are in both cases explicitly relying on the type of p. Yes, that is correct. However, C does several clever things with arrays of 'char' that it doesn't do with any other type of array, so if you're going to start passing 'p' to 'strlen' or 'fputs', odds are that the type of 'p' isn't going to change anytime in the foreseeable future (to steal Dan Pop's phrase). In the first case you might be said to implicitly explicitly rely on the type of p. :p If the next line of the function is strcpy(p, "hello"); then IMHO that assumption is perfectly justifiable. -Arthur Nov 13 '05 #18

 P: n/a "E. Robert Tisdale" writes: [...] I don't want to discuss C++. Then don't. But *real* C programmers can't afford to ignore C++. They must write C code which can be compiled by C++ compilers as well as by C compilers. That's complete nonsense, as I'm sure you know. -- Keith Thompson (The_Other_Keith) ks*@cts.com San Diego Supercomputer Center <*> Schroedinger does Shakespeare: "To be *and* not to be" Nov 13 '05 #19

 P: n/a On Wed, 29 Oct 2003 17:23:18 -0500 (EST) "Arthur J. O'Dwyer" wrote: On Wed, 29 Oct 2003, Charles Harrison Caudill wrote: Christopher Benson-Manica wrote: Is that preferable to the following (untested) code? Well, I didn't think of your way, but both ways work. :) I think the use of 'memmove' instead of 'memcpy' is a little more obscure, I don't find memmove any more obscure than memcpy, if anything I find it less obscure because it gives defined results then memcpy invokes UB and when memcpy does not invoke UB memmove behaves the same. and I personally try to avoid 'realloc' in general, just because of the contortions through which one has to go in order to do proper error-checking. Write a realloc wrapper, then you only have to worry about this once. But your (Chris's) way works, and I bet there are sane people out there who prefer it over mine. { const int size=10; char *p=malloc( size ); char *tmp=p; if( !p ) exit( EXIT_FAILURE ); memmove( p, p+3, size-3 ); /* assumes p has at least four members */ if( (tmp=realloc(p,size-3)) == NULL ) { free( p ); /* not strictly necessary */ exit( EXIT_FAILURE ); } ... free( p ); I'm assuming that here you mean free(tmp); Probably Chris meant to insert an else { p = tmp; } three lines up, instead. The advantage I see in the memmove/realloc version written by Christopher over the memcpy/malloc/free version written by Arthur is that it potentially has lower memory requirements and may fragment memory less. After all, if you have only 5 bytes available for mallocing by the C environment the malloc(10) will fail but the realloc(p,size-3) could succeed since it does not need any more memory. -- Mark Gordon Paid to be a Geek & a Senior Software Developer Although my email address says spamtrap, it is real and I read it. Nov 13 '05 #20

 P: n/a Arthur J. O'Dwyer spoke thus: Probably Chris meant to insert an else { p = tmp; } three lines up, instead. Why, yes, yes I did ;( Thanks! -- 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. Nov 13 '05 #21

 P: n/a Mark Gordon spoke thus: I don't find memmove any more obscure than memcpy, if anything I find it less obscure because it gives defined results then memcpy invokes UB and when memcpy does not invoke UB memmove behaves the same. On the other hand, I imagine memmove requires some amount of extra processing time in exchange for defined behavior... -- 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. Nov 13 '05 #22

 P: n/a "E. Robert Tisdale" writes: Dan Pop wrote: Kelvin Leung writes: If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10); The right way of doing it is: char *p = malloc(10); The cast is a bad idea and the size of a char is not going to change from 1 anytime in the foreseeable future. This is bad advice if you need to compile with a C++ compiler: But in that case, it would not be C code anymore. The advice is perfectly fine for anyone writing C code. (Great, not this discussion again...) -- Micah J. Cowan mi***@cowan.name Nov 13 '05 #23

 P: n/a "E. Robert Tisdale" writes: I don't want to discuss C++. But *real* C programmers can't afford to ignore C++. They must write C code which can be compiled by C++ compilers as well as by C compilers. sez you. There are many "*real* C programmers" on this NG that sez otherwise. Unless you have a unique definition for "real" (or "C programmer"). -- Micah J. Cowan mi***@cowan.name Nov 13 '05 #24

 P: n/a In article , Micah Cowan wrote:"E. Robert Tisdale" writes: I don't want to discuss C++. But *real* C programmers can't afford to ignore C++. They must write C code which can be compiled by C++ compilers as well as by C compilers.sez you. There are many "*real* C programmers" on this NG thatsez otherwise. Unless you have a unique definition for "real" (or"C programmer"). The ones who aren't complex, of course. It's the simple C programmers that can't ignore C++. dave (gratuitiously abusing language since... maybe 1982?) -- Dave Vandervies dj******@csclub.uwaterloo.ca We maintain a healthy fiction here that we don't know anything about off-topic subjects, except for such things as food, music, and when to call Lawrence Kirby "Fred". --Martin Ambuhl in comp.lang.c Nov 13 '05 #25

 P: n/a Dave Vandervies wrote: The ones who aren't complex, of course. It's the simple C programmers that can't ignore C++. I think you mean irrational C programmers. -- Thomas. Nov 13 '05 #26

 P: n/a In <3F**************@jpl.nasa.gov> "E. Robert Tisdale" writes: Dan Pop wrote: Kelvin Leung writes: If I allocate a block of memory char *p = (char*)malloc(sizeof(char)*10); The right way of doing it is: char *p = malloc(10); The cast is a bad idea and the size of a char is not going to change from 1 anytime in the foreseeable future.This is bad advice if you need to compile with a C++ compiler: What is a C++ compiler? If it is anything behaving like a conforming standard C compiler, then my advice is excellent. If it is anything else, it is off-topic in this newsgroup. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #27

 P: n/a "E. Robert Tisdale" wrote in message news:<3F**************@jpl.nasa.gov>... [snip] I don't want to discuss C++. But *real* C programmers can't afford to ignore C++. They must write C code which can be compiled by C++ compilers as well as by C compilers. This is the single most asinine thing I've read all week. Either you're writing C (in which case you use a C compiler) or C++ (in which case you use a C++ compiler). They're completely different languages. You wouldn't require someone to write C code that also compiles as Java, would you? How about C#? I've worked on a number of projects that had both C and C++ components; we simply used the appropriate compiler for the given language. I would have thought that was the obvious, logical solution, rather than deliberately crippling our code to meet the demands of two different compilers. Nov 13 '05 #28

 P: n/a In <3F**************@jpl.nasa.gov> "E. Robert Tisdale" writes: But *real* C programmers can't afford to ignore C++.They must write C code which can be compiled by C++ compilersas well as by C compilers. _____________________ /| /| | | ||__|| | Please do not | / O O\__ | feed the | / \ | Trolls | / \ \|_____________________| / _ \ \ || / |\____\ \ || / | | | |\____/ || / \|_|_|/ | _|| / / \ |____| || / | | | --| | | | |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ | || / _ \\ | / `' * / \_ /- | | | * ___ c_c_c_C/ \C_c_c_c____________ Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 13 '05 #29

 P: n/a In article <3f********@nntphost.cis.strath.ac.uk>, Thomas Stegen wrote:Dave Vandervies wrote: The ones who aren't complex, of course. It's the simple C programmers that can't ignore C++.I think you mean irrational C programmers. That works too, but it doesn't follow quite as nicely from "not complex". (Unless you can find another way to get from "real" to "irrational"?) dave -- Dave Vandervies dj******@csclub.uwaterloo.ca Si tu hoc leger scis, tu nimis argutior es. Nov 13 '05 #30

 P: n/a On Thu, 30 Oct 2003 00:48:41 +0000 (UTC) Christopher Benson-Manica wrote: Mark Gordon spoke thus: I don't find memmove any more obscure than memcpy, if anything I find it less obscure because it gives defined results then memcpy invokes UB and when memcpy does not invoke UB memmove behaves the same. On the other hand, I imagine memmove requires some amount of extra processing time in exchange for defined behavior... Yes, it does require extra checks so I still use memcpy when performance matters *and* I can be certain not to have overlapping source & destination. -- Mark Gordon Paid to be a Geek & a Senior Software Developer Although my email address says spamtrap, it is real and I read it. Nov 13 '05 #31

 P: n/a Dave Vandervies wrote: In article <3f********@nntphost.cis.strath.ac.uk>, Thomas Stegen wrote:Dave Vandervies wrote:The ones who aren't complex, of course.It's the simple C programmers that can't ignore C++.I think you mean irrational C programmers. That works too, but it doesn't follow quite as nicely from "not complex". (Unless you can find another way to get from "real" to "irrational"?) I just thought real numbers, complex numbers and irrational numbers. Maybe that is what you thought as well :) -- Thomas. Nov 13 '05 #32

 P: n/a In article <3f********@nntphost.cis.strath.ac.uk>, Thomas Stegen wrote:Dave Vandervies wrote: In article <3f********@nntphost.cis.strath.ac.uk>, Thomas Stegen wrote:Dave Vandervies wrote: [about "real C programmers"] The ones who aren't complex, of course.It's the simple C programmers that can't ignore C++.I think you mean irrational C programmers. That works too, but it doesn't follow quite as nicely from "not complex". (Unless you can find another way to get from "real" to "irrational"?)I just thought real numbers, complex numbers and irrational numbers.Maybe that is what you thought as well :) Well, almost. I thought real and complex numbers (the complex numbers are generally treated as the ones that aren't real, even though they contain the reals as a subset), and then went from complex to simple (to undo the "opposite meaning", y'see). The problem with using irrational there is that irrational numbers aren't generally considered as "not ", so using that distinction didn't leave the same opportunity to get in some mathematically rigorous wordplay at Tisdale's expense. dave -- Dave Vandervies dj******@csclub.uwaterloo.ca Not yet; give it another century or so. As of now, it's still sloppy speech. --Eric the Read in the scary devil monastery Nov 13 '05 #33

 P: n/a E. Robert Tisdale wrote: But *real* C programmers can't afford to ignore C++. They must write C code which can be compiled by C++ compilers as well as by C compilers. A perfect occasion for that fine phrase, "arrant nonsense". -- Allin Cottrell Department of Economics Wake Forest University, NC Nov 13 '05 #34

 P: n/a "Dave Vandervies" wrote in message news:bn**********@rumours.uwaterloo.ca... In article <3f********@nntphost.cis.strath.ac.uk>, Thomas Stegen wrote:Dave Vandervies wrote: In article <3f********@nntphost.cis.strath.ac.uk>, Thomas Stegen wrote:Dave Vandervies wrote: [about "real C programmers"]The ones who aren't complex, of course.>>It's the simple C programmers that can't ignore C++.I think you mean irrational C programmers. That works too, but it doesn't follow quite as nicely from "not complex". (Unless you can find another way to get from "real" to "irrational"?)I just thought real numbers, complex numbers and irrational numbers.Maybe that is what you thought as well :) Well, almost. I thought real and complex numbers (the complex numbers are generally treated as the ones that aren't real, even though they contain the reals as a subset), and then went from complex to simple (to undo the "opposite meaning", y'see). The problem with using irrational there is that irrational numbers aren't generally considered as "not ", so using that distinction didn't leave the same opportunity to get in some mathematically rigorous wordplay at Tisdale's expense. What about "surreal" ? Doesn't involve heavy:-) math and triple indirection. Should be good enough even for simple ones (programmers || trolls:-) Nov 13 '05 #35

### This discussion thread is closed

Replies have been disabled for this discussion.