fix for the logic in two-argument '='

[james anderson]

(sorry about the terseness, but i spent fifteen minutes writing a nice bug report only to have the site discard it as a stale page...)

i attach a patch to 1.2.14 which corrects the logic in the two argument equals to properly compare unity rationals with integers.

with the patch

$ sbcl
This is SBCL 1.2.14.91-0485dbb-dirty, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (defun make-rational (num den)
  (sb-kernel::%make-ratio num den))

MAKE-RATIONAL
* (= (make-rational 0 1) 0)

T
* (ceiling (make-rational 49 1) )

49
0/1

otherwise the result is one off.
the same is likely for other math operators as they depend on a test for '0' which fails with for the remainder result from truncate.

[Stas Boukarev (stassats)]

That's not a legal ratio.

[james anderson (james-anderson-0)]

why should "0/1" be illegal?

the definition of rational permits the form and i found nothing in the description of arithmetic operator to preclude it.
there is a reference to automatic canonicalization, but a canonical form does not proscribe the existence of other representations.

given that specification, one would expect the operator implementations not to produce values of this form as a result, but one would also not expect them to produce arithmetically incorrect results when one is supplied.

[Stas Boukarev (stassats)]

That you had to use an internal mechanism to create such a thing should have been a hint, but ratio is pretty well defined http://www.lispworks.com/reference/HyperSpec/Body/t_ratio.htm

[james anderson (james-anderson-0)]

yes, i have read that.

10/1 is such a thing.
that is the source of the issue.

there are some use cases which dictate that an implementation distinguish between the integer "10" and the ratio "10/1". i did not establish the requirement. i am just trying to fullfill it. and, to do so without reimplementing the rational datatype with a double-boxed representation. more or less a sensible thing to do. until one observes that (ceiling 49/1) turns out to be 50.

if you are adamant, that the implementation cannot permit 0/x, this is fine, but then one would expect truncate to return a second value which the other math operators would recognize.
it did not.
for values such as "10/1" it returns "0/1" as the remainder.

would a more suitable patch cause truncate to return a second value which the remainder of the math operator implementation see as "zero", as it is?

[Stas Boukarev (stassats)]

10/1 cannot be produced.