tags:

views:

482

answers:

7

And why don't they change it?

Edit: The reason ask is because I'm new to emacs and I would like to use Emacs as a "programmer calculator". So, I can manipulate 32-bit & 64-bit integers and have them behave as they would on the native machine.

+6  A: 

The remaining 3 bits are used as flags by the Lisp interpreter. (You can get bigger integers by compiling Emacs for a 64-bit machine.)

cjm
A: 

That is only true for 32 bit architectures, and can be changed based on build options. The other bits are used for tagging the basic data structures.

You can use a 64-bit build which has larger integers, and there are packages for arbitrarily large integer arithmetic.

Or, you're just asking a rhetorical question trying to sound angry and important...

Trey Jackson
+1  A: 

In many Lisp implementations, some of the bits in a word are used for a tag. This lets things like the garbage collector know what is a pointer and what isn't without having to guess.

Why do you care how big an Elisp fixnum is? You can open gigantic files as it is.

jfm3
+3  A: 

The other three bits are used as a tag of the type of object. This used to be so prevalent that a number of CPU architectures included at least some support for tagged integers in their instruction sets: Sparc, Alpha, Burroughs, and the K-Machine for example. Nowadays we let the Lisp runtime deal with tags, without additional hardware support. I'd recommend reading the first link, about Sparc, if you want to get a quick overview of the history.

DGentry
+13  A: 

Emacs-Lisp is a dynamically-typed language. This means that you need type tags at runtime. If you wanted to work with numbers, you would therefore normally have to pack them into some kind of tagged container that you can point to (i.e. “box” them), as there is no way of distinguishing a pointer from a machine integer at runtime without some kind of tagging scheme.

For efficiency reasons, most Lisp implementations do therefore not use raw pointers but what I think is called descriptors. These descriptors are usually a single machine word that may represent a pointer, an unboxed number (a so-called fixnum), or one of various other hard-coded data structures (it's often worth encoding NIL and cons cells specially, too, for example).

Now, obviously, if you add the type tag, you don't have the full 32 bits left for the number, so you're left with 26 bits as in MIT Scheme or 29 bits as in Emacs or any other number of bits that you didn't use up for tagging.

Some implementations of various dynamic languages reserve multiple tags for fixnums so that they can give you 30-bit or even 31-bit fixnums. SBCL is one implementation of Common Lisp that does this. I don't think the complication that this causes is worth it for Emacs, though. How often do you need fast 30-bit fixnum arithmetic as opposed to 29-bit fixnum arithmetic in a text editor that doesn't even compile its Lisp code into machine code (or does it? I don't remember, actually)? Are you writing a distributed.net client in Emacs-Lisp? Better switch to Common Lisp, then! ;)

Matthias Benkard
+4  A: 

Others have commented on why fixnums are only 29 bits wide. But if you want a programmer's calculator, check out calc. It offers arbitrary-precision integers, matrix operations, unit conversions, graphics via gnuplot, statistical functions, financial functions, scientific functions, RPN and algebraic notation, formula simplification... and it's already part of Emacs, so to get started, visit the Info node for "calc" and start at the tutorial.

Jouni K. Seppänen
A: 

I use the Common Lisp interpreter CLISP as a programmer's calculator. Common Lisp has the sanest number handling that I've seen in any programming language; most notably, it has integers of arbitrary size, i.e. bignums, as well as rational numbers. It also has input in arbitrary number bases and bitwise functions for bignums. If you want to calculate from within Emacs, you can run CLISP in an M-x shell. As a bonus, the syntax is almost exactly the same as what you would use in Emacs Lisp.