🚀 go-pugleaf

In article <416ouv$ekq@newsbf02.news.aol.com>,
ffarance@aol.com (FFarance) wrote:

 > ::  From: thads@csn.net (Thad Smith)

 > :: 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).

 > No.  You'd probably also conclude that any number could be treated
 > as a series of 8-bit bytes and stored as several fields in a
 > structure.

There is great utility in counting beyond 255.  Very little in
counting beyond 2 to the 64th.

 > 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.

 > 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.

 > 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.

 > 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.

Thad