GNU bug report logs - #41347
28.0.50; calculator.el: Cannot input negative exponents

Previous Next

Package: emacs;

Reported by: Chris Zheng <chriszheng99 <at> gmail.com>

Date: Sun, 17 May 2020 05:54:02 UTC

Severity: normal

Found in version 28.0.50

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Eli Barzilay <eli <at> barzilay.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 41347 <at> debbugs.gnu.org, Chris Zheng <chriszheng99 <at> gmail.com>
Subject: bug#41347: 28.0.50; calculator.el: Cannot input negative exponents
Date: Sun, 17 May 2020 16:26:39 -0400

On Sun, May 17, 2020 at 7:08 AM Mattias Engdegård <mattiase <at> acm.org> wrote:
>
> > @@ -863,7 +863,7 @@ calculator-string-to-number
> >      (let* ((str (replace-regexp-in-string
> >                   "\\.\\([^0-9].*\\)?$" ".0\\1" str))
> >             (str (replace-regexp-in-string
> > -                 "[eE][+-]?\\([^0-9].*\\)?$" "e0\\1" str)))
> > +                 "[eE]\\([+-]?\\)?$" "e\\10" str)))
> >        (float (string-to-number str)))))
>
> Thanks for the report and the suggested patch! However, I'm not sure
> what either of these replace-regexp-in-string calls are good for. The
> first one possibly to accept 1.e23 instead of 1e23; the second one is
> less clear. Frankly, I think we can drop both.
>
> Eli, do you remember?

Sidenote: there's not much point in the double "?" in "\\([+-]?\\)?".

But more to the point, I don't remember why I switched to the regexp
mess in the first place.  The original code:

    (car (read-from-string
          (cond ((equal "." str) "0.0")
                ((string-match "[eE][+-]?$" str) (concat str "0"))
                ((string-match "\\.[0-9]\\|[eE]" str) str)
                ((string-match "\\." str)
                 ;; do this because Emacs reads "23." as an integer
                 (concat str "0"))
                ((stringp str) (concat str ".0"))
                (t "0.0"))))

makes the intention clear -- the idea is to mimic common calculators
where you can type "3." or "3e" and get 3.  (Re the fix from a short
while ago, the comment also shows that the original intention was to
always get a float.)

It looks like going back to a simplified (due to the float) version of
this would be better.  Also testing that the thing I mentioned in the
log still works ("e+" using "+" as an operator).

-- 
                   ((x=>x(x))(x=>x(x)))                  Eli Barzilay:
                   http://barzilay.org/                  Maze is Life!
This bug report was last modified 5 years and 5 days ago.

Previous Next

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