开发者

Emacs Lisp number crunching (actually, simple addition)

开发者 https://www.devze.com 2023-01-02 02:10 出处:网络
this is what I get when I try to do some calculations in emacs lisp... (+ 2082844800. 1274511600.0) => 1209872752.0

this is what I get when I try to do some calculations in emacs lisp...

(+ 2082844800. 1274511600.0)
=> 1209872752.0
(+ 2082844800.0 1274511600.0)
=> 3357356400开发者_开发知识库.0

Could anyone tell me what's going on and what's the difference between representing a floating-point number with . and .0 at the end? Thanks


Building on Anton's answer and jamessan's answer, and reading the latest NEWS file:

It looks like you've got a 32-bit build of Emacs. Emacs has a limit for integers that is most-positive-fixnum, which has traditionally been 268435455 for 32-bit builds. In the latest Emacs (23.2), the NEWS file indicates:

** The Lisp reader turns integers that are too large/small into floats. For instance, on machines where 536870911' is the largest integer, reading536870912' gives the floating-point object `536870912.0'.

This change only concerns the Lisp reader; it does not affect how actual integer objects overflow.

So, in 23.1 and earlier (on a 32-bit Emacs), 2082844800. was read as an integer, but is too big, causing it to overflow and turn into -64638848.

Adding the .0 suffix in 23.1 forced the lisp reader to treat the number as floating point, causing the math to turn out as you expect.

In Emacs 23.2, the reader does this conversion from integer to float for you automatically if the number is too large. So if you upgrade, you won't have to worry about this.


Try

(floatp 2082844800.) 
(floatp 2082844800.0)
(integerp 2082844800.)

also

(+ 0 2082844800.)

Hope that helps


Using Emacs 23.2, I see no difference between the two expressions. Which version are you using and how are you performing the calculations?


It depends on what the largest integer value your build of Emacs can represent. Anything above that is promoted from an integer to a float. You can access this information through the most-positive-fixnum/most-negative-fixnum variables. In my case, most-positive-fixnum is 536870911 which is smaller than the 2082844800 and therefore explains why both expressions were the same for me.

0

精彩评论

暂无评论...
验证码 换一张
取 消