I guess this is a general issue about ALL commands, namely
should f(x) mean this:
If f does not make sense to apply to x, then change it to
map(f,x), (or something else?)
In the case of ratnumer, it tried to make sense of
ratnumer( LIST) by returning LIST. The belief being that
you COULD have encoded a polynomial in the variable z=[1/x+1/y]
and asked for the numerator of z/1. So it returned z.
This is perhaps what you get for a non-strict-type system. Two
people, and two interpretations. Maybe more.
Would it be better to return a message "ratnumer works only
on CRE forms"?
willisb@unk.edu wrote:
> Described below is an annoying (my opinion) feature of ratnumer.
> Consider:
>
> /* The ratnumer function doesn't automatically map over lists */
>
> (C1) q : ratnumer([1/x + 1/y,x]);
> (D1) [1/y+1/x,x]
>
> /* I can live with this; however, ratp(q) evaluates to true, yet
> the members of q aren't in CRE form. */
actually, there should be a /R/ near that (D1). Because
D1 and q ARE in CRE form, the main variable being [1/x+1/y,x].
>
> (C2) ratp(q);
> (D2) TRUE
> (C3) map(ratp,q);
> (D3) [FALSE,FALSE]
map decided to take q out of CRE form, in which case it is a list.
perhaps this is over-reaching.
>
> /* Worse yet, listp(q) evaluates to false. */
>
> (C4) listp(q);
> (D4) FALSE
That's what I expected. q is a CRE or "ratp".
> (C5) q;
> (D5) [1/y+1/x,x]
> (C6) ?print(q);
> ((MRAT SIMP
> (((MLIST SIMP)
> ((MPLUS SIMP) ((MEXPT SIMP) |$x| -1) ((MEXPT SIMP) |$y| -1))
> |$x|))
> (#:|x1101| #:|[1/y+1/x,x]1100|))
> (#:|x1101| 1 1) . 1)
>
> I got the same results using commercial macsyma (version 2.2 and 422).
>
> Lesson: don't apply ratnumer to a Maxima list.
Try map(ratnumer, q), I think, to get what you want.
>
You can declare a name rr declare(rr,threadable) in which case
rr(q) becomes [ rr(1/x)+rr(1/y),rr(x)] which is not
what you want, either. And it won't change ratnumer.
RJF