* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
@ 2017-07-19 12:37 Eythan Weg
2017-07-19 12:54 ` Andreas Schwab
0 siblings, 1 reply; 8+ messages in thread
From: Eythan Weg @ 2017-07-19 12:37 UTC (permalink / raw)
To: 27765
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))
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2017-07-19 12:37 bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes Eythan Weg
@ 2017-07-19 12:54 ` Andreas Schwab
2017-07-19 13:49 ` Eythan Weg
0 siblings, 1 reply; 8+ messages in thread
From: Andreas Schwab @ 2017-07-19 12:54 UTC (permalink / raw)
To: Eythan Weg; +Cc: 27765
On Jul 19 2017, eythanweg@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2017-07-19 12:54 ` Andreas Schwab
@ 2017-07-19 13:49 ` Eythan Weg
2017-07-19 14:10 ` Andreas Schwab
0 siblings, 1 reply; 8+ messages in thread
From: Eythan Weg @ 2017-07-19 13:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 27765
Andreas Schwab <schwab@suse.de>
Wed, 19 Jul 2017 14:54:01 +0200
>On Jul 19 2017, eythanweg@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@suse.de
>GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
>"And now for something completely different."
Eythan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2017-07-19 13:49 ` Eythan Weg
@ 2017-07-19 14:10 ` Andreas Schwab
2017-07-19 17:59 ` Eythan Weg
0 siblings, 1 reply; 8+ messages in thread
From: Andreas Schwab @ 2017-07-19 14:10 UTC (permalink / raw)
To: Eythan Weg; +Cc: 27765
On Jul 19 2017, eythanweg@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2017-07-19 14:10 ` Andreas Schwab
@ 2017-07-19 17:59 ` Eythan Weg
2021-09-03 8:12 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Eythan Weg @ 2017-07-19 17:59 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 27765
Andreas Schwab <schwab@suse.de>
Wed, 19 Jul 2017 16:10:52 +0200
>On Jul 19 2017, eythanweg@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2017-07-19 17:59 ` Eythan Weg
@ 2021-09-03 8:12 ` Lars Ingebrigtsen
2021-09-03 9:22 ` Mattias Engdegård
0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-03 8:12 UTC (permalink / raw)
To: Eythan Weg; +Cc: Andreas Schwab, 27765, Mattias Engdegård
eythanweg@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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2021-09-03 8:12 ` Lars Ingebrigtsen
@ 2021-09-03 9:22 ` Mattias Engdegård
2021-09-03 14:56 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Mattias Engdegård @ 2021-09-03 9:22 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Andreas Schwab, Eythan Weg, 27765
3 sep. 2021 kl. 10.12 skrev Lars Ingebrigtsen <larsi@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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes
2021-09-03 9:22 ` Mattias Engdegård
@ 2021-09-03 14:56 ` Lars Ingebrigtsen
0 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-03 14:56 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: Andreas Schwab, Eythan Weg, 27765
Mattias Engdegård <mattiase@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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-03 14:56 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-19 12:37 bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes Eythan Weg
2017-07-19 12:54 ` Andreas Schwab
2017-07-19 13:49 ` Eythan Weg
2017-07-19 14:10 ` Andreas Schwab
2017-07-19 17:59 ` Eythan Weg
2021-09-03 8:12 ` Lars Ingebrigtsen
2021-09-03 9:22 ` Mattias Engdegård
2021-09-03 14:56 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.