On 12/9/06, Barton Willis <willisb at unk.edu> wrote:
> The equal(%e,2.718281828459045) fact is bogus. I suggest that we
> eliminate it (same for %pi, %phi, and %gamma).
OK by me (although I haven't thought about this very hard).
> The new meqp function looks at the current fact database
> for equal facts to decide equality.
> If it looked at the global fact database as well, it would do
> equal(%e,2.718281828459045) --> true (and I don't like that).
Hmm, I get
(%i7) is(equal(%e, 2.718281828459045));
`rat' replaced -2.71828182845905 by -23225/8544 = -2.71828183520599
(%o7) false
But stuff like is(abs(%pi - 22/7) < 1/10) --> true is certainly OK --
can Maxima deduce that in the absence of equal(%pi, 3.14...) ?
> Also, numerval allows non-double floats for values, but I don't
> know of a user-level function that extracts such data. The
> only way I know to get the actual numerval data is to use ?mget:
>
> (%i4) numerval(pie,22/7);
> (%o4) [pie]
> (%i5) ?mget(pie,'numer);
> (%o5) 22/7 /* pie, numer --> 3.142857142857143 */
pie, numer --> 3.142857142857143 is a consequence of numer
causing the float flag to be turned on, isn't it?
Maxima has fetched 22/7 and re-evaluated it with numer=true.
(Same thing for numerval(pie, 3.14b0) -- ev(pie, numer) => float,
not a bigfloat.)
That behavior is inconvenient here, but I don't know if it's a bug ...
All the best,
Robert