From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,30e368bdb3310fe5 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Number representation (was: Hungarian notation - whoops!) Date: 1996/02/19 Message-ID: <4g99ov$gir@goanna.cs.rmit.EDU.AU> X-Deja-AN: 140043787 references: <30C40F77.53B5@swsbbs.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2 Date: 1996-02-19T00:00:00+00:00 List-Id: tsw@3do.com (Tom Watson) writes: >In article <4fms62$c0p@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU >(Richard A. O'Keefe) wrote: >> >> >By the way, S&M is of course the right representation of floating-point, >> >using 2's complement for floating-point is a goof that only a designer >> >not understanding fpt would make! >> I did _not_ write that, I _quoted_ it. >I'm not so sure. With sign & magnitude you get TWO representations of the >same number (zero). In the B6700, you did indeed get two representations of 0, but unless you used some non-standard extensions (-0 .EQ. 0) but (.NOT.(-0 .IS. 0)) nothing in your program could depend on this fact. The presence of two signed integer zeros (which were the same as the two signed floating point zeros) was something that a programmer could and did completely ignore. All the hardware had to do was to make sure that -0 and +0 acted the same in ordinary comparisons. >Some may argue that the difference is that negative >zero is what a very small negative number decays into, and positive zero >is what a very small positive number decays into. That is not the way it worked in the B6700 or the DECsystem-10. So you have two representations of 0 with identical arithmetic properties. So what? Comparison hardware has to worry, programmers don't. The VAX uses (used?) a sign-and-magnitude format, but never generated -0.0 and regarded the "-0.0" representation as an "illegal operand". As for IEEE arithmetic, I find that it helps to think of it as having NO representation for 0. Instead, it can represent -1/epsilon, , -epsilon +epsilon +1/epsilon >My understanding of numbers (no, I'm not an expert at this!) is that >zero is only ONE number (basically without sign). Most numbering >systems (like two's complement integers) have put in the positive >domain. >Programs didn't need to test for >multiple incantations of zero (which needs to be done with IEEE numbers if >the hardware doesn't detect BOTH forms). Should "incantations" be "incarnations"? If the hardware doesn't process +0 and -0 and process them distinctly, isn't IEEE. >As far as I can see, the only good thing (tm) that multiple (+ & -) zeros >gets you is multiple infinities when you divide by it (which may be the >object). As long as both positive and negative numbers exist, and there >is SOME method of making a bit pattern happen for each of them that are >defined, it probably doesn't mean much which bits are turned on (use gray >code, I don't care). Just make sure that all the operations necessary are >working, and give proper (documented) results. I think I should make it clear that when I criticised twos-complement as silly because it significantly complicates the arithmetic model that the programmer has to work with, I was not particularly concerned about the hardware representation of numbers. To a programmer who "grew up" with a machine having 48 data bits of which numbers used only 47, it is obvious that the connection between numbers and bits is only conventional. (For example, you could pack 6 EBCDIC characters per word using bit instructions, but try to do it using integer arithmetic and you were sure of an overflow.) What I care about is programs running on "hopefully sufficiently large" machines that turn out _not_ to be "sufficiently large" being quietly given wrong answers. There are occasions when Ada 95's modular types are exactly the right thing to use. There are many more when plain integer types are right, and I'm glad that Ada _encourages_ overflow detection. >From ok Mon Feb 19 18:10 EST 1996 Received: (from ok@localhost) by goanna.cs.rmit.EDU.AU (8.7.1/8.6.9) id SAA15322; Mon, 19 Feb 1996 18:10:40 +1100 (EST) Date: Mon, 19 Feb 1996 18:10:40 +1100 (EST) From: "Richard A. O'Keefe" Message-Id: <199602190710.SAA15322@goanna.cs.rmit.EDU.AU> To: ok Subject: follow failed Content-Type: text Content-Length: 1504 posted, but mailed to the moderator for approval. Your response has been saved in ~/dead.letter Your article follows: Newsgroups: comp.lang.c.moderated Subject: Re: But DO C hackers code concisely? References: <4fa7e7$2pu@solutions.solon.com> <4fst4u$2f1@solutions.solon.com> <4fvh88$e3l@solutions.solon.com> "Robert F. Monroe" writes: >What conceivable use could there be for either printf or scanf in a >Windows DLL? The very nature of Windows I/O would cause them to only >produce garbage. Well, the C standard *requires* them. If you haven't got printf() and scanf(), you haven't got a "hosted" C implementation. printf(~~1~~) === fprintf(stdout, ~~1~~) and scanf(~~2~~) === fscanf(stdin, ~~2~~) so the problem is not printf and scanf per se but stdin and stdout, and if you haven't got _them_ you haven't got a conforming "hosted" C implementation either. One very good reason for having them in the library is precisely to catch code which has been ported to Windows but incompletely. Since Microsoft C has exceptions, I would think it appropriate for - input from stdin, however expressed - output to stdout, however expressed to raise an exception, and for the library to define printf &c so that user code cannot accidentally rely on defining them to do something different. getchar, putchar, printf, scanf, could all share the same few "raise exception" bytes. In any case, this is irrelevant to the original example, which used sprintf not printf. >From ok Mon Feb 19 18:17 EST 1996 Received: (from ok@localhost) by goanna.cs.rmit.EDU.AU (8.7.1/8.6.9) id SAA15797; Mon, 19 Feb 1996 18:17:38 +1100 (EST) Date: Mon, 19 Feb 1996 18:17:38 +1100 (EST) From: "Richard A. O'Keefe" Message-Id: <199602190717.SAA15797@goanna.cs.rmit.EDU.AU> To: ok Subject: follow failed Content-Type: text Content-Length: 1348 posted, but mailed to the moderator for approval. Your response has been saved in ~/dead.letter Your article follows: Newsgroups: comp.lang.c.moderated Subject: Re: But DO C hackers code concisely? References: <4fa7e7$2pu@solutions.solon.com> <4fst4u$2f1@solutions.solon.com> I gave the example of complex code that could have been replaced by tiny calls to sprintf. Michael Smith writes: >Yes I do think that MS leaving these functions out is realy stupid, >but you have to work with the tools you have. This doesn't in the least spoil my argument. Assume that leaving the printf() and scanf() _families_ out of the library used with DLLs is a good decision, and ignoring wsprintf(), (a) This wasn't a DLL, it was a complete program. (b) Converting integers from binary to text is pretty useful. If sprintf() is not available, or if efficiency is a concern and sprintf() proves slow, the answer is to write functions struct Integer_Format { unsigned char base; /* 2, 8, 10, 16 */ unsigned char pad ; unsigned char width; /* a minimum value */ }; static const struct Integer_Format plain = {10, ' ', 1}; ltostr(char *buf, long val, struct Integer_Format *); ultostr(char *buf, unsigned long val, struct Integer_Format *); or something similar, and stick them in your personal library. -- Election time; but how to get Labour _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.