Fix: Support to assign the complex number to SimpleArray #662

ThreeMonth03 · 2026-01-20T07:06:46Z

Problem

In issue #604 , when we assign values from np.complex128 or Complex to SimpleArrayComplex128, the cast of python instance fails.

import modmesh as mm
import numpy as np

nc = np.array([1.0 + 0.1j])
mc = mm.SimpleArrayComplex128([1])
mc[0] = nc[0]          # <- fails

print(mc[0].real, mc[0].imag)

Traceback (most recent call last):
  ...
  mc[0] = nc[0]
RuntimeError: Unable to cast Python instance of type <class 'numpy.complex128'> to C++ type '?' 
(#define PYBIND11_DETAILED_ERROR_MESSAGES or compile in debug mode for details)

Solution

The function __setitem__ in wrap_SimpleArray.cpp calls &property_helper::setitem_parser, and the fuunction calls &property_helper::setitem_parser checks if the value is number based on the following logic:

const bool is_number = py::isinstance<py::bool_>(py_value) || py::isinstance<py::int_>(py_value) || py::isinstance<py::float_>(py_value) || is_complex_v<T>;

This condition ignores whether py_value is np.complex128 or Complex, it just check whether py_value is modmesh.complex128.

ThreeMonth03

@yungyuc @tigercosmos Please review this pull request. Thanks.

ThreeMonth03 · 2026-01-20T07:55:50Z

cpp/modmesh/buffer/pymod/array_common.hpp

+                if constexpr (is_complex_v<T>)
+                {
+                    if (py::isinstance(py_value, complex_class))
+                    {
+                        arr_out.at(key) = py_value.cast<std_complex_t<T>>();
+                        return;
+                    }
+                }


When py_value is Complex or np.complex, casting to std::complex at first.

The if/else code is unbalanced and hard to read:

if constexpr (is_complex_v<T>) { if (py::isinstance(py_value, complex_class)) { arr_out.at(key) = py_value.cast<std_complex_t<T>>(); return; } } arr_out.at(key) = py_value.cast<T>(); return;

The following code is more concise and maintainable:

if (is_complex_v<T> && py::isinstance(py_value, complex_class)) { arr_out.at(key) = py_value.cast<std_complex_t<T>>(); } else { arr_out.at(key) = py_value.cast<T>(); }

constexpr is unnecessary because py::isinstance(py_value, complex_class) needs to happen during runtime rather than compile time.

However, the program will return compile error if we don't use if constexpr.

template <typename T> struct complex_element_type { }; template <typename T> struct complex_element_type<Complex<T>> { using type = T; }; template <typename T> using complex_element_type_t = typename complex_element_type<T>::type; template <typename T> using std_complex_t = std::complex<complex_element_type_t<T>>;

The following message is compile error.

/home/threemonth03/Downloads/modmesh/cpp/modmesh/buffer/pymod/wrap_SimpleArrayPlex.cpp:325:55: required from here /home/threemonth03/Downloads/modmesh/cpp/modmesh/math/Complex.hpp:287:7: error: no type named ‘type’ in ‘struct modmesh::complex_element_type<double>’ In file included from /home/threemonth03/Downloads/modmesh/cpp/modmesh/math/math.hpp:8, from /home/threemonth03/Downloads/modmesh/cpp/modmesh/buffer/SimpleArray.hpp:32, from /home/threemonth03/Downloads/modmesh/cpp/modmesh/buffer/buffer.hpp:38, from /home/threemonth03/Downloads/modmesh/cpp/modmesh/toggle/toggle.hpp:32, from /home/threemonth03/Downloads/modmesh/cpp/modmesh/python/common.hpp:38, from /home/threemonth03/Downloads/modmesh/cpp/modmesh/buffer/pymod/buffer_pymod.hpp:34, from /home/threemonth03/Downloads/modmesh/cpp/modmesh/buffer/pymod/wrap_SimpleArray.cpp:29:

Interesting. Please figure out why.

Interesting. Please figure out why.

The error message is simple, it caused from the missing alias in generic template.

template <typename T> struct complex_element_type { };

However, if we add the alias using type = T; in generic template, it would deduce to a wrong type, so I think I should redesign the template , such that it might look like using convert_to_std_t = something...;.

ThreeMonth03 · 2026-01-20T07:56:56Z

cpp/modmesh/math/Complex.hpp

+template <typename T>
+struct complex_element_type
+{
+};
+
+template <typename T>
+struct complex_element_type<Complex<T>>
+{
+    using type = T;
+};
+
+template <typename T>
+using complex_element_type_t = typename complex_element_type<T>::type;
+
+template <typename T>
+using std_complex_t = std::complex<complex_element_type_t<T>>;
+


Given the type of complex<T>, return std::complex<T>

ThreeMonth03 · 2026-01-20T07:57:44Z

cpp/modmesh/math/pymod/wrap_Complex.cpp

+            .def("__complex__",
+                 [](const wrapped_type & self)
+                 {
+                     return self.to_std_complex();
+                 })


Add an interface to support casting.

yungyuc

Good job. Points to address:

Balance the if/else to improve readability for the value assignment.
Write an informative summary in the commit log.

yungyuc · 2026-01-20T14:43:38Z

cpp/modmesh/buffer/pymod/array_common.hpp

+                if constexpr (is_complex_v<T>)
+                {
+                    if (py::isinstance(py_value, complex_class))
+                    {
+                        arr_out.at(key) = py_value.cast<std_complex_t<T>>();
+                        return;
+                    }
+                }


The if/else code is unbalanced and hard to read:

if constexpr (is_complex_v<T>) { if (py::isinstance(py_value, complex_class)) { arr_out.at(key) = py_value.cast<std_complex_t<T>>(); return; } } arr_out.at(key) = py_value.cast<T>(); return;

The following code is more concise and maintainable:

if (is_complex_v<T> && py::isinstance(py_value, complex_class)) { arr_out.at(key) = py_value.cast<std_complex_t<T>>(); } else { arr_out.at(key) = py_value.cast<T>(); }

constexpr is unnecessary because py::isinstance(py_value, complex_class) needs to happen during runtime rather than compile time.

ThreeMonth03

Balance the if/else to improve readability for the value assignment.

Write an informative summary in the commit log.

@yungyuc Please review this pull request again. Thanks.

ThreeMonth03 · 2026-01-21T10:54:03Z

cpp/modmesh/buffer/pymod/array_common.hpp

+template <typename T>
+struct convert_to_std
+{
+    using type = T;
+};
+
+template <typename T>
+struct convert_to_std<Complex<T>>
+{
+    using type = std::complex<T>;
+};
+
+template <typename T>
+using convert_to_std_t = typename convert_to_std<T>::type;
+


The template could identify not only modmesh::complex<T> but also standard type.

ThreeMonth03 · 2026-01-21T10:54:24Z

cpp/modmesh/buffer/pymod/array_common.hpp

-
+                if (is_complex_v<T> && py::isinstance(py_value, complex_class))
+                {
+                    arr_out.at(key) = py_value.cast<convert_to_std_t<T>>();
+                    return;
+                }


Remove if constexpr.

Please balance if/else as I mentioned in the previous review:

if (/* ... */) { // ... } else { // ... }

The early return should be factored outside the branch.

I notice that if we replace the branch with the following code, it also could work.

arr_out.at(key) = py_value.cast<convert_to_std_t<T>>();

However, if the input is modmesh::complex<T>, it casts to std::complex<T> at first, then it casts to modmesh::complex<T>. I'm not sure which design is better.

yungyuc

The commit log looks good, but you did not balance the branch.

yungyuc · 2026-01-21T23:34:55Z

cpp/modmesh/buffer/pymod/array_common.hpp

-
+                if (is_complex_v<T> && py::isinstance(py_value, complex_class))
+                {
+                    arr_out.at(key) = py_value.cast<convert_to_std_t<T>>();
+                    return;
+                }


Please balance if/else as I mentioned in the previous review:

if (/* ... */) { // ... } else { // ... }

The early return should be factored outside the branch.

…the argument of `np.complex` - Check whether `py::object py_value` is `np.complex`. - If `py::object py_value` is `np.complex`, cast `py::object py_value` to `modmesh::complex<T>`.

ThreeMonth03

@yungyuc Please review this pr. Thanks.

ThreeMonth03 · 2026-01-24T10:57:08Z

cpp/modmesh/buffer/pymod/array_common.hpp

-
+                if (is_complex_v<T> && py::isinstance(py_value, complex_class))
+                {
+                    arr_out.at(key) = py_value.cast<convert_to_std_t<T>>();
+                    return;
+                }


I notice that if we replace the branch with the following code, it also could work.

arr_out.at(key) = py_value.cast<convert_to_std_t<T>>();

However, if the input is modmesh::complex<T>, it casts to std::complex<T> at first, then it casts to modmesh::complex<T>. I'm not sure which design is better.

ThreeMonth03 force-pushed the issue604 branch 2 times, most recently from 9d890ea to 7836ffb Compare January 20, 2026 07:39

ThreeMonth03 commented Jan 20, 2026

View reviewed changes

yungyuc requested a review from j8xixo12 January 20, 2026 14:36

yungyuc assigned ThreeMonth03 Jan 20, 2026

yungyuc requested changes Jan 20, 2026

View reviewed changes

yungyuc added the array Multi-dimensional array implementation label Jan 20, 2026

ThreeMonth03 force-pushed the issue604 branch from 7836ffb to 9792bac Compare January 21, 2026 10:44

ThreeMonth03 commented Jan 21, 2026

View reviewed changes

yungyuc requested changes Jan 21, 2026

View reviewed changes

ThreeMonth03 force-pushed the issue604 branch 3 times, most recently from a9ae9be to a3f3b10 Compare January 22, 2026 10:21

Fix array_common.hpp: Fix the function setitem_parser to deal with …

f93b669

…the argument of `np.complex` - Check whether `py::object py_value` is `np.complex`. - If `py::object py_value` is `np.complex`, cast `py::object py_value` to `modmesh::complex<T>`.

ThreeMonth03 force-pushed the issue604 branch from a3f3b10 to f93b669 Compare January 24, 2026 09:33

ThreeMonth03 commented Jan 24, 2026

View reviewed changes

ThreeMonth03 requested a review from yungyuc January 24, 2026 10:58

Fix: Support to assign the complex number to SimpleArray #662

Are you sure you want to change the base?

Fix: Support to assign the complex number to SimpleArray #662

Uh oh!

Conversation

ThreeMonth03 commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Uh oh!

ThreeMonth03 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 Jan 20, 2026 • edited by yungyuc Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yungyuc left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yungyuc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 left a comment

Choose a reason for hiding this comment

Uh oh!

ThreeMonth03 Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ThreeMonth03 commented Jan 20, 2026 •

edited

Loading

ThreeMonth03 Jan 21, 2026 •

edited

Loading

ThreeMonth03 Jan 21, 2026 •

edited

Loading

ThreeMonth03 Jan 20, 2026 •

edited by yungyuc

Loading

yungyuc left a comment •

edited

Loading

ThreeMonth03 Jan 24, 2026 •

edited

Loading

ThreeMonth03 Jan 24, 2026 •

edited

Loading