>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.
>>>
>>>
>>
>