Karim BELABAS on Mon, 8 Nov 1999 13:04:27 +0100 (MET)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: if-bug


[ == bug, in fact ]

>>[Leonhard Moehring:]
>> ? if([1]==1,)
>>   ***   forbidden addition t_INT + t_VEC.
>> Seems like a bug to me.

> [Michael Somos:]
>Actually, no. It is a feature. You can multiply or divide a vector
>by a scalar, but not add or subtract. In this case, comparison is
>in the same class as addition, hence is not allowed.

Actually, I would call it a bug. Tests for equality/inequality, as opposed to
comparisons, should never raise an error (unless the internal objects are
corrupted, that is).

I agree that the function should first check whether the objects can be added
(substracted in fact), and return 0 if they are not. Currently, there's only
a hack discriminating character strings so that comparison between a string
and anything else (incl. a string) returns the expected answer.

I believe that objects of different types (after simplification) should never
be declared equal. Currently, we have, e.g.

(12:38) gp > [] == 0
%1 = 1

(12:38) gp > Mod(1,3) == 1 + O(3^2)
%2 = 1

(12:38) gp > Mod(x,x^2+1) == x
%3 = 1

But

(12:38) gp > Mod(1,3) == Mod(1,9)
%4 = 0

although

(12:38) gp > Mod(1,9) - Mod(1,3) == 0
%5 = 1

Also

(12:38) gp > Mod(x,x^2+1) == I
%6 = 0

(12:38) gp > Mod(x,x^2+1) == Mod(y,y^2+1)
%7 = 0
[ of course, the identification is not canonical, but why not ? ]

(12:38) gp > quadgen(-4) == I
  ***   impossible addition t_COMPLEX + t_QUAD.

(12:38) gp > [1] == 1
  ***   forbidden addition t_INT + t_VEC.

We also have the problem (from TODO list):

  gcmp/gegal not transitive: [] == 0, [0] == 0, but [0] != []

The first 3 are certainly useful hacks when you're aware of them (in fact,
when you look at the C code [and, unfortunately, possibly modify it!] while
writing your scripts). It all follows directly from the so-called
"PARI-philosophy", defining function semantics basically as: "anything that
should make sense does, and yields indeed the expected result".

I feel the resulting uncertainty (when is this function defined and for
which arguments does the result really make sense ?) outweighs the advantage.
I dare not modify it now for backward compatibility reasons, but it may well
become an option in later releases [ e.g default(sane_equality_test, 1) ].

In the meantime I added to the TODO list the line (in the BUGS section)

5  gegal should return 0, not raise an error when its arguments can't be
   substracted

Karim.

P.S: No patch [although I just wrote a hackish one for my version for testing
purposes], this requires careful thinking... Also, when errors become
trapable in the library, the fix will be trivial.
__
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://hasse.mathematik.tu-muenchen.de/ntsw/pari/