GNU bug report logs - #33765
emacs-26.1-mac-7.4; (expt 2 140) ; produces 0 in scratch buffer, unexpectedly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33765 in the body.
You can then email your comments to 33765 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van L <van <at> scratch.space>
To: bug-gnu-emacs <at> gnu.org
Subject: emacs-26.1-mac-7.4; (expt 2 140) ;
 produces 0 in scratch buffer, unexpectedly
Date: Sun, 16 Dec 2018 17:24:18 +1100

Hello,

I was pushed to by reading the following to report this bug.

┌────
│ In this business we speak the language of mathematics
│ https://www.washingtonpost.com/local/obituaries/evelyn-berezin-entrepreneur-and-engineer-who-designed-early-word-processor-dies-at-93/2018/12/13/20af4524-fee7-11e8-ad40-cdfd0e0dd65a_story.html
└────


- ------------------------------------------------------------------

#+NAME: unexpected-result-in-scratch-buffer
#+BEGIN_SRC emacs-lisp
(expt 2 140) ; unexpected result is 0
#+END_SRC

- ------------------------------------------------------------------

#+NAME: result-for-comparison

      Chez Scheme Version 9.5
      Copyright 1984-2017 Cisco Systems, Inc.

      > (expt 2 140)
      1393796574908163946345982392040522594123776
      

Message #8 received at 33765 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org,Van L <van <at> scratch.space>,33765 <at> debbugs.gnu.org
Subject: Re: bug#33765: emacs-26.1-mac-7.4; (expt 2 140) ;
 produces 0 in scratch buffer, unexpectedly
Date: Sun, 16 Dec 2018 09:29:09 +0200

On December 16, 2018 8:24:18 AM GMT+02:00, Van L <van <at> scratch.space> wrote:
> Hello,
> 
> I was pushed to by reading the following to report this bug.
> 
> ┌────
> │ In this business we speak the language of mathematics
> │
> https://www.washingtonpost.com/local/obituaries/evelyn-berezin-entrepreneur-and-engineer-who-designed-early-word-processor-dies-at-93/2018/12/13/20af4524-fee7-11e8-ad40-cdfd0e0dd65a_story.html
> └────
> 
> 
> - ------------------------------------------------------------------
> 
> #+NAME: unexpected-result-in-scratch-buffer
> #+BEGIN_SRC emacs-lisp
> (expt 2 140) ; unexpected result is 0
> #+END_SRC
> 
> - ------------------------------------------------------------------
> 
> #+NAME: result-for-comparison
> 
>       Chez Scheme Version 9.5
>       Copyright 1984-2017 Cisco Systems, Inc.
> 
>       > (expt 2 140)
>       1393796574908163946345982392040522594123776
>       

Why do you say this is unexpected?

If you want the same support for huge numbers as in Scheme, try Emacs 27.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van L <van <at> scratch.space>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, 33765 <at> debbugs.gnu.org
Subject: Re: bug#33765: emacs-26.1-mac-7.4; (expt 2 140) ;
 produces 0 in scratch buffer, unexpectedly
Date: Sun, 16 Dec 2018 22:11:25 +1100

> Why do you say this is unexpected?

I am not a mathematician but I believe the answer is wrong for 2^140.

> If you want the same support for huge numbers as in Scheme, try Emacs 27.

I take that to mean the master branch but the emacs-mac repo-updates are less freq. than gnu-emacs’s.

Thanks.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van L <van <at> scratch.space>
Cc: bug-gnu-emacs <at> gnu.org, 33765 <at> debbugs.gnu.org
Subject: Re: bug#33765: emacs-26.1-mac-7.4; (expt 2 140) ;
 produces 0 in scratch buffer, unexpectedly
Date: Sun, 16 Dec 2018 15:07:48 +0200

On December 16, 2018 1:11:25 PM GMT+02:00, Van L <van <at> scratch.space> wrote:
> 
> > Why do you say this is unexpected?
> 
> I am not a mathematician but I believe the answer is wrong for 2^140.

The correct value cannot be represented in an Emacs fixnum.  What did you expect Emacs to do?  IOW, what would be the "expected" result, given the limited range of integers we can represent?

> > If you want the same support for huge numbers as in Scheme, try
> Emacs 27.
> 
> I take that to mean the master branch but the emacs-mac repo-updates
> are less freq. than gnu-emacs’s.

Some features, such as this one, will not be available in older versions.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van L <van <at> scratch.space>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, 33765 <at> debbugs.gnu.org
Subject: Re: bug#33765: emacs-26.1-mac-7.4; (expt 2 140) ;
 produces 0 in scratch buffer, unexpectedly
Date: Mon, 17 Dec 2018 08:24:21 +1100

>>> Why do you say this is unexpected?
>> 
>> I am not a mathematician but I believe the answer is wrong for 2^140.
> 
> The correct value cannot be represented in an Emacs fixnum.  What did you expect Emacs to do?  IOW, what would be the "expected" result, given the limited range of integers we can represent?

I expect no answer and an error out with an informative explanation if asked for, when Emacs is unable to do.

>>> If you want the same support for huge numbers as in Scheme, try
>> Emacs 27.
>> 
>> I take that to mean the master branch but the emacs-mac repo-updates
>> are less freq. than gnu-emacs’s.
> 
> Some features, such as this one, will not be available in older versions.

A helpful place to explain the versioning policy would be a file in the emacs/etc directory.

Version 26 means stable, 27 means unstable is my guess.

Message #32 received at 33765 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van L <van <at> scratch.space>
Cc: 33765 <at> debbugs.gnu.org
Subject: Re: bug#33765: emacs-26.1-mac-7.4; (expt 2 140) ;
 produces 0 in scratch buffer, unexpectedly
Date: Mon, 17 Dec 2018 17:53:37 +0200

> From: Van L <van <at> scratch.space>
> Date: Mon, 17 Dec 2018 08:24:21 +1100
> Cc: bug-gnu-emacs <at> gnu.org,
>  33765 <at> debbugs.gnu.org
> 
> > The correct value cannot be represented in an Emacs fixnum.  What did you expect Emacs to do?  IOW, what would be the "expected" result, given the limited range of integers we can represent?
> 
> I expect no answer and an error out with an informative explanation if asked for, when Emacs is unable to do.

Since we already do better than that on the master branch (including
signal an overflow error when even a bignum cannot represent the
result), I think this bug is already solved and should be closed.

> A helpful place to explain the versioning policy would be a file in the emacs/etc directory.
> 
> Version 26 means stable, 27 means unstable is my guess.

We don't have stable and unstable releases.  We have a release branch
and a development branch, and their roles are described in CONTRIBUTE.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.