Skip to content

DOC: Update types table #24867

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

Merged
merged 3 commits into from
Oct 17, 2023
Merged

DOC: Update types table #24867

merged 3 commits into from
Oct 17, 2023

Conversation

mtsokol
Copy link
Member

@mtsokol mtsokol commented Oct 5, 2023

Hi @rgommers @ngoldbaum,

It looks that a table with numpy to C types mapping already exists: link.

I updated it according to our discussions and a table in #24651.

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.

Just a couple comments but this looks great

@@ -12,87 +12,116 @@ Array types and conversions between types
NumPy supports a much greater variety of numerical types than Python does.
This section shows which are available, and how to modify an array's data-type.

The primitive types supported are tied closely to those in C:
NumPy's primitive types are tied closely to those in C:
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 good to explicitly explain why we have all these catagories of types. I'd replace the sentence above with this text:

NumPy provides both bit sized type names and names based on the names of C types. Since the definition of C types are platform dependent, this means the explicitly bit sized should be preferred to avoid platform-dependent behavior in programs using NumPy.

To ease integration with C code, where it is more natural to refer to platform-dependent C types, NumPy also provides type aliases that correspond to the C types for the platform.

Copy link
Member

Choose a reason for hiding this comment

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

It would also be good to explain why some types don't have a canonical name or don't have a C-like name.

Copy link
Member Author

Choose a reason for hiding this comment

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

Then I think for bool would be that bool does not exists and 0 and 1 ints are preferred (or <stdbool.h> is required).
For intp/uintp the same name could be considered as "C-like".
For longlong, because it only a C concept ported to Python?

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's ok to use the stdbool types in the table, we're already using other c99 types.

I think I just wanted you to comment that some of the type names have a trailing underscore to avoid confusion with builtin python type names. No need to go into detail on longlong and intp.

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, I added a comment about trailing underscore.

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 see two minor issues, will merge once they're fixed.

@rgommers rgommers mentioned this pull request Oct 7, 2023
9 tasks
@ngoldbaum
Copy link
Member

Sorry for not coming back to this, merging. Thanks @mtsokol!

@ngoldbaum ngoldbaum merged commit 6879655 into numpy:main Oct 17, 2023
@mtsokol mtsokol deleted the update-docs-types-table branch October 17, 2023 14:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants