-
Notifications
You must be signed in to change notification settings - Fork 87
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
feat: add string formatter to ak.Array.show
#2803
Conversation
Codecov Report
Additional details and impacted files
|
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.
This is great! Also, I'm glad this is opt-in, so the default precision is still 3 digits. But if someone needs to see more, we can point them to this.
It's also nice that this is following existing conventions, so the documentation only needs to reference https://numpy.org/doc/stable/reference/generated/numpy.set_printoptions.html.
@jpivarski note that the default precision for complex numbers will increase after this PR: https://github.com/scikit-hep/awkward/pull/2803/files#diff-9d47b8746eed8b0f77589c076ef5be2891fec7d0acd9d41f04dac9cc9bbb1076L227 Are you OK with that change? I'm thinking it's fine; few people are likely using complex numbers, and fewer still should be relying on the string representation. Ideally we'd gracefully handle this but I don't think it's worth the added complexity. |
I had checked out the code and had tested it with a floating point value, so I missed the fact that the complex precision used to be 2 digits >>> ak.Array([np.pi + np.pi*1j]).show()
[3.1+3.1j] but will now be 3 digits >>> ak.Array([np.pi + np.pi*1j]).show()
[3.14+3.14j] The rationale for shorter complex numbers must have been because they use up so much space anyway, with two values, a The This PR can be merged. |
This PR closes #1281 by adding support for a subset of NumPy's
printoptions
simple string formatting configuration. These options are compatible with NumPy's formatting options, apart from strings (onlystr_kind
is compatible with both libraries):"numpystr"
is ignored"str"
and"bytes"
are used for str/bytesN.B. we use the
g
conversion type, which is different to NumPy's default mode.Precision:
Formatter:
I don't think we need to fully replicate NumPy's features here, or support their options context. This PR should add enough control for some additional use cases.