What does a Complex number look like?

[rowlesmr]

From jamesrhester/pycifrw#22

What do Complex numbers look like?

They're defined here, but without any notion of what they look like in string representation.

Some examples include:

• 'complex number <R>+j<I>'
• 'Real + Imag' == 'Real' + 'Real[jJ]'

And for that matter, what does a Real number look like? Does the CIF1.1 spec still hold?

@jamesrhester suggests

we enhance the DDL definition to state that complex numbers should be represented in text formats as <R>+<I>j, where <R> and <I> are real numbers.

[rowlesmr]

Some things to think about:

• how to represent a negative imaginary component?
• where does the SU go, if a part of the value?
• are brackets allowed?

Some examples of potential representations:

"1.35e6 + 1.24e-7j"
"1.3(3) - 1.2(2)j"
"(1.3)+ (-1.2)j"
1.35(3)e6+1.24(29)e-7j
1.35e6(3)+1.24e-7(29)j
(1.3)+(-1.2(2))j
"1.35d6 + -1.24e-7j"

all assuming j, and placing it after the imaginary component. Could also be before, or i, I, or J.

[merkys]

With my mathematician's hat on, I would say i looks more natural. Standard libraries of C++ and Ruby uses i as well, as does Perl's Math::Complex module. Admittedly, Julia uses im and Python uses j. j seems to originate from electrical engineering.

[jamesrhester]

I am running this question past the ddlm-group, whose deliberations can be monitored here.

[vaitkus]

A similar issue has been recently raised in the IUCr ddlm-group mailing list group (https://www.iucr.org/__data/iucr/lists/ddlm-group/msg01740.html) thus we might have two discussions going on in parallel.

I think we are actually dealing with three aspects of the imaginary number representation:

1. How it is expressed in DDLm. Here it seems to be syntax agnostic and depend on the data format that uses the format (CIF, HDF5, etc.)
2. How it is expressed in a CIF that conforms to a DDLm. More on this below.
3. How it is expressed in dREL. Here it would be nice to follow the CIF+DDLm approach, however, it might not be convenient, e.g. given the similarities to Python, <R> + <I>j might seem most natural while we might end going with <R> + <I>i in the CIF.

I assume, that out of the three, @rowlesmr is most interest in option 2?

The CIF validator used in the dictionary repository checks follows the syntax of a complex number specified in a draft version of the "Construction and interpretation of CIF dictionaries" chapter of the upcoming ITC which I got to review (@jamesrhester, please correct me if the details have changed). Table 3 of the chapter provides a mapping between DDLm types and their representation in CIF, specifically, for Imag and Complex types:

DDLm type	Example	Derivation from CIF value
Imag	2.10(3)j	Final character of string should be ’j’; remainder of string interpreted as number and multiplied by i
Complex	1-3j	CIF string should have form ’a ± bj’ (whitespace optional) where a and b are interpreted as numbers)

My interpretation of this written text boils down to the following Perl regex:
^(?:$int|${float})(?:${su})?[ ]?[+-][ ]?(?:${u_int}|${u_float})(?:${su})?[jJ]$, where:

• $int, $float are signed integer and float values as defined by the CIF 1.1 grammar.
• $u_int, $u_float are same as above, but unsigned.
• $su is the standard uncertainty in parenthetic notation, i.e. (<int>).

Going back to the examples that you provide, the regex would treat them as:

Value	Status	Explanation
"1.35e6 + 1.24e-7j"	PASS	-
"1.3(3) - 1.2(2)j"	PASS	-
"(1.3)+ (-1.2)j"	FAIL	Parentheses not allowed
1.35(3)e6+1.24(29)e-7j	FAIL	Exponent must be placed before the precision
1.35e6(3)+1.24e-7(29)j	PASS	-
(1.3)+(-1.2(2))j	FAIL	Parentheses not allowed
"1.35d6 + -1.24e-7j"	FAIL	We do not support the d exponent notation as it is not really in use (although maybe we should)

[rowlesmr]

With my mathematician's hat on, I would say i looks more natural.

With my physicist's hat on, I concur wholeheartedly.

[rowlesmr]

2. How it is expressed in a CIF that conforms to a DDLm

Yes, this was my main concern.

.

Your regex matches up with my expectations.

I also did two things at once with the last string, here it is with just one:

"1.35e6 + -1.24e-7j"

Just to emphasise that the sign on the imaginary component is given by the operator joining the real and imaginary bits; it isn't always a plus operator.

.

Regarding SUs, does the following track for everyone?

_tag.complex_value "1.3(3) - 1.2(2)j"

_tag.another_complex_value     "1.3 - 1.2j"
_tag.another_complex_value_su  "0.3 + 0.2j"

There could be an additional constraint that the signs of the values in an SU can only be positive.

[rowlesmr]

Is a complex number that is purely real or purely imaginary required to still give both components?

[vaitkus]

I also did two things at once with the last string, here it is with just one:

"1.35e6 + -1.24e-7j"

This is currently not supported by the regex (but 1.35e6-1.24e-7j, 1.35e6 - 1.24e-7j, 1.35e6 -1.24e-7j) are. I guess it could be introduced, but it does look a bit strange to me.

_tag.complex_value "1.3(3) - 1.2(2)j"

_tag.another_complex_value     "1.3 - 1.2j"
_tag.another_complex_value_su  "0.3 + 0.2j"

From the representational standpoint this looks ok, however, does this take the potential correlation between the real and the imaginary part into account? Seems like a bit of a can of worms. 😰

There could be an additional constraint that the signs of the values in an SU can only be positive.

SU values are currently mandated to be non-negative, however, the concept of a non-negative value does not really apply to complex numbers, so your suggestion might be a more elegant way of requiring the values to appear in the top-right quadrant.

Is a complex number that is purely real or purely imaginary required to still give both components?

I would say "yes", both parts are always mandatory, even if they are 0.

[jamesrhester]

The CIF validator used in the dictionary repository checks follows the syntax of a complex number specified in a draft version of the "Construction and interpretation of CIF dictionaries" chapter of the upcoming ITC which I got to review (@jamesrhester, please correct me if the details have changed). Table 3 of the chapter provides a mapping between DDLm types and their representation in CIF, specifically, for Imag and Complex types:

Oops, I checked the Syntax chapter but not the Dictionary chapter when initiating the thread. The text hasn't changed since @vaitkus saw it.

The present discussion has exposed some corner cases that should be made explicit in both revised Chapter 3 text and ddl.dic. As far as I know there are no extant data files that contain complex numbers so we have some freedom of movement.

My preference would be not to allow the form a + - bj, as that is purely equivalent to a-bj and so unnecessarily complicates parsing.

Agree with the points about SU and suggestion to mandate sign always positive in SU for Complex numbers.

The point about correlations is a good one, which is best handled by a separate data name for the off-diagonal term where this is likely to be an issue. The bracket notation for SU should be seen as a convenience way of providing the values for the associated SU data names, we just don't provide that convenience for the correlation term.