Strange division using mixed integers and floats

Strange division using mixed integers and floats

[Johan Bockgård]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (sparc-sun-solaris2.8, X toolkit)
 of 2002-09-24 on nob.dd.chalmers.se
configured using `configure  --x-includes=/opt/pd/include/ --x-libraries=/opt/pd/lib --prefix=/rec/emacs-21.2/'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: iso_8859_1
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Ok, I know why this happens:

(/ 5 4) => 1

But this behaviour is *highly* confusing:

(/ 5 4 2.3) => 0.4347826086956522

Cf. (/ 5 4.0 2.3) => 0.5434782608695653

At least there should be a warning in the manual.

Recent input:
C ESC O C ESC O C ESC O C ESC O C ESC O C ESC O D q 
ESC O B ESC O B ESC O B ESC O B ESC O B ESC O B ESC 
O B ESC O B ESC O B ESC O B ESC O B ESC O B ESC O B 
ESC O B ESC O B ESC O B C-l ESC O A ESC O A ESC O A 
C-x b C-g ESC O A ESC O B ESC O B ESC x r e p o r t 
TAB RET

Recent messages:
Region saved
-1
0
0.0
Entering debugger...
 [2 times]
Back to top level.
Mark set
iswitchb-read-buffer: Quit
Loading emacsbug...done

-- 
Johan Bockgård

Re: Strange division using mixed integers and floats

[Kevin Rodgers]

Johan Bockga*rd wrote:
 > Ok, I know why this happens:
 >
 > (/ 5 4) => 1
 >
 > But this behaviour is *highly* confusing:
 >
 > (/ 5 4 2.3) => 0.4347826086956522
 >
 > Cf. (/ 5 4.0 2.3) => 0.5434782608695653
 >
 > At least there should be a warning in the manual.

*** elisp-manual-21-2.8/numbers.texi.orig	Sat Sep  8 11:42:52 2001
--- elisp-manual-21-2.8/numbers.texi	Tue Apr 27 09:45:26 2004
***************
*** 541,547 ****
   divides @var{dividend} by each divisor in turn.  Each argument may be a
   number or a marker.

! If all the arguments are integers, then the result is an integer too.
   This means the result has to be rounded.  On most machines, the result
   is rounded towards zero after each division, but some machines may round
   differently with negative arguments.  This is because the Lisp function
--- 541,548 ----
   divides @var{dividend} by each divisor in turn.  Each argument may be a
   number or a marker.

! If both of the arguments are integers, then the result---the
! intermediate result, if there are additional arguments---is an integer too.
   This means the result has to be rounded.  On most machines, the result
   is rounded towards zero after each division, but some machines may round
   differently with negative arguments.  This is because the Lisp function

-- 
Kevin Rodgers

Re: Strange division using mixed integers and floats

[Richard Stallman]

    But this behaviour is *highly* confusing:

    (/ 5 4 2.3) => 0.4347826086956522

    Cf. (/ 5 4.0 2.3) => 0.5434782608695653

We could change the functions to convert the arguments to
floating point at the start if any is floating point.

Is there any reason not to do that?

Re: Strange division using mixed integers and floats

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     But this behaviour is *highly* confusing:
> 
>     (/ 5 4 2.3) => 0.4347826086956522
> 
>     Cf. (/ 5 4.0 2.3) => 0.5434782608695653
> 
> We could change the functions to convert the arguments to
> floating point at the start if any is floating point.
> 
> Is there any reason not to do that?

Efficiency?  Lisp is not a statically typed language.  We don't know
the type of the arguments until after they have been evaluated.

We would have to store all intermediate results away before being
allowed to do the first operation.

Also (/ 5 4 2.3) would no longer be equivalent to (/ (/ 5 4) 2.3).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange division using mixed integers and floats

[Lars Brinkhoff]

David Kastrup <dak@gnu.org> writes:
> Richard Stallman <rms@gnu.org> writes:
> >     But this behaviour is *highly* confusing:
> >     (/ 5 4 2.3) => 0.4347826086956522
> >     Cf. (/ 5 4.0 2.3) => 0.5434782608695653
> > 
> > We could change the functions to convert the arguments to floating
> > point at the start if any is floating point.  Is there any reason
> > not to do that?
> 
> Efficiency?  Lisp is not a statically typed language.  We don't know
> the type of the arguments until after they have been evaluated.  We
> would have to store all intermediate results away before being
> allowed to do the first operation.

Seems like it's only a matter of changing arith_driver to do

      if (FLOATP (val))
        {
          if (code == Adiv)
            return float_arith_driver (0.0, 0, code, nargs, args);
          else
            return float_arith_driver ((double) accum, argnum, code,
                                       nargs, args);
        }

or similar.  Loss of efficiency should be small.

> Also (/ 5 4 2.3) would no longer be equivalent to (/ (/ 5 4) 2.3).

That's more significant, as it's a user-visible change.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

Re: Strange division using mixed integers and floats

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Efficiency?  Lisp is not a statically typed language.  We don't know
> the type of the arguments until after they have been evaluated.
>
> We would have to store all intermediate results away before being
> allowed to do the first operation.

Which we do anyway, since / is not a special form.  Arguments of normal
functions are always evaluated before being applied.

> Also (/ 5 4 2.3) would no longer be equivalent to (/ (/ 5 4) 2.3).

I don't think it was ever documented as such.  The Emacs Lisp manual only
covers the case of all arguments being integers, but does not specifically
say anything about mixed mode arguments, except that a floating point
value is returned if any argument is floating.  So always using floating
point arithmetics in this case would fit the principle of least surprise.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Strange division using mixed integers and floats

[Kevin Rodgers]

Andreas Schwab wrote:
 > David Kastrup <dak@gnu.org> writes:
 >>Also (/ 5 4 2.3) would no longer be equivalent to (/ (/ 5 4) 2.3).
 >
 > I don't think it was ever documented as such.  The Emacs Lisp manual
 > only covers the case of all arguments being integers, but does not
 > specifically say anything about mixed mode arguments, except that a
 > floating point value is returned if any argument is floating.  So
 > always using floating point arithmetics in this case would fit the
 > principle of least surprise.

The manual says:

| If there are additional arguments DIVISORS, then it divides DIVIDEND
| by each divisor in turn.

To me that means (/ 5 4 2.3) is equivalent to (/ (/ 5 4) 2.3).

-- 
Kevin Rodgers

Re: Strange division using mixed integers and floats

[Richard Stallman]

    Efficiency?  Lisp is not a statically typed language.  We don't know
    the type of the arguments until after they have been evaluated.

All the args have been evaluated by the time the function is called.
It just has to check their types and maybe convert the first arg
to floating point.

    Also (/ 5 4 2.3) would no longer be equivalent to (/ (/ 5 4) 2.3).

I don't think that is a big loss.

Re: Strange division using mixed integers and floats

[peta]

>     Also (/ 5 4 2.3) would no longer be equivalent to (/ (/ 5 4) 2.3).
> 
> I don't think that is a big loss.

In ansii common lisp they are equivalent, but that is because integer
division gives a rational result.  So in the absence of rational numbers
converting all arguments to float would be a close approximation of the
same.

-- 
Peter Whaite (http://whaite.ca)