Also, as discussed a few months ago, converting complex numbers to rationals is done on the real and imaginary parts _separately_.
This behavior is not in the spirit of epsilons in the complex plane, where the epsilon is typically the radius of a _circle_ in the complex plane.
At 01:09 PM 11/29/2012, Richard Fateman wrote:
>The arguments about how to deal with floats probably will continue indefinitely.
>
>Initially (circa 1968) all floats were converted to rationals by rat() etc.
>This doesn't work for sin/cos/exp/log, so it can't be a solution for the whole system.
>
>Doing rational expression arithmetic with floats is almost OK if you have polynomials
>only, but gets sticky if you have ratios.
>e.g. a=(0.5*x+5)/(3*x+9)
> and b= (1/6*x+5/3)/(x+3.0))
>come out looking different, but might be the same. GCD doesn't really work
>(officially, in a field-theoretic view, all non-zero numbers are "units" and so
>all denominators could be made monic, or not.)
>
>I noticed that definite integration uses exact numbers for certain tests, like
>introducing 1/100000000 here and there. I view this as an unfortunate
>heuristic, just waiting for some nasty bug-finder to announce a bad result...
>
>Keeping floats away has the downside of making computations take a long time,
>especially if the actual knowledge of the numbers do not justify carrying around
>extra precision, and in the case of rationals, an exponential growth in the number
>of digits.
>
>I would encourage people to change Maxima to warn users who start inputting
>floats, that the system is oriented toward exact arithmetic, and typing 0.5 instead
>of 1/2 can have dramatic mostly undesirable consequences. On the other
>hand, floats can be useful if needed for transcendental functions, plotting,
>approximating irrational or even rational number, and in general
>numerical iterative computations.
>
>RJF
>
>On 11/29/2012 9:32 AM, Robert Dodier wrote:
>>integrate and probably other functions don't handle floats in
>>expressions very well, so the keepfloat flag causes trouble for them.
>>Can we straighten things out by doing away with keepfloat? Or should we
>>try to fix the bugs in integrate & elsewhere? E.g. maybe we can fix all
>>such bugs by substituting symbols for floats, carrying out the
>>calculation, then substituting again at the end. I suppose that could
>>change the result in unpredictable ways -- integrate might succeed with
>>a number but not a symbol, or vice versa -- but maybe that's preferable
>>to running into an error.
>>
>>Bug report [1] is the immediate motivation for this message, although
>>we've known about such problems for a long time.
>>
>>best,
>>
>>Robert Dodier
>>
>>[1] http://sourceforge.net/p/maxima/bugs/2510/