Someone from the Fortran community might find this discussion completely incomprehensible.
Perhaps a symbolic algebra system that steadfastly refuses to produce numeric output in spite of the severest possible beatings should be considered to be a triumph of symbolic manipulation?? :-)
At 04:14 PM 2/24/2013, Richard Fateman wrote:
>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> 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.
>