GNU bug report logs -
#27765
26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
Previous Next
Reported by: eythanweg <at> gmail.com (Eythan Weg)
Date: Wed, 19 Jul 2017 12:38:01 UTC
Severity: minor
Tags: moreinfo, wontfix
Found in version 26.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27765 in the body.
You can then email your comments to 27765 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Wed, 19 Jul 2017 12:38:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
eythanweg <at> gmail.com (Eythan Weg)
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 19 Jul 2017 12:38:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Start calc.
1 <RET>
2 <RET>
b%
you get on the stack 100%
type 'relch(1,2)
and you get 1 on the stack.
In GNU Emacs 26.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.22.6)
of 2017-07-09 built on pascal
Repository revision: bb2ea81bc569bdc51e1c9af1c503a22fb95e4384
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description: Debian GNU/Linux unstable (sid)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 95433 10140)
(symbols 48 20407 1)
(miscs 40 52 143)
(strings 32 28710 1174)
(string-bytes 1 755741)
(vectors 16 14673)
(vector-slots 8 497543 9982)
(floats 8 48 108)
(intervals 56 201 0)
(buffers 976 11))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Wed, 19 Jul 2017 12:55:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 27765 <at> debbugs.gnu.org (full text, mbox):
On Jul 19 2017, eythanweg <at> gmail.com (Eythan Weg) wrote:
> Start calc.
> 1 <RET>
> 2 <RET>
> b%
>
> you get on the stack 100%
>
> type 'relch(1,2)
> and you get 1 on the stack.
100% == 1, so they are the same.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Wed, 19 Jul 2017 13:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 27765 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> suse.de>
Wed, 19 Jul 2017 14:54:01 +0200
>On Jul 19 2017, eythanweg <at> gmail.com (Eythan Weg) wrote:
>> Start calc.
>> 1 <RET>
>> 2 <RET>
>> b%
>>
>> you get on the stack 100%
>>
>> type 'relch(1,2)
>> and you get 1 on the stack.
>100% == 1, so they are the same.
Agreed. However, the displays are different. Won’t expect b% and relch
behaves exactly the same? Perhaps it does not matter. But calc
provides c % and = for conversions from one display to the other. What
for, then?
>Andreas.
>--
>Andreas Schwab, SUSE Labs, schwab <at> suse.de
>GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
>"And now for something completely different."
Eythan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Wed, 19 Jul 2017 14:11:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 27765 <at> debbugs.gnu.org (full text, mbox):
On Jul 19 2017, eythanweg <at> gmail.com (Eythan Weg) wrote:
> Agreed. However, the displays are different. Won’t expect b% and relch
> behaves exactly the same?
That's called convenience, probably.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Wed, 19 Jul 2017 18:00:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 27765 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> suse.de>
Wed, 19 Jul 2017 16:10:52 +0200
>On Jul 19 2017, eythanweg <at> gmail.com (Eythan Weg) wrote:
>> Agreed. However, the displays are different. Won’t expect b% and relch
>> behaves exactly the same?
>That's called convenience, probably.
A little more than that. E.g. the org-mode speadsheet uses calc.
Summing cells which display percentages like 10% and 90%, one expects
the result to be 100% rather than 1. Here the uniform display of
percentages is significant, I would say.
Curiosity lead me to check the same operation on libreoffice and gnumeric.
They both adhere to the expected.
>Andreas.
Eythan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Fri, 03 Sep 2021 08:13:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 27765 <at> debbugs.gnu.org (full text, mbox):
eythanweg <at> gmail.com (Eythan Weg) writes:
> >> Agreed. However, the displays are different. Won’t expect b% and relch
> >> behaves exactly the same?
>
> >That's called convenience, probably.
>
> A little more than that. E.g. the org-mode speadsheet uses calc.
> Summing cells which display percentages like 10% and 90%, one expects
> the result to be 100% rather than 1. Here the uniform display of
> percentages is significant, I would say.
>
> Curiosity lead me to check the same operation on libreoffice and gnumeric.
> They both adhere to the expected.
As far as I can tell, relch isn't documented to display the percentage
in one format or another (i.e., "50%" or "0.5"), while `b %' is
documented to do "50%".
I don't use calc much, but I think the current behaviour makes sense --
a function like relch might be supposed to use the format "0.5" since
that's what more math-ey types are used to seeing relative change
represented as.
But perhaps others have other opinions; I've added Mattias to the CCs --
perhaps he has some comments.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 03 Sep 2021 08:13:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Fri, 03 Sep 2021 09:23:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 27765 <at> debbugs.gnu.org (full text, mbox):
3 sep. 2021 kl. 10.12 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:
> But perhaps others have other opinions; I've added Mattias to the CCs --
> perhaps he has some comments.
I'm afraid I have nothing clever to say about it. It seems understandable that `relch`, or `calcFunc-relch` in Lisp, follows the convention of just returning the value and not concern itself with its presentation. `b%` is an interactive command and therefore may take an interest in how the result is presented to the user. A weak argument, but perhaps it makes some sort of sense.
I have no idea what would break if we changed `calcFunc-relch` to return something like `(calcFunc-percent 25)` instead of 0.25. Maybe it just works.
Regarding the uniform display of percentages in org-mode: spreadsheet applications tend to use formatting of cells or columns when a certain presentation (like percentage or a certain number of decimals) is desirable. On the other hand, some functions in popular spreadsheets do return values adorned with a presentation hint; this is the case for financial functions that compute interest, for example.
Maybe Calc assumes that someone who uses b% is a HP-12C type of person and wants a percentage, while those using algebraic mode get plain values.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27765
; Package
emacs
.
(Fri, 03 Sep 2021 14:57:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 27765 <at> debbugs.gnu.org (full text, mbox):
Mattias Engdegård <mattiase <at> acm.org> writes:
> Maybe Calc assumes that someone who uses b% is a HP-12C type of person
> and wants a percentage, while those using algebraic mode get plain
> values.
Yeah, quite likely, so I'm closing thing bug report.
(Note that I'm not against changing this is somebody has a convincing
argument why it should be changed -- but I think if we change the
behaviour of something like this, the change should be obviously and
clearly for the better, and this is more of an "uhm... I guess either
works?" kind of situation, in which case "don't change" wins.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 03 Sep 2021 14:58:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
27765 <at> debbugs.gnu.org and eythanweg <at> gmail.com (Eythan Weg)
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 03 Sep 2021 14:58:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 02 Oct 2021 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 317 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.