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

*To*: info-dylan@CAMBRIDGE.APPLE.COM*Subject*: Re: small integers*From*: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU*Date*: Thu, 08 Oct 92 03:09:06 -0400*In-reply-to*: Your message of Wed, 07 Oct 92 17:57:37 -0500. <9210072201.AA21644@brazil.cambridge.apple.com>

I generally like Rob Maclachlan's proposal for small and extended integer types. (Not surprising, perhaps, since Rob and I have discussed these issues before.) The Common Lisp decision to create a single integer type, with automatic rollover into bignums as needed, is conceptually very elegant, but I've gradually, relucantly, come around to the conclusion that it was a mistake for real programming on real machines. Assuming that the short-integers (or fixnums, in CL parlance) are of reasonable size -- 28 bits or more is typical -- bignums are rarely used, but having them available at all times is expensive. The bignum code significantly increases the size of the runtime system, and if you want fixnum arithmetic to compile efficiently inline you have to put "fixnum" type-declarations *everywhere*. I wish I had a dollar for every (the fixnum ...) form I've written (or that a macro has written for me) in the past five years. Under Rob's proposal, small-integer arithmetic would once again be easy and efficient, and the extended-integer stuff could be an optional facility. Some very small implementations of Dylan could decline to support extended numbers at all, and others could load the extended arithmetic code only when it is used. Ratios (which often cross over into bignums) could be supported as yet another optional facility. I have two quibbles with Rob's proposal: Numeric operations on non-integers with integer results (truncate,floor,ceiling,round,/-variants,numerator,denominator, probably real-part, imag-part) always return <extended-integer>s. This seems like the wrong default to me if we don't want extended-integers to be sneaking in the back door all the time. Second, I think users may find it very confusing to have an extended-integer 5 and a short-integer 5 that print the same, and it is awkward not to be able to type in the extended integers. I think that the extended integers need to be decorated in some way so that they are visually different from short integers. One possibility would be to use a training decimal point to indicate an extended integer: 5. would be extended, while 5 is a short-integer. Alternatively, some # code might be used. I'm not sure if any existing language makes this same distinction and has come up with a better convention. -- Scott =========================================================================== Scott E. Fahlman School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 Internet: sef+@cs.cmu.edu

**References**:**small integers***From:*Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU

- Prev by Date:
**REQUIRED FILES for GAMBIT implementation of THOMAS** - Next by Date:
**REQUIRED FILES for GAMBIT implementation of THOMAS** - Previous by thread:
**small integers** - Next by thread:
**Re: small integers** - Index(es):