Surely those who differentiate 1j0 and 1j_0 in the sqrt are asking that 2
square roots be returned. If there is a difference between _0 and 0 in your
software I wonder if anyone really understands what is going on.
On Wed, 25 Apr 2007, Henry Rich wrote:
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
