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

Groups > comp.graphics.apps.gnuplot > #1140 > unrolled thread

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

Back to article view | Back to comp.graphics.apps.gnuplot

Contents

  (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

#1140 — (negative Value)**(-1.0) creates complex values

Is there a way to prevent gnuplot from generating complex numbers for
(negative Value)**(-1.0) and similar cases.
Here an example what I mean:

gnuplot> print (-1)**(-1)
-1.0
gnuplot> print (-1)**(-1.0)
{-1.0, -1.22460635382238e-016}

or

gnuplot> print (-1)**(-2)
1.0
gnuplot> print (-1)**(-2.0)
{1.0, 2.44921270764475e-016}


That sounds like a rouding error or something similar.

[toc] | [next] | [standalone]

#1141

On 25.05.2012 12:36, Michi wrote:
> Is there a way to prevent gnuplot from generating complex numbers for
> (negative Value)**(-1.0) and similar cases.

No.  Nor should there be one.

The result of such computations _is_ complex by definition.  If you 
don't want that answer, ask gnuplot a different question, i.e. make the 
exponent an actual integer, reduce the result to its real part.  Or 
maybe just take a step back and ask yourself what's so bad about the 
result you got.

[toc] | [prev] | [next] | [standalone]

#1144

Am 2012-05-25 20:45, schrieb Hans-Bernhard Bröker:

>> Is there a way to prevent gnuplot from generating complex numbers for
>> (negative Value)**(-1.0) and similar cases.
>
> No. Nor should there be one.

Well, (-1)**(-1) is just 1/(-1) = -1. The tiny imaginary part is just a 
rounding error. But I can't see a smooth way to avoid them since gnuplot 
doesn't know whether a real exponent is ever indented to become a 
non-integer value.

Best wishes,

Ingo

[toc] | [prev] | [next] | [standalone]

#1148

Ingo Thies wrote:

> Am 2012-05-25 20:45, schrieb Hans-Bernhard Bröker:
> 
>>> Is there a way to prevent gnuplot from generating complex numbers
>>> for (negative Value)**(-1.0) and similar cases.
>>
>> No. Nor should there be one.
> 
> Well, (-1)**(-1) is just 1/(-1) = -1. The tiny imaginary part is just
> a rounding error. But I can't see a smooth way to avoid them since
> gnuplot doesn't know whether a real exponent is ever indented to
> become a non-integer value.

It seems to me that the complaint is really about the output format.
The OP would like a way to print {-1.0, -1.22460635382238e-016} as -1,  
similar to the way %f would print -1.22460635382238e-016 as -0.000000.
That is, they want a format specifier that hides the complex nature of
a number whose imaginary component is sufficiently small.

But neither C nor gnuplot offers special format specifiers for complex
numbers.

	Ethan

[toc] | [prev] | [next] | [standalone]

#1145

Am 2012-05-25 12:36, schrieb Michi:
> Is there a way to prevent gnuplot from generating complex numbers for
> (negative Value)**(-1.0) and similar cases.
> Here an example what I mean:
>
> gnuplot>  print (-1)**(-1)
> -1.0
> gnuplot>  print (-1)**(-1.0)
> {-1.0, -1.22460635382238e-016}

Well, is there any good reason not to use integer exponents (i.e. 
without the decimal dot)?

If, however, you are using a variable as exponent which may also have 
non-integer values, for which the result is necessarily non-real, the 
only way to force a real result for integer-valued exponents would be 
some trap condition: If the exponent is integar-valued, it should be 
treated as an integer resp. the imaginary part should be treated as 
zero. Or just use the real part only, if you never expect any non-real 
result.

Just for clarification of terms: Any real number is by definition also a 
complex one (just with zero imaginary part), just as natural numbers are 
also a real, or like humans are also animals. But as not every animal is 
a human (e.g. cats are non-human animals), similarly, not every complex 
number is a real number. With "non-real number" I mean a number which 
has a non-zero imaginary part, like the one on your second print example.

Best wishes,
Ingo

[toc] | [prev] | [next] | [standalone]

#1146

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.

[toc] | [prev] | [next] | [standalone]

#1147

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.graphics.apps.gnuplot

csiph-web