Michael Stoll on Sun, 26 Apr 1998 15:55:21 +0200

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

[0] == 0 ?

Here is something strange.

gp (15:20)> [0]==0
%7 = 1
gp (15:20)> [1]==1
  ***   forbidden addition Scalar + vector/matrix.
gp (15:34)> []==0
%14 = 1
gp (15:35)> [0,0,0]==0
%15 = 1
gp (15:35)> [0,0,0]==[0]
%17 = 0
(so equality is not transitive?)

IMHO, testing objects of incompatible types for equality should give FALSE
(and not an error message, and certainly not TRUE).

I suggest to extend the `then' part of the first `if' statement in
gegal() (in gen2.c) to also return zero when the types of x and y are
incompatible. I.e.

  if (tx!=ty)
    { if (tx == t_STR || ty == t_STR) return 0; }

should become

  if (tx!=ty)
    { if INCOMPATIBLE(tx,ty) return 0; }

and INCOMPATIBLE should be defined somewhere (as a macro using nested
switch stetements or (probably better) array lookup), if it isn't already.

Maybe there should be a separate predicate that checks if two objects
are interchangeable as objects (i.e. also checking equality of types):
  equal(1,1.0) --> FALSE
  equal([0],0) --> FALSE
but maybe
  equal(Mod(x,x^2+1),Mod(y,y^+1)) --> TRUE
(but I'm not sure if this really would be a good idea.)
  equal(Mod(0,5),0) --> FALSE

This would essentially only require to change the if statement into

  if (tx!=ty)
    { return 0; }

plus some work for padics and series to ensure that we really have the
`same' object (including precision) (maybe this affects reals as well).
In short, equal(x,y) should test whether x and y have the same internal
representation. Opinions?

BTW, the comparison of fractions:

      case t_FRAC: case t_FRACN: case t_RFRAC: case t_RFRACN:
	av=avma; i=gegal(gmul((GEN)x[1],(GEN)y[2]),gmul((GEN)x[2],(GEN)y[1]));
	avma=av; return i;

seems unnecessarily costly to me in the case of reduced fractions
(type t_FRAC at least), since they are stored in normal form, so it would
be sufficient to simply compare numerators and denominators.