#2835 Inconsistent handling of complex numbers with infinity components

[Hiroki Motoyoshi]

I've encountered inconsistent behavior when defining a complex number containing infinity values.
The real part may be converted to NaN when the imaginary part has infinity value.

gnuplot> inf = real("Inf")
gnuplot> a = inf + 2*I
gnuplot> b = 2 - inf*I
gnuplot> print real(a)
inf.0
gnuplot> print imag(a)
2
gnuplot> print real(b)
NaN                     # Expected: 2
gnuplot> print imag(b)
-inf.0
gnuplot> print real(a*I)
NaN                     # Expected: -2
gnuplot> print imag(a*I)
inf.0
gnuplot> print real(b*I)
NaN                     # Expected: inf.0
gnuplot> print imag(b*I)
NaN                     # Expected: 2

Additional minor issue 1

When a complex number has a NaN real part, the print command displays only "NaN" and suppresses the imaginary part entirely, even when the imaginary part has a valid value.

gnuplot> inf = real("Inf")
gnuplot> b = NaN + 2*I
gnuplot> print b
NaN                     # Imaginary part (2) is not displayed
gnuplot> print real(b)
NaN
gnuplot> print imag(b)
2                       # Imaginary part exists and is valid

Additional minor issue 2

The display format for infinity values includes an unnecessary .0 suffix.

gnuplot> inf = real("Inf") 
gnuplot> print inf
inf.0
gnuplot> print -inf
-inf.0

[Ethan Merritt]

Minor issue 1
This comes down to what the "print" command should do.
It could, for instance, use the new "%C" format for complex values.
I do not have a strong opinion about whether this would be better

gnuplot>  b = NaN + 2*I
gnuplot> print b
NaN
gnuplot> print gprintf("%C",b)
{nan, 2}

Minor issue 2
Fixed last month
6.1 commit bc7dbe89 "infinity has no decimal point"
6.0 commit 11dc6c24 "infinity has no decimal point"

Where to go with Inf, NaN, and complex values
As to the rest of it, thank you for bringing this up. It is very timely, as it relates strongly to the in-progress work to support the c23 language standard which is now the default for the gcc15 compiler. The clang compiler still defaults to -std=gnu17 as of clang 20.1 but I expect it will also switch to c23 in the near future.

Note that the IEEE 754 floating point standard does not specify how to handle complex numbers algorithmically nor does it is cover the presence of Inf or NaN in complex numbers. This leaves it up to individual languages, libraries, or supplemental standards to provide guidance.

Gnuplot is written in C and it's handling of arithmetic values and expressions has so far as I know always been guided by C language rules. However gnuplot predates widespread adoption of IEEE 754 and in fact it originally went to great lengths to support other standards for floating point math. You can still find remnants of this in the source code, particularly in specfun.c. Furthermore gnuplot has always supported complex values and complex arithmetic, even though the "complex" data type was not added to C until c99, which means that prior to gnuplot 6.0 we were not assuming C language support for complex values. The one exception, introduced in gnuplot 5, was optional inclusion of the libcerf special function routines if C99 support was in fact present.

OK, so c99 did introduce complex types as well as Inf and NaN. After some digging, I found that guidance for how these interact has been updated several times: for c99, c11, c17, and most recently for c23. Since we (meaning gnuplot) are just now dealing with code changes needed to make it compile cleanly with c23, I think we can skip the earlier updates and aim for guidance from the c23 standard. Unfortunately according to Wikipedia this is only publically available in draft form.
https://en.wikipedia.org/wiki/C23_(C_standard_revision)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

I have downloaded this draft but I have not yet worked through it to see where it may differ from gnuplot's current behavior. The relevant section seems to be Annex F (page 511) and maybe also Annex G if you consider the output of gnuplot's imag() function as being equivalent to the new c99 "imaginary" type.

There is also the question of when, if ever, gnuplot functions should return Inf rather than VERYLARGE (1e+308) as a numerical value.

[Hiroki Motoyoshi]

Thank you for the explanation. It gave me a good understanding of how gnuplot has struggled to handle complex numbers since before IEEE 754 became widespread. The issue with Inf and NaN in Complex that I reported was actually a behavior I discovered while testing the display of complex numbers with the print command, as I was concerned about "Minor issue 2" (which had already been fixed). Therefore, this is a long-standing behavior and may not require immediate correction. I hope an optimal solution will be found as part of addressing the changes in the C language since C99.

On a related note, I'd like to ask: in the current implementation, the operation 1.0/0.0 is treated as an undefined value—is this a specification designed to facilitate the handling of function plots with singularities?