Unary /

Unary /

[David Kastrup]

I was surprised to discover that unary / does not work analogously to
unary -, namely creating the multiplicative inverse.

In Elisp, (/ 2.0) returns 2.0.  In Common Lisp
<URL:http://www.lispworks.com/documentation/lw50/CLHS/Body/f_sl.htm>
(and in Scheme), this returns 0.5.

Any reason for that?  The Elisp behavior does not appear overly useful.

-- 
David Kastrup

Unary /

[Stephen J. Turnbull]

David Kastrup writes:

 > In Elisp, (/ 2.0) returns 2.0.  In Common Lisp
 > <URL:http://www.lispworks.com/documentation/lw50/CLHS/Body/f_sl.htm>
 > (and in Scheme), this returns 0.5.

Also in XEmacs (/ 2.0) => 0.5.  Just a bug in Emacs, I bet.  So I
guess the Common Lisp behavior isn't particularly useful, either or
somebody would have reported sooner. :-)

Re: Unary /

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > In Elisp, (/ 2.0) returns 2.0.  In Common Lisp
>  > <URL:http://www.lispworks.com/documentation/lw50/CLHS/Body/f_sl.htm>
>  > (and in Scheme), this returns 0.5.
>
> Also in XEmacs (/ 2.0) => 0.5.  Just a bug in Emacs, I bet.

Hardly a bug since it matches the function DOC:

/ is a built-in function in ‘src/data.c’.

(/ DIVIDEND &rest DIVISORS)

Return first argument divided by all the remaining arguments.
The arguments must be numbers or markers.

[back]

> So I guess the Common Lisp behavior isn't particularly useful, either
> or somebody would have reported sooner. :-)

At least it's a good data point that XEmacs has it the other way round.
That suggests that at least packages common to both Emacsen do not rely
on either definition in important code.

That makes it more of a temptation to change it after all this time.

-- 
David Kastrup

Re: Unary /

[Tassilo Horn]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>  > In Elisp, (/ 2.0) returns 2.0.  In Common Lisp
>  > <URL:http://www.lispworks.com/documentation/lw50/CLHS/Body/f_sl.htm>
>  > (and in Scheme), this returns 0.5.
>
> Also in XEmacs (/ 2.0) => 0.5.  Just a bug in Emacs, I bet.  So I
> guess the Common Lisp behavior isn't particularly useful, either or
> somebody would have reported sooner. :-)

Before Fri Nov 9 17:20:47 2012 -0500, / required at least two arguments
in Emacs.

Bye,
Tassilo

Re: Unary /

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> I was surprised to discover that unary / does not work analogously to
> unary -, namely creating the multiplicative inverse.
>
> In Elisp, (/ 2.0) returns 2.0.  In Common Lisp
> <URL:http://www.lispworks.com/documentation/lw50/CLHS/Body/f_sl.htm>
> (and in Scheme), this returns 0.5.
>
> Any reason for that?  The Elisp behavior does not appear overly useful.

Probably because before Emacs supported floats this wasn't such a useful
operation.

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

Re: Unary /

[David Kastrup]

Tassilo Horn <tsdh@gnu.org> writes:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>>  > In Elisp, (/ 2.0) returns 2.0.  In Common Lisp
>>  > <URL:http://www.lispworks.com/documentation/lw50/CLHS/Body/f_sl.htm>
>>  > (and in Scheme), this returns 0.5.
>>
>> Also in XEmacs (/ 2.0) => 0.5.  Just a bug in Emacs, I bet.  So I
>> guess the Common Lisp behavior isn't particularly useful, either or
>> somebody would have reported sooner. :-)
>
> Before Fri Nov 9 17:20:47 2012 -0500, / required at least two arguments
> in Emacs.

Ah, so there will not be a lot of legacy code relying on the current
semantics.  This would be

commit 32e5c58ca969ec30d31520da52c9866cafa62927
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Fri Nov 9 17:20:47 2012 -0500

    Provide new `defalias-fset-function' symbol property.
    * src/lisp.h (AUTOLOADP): New macro.
    * src/eval.c (Fautoload): Don't attach to loadhist, call Fdefalias instead.
    * src/data.c (Ffset): Remove special ad-advice-info handling.
    (Fdefalias): Handle autoload definitions and new Qdefalias_fset_function.
    (Fsubr_arity): CSE.
    (Finteractive_form): Simplify.
    (Fquo): Don't insist on having at least 2 arguments.
    (Qdefalias_fset_function): New var.
    * lisp/emacs-lisp/advice.el (ad-set-advice-info): Set defalias-fset-function.
    (ad--defalias-fset): New function.
    (ad-safe-fset): Remove.
    (ad-make-freeze-definition): Use cl-letf*.

Since there are about a dozen apparently unrelated changes, the question
is whether anything specifically relied on this change.

Stefan, any insights?

-- 
David Kastrup

Re: Unary /

[Stefan Monnier]

> Ah, so there will not be a lot of legacy code relying on the current
> semantics.  This would be
[...]
> Since there are about a dozen apparently unrelated changes, the question
> is whether anything specifically relied on this change.

I don't remember the specific case that motivated the change.
IIRC I changed it mostly because the limitation was arbitrary (as you
can see in the patch, which doesn't actually change the code).

I didn't know that CL had decided to give a completely different meaning
to the unary / than the natural generalization of the behavior of (/ X1
X2 ... Xn).  It seems backward to me, so I guess my sense of aesthetics
would incite me to simply revert my patch, adding a comment that for the
semantics of the unary / there is a conflict between the natural choice
and CL compatibility.


        Stefan

Re: Unary /

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Ah, so there will not be a lot of legacy code relying on the current
>> semantics.  This would be
> [...]
>> Since there are about a dozen apparently unrelated changes, the question
>> is whether anything specifically relied on this change.
>
> I don't remember the specific case that motivated the change.
> IIRC I changed it mostly because the limitation was arbitrary (as you
> can see in the patch, which doesn't actually change the code).
>
> I didn't know that CL had decided to give a completely different meaning
> to the unary / than the natural generalization of the behavior of (/ X1
> X2 ... Xn).  It seems backward to me, so I guess my sense of aesthetics
> would incite me to simply revert my patch, adding a comment that for the
> semantics of the unary / there is a conflict between the natural choice
> and CL compatibility.

Should we do that for unary - as well?  It's exactly the same situation.

(- 3) is not the same as (- 3 0) but as (- 0 3), just like (/ 3.0) is
not the same as (/ 3.0 1.0) but as (/ 1.0 3.0).

That is, given only a single argument, you get the inverse element for
addition/multiplication, respectively.

-- 
David Kastrup

Re: Unary /

[Stefan Monnier]

> (- 3) is not the same as (- 3 0) but as (- 0 3), just like (/ 3.0) is
> not the same as (/ 3.0 1.0) but as (/ 1.0 3.0).

Indeed, the - has the same asymmetry, but it seems that "unary -" is  much
more commonly found operator than "unary /".

And I'm pretty sure there are many uses of (- X) out there, so we can't
really get rid of it.


        Stefan

Re: Unary /

[Paul Eggert]

On 10/15/2015 11:45 AM, Stefan Monnier wrote:
> Indeed, the - has the same asymmetry, but it seems that "unary -" is  much
> more commonly found operator than "unary /".

I suspect David was being ironic....

Unary / is rare in Elisp code, partly because the GNU Emacs byte 
compiler complains about it, partly because it doesn't work in GNU Emacs 
24.2 and earlier, partly because it has the Common Lisp semantics in 
XEmacs, and partly because one doesn't often need the reciprocal of a 
floating-point number. With all that being said, it's a bit more useful 
for (/ N) to return the reciprocal of N than to return N, so we might as 
well be compatible with CL here.

I've proposed a patch to change unary / to behave more like CL, in 
Bug#21690. Since we're in feature-freeze now isn't a good time to be 
changing the semantics of /, but there's no rush. In the meantime we can 
leave the byte-compiler alone, as its bogus warning about (/ N) will 
help scare users away from the soon-to-be-withdrawn semantics.