Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #1147

Re: (negative Value)**(-1.0) creates complex values

Show all headers | View raw

In article 
<ae3f9a7a-c5cf-41ac-a8fd-72f9ff08d3c5@w24g2000vby.googlegroups.com>,
 Michi <michael.boelling@gmail.com> wrote:

> The reason I introduced real values is that I convert my equations
> from content mathml to gnuplot with formconv 
> http://sourceforge.net/projects/formconv/
> .
> Numbers are there converted into fractions and I ended up with integer
> division resulting in 0 values like
> 1/10000=0 as they where threated as integers. To avoid that there is
> an option -r that adds 1.0* to every number and so I ended up with
> real valued exponents and as a result complex numbers and the plot
> routine that does several thousand plots threw an exception: all y
> values undefined as the plot command could not handle complex numbers.
> I now catch that exception a replot the equation wrapped by real() but
> I was thinking of maybe there is another solution to this problem.
> Maybe I try a regular expression that converts digits.0 in the **
> function to integers.
> 
> Reading all your comments is very helpful, thanks.

FYI, the way gnuplot treats the a^b expression is the same way other 
programming languages treat it.  With the integer arguments, the 
result is computed with (effectively) repeated multiplications and 
divisions.  The math libraries do this in a fancy way so that large 
exponents are done efficiently, but that is really the way the 
expression is evaluated.  When a is real and b is a small integer, 
the same approach is used.  Multiplications and divisions of real 
numbers result in real numbers, so everything is done with purely 
real arithmetic.

Floating point exponents and large integer exponents are not done 
this way.  Instead the identity x=exp(ln(x)) is used to evaluate the 
expression.  For x=a^b, this means that the result is evaluated as

   exp(b * ln(a))

For positive a, this is done with real arithmetic, and everything 
agrees with the repeated mulitplication approach.

For negative a (or complex b), the result is generally complex, so 
the expression is evaluated the same way regardless of the value of 
b in order to have smooth continuous results as b changes 
continuously by small amounts.

Consider the special case when b is 1/2.  Now you know that there 
are two solutions that differ by a sign.  When a is positive, the 
two solutions are real, and when a is negative the two solutions are 
purely imaginary.  The above expression only returns one of them, 
and sometimes that is the one you want and sometimes you want the 
other one.  It depends on what you need at the time.  When b is real 
and near the value of 1/2, you might want the result to vary 
smoothly within that neighborhood.  Or you might not, you might want 
some other condition to determine which solution is plotted.

When b is 1/3, then you know that there are three solutions.  Things 
are a little more complicated because now there are three values to 
choose from.  In general, when b is near 1/n for some integer n, 
there are n different solutions and you need to decide which one you 
want: the continuous one, the one with positive real part, the one 
with positive imaginary part, the one with the smallest imaginary 
magnitude, and so on.

The concept of "b changing continuously" when b is an integer does 
not apply.  So computer languages treat the two cases, b integer and 
b real, completely differently.  As you can see in your calculated 
results, in this case the complex result is almost the same as the 
real result.  There is a very small imaginary error when evaluating 
the complex expression.  In other cases, there will be a large 
difference in evaluating the two expressions because of branch 
points and Riemann sheets in the complex case.  If you don't know 
what those things are, look them up in google and you will begin to 
see how interesting this topic is.

From your comments above, it looks like you are on the right track 
to understanding this issue.

$.02 -Ron Shepard

Back to comp.graphics.apps.gnuplot | Previous | Next — Previous in thread | Find similar

Thread

(negative Value)**(-1.0) creates complex values Michi <michael.boelling@gmail.com> - 2012-05-25 03:36 -0700
  Re: (negative Value)**(-1.0) creates complex values Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-05-25 20:45 +0200
    Re: (negative Value)**(-1.0) creates complex values Ingo Thies <ingo.thies@gmx.de> - 2012-05-26 10:07 +0200
      Re: (negative Value)**(-1.0) creates complex values sfeam <sfeam@users.sourceforge.net> - 2012-05-26 10:38 -0700
  Re: (negative Value)**(-1.0) creates complex values Ingo Thies <ingo.thies@gmx.de> - 2012-05-26 10:19 +0200
    Re: (negative Value)**(-1.0) creates complex values Michi <michael.boelling@gmail.com> - 2012-05-26 02:39 -0700
      Re: (negative Value)**(-1.0) creates complex values Ron Shepard <ron-shepard@NOSPAM.comcast.net> - 2012-05-26 11:42 -0500

csiph-web