Subject: [ maxima-Bugs-609464 ] 1+%e,numer and %e^%e,numer
From: Harald Geyer
Date: Thu, 21 May 2009 23:26:54 +0200
> > (%i4) sin(0), numer;
> > (%o4) 0.0
> >
> > Note that numer is intended to return numerical but exact answers where
> > possible (hance %o2 seems correct) but %o4 is a float!
>
> Because 0 is changed to 0.0 when numer is TRUE the sin function returns
> a floating point result. This is the way almost all functions are
> implemented. E.g. gamma(1) gives 1, but gamma(1),numer and gamma(1.0)
> will give 1.0 and gamma(1.0b0) will give 1.0b0.
Well, this kind of defeats the purpose of numer ...
> > I wonder why numerical evaluation can't be performed from inner parts of
> > expressions to outer parts. i.e. in sin(%e^(%e+1)) first look at
> > %e+1, evaluate this to a float if numer=true, then look at %e^some_float
> > and always evaluate it, because it already is a float and finally look
> > at sin(some_other_float) ...
>
> That is the way the code of the simplifer does the evaluation to get a
> numerical result when we implement the proposed additional code.
Obviously that's not strictly the case - as the example of sin(0), numer
shows.
> > As an orthogonal issue: Why is numer a flag (I personally don't recall
> > ever setting it to true for anything beside tests, but I often use it
> > on the prompt like "foo, numer" but numer(foo) would work for me too).
> > If it wasn't a flag perhaps we wouldn't need to handle it in the
> > core simplifier.
>
> The numerical evaluation of all implemented functions depends on the
> mechanism of $numer. There is a lot of code which has to be changed when
> we introduce a new concept.
Well there is also numerical evaluation via bfloat. Perhaps things could
be simplified/unified a bit. (Just thinking aloud.)
Harald