Subject: couple of questions about complex expressions
From: Stavros Macrakis
Date: Fri, 28 Sep 2012 11:42:24 -0400
float(...) seems to be the closest to what you want, rather than ...
(numer=true) or ... (float=true). What a mess!
I think we can afford to change the semantics of numer in this edge case
without causing problems. But it's not clear that you can implement that
as a flag in any reasonable way given the calling structure of
meval1/simplifya -- which is in effect bottom-up. Which is why float(...)
is a function, not a flag.
What are the chances we can wean our users from ...,numer and convince them
to use float(...) instead?
-s
On Fri, Sep 28, 2012 at 11:28 AM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On 2012-09-28, Barton Willis <willisb at unk.edu> wrote:
>
> > When simplifying (-5)^(1/3) with numer : true, conversion of 1/3 to a
> > binary64 happens before simpexpt ever looks at (-5)^(1/3).
> > The function *red (called by simpquot) does the conversion
> >
> > (%i3) (-5)^(1/3),numer;
> > 1> (SIMPQUOT ((MQUOTIENT) 1 3) 1 NIL)
> > <1 (SIMPQUOT 0.33333333333333331)
> > 1> (SIMPEXPT ((MEXPT) -5 0.33333333333333331) 1 NIL)
> > 2> (SIMPEXPT ((MEXPT) -1 0.33333333333333331) 1 T)
> > <2 (SIMPEXPT ((MEXPT SIMP) -1 0.33333333333333331))
> > <1 (SIMPEXPT
> > ((MTIMES SIMP) 1.7099759466766968
> > ((MEXPT SIMP) -1 0.33333333333333331)))
> > (%o3) 1.709975946676697*(-1)^0.33333333333333
>
> Hmm. That seems unfortunate, in the sense that converting 1/3 to a float
> actually complicates the goal of extracting a numerical value ...
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>