I would like to learn more about thie issues here if you don't mind, John.
My puzzlement is: -0 is such a tiny sliver of the number range. How can the treatment of -0 in the language/hardware be the thing that makes code robust or not? For example: you say you want sqrt(_1j_0) = 0j_1, but sqrt (_1j+0) = 0j1 . OK. But what is sqrt(_0.5j_0 + _0.5j+0)? Are the computations carefully arranged so that numbers that are known to approach close to 0 are allowed as operands only to a restricted set of functions that are known not to push them over the boundary? Changing the subject slightly: my mastery of complex variables could be charitably described as skeletal, but my understanding is that the branch cut could be anywhere in the complex plane; that it is chosen for convenience, being a way to treat the four-dimensional Riemann surface in three dimensions. If that's not off base, then the choice of the negative real axis for the branch cut is just an arbitrary programming decision. Wherever you put the branch cut, you should expect to have trouble that you will have to program around. Hoping that hardware support for -0 will bail you out of that trouble seems like wishful thinking to me: prone to disaster if you step over the line, and kludgy even if you get it to work somehow. I'm thinking this is what Pepe meant when he said "This is like deja vu all over again." If people are really finding -0 to be the solution to real problems, I'd like to understand better how they arrange their processing to be sure they get good results. Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Randall > Sent: Tuesday, April 24, 2007 5:24 PM > To: General forum > Subject: Re: [Jgeneral] zero > > Raul Miller wrote: > > On 4/24/07, John Randall <[EMAIL PROTECTED]> wrote: > > > >> 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.) > > > > I am by no means warning you off. I am just trying to > explain that this > sort of problem is important to people who care about > floating-point and > complex arithmetic, that they are the audience, and they might be > reasonably be expected to appreciate the example with little > preamble. I > agree that Kahan's does not explain as much as he might, and that his > style can come across as ranting. > > > 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. > > > > I agree an alternative approach could work. However, the scenario in > which a region is transformed so that part of its boundary is > a branch cut > is both common and the place for maximal error as you approach the > boundary. The inclusion of +/-0 in the IEEE standard was > inspired by this > kind of consideration, and Kahan is apoplectic that it is > ignored in many > languages used for numerical analysis, despite hardware > support. Having > language support for this eliminates a lot of work-arounds and naive > errors. > > It is impossible to get a perfect model of the complex numbers on a > computer. Kahan's suggestion addresses an important > recurring problem. > > > Best wishes, > > John > > > > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
