4 ms·

Small numbers are "eq" in python. It saves space and time, because probably those numbers dont even exist, and the value is derived from the pointer value. >

Small numbers are "eq" in python. It saves space and time, because probably those numbers dont even exist, and the value is derived from the pointer value. >>> a=3 >>> b=3 >>> a is b True >>> a=1e20 >>> b=1e20 >>> a is b False But in Commonlisp all numbers are "eq". Very strange. Is there heap of numbers and once created, they reuse those? [4]> (setq b 1E20) 1.0E20 [5]> (setq a 1E20) 1.0E20 [6]> (eq a b) T

Jtsummers 1y ago
> But in Commonlisp all numbers are "eq" No, that's not true. >> numbers with the same value need not be eq, http://clhs.lisp.se/Body/f_eq.htm#eq http://clhs.lisp.se/Body/f_eq.htm#eq It's not guaranteed that eq will return true for two numbers of the same value in Common Lisp. It happens to work much of the time, but it is never guaranteed to work. For a given implementation it could even be true all the time (as it's not disallowed), but for portability it should not be relied upon.
kazinator 1y ago
In Common Lisp, in fact, no numbers are required to be eq! Even (eq 0 0) is not required by ANSI CL to return true. Why your Lisp implementation produces true for (eq a b) is probably because of the following. Firstly, in Common Lisp there are single and double precision floats. Floating point tokens written with E or e are single. An implementation is allowed to map that to a 32 bit float. If the implementation has 64 bit values, it can easily arrange for single precision floats to be unboxed without any special tricks; they need only half the word. Try evaluating with 1D+20 to see what that does. But even 64 bit values can be unboxed with a trick called NAN tagging. I implemented NAN tagging in TXR Lisp (which has only double-precision floats), enabled on 64 bit targets: 64 bit machine: 1> (eq 1E20 1E20) t 2> (sizeof val) 8 32 bit machine: 1> (eq 1E20 1E20) nil 2> (sizeof val) 4 On 32 bits, floating-point objects are on the heap. It's pretty important to have unboxed floats for intense numerical work.

Jtsummers 1y ago

> But in Commonlisp all numbers are "eq" No, that's not true. >> numbers with the same value need not be eq, http://clhs.lisp.se/Body/f_eq.htm#eq http://clhs.lisp.se/Body/f_eq.htm#eq It's not guaranteed that eq will return true for two numbers of the same value in Common Lisp. It happens to work much of the time, but it is never guaranteed to work. For a given implementation it could even be true all the time (as it's not disallowed), but for portability it should not be relied upon.

kazinator 1y ago

In Common Lisp, in fact, no numbers are required to be eq! Even (eq 0 0) is not required by ANSI CL to return true. Why your Lisp implementation produces true for (eq a b) is probably because of the following. Firstly, in Common Lisp there are single and double precision floats. Floating point tokens written with E or e are single. An implementation is allowed to map that to a 32 bit float. If the implementation has 64 bit values, it can easily arrange for single precision floats to be unboxed without any special tricks; they need only half the word. Try evaluating with 1D+20 to see what that does. But even 64 bit values can be unboxed with a trick called NAN tagging. I implemented NAN tagging in TXR Lisp (which has only double-precision floats), enabled on 64 bit targets: 64 bit machine: 1> (eq 1E20 1E20) t 2> (sizeof val) 8 32 bit machine: 1> (eq 1E20 1E20) nil 2> (sizeof val) 4 On 32 bits, floating-point objects are on the heap. It's pretty important to have unboxed floats for intense numerical work.