About Bug 1742275: featurep(false, 'complex)

Hi!

I have thought about bug 1742275 "featurep(false, 'complex) -> true"
a bit and i basically see two possible solutions:

a)
Just remove the condition ((eq ind '$complex) t) from $featurep.
With this we would get
  declare(z, 'complex); featurep(z, 'complex); -> true
because of the generic condition for symbol properties. But 
  featurep(1+%i, 'complex); -> false

b)
Change the condition to
((eq ind '$complex)
 (let ((ris (trisplit e)))
       (not (or (zerop1 (car ris)) (zerop1 (cdr ris))))))
which is equivalent to realpart(expr) != 0 and imagpart(expr) != 0

Both changes pass the test suite.

I personally prefer a) over b) because b) doesn't add any new 
functionality to maxima and a) seems to be covered by the current
documentation of featurep(). 

Also featurep(..., 'real) has a different idea of what "real" means 
than realpart() - leading to ugly results like:
  declare(z, 'complex);
  featurep(realpart(z), 'real); -> true
  featurep(realpart(x), 'real); -> false

Actually featurep(..., 'real) already does refer to realpart(), causing
even worse results like:
  featurep(x, 'real); -> false
  featurep(x+y, 'real); -> true

Also featurep(..., 'imaginary) has the a) style implementation, which
leads to:
  featurep(%i, 'imaginary); -> false
This might be considered a bug, but would it be useful to get true in
this case without also getting true for 2*%i, which actually would be
a b) style implementation?

Also with b) we would need to figure out how featurep() should handle
lists. I think this should be consistent across all supported
features.

Summary:
If nobody objects within reasonable time, I will commit variant a)
and comment out the call to rectform() in featurep(..., 'real).

If the people on this ML think that featurep(1+%i, 'complex) -> false
is absolutely unacceptable then I will commit variant b). Thus
improving featurep() a bit but not really fixing the mess.

If you like neither proposal then I'm out of ideas ... ;-)


Harald