Re: Number representation (was: Hungarian notation - whoops!)

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

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,
	    <negative finite numbers>,
		-epsilon
		<NO zero>
		+epsilon
	    <positive finite numbers>
	+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" <ok>
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" <Robert@hever.demon.co.uk> 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" <ok>
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 <msmith@mpx.com.au> 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.