featurep(e, real)



I think it would be much more important to have what is
essentially a type-checking functionality that works, versus
a function that attempts to solve an undecidable problem
using methods that are poorly defined.
You can have both, but they shouldn't be the same name.

RJF

  ----- Original Message -----=20
  From: Stavros Macrakis=20
  To: Barton Willis=20
  Cc: Maxima at math.utexas.edu ; Robert Dodier=20
  Sent: Monday, May 15, 2006 1:20 PM
  Subject: Re: [Maxima] featurep(e, real)


  On 5/15/06, Barton Willis <willisb at unk.edu> wrote:
    The function rectform contains the logic that featurep( . , real) needs.
    Duplication is bad.  Thus I'm leaning towards making

    featurep(e, real) :=3D freeof(%i, rectform(e)).

  Or, more simply, :=3D is(equal(imagpart(e),0)).  At some point, if
  efficiency matters, I suppose we could rewrite risplit so that it
  doesn't return unused components.  Currently, realpart and imagpart
  generate the full rectform and throw away the part they don't need.



  By the way, featurep(,complex) is useless, always returning True
  (because the reals are a subset), even for featurep(true,complex),
  featurep(matrix([q]),complex), etc.  The only way to see if something is
  declared complex is not(featurep(x,real)).

  Strange thing is, I think featurep started out originally simply as a
  way to query the database, and not a way of determining the
  characteristics of expressions.  Here we see why it might be useful to
  keep those functions distinct....

               -s