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/