About Bug 1742275: featurep(false, 'complex)

> Well, featurep has evolved toward evaluating predicates of the
> form is(x in S) where S is a set; I think featurep recognizes
> integers, rationals, reals, complex, and pure imaginary, maybe
> some others. That is a useful idea, but at present featurep is not
> a very good implementation of it.
>
> In that spirit, feature(false, 'complex) should return false
> because false is a Boolean literal and therefore demonstrably
> not an element of set of complex numbers.
> Likewise featurep(true, 'complex) and featurep("foo", 'complex)
> should return false.

I think handling infinite sets would be a very nice feature but I
believe it shouldn't be mixed with declarations. These two have
some similarities but nevertheless are distinctive: Working with
sets should allow things like is_elementp(foo, C without R).
This seems outside the scope of declarations and/or featurep()
to me.

Also featurep() was never documented to implement any notion of
sets or subsets.

Currently I know of no other way to check (without going to lisp)
whether symbol foo is declared complex than freeof(%i, rectform(foo)).

> > 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
>
> Hmm. I guess I don't like this one.
>
> > 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
> 
> At present featurep seems to embody the notion that
> featurep(X, S) => featurep(X, T) when S is a subset of T.
> That makes sense to me and I don't want to change it at
> the moment. Requiring that realpart and imagpart be nonzero
> makes featurep true isn't consistent with that.
> So I guess I don't like this one either.

I don't like this one either (actually I prefer a)) because it
is an other evil hack without a clear concept. The reason why 
I made this suggestion is, that it would be consistent with
declared facts.

Also note that this subset idea is contrary to what the 
documentation says, which is more or less "return true if the
property can be proven form the set of declarations, return false
in all other cases".

> As mentioned by others, featurep has accumulated some baggage
> over the years and probably we're best off separating the
> stuff which has only to do with declared properties of symbols,
> and potentially-inferred properties of symbols or expressions.
> 
> For the moment I think changing featurep(foo, complex) to
> return false when foo is a Boolean or string literal is a step forward.
> 
> In the long run, I would like to see declarations expanded to
> expressions as well as symbols, which would allow stuff like:
> 
>   declare (x in Z);
>   declare (matrixp (y));
>   declare (z in R and z > 0);
> 
> I'd like to merge the declare and assume stuff --- these could
> equally well be assume(x in Z), assume(matrixp(y)), etc.

I too think this would be a good thing, but the following 
distinction might be useful in some cases: assume stuff depends
on some context, while declarations seem to be global. This is
something to consider. (for those parts of maxima that don't
choose one of the two at random ;) )

Harald