Just spent a day and a half hunting down a bug that was making me question my sanity. As it turns out, #emacs #lisp's / function silently drops the decimal in its result if both of its inputs are integers... so (/ 1 2) evaluates to 0, not 0.5. Granted, this is also the way that C does it, but in my defense, #CommonLisp does not do this.
in reply to Jonathan Lamothe

As a first approximation, I suggest thinking of Emacs Lisp as closer to MacLisp than to Common Lisp.

A precise description of "closer" would be fairly long.
For example, Emacs Lisp acquired things like bignums and lexical bindings fairly late.

Again as an approximation, the descendancies are:
MacLisp → Emacs Lisp
MacLisp and others → Common Lisp
(Those others include, in alphabetical order, Interlisp, Scheme, Zeta Lisp, etc., but not Emacs Lisp.)

And then an important aspect of these approximations is the `cl' package, also a late addition that evolved quite a bit.

Transferring knowledge about C to Emacs Lisp is rather tricky, even though the implementation of a part of Emacs (including the Emacs Lisp virtual machine) is written in C.

#CommonLisp
#Elisp
#Emacs
#EmacsLisp

@me

in reply to Jonathan Lamothe

yup of course, but that's integer math, not floating point math

GNU Clisp and SBCL don't show decimals for integer division, but return fractions instead!

* (/ 1 2)
1/2

But of course if you use floating point representation for the parameters then the result is a floating point number as expected:
[1]> (/ 1.0 2.0)
0.5

Elisp, with floating point parameters, also works as expected:
(/ 1.0 2.0)
0.5

In C, with IEEE 754 double values, then 1.0/2.0 = 0.50, exactly, no rounding or epsilon comparison needed.

This website uses cookies. If you continue browsing this website, you agree to the usage of cookies.