The ASDF standard defines a core/complex schema for representing complex number-valued scalars in the YAML tree.
Supporting this should be part of the standard built-in extensions. This is orthogonal to #215 which refers to the complexN datatypes for ndarrays, though there is overlap in the implementation (deciding the appropriate C representation to use for complex-valued variables).
Relatedly, there was also a TODO note in docs/usage/extensions.rst, removed (for clarity) in #202 stating:
.. todo::
The core/complex tag might be a useful example to point to here, but we
haven't implemented it yet.
The thinking being that the complex extension implementation might be simple-enough to use as a good example in the documentation for defining an extension type, as opposed to the current example of a meaningless "foo" type. I'm not totally sure about this yet, but we'll see. It would probably still have to be simplified from the real implementation. Another good candidate for this might be core/constant which also still needs to be implemented (now #217).
The ASDF standard defines a
core/complexschema for representing complex number-valued scalars in the YAML tree.Supporting this should be part of the standard built-in extensions. This is orthogonal to #215 which refers to the complexN datatypes for ndarrays, though there is overlap in the implementation (deciding the appropriate C representation to use for complex-valued variables).
Relatedly, there was also a TODO note in
docs/usage/extensions.rst, removed (for clarity) in #202 stating:The thinking being that the complex extension implementation might be simple-enough to use as a good example in the documentation for defining an extension type, as opposed to the current example of a meaningless "foo" type. I'm not totally sure about this yet, but we'll see. It would probably still have to be simplified from the real implementation. Another good candidate for this might be
core/constantwhich also still needs to be implemented (now #217).