-
-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
DOC: Update types table #24867
Conversation
4003270
to
4ca2542
Compare
There was a problem hiding this 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
doc/source/user/basics.types.rst
Outdated
@@ -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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
Sorry for not coming back to this, merging. Thanks @mtsokol! |
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.