I think that as long as we are considering nesting of float(),
rectform(), ev(..,numer) etc. we might
as well write one tree-walking program to do it "all". For the fun of
it, maybe call it b(). short for Bakery...
( for "take a number").
What would it do? recursively from the top down..
b(x+y) -> add the (possibly complex) floating-point numbers(b(x),
b(y)). If one is not a float, what to do?
b(x*y) ->multiply etc.
b(%e) -> 2.71828.. EXCEPT:
b(%e^x) -> compute exponential of b(x). If x is not a float, what to
do? 2.71828..^ x is a bad idea, I think.
b(sin(x)) -> ...
b( x^y) -> complex rectform?
... add extra rules here
Another version might be set up for bigfloats.
...............
RJF
On 2/24/2013 3:57 PM, Stavros Macrakis wrote:
> From the user's point of view, it would seem natural I think that
> *rectform/polarform/*/etc./ take *numer* into account, so that they
> could calculate the numeric answer bottom-up rather than first
> constructing expressions like sin(%pi/7) and only later evaluating
> them to 0.434.
>
> But *numer* controls /evaluation/ and not /simplification./ Thus in
> theory it is wrong for an expression-manipulating function like
> *rectform* to look at *numer*. Moreover, there is no corresponding
> flag for *bfloat*.
>
> Not sure exactly what the best answer is here. A simplifier flag (say
> *numeric *: *false *or *float *or *bfloat*) looked at by
> /simplification/ would require modifying every simplifier function to
> handle the symbolic-constant case. Something specific to
> *rectform* and company would be faster to implement, but not extend to
> other cases.
>
> Thoughts?
>
> -s
>
> On Sun, Feb 24, 2013 at 6:15 PM, Stavros Macrakis
> <macrakis at alum.mit.edu <mailto:macrakis at alum.mit.edu>> wrote:
>
> Actually, I was wrong about calculations within the rectform being
> done in floating-point here. In particular, %pi is not expanded
> to a float. Rectform should probably take numer into account here
> to make it more efficient. Or maybe the simplifier should always
> use the numeric form of symbolic constants like %e, %pi, etc. when
> they are combined with floats, e.g. 2.0*%pi => 6.28, not 2.0*%pi.
>
> -s
>
> On Sun, Feb 24, 2013 at 12:33 PM, Stavros Macrakis
> <macrakis at alum.mit.edu <mailto:macrakis at alum.mit.edu>> wrote:
>
> To put a numerical expression in a+b*%i form, use
>
> block([numer:true],float(rectform(subst([a=1,b=2,...],expr))))
>
> or
>
> ev(float(rectform(expr)),numer,a=1,b=2,...).
>
> These ensures that calculations /within /the rectform are done
> in floating-point, not symbolic form, which can be
> /much/ faster that something like float(rectform(expr)) on
> large expressions because it avoids unnecessary
> intermediate-expression expansion.
>
> Both of these solutions seem unnecessarily complicated. There
> have been proposals to treat complex numbers as single
> numbers, rather than expressions involving numbers, but as far
> as I know, no one has demonstrated a comprehensive solution
> along those lines (that handles complex rationals, complex
> bfloats, etc. uniformly).
>
> You may be wondering what the 'float' is for if we already
> have numer:true. That is to catch the edge case where expr is
> a simple integer: ev(3,numer) => 3, not 3.0.
>
> -s
>
> On Sun, Feb 24, 2013 at 10:33 AM, Henry Baker
> <hbaker1 at pipeline.com <mailto:hbaker1 at pipeline.com>> wrote:
>
> What is the preferred way to convert the results of
> solve(z^3+b*z^2+c*z+d,z), where b,c,d are complex floating
> point numbers, and z is a complex variable, into floating
> point?
>
> numer doesn't always do it.
>
> expand doesn't always do it.
>
> rectform doesn't always do it.
>
> radcan doesn't do it.
>
> I keep getting expt(...) forms in my display that I can't
> always get rid of.
>
> These are all _constant_ numerical numbers, so there ought
> to be a way to force numerical evaluation.
>
>
>
>
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima