[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

an alternate BOGUS-FIXNUMS proposal

   From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
   Date: Wed, 13 Jul 88 09:52:31 MDT

   - It does not address the issue of what happens to the BIGNUM type

I wouldn't be adverse to removing BIGNUM as a type specifier altogether.

   - Programmers would still be able to put FIXNUM declarations in their
     code, but under this proposal FIXNUMs would not necessarily guarantee
     the most efficient representation (which appears to be the main reason
     why people are so anxious to preserve the FIXNUM type in the first

It would guarantee an efficient representation in all cases where it can be
reasonably expected to do so.  That is, in all implementations which have a
sufficiently large range of efficient integers.

   Also, note that if users specify a smaller subrange of integers than
   the nominal FIXNUM size in their declarations, it may be possible to
   get even more improvements in performance.

That's right.  Users can always take the extra time and effort needed to do a
more detailed range analysis in especially critical sections of code.

Use of FIXNUM's is not always prompted by programmers' laziness in analyzing
their code.  The problem is that in those implementations which do support
fixnums, the efficiency difference between fixnums and bignums is usually
fairly large.  It's large enough that users are willing to structure their
code to take note of it.  Different algorithms (e.g. different space/speed
tradeoffs) might be appropriate for fixnums and bignums.  In Macsyma, there
are a number of instances where an argument is checked for being a fixnum,
and different code is used if it is (actually it's often the same code,
but full of fixnum declarations for all the intermediate results).  This
is not something that can be done with range declarations.  The following piece
of code is also from Macsyma:
   (DO ((I 0 (1+ I))
    ((= I 20.)))
This makes a table of the 20 largest primes which fit in a fixnum.  The table
is used to good effect by various algorithms within Macsyma.  Do you really
wish to disallow these kinds of optimizations?

Common Lisp goes to some trouble to provide for the needs of people writing
serious numerical floating point code.  I think recognizing the (possibility
of the) FIXNUM/BIGNUM distinction is the minimum that can be done for people
writing serious numerical integer code.  There may be a problem with the more
"casual" use of FIXNUM declarations for loop counters and such, but I don't
think that the way to address that problem is to pretend the distinction
doesn't exist.