🚀 go-pugleaf

> From: thads@csn.net (Thad Smith)
> 
> 
> There is great utility in counting beyond 255.  Very little in
> counting beyond 2 to the 64th.

As I said before, the appliations don't *count* beyond 64-bits, but
*operate* with numbers that large.  Counting is one but not all uses
of numbers.

>  > While anything can be decomposed, there is utility in having a
>  > complete integer.
> 
> While fields can be crammed into a single unit and called an integer,
> the utility decreases as the size increases.  In the rare cases where
> there are significant advantages, such as cryptography, we can use
> explicit multiple-precision routines, rather than bloat the required
> language translator and library.

First, the utility is the same -- large or small.  If you need to perform
arithmetic operations with X-bit integers, they should look the same.  The
size doesn't change their utility.

Second, it doesn't ``bloat'' the translator and library.  If you call the
multi-precision routines explicitly or implicitly, the size of the library
is the same.  If fact it is probably less in some cases because the
translator can generator better code than the library.  The use of the
translator might permit better optimizations that had the programmer
called library functions.  Also, the changes to the translator are
small (see previous posting on the thread ``long longs in c'').

Third, the programmer doesn't get this right when he/she codes an
arithmetic expression as a bunch of function calls.  The use of an
inuitive syntax (i.e., arithmetic expressions) helps the programmer avoid
mistakes.

You might ask why can't this be done as a class library in C++?  The
answer is that the overloading feature is messed up.  You have to extend
the promotion rules by *itemizing* all the combinations.  This requires
1000's of function prototypes just to do arithmetic.  If you don't believe
me, try implementing the *existing* C arithmetic types (e.g., call them
"c_int", "c_char", "c_float", etc.) as a *quality* class library, i.e.,
something you'd actually use rather than a toy program.  You'll find that
the C++ overloading mechanism is not good for arithmetic types.  There is
a better way -- some people are working on this in C9X, but there aren't
any specific proposals yet.  I report back when there are proposals on
any type of overloading feature.

> > In the timestamp example, I'd expect to do arithmetic on the
> > *complete number*, not each part separately.
> 
> While it might be a convenience in having a single number spanning
> from nanoseconds to centuries, most applications do not need that
> combination of resolution and range.

A good number of applications need more than 32-bits (heck, Bill Gates
needs more than 32-bits to store his net worth :-).  Applications *do*
need 64-bits precision for time (e.g., POSIX systems with incremental
timers).  Crypto stuff needs more than this.  I think you're confusing
applications that count (e.g., timers) with applications that use numbers
for modeling.

> > Similarly, with the fat pointer I expect to perform arithmetic on
> > it as a 64-bit number -- you wouldn't represent a ``far'' pointer
> > as a structure because you'd treat it as a single entity.
> 
> I would be suspicious of arithmetic performed on a fat pointer
> consisting of an IP address + machine address.  If the operation were
> not test fir equality, I would expect that the operands be
> constrained to have the same IP, in which case you are accessing the
> components of the compound units.

You are thinking of ``far'' pointers rather than ``huge'' pointers (both
the same size, but the use is different).  If my object spans several
machines, this is a convenient way to address it.  And yes, I can walk
it with a pointer increment (full 64-bit addition).  Some of the
distributed memory architectures use this technique.

>  > Meanwhile, there are still applications in mathematics,
>  > handwriting systems, and databases for more than 64 bits.
>  > Floating point isn't as convenient (different semantics, lower
>  > performance) than fixed pointer arithmetic for certain
>  > applications.  What applications? Picture any program you've
>  > written that uses integer types.  Now change the declarations so
>  > floating types are used.  Does the program behave the same (i.e.,
>  > same functionality) and have the same performance? If not, you've
>  > got an example of an application where fixed point is more
>  > convenient than floating point.
> 
> Current fixed point usage is usually more efficient than floating
> point in the places it is now used.  In general, though, applications
> don't require ultra-long ints, as is being discussed.  I would agree
> that if 128-bit integers do something useful that isn't feasible (or
> efficient) with 32- or 64-bit ints or floating point arithmetic, we
> should consider adding it to standard language support.  I think that
> the utility and costs of ultra-long ints should be realistically
> considered.

You keep saying that these applications don't exist, yet I keep pointing
out applications that do exist.  In each application, you point to a
work around which is just that: it may work, but it is inconvenient.  The
problem is that is inconvenient for many people.  I think you need to
make a stronger argument why you believe that all the people persuing
this should be no longer interested in this feature.

-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