bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Eythan Weg]

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))

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Andreas Schwab]

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."

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Eythan Weg]

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 

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Andreas Schwab]

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."

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Eythan Weg]

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

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Lars Ingebrigtsen]

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

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Mattias Engdegård]

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.

bug#27765: 26.0.50; Calc b% and relch are inconsistent in algebraic and rpn modes

[Lars Ingebrigtsen]

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