Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating Quaddtype #102

Merged
merged 33 commits into from
Sep 22, 2024
Merged

Updating Quaddtype #102

merged 33 commits into from
Sep 22, 2024

Conversation

SwayamInSync
Copy link
Contributor

This PR updates the following to quaddtype

  • Support for second longdouble backend
  • more unary and binary funcs
  • renamed to numpy_quaddtype
  • Dragon4 printing

and more small refactors

Copy link
Member

@ngoldbaum ngoldbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not carefully review all the reference counting or go over everything with a fine-toothed comb but I did go over the whole thing and followed along with the structure.

Overall this looks really nice. I think there are some clear paths to improve it, but that's always going to be the case and this is already far enough along that once we have some basic docs written we can try inviting people to test it and start thinking about a NEP to do something about np.128.

quaddtype/README.md Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed for this PR, but it would be nice to get proper docstrings for all the types and functions that are visible to python. Also a small module-level docstring showing basic usage.

else {
result.longdouble_value = x;
}
return result;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not needed for this PR, but the repeated boilerplate above is a good place to use a template function IMO

}
else {
return x.longdouble_value;
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be simpler to template over backend and output type, then you wouldn't need the runtime branching.

quaddtype/numpy_quaddtype/src/casts.cpp Show resolved Hide resolved
quaddtype/numpy_quaddtype/src/dtype.c Outdated Show resolved Hide resolved
quaddtype/numpy_quaddtype/src/ops.hpp Outdated Show resolved Hide resolved
quaddtype/numpy_quaddtype/src/scalar.c Outdated Show resolved Hide resolved
quaddtype/numpy_quaddtype/src/umath.cpp Show resolved Hide resolved
quaddtype/numpy_quaddtype/src/umath.cpp Outdated Show resolved Hide resolved
@ngoldbaum ngoldbaum merged commit 79e5ea2 into numpy:main Sep 22, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants