Consider making a module rather than a fork

[rkern]

Hello!

I am an occasional numpy core developer, and I have a couple of questions and suggestions that might help getting this work used in the numpy community.

First, do you need this to be a fork of numpy? I haven't reviewed all of your modifications, but it seems to me that you are mostly adding a new dtype for posits. numpy does have the facility for new dtypes to be added by third-party packages without having to modify numpy itself. The support isn't necessarily the greatest, but if you run into issues, we'd like to hear about them; we would like to fix them to make life easier for you. You can see the numpy-quaternion package as an example of providing a new dtype. We very much encourage this approach.

If you do need to modify numpy itself, do you intend to propose merging this work into upstream numpy? If so, I recommend following the git workflow outlined in the Numpy Developer's Guide. Specifically, in your Github fork, leave the master branch untouched and work in a separate branch. This will help you stay up to date with upstream development and facilitate comparisons with the mainline development through the Github interface. When you are ready, you can just make a PR to numpy.

The problem with maintaining a true fork of numpy is that users are going to have problems deploying packages that depend on numpy-posit and other packages that depend on numpy proper. pip and other package management tools don't necessarily work particularly well in such cases.

In any case, I wish you the best of luck! I look forward to experimenting with posits in the future! Thank you for your attention.

[xman]

Hi Robert,

Thanks for your feedback. Didn't see the feedback until now.

I was initially started with building posit as numpy extension. I was able to get the basic stuffs working, but the ufunc type resolving and other issues that I have forgotten now didn't work the same for native dtype and extended dtype through dtype registration API. The functions that are defined through PyNumberMethods are working well. But there are a whole list of ufunc in the numpy/core/code_generators/generate_umath.py that I didn't manage to get them work with non-standard dtype. The PyUFunc_FromFuncAndData didn't allow me to define for non-standard dtypes.

As we currently use floating as the number category for posits, it does create some confusions on the coercion e.g. posit32 and float32 are same byte size, the current numpy type system thinks posit32 (with 4 bytes and also floating category) is the same as float32, hence mess up in the type resolving.

I'll check out the numpy-quaternion to see if there are something I missed. I do hope the posit can be integrated as extension as that will avoid whole lot of other problems that you described. I'm aware of the pypi issue that the dependencies will mess up.

Once we have a consensus on the best method to merge into upstream, I'll like to update and do that merging as an optional numpy feature.

In summary, my previous main issues with building posit as numpy extension were on getting the whole list of ufunc to work seamlessly with new posit dtype, and the type coercion needs to work correctly.

Thanks again for your feedback.

Regards,
Shin Yee