Hi Henry,
I very much liked the algorithm that you evolved, and I encourage you to
publish it in CCA or elsewhere.
The method that I proposed is definitely less elegant and has an extreme
bias towards the cardinal directions. However, that bias was the intent
because so often I am thwarted by a functionality such as plotting being
foiled by a relatively negligible imaginary part or (less frequently) by a
relatively negligible real part.
Here is an improvement to my hasty algorithm: When using tolerances not
only is it a good idea to clear the denominator of a relative quantity to
avoid possible zero-division -- It is also a good idea to use "<=" rather
than "<" to make the tests work in the degenerate case when the consequent
right side is 0.0. It makes no difference for Maxima, but for Mathematica
and Maple, the 0.0*%i does not automatically disappear in 0.0 + 0.0*%i. A
strict type adherent could argue that it shouldn't go away, but I find
those pesky 0.0 imaginary parts distracting and annoying.
-- best regards, david stoutemyer
On Wed, Jul 11, 2012 at 4:09 AM, Henry Baker <hbaker1 at pipeline.com> wrote:
> Hi David:
>
> Yes, this "square" method would be better than the current situation, but
> it isn't as elegant as a "circular" method.
>
> About 85% of my motivation was the "pure math" issue of how "best" to do
> it. Now that I think I understand the problem, I'm more open to more
> engineering-oriented solutions.
>
> At 10:32 AM 6/29/2012, David Stoutemyer wrote:
> >How about:
> >
> >If abs(im) < epsilon*abs(re) then rationalize(re)
> >else if abs(re) < eplsilon*abs(im) then rationalize(im)*%i
> >else rationalize re+im*%i
> >
> >-- best regards, david stoutemyer
> >
> >On Fri, Jun 29, 2012 at 6:50 AM, Henry Baker <hbaker1 at pipeline.com>
> wrote:
> >I want to "rationalize" a complex number, but I don't want to rationalize
> the real & imaginary parts separately, because this won't convert
> 1.0+%i*1.0e-10 into 1.
> >
> >ratepsilon isn't helping here.
> >
> >Any suggestions?
> >
> >Thanks in advance.
>
>