Athan

@Snehil-Shah No, haven't had the bandwidth to think about. I updated the labels accordingly.

> will `Complex128` be formatted as `Complex128.prototype.toString()`? No, not necessarily, as users should be able to specify the desired precision, just as they can with real-valued floating-point numbers. In which...

Additionally, [`@stdlib/random/base/mt19937`](https://github.com/stdlib-js/stdlib/tree/78c20d666e1d75170afc967dfd97666e9f098f0d/lib/node_modules/%40stdlib/random/base/mt19937) is another good reference package.

@Ahtaxam Are you still interested in working on this?

@marsian83 Sure. Would you be open to working on `@stdlib/string/base/distances/hamming-code-points`?

Note that the UTF-16 code unit implementation has already been added. The code points implementation should iterate over Unicode code points (e.g., most Unicode characters and some emoji). You can...

@mayankkamboj47 Sure. You'll probably want to rely on `next-grapheme-cluster-break` in order to derive string indices for the purpose of comparing substrings.

In the specification, we opted to be [restrictive](https://data-apis.org/array-api/2022.12/API_specification/generated/array_api.astype.html#array_api.astype) in disallowing `complex -> real`. As such, I will go ahead and close this issue.

As this discussion hasn't been active in a while and the general consensus is against adding a `gradient` function to the array API specification, I'll close this out.

@honno Is this something that we can move forward?