🚀 go-pugleaf

In article <413qbk$jeq@newsbf02.news.aol.com>,
ffarance@aol.com (FFarance) wrote:
> As I read the competing interests in WG14, there are
>those (implementors, of course) that want the number as small as
>possible and others (e.g., users) that want the number as large as
>possible (possibly unlimited).  The following is my reading of possible
>values:
>
>	32 bits: Not useful - we already have this now in C.
>
>	64 bits: Minimally useful because it satisfies a need for
>	having a 64-bit type.  This is not enough for the 128-bit
>	types of IEEE 1596.5.
>
>	96 bits: An oddball number (people would want 64 or 128, not
>	96).  This is not enough for the 128-bit types of IEEE 1596.5.
>
>	128 bits: Acceptable for IEEE 1596.5.  Good (probably) for the
>	next 10 years as 128-bit machines become available.  There is
>	some grumbling from implementors emulating this arithmetic on
>	their machines.

I haven't seen IEEE 1596.5, but have to wonder what the uses of
integers beyond 40 bits or so is.  The primary point of integers is to
count.  When do you need to count beyond 2 to the 40th?  2 to the
64th?

Other conceivable uses are for high-resolution fixed point arithmetic
(why not use floating point?), structures holding several fields (why
not declare these as actual structures?) and number theory, as used in
RSA computing (you need more precision anyway for this application).

Thad
>	256 bits: There aren't a whole lot of applications or users
>	screaming for this.  This would be a burden on implementors
>	for a feature that would hardly be used.
>
>	>256 bits: About the only reason for larger precision might be
>	handling 307 digit RSA keys (about 1020 bits of arithmetic)
>	in PGP security.  Again, users haven't been screaming for this.
>
>	Arbitrary precision: There isn't a minimum maxima, so this
>	would revert to 32 bits for strictly conforming applications --
>	not useful.
>
>Since the minimum maxima is a separable issue, I'd expect that we will
>revisit this many times in C9X.  We really need to hear all sides on
>this issue (vendors, test suites, users, etc.) to make an informed
>decision.  I will be collecting this information to include in the SBEIR
>rationale.  If you'd like to propose a specific minimum maxima, send me
>E-mail at "frank@farance.com" with your suggestion and its rationale
>(don't just send a number without rationale).  Thanx in advance for your
>input.
>
>-FF
>-------------------------------------------------------------------
>(``I only use AOL for reading netnews.'')
>Frank Farance, Farance Inc.
>E-mail: frank@farance.com, Telephone: +1 212 486 4700
>ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor