expt weirdness in floatfns.c

expt weirdness in floatfns.c

[D Goel]

(expt 3 3) tries to return 27 instead of 27.0
That is good

However, this has an unexpected outcome:

(expt 2 -2) returns 0 instead of 0.25


I couldn,t understand the c code, but it seems to do this: 

 /* don't promote to floats, if both are ints */

 
(if 
 (and (integerp a)
      (integerp b))
 
  (leave-them-be))

Perhaps it should add  this condition to the above:

 
(if 
 (and (integerp a)
      (integerp b)
      (plusp b)) 
  (leave-them-be))

.
.
.

 ====================================================

One might try to argue this to explain away the present behavior: the
user shoud expect an integer if both inputs were integers.

But if that were so, then conversely,  (log 2 8) should return 0 and
not .33333

====================================================

i think that both should return the proper values instead of truncated
integers., truncating to integers only has precedent when it comes to
division (and even there, elisp differs from most other langages,
including CL)



 ====================================================

In the case of expt, it looks like (?) the author never intended to
return a truncated answer, he was just trying to be nice and return an
integer for things line 3^3, and just overlooked the possibility of b
being negative at this stage.

Re: expt weirdness in floatfns.c

[Thien-Thi Nguyen]

"D Goel" <deego@gnufans.org> writes:

> i think that both should return the proper values instead of
> truncated integers

i agree.  how does the following patch look?

thi


___________________________________
*** floatfns.c  4 Jul 2005 16:06:31 -0000       1.84
--- floatfns.c  6 Aug 2005 14:07:36 -0000
***************
*** 460,466 ****
    CHECK_NUMBER_OR_FLOAT (arg1);
    CHECK_NUMBER_OR_FLOAT (arg2);
    if (INTEGERP (arg1)     /* common lisp spec */
!       && INTEGERP (arg2)) /* don't promote, if both are ints */
      {                         /* this can be improved by pre-calculating */
        EMACS_INT acc, x, y;    /* some binary powers of x then accumulating */
        Lisp_Object val;
--- 460,467 ----
    CHECK_NUMBER_OR_FLOAT (arg1);
    CHECK_NUMBER_OR_FLOAT (arg2);
    if (INTEGERP (arg1)     /* common lisp spec */
!       && INTEGERP (arg2)   /* don't promote, if both are ints, */
!       && 0 <= XINT (arg2)) /* or if we are taking the ARG2'th root */
      {                         /* this can be improved by pre-calculating */
        EMACS_INT acc, x, y;    /* some binary powers of x then accumulating */
        Lisp_Object val;

Re: expt weirdness in floatfns.c

[Richard M. Stallman]

    I couldn,t understand the c code, but it seems to do this: 

     /* don't promote to floats, if both are ints */

The comment suggests this was for compatibility with Common Lisp.
We may as well not change it.

Re: expt weirdness in floatfns.c

[Thien-Thi Nguyen]

"Richard M. Stallman" <rms@gnu.org> writes:

> The comment suggests this was for compatibility with Common Lisp.
> We may as well not change it.

i changed `Fexpt' so that:

  (expt 2 -2) => 0.25

i'm inclined to leave the change in for (more) mathematical correctness,
and also because w/ the change, the behavior concords w/ the elisp info
page which says:

  @defun expt x y
  This function returns @var{x} raised to power @var{y}.  If both
  arguments are integers and @var{y} is positive, the result is an
  integer; in this case, overflow causes truncation, so watch out.
  @end defun

if someone complains, we can always revert it (and update the docs to
mention the (IMHO) strange behavior).

thi

Re: expt weirdness in floatfns.c

[Luc Teirlinck]

I basically agree with your change, but your comment looks confusing:

      && INTEGERP (arg2)   /* don't promote, if both are ints, and */
      && 0 <= XINT (arg2)) /* we are not computing the -ARG2 root */

root?  Are you confusing with `(expt 2 0.5)'?  Should the second line
not simply be:  /* ARG2 is nonnegative */ ?

Sincerely,

Luc.

Re: expt weirdness in floatfns.c

[Thien-Thi Nguyen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I basically agree with your change, but your comment looks confusing:
> 
>       && INTEGERP (arg2)   /* don't promote, if both are ints, and */
>       && 0 <= XINT (arg2)) /* we are not computing the -ARG2 root */
> 
> root?  Are you confusing with `(expt 2 0.5)'?  Should the second line
> not simply be:  /* ARG2 is nonnegative */ ?

you're right (i was confused; "root" is the wrong word).
thanks for pointing this out.

thi

Re: expt weirdness in floatfns.c

[Luc Teirlinck]

I believe that your src change log entry should be corrected two.
Negative exponents compute inverses, not roots.

Sincerely,

Luc.

Re: expt weirdness in floatfns.c

[Thien-Thi Nguyen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I believe that your src change log entry should be corrected two.
> Negative exponents compute inverses, not roots.

i changed the ChangeLog file yesterday, and have just now updated the
cvs repo (the ,v file) w/ the "cvs admin -mREV:MSG" command.  (now i'm
ready to move on to the next blunder! :-)

thi

Re: expt weirdness in floatfns.c

[Richard M. Stallman]

    i changed `Fexpt' so that:

      (expt 2 -2) => 0.25

I undid the change, because the comment said this was for Common Lisp
compatibility, and you hadn't got my ok.  (Also, this is consistent
with the way / works when given integers.)

However, given that Luc checked the Common Lisp spec and found that
the old behavior is not really like Common Lisp, that means the reason
to keep the old code is invalid.  So now I agree your change is an
improvement.

I can put it back in, or you can.

Re: expt weirdness in floatfns.c

[Thien-Thi Nguyen]

"Richard M. Stallman" <rms@gnu.org> writes:

> I can put it back in, or you can.

at the moment, gnu servers are refusing connection,
so i will try another day, unless someone beats me to it.

thi

Re: expt weirdness in floatfns.c

[Luc Teirlinck]

Richard Stallman wrote:

   The comment suggests this was for compatibility with Common Lisp.
   We may as well not change it.

I do not see how Emacs can be compatible with Common Lisp in this
respect, since it does not implement rational numbers.  From the CL Hyperspec:

    expt returns base-number raised to the power power-number. If the
    base-number is a rational and power-number is an integer, the
    calculation is exact and the result will be of type rational;
    otherwise a floating-point approximation might result.

>From the Common Lisp implementation CLISP:

[1]> (expt 2 -2)
1/4

which is consistent with the above quote.

To be compatible with CL, Emacs should return 1/4, which it can not
do, having no rational numbers.  0.25, even though inexact, would
appear to be more "compatible" with 1/4 than 0.

Sincerely,

Luc.