I'm not aware of the innards of Maxima, so my comments may seem naive.
Why does everything have to go through the _same_ evaluator, and then controlled by 1,000 different switches?
Wouldn't it make more sense to have multiple evaluators? How hard can it be to implement an evaluator? How many cases does it have to handle?
Re simplification:
I may have similar thoughts here, since the _goals_ of different simplifiers are dramatically different. Depending upon the _goal_, factoring in one context could be considered simplification, while expansion in another context could be considered simplification.
I think that simplification & variable substitution should be considered as different processes. In traditional Lisp interpreters, both variable substitution is done along with expression reduction, but this is due to the _goal_ of producing a single value at the end.
I have been talking about both _type/value/range inferencing_ and compilation; these have entirely different goals. So a "type/value/range inference macro" might be expanded during the inferencing stage, while a "compilation/efficiency-hack macro" might be expanded during a compilation stage. E.g., a type inference macro might want to force case analysis, while it might be pointless and wasteful during execution to do case analysis.
At 03:57 PM 2/24/2013, 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> 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> 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> 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.