On 4/24/07, John Randall <[EMAIL PROTECTED]> wrote:
Raul Miller wrote: > gz=:*: + ] * 1e_99 + %:@(1 + *:) > > This eliminates the quirks that I think we are calling the problem.
I agree that your new verb avoids zero crossings with 200 at the end, but not with 300. You also get the artifact of a short segment of the channel wall in a streamline. There are also corners in the streamlines: impossible if the transform is conformal, and in particular preserves local angles. Choosing a small negative epsilon is not a million miles from recognizing -0.
Ok: I see the zero crossing that results from extending the radius to 3. And, I see the roughly horizontal lines which I presume are what you mean by "a short segment of the channel wall in a streamline", with corners at the ends of those horizontal lines.
We could argue endlessly about the details of the example. It obviously did not impress you.
Right -- it did not impress me because it left out so many details about what is supposed to be going on here, and why I should expect different behavior.
Its intended audience is people doing scientific computation, where solutions to differential equations (like streamlines) are commonplace. People using complex numbers expect them to work correctly in standard scenarios, such as conformal mappings of boundary value problems.
Ok. If you believe this topic should not be approached by a person without that background, I guess I should not post further on this topic. (Though I might if I find what I feel is an elegant way of finding these streamlines without the artifacts you've mentioned here.)
Kahan's point is that Fortran-style complex numbers do not allow one to express some one-sided limits because of the way standard libraries implement complex square root and log (they ignore the sign of +/-0 in real and imaginary parts and assume there is just one complex zero). This is particularly problematic at branch points, which are also important in practice. Minor changes to languages, such as has been done in C99, can be done easily. This makes an important application (numerical solution of differential equations: probably 99% of all floating-point CPU cycles) less error-prone.
Ok... I am not completely convinced that an alternate representation couldn't also address the issue of which branch point value is desired from the function range. However, I do understand that this is an important issue. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
