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

DM-13534: avoid usage of old ndarray PyConverter APIs #325

Merged
merged 3 commits into from Mar 8, 2018

Conversation

TallJimbo
Copy link
Member

pybind11's own numpy APIs are now preferred, as that's what the ndarray pybind11 converters use.

Both old and new code depend on ndarray internals, but at
least the new code depends on something that really ought
to be public rather than something that has already been
removed.
These are contiguous arrays, and we should tell NumPy that.
...in one file, to make sure it works.  Removing the
rest will be another ticket.
CatalogT<Record> const& catalog, ///< Catalog
Key<T> const& key ///< Key to column to extract
) {
ndarray::Array<typename Field<T>::Value, 1, 0> out = ndarray::allocate(catalog.size());
ndarray::Array<typename Field<T>::Value, 1, 1> out = ndarray::allocate(catalog.size());
Copy link

Choose a reason for hiding this comment

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

How many more of these are out there? And would auto work nicely for them to prevent such issues in the future?

Copy link
Member Author

@TallJimbo TallJimbo Mar 6, 2018

Choose a reason for hiding this comment

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

These are not a big deal; it basically boils down to whether incrementing an iterator uses n += s (where s == 1) instead of just ++n. I just happened to notice it here.

auto won't help at all and in fact would hurt quite a bit, because ndarray::allocate doesn't return an Array and we're relying on implicit conversions in an expression-template kind of way.

declareBaseColumnViewArrayOverloads<std::uint8_t>(cls);
declareBaseColumnViewArrayOverloads<std::uint16_t>(cls);
declareBaseColumnViewArrayOverloads<int>(cls);
declareBaseColumnViewArrayOverloads<float>(cls);
declareBaseColumnViewArrayOverloads<double>(cls);
// Angle requires custom wrappers, because ndarray doesn't
// recognize it natively; we just return a double view
// (e.g. radians).
Copy link

Choose a reason for hiding this comment

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

This is breaking the encapsulation of Angle a bit right? Or does the API for getData specify that the values are in radians?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, it's breaking encapsulation, but it was broken before; I'm just breaking it differently now.

@TallJimbo TallJimbo merged commit bf9fc95 into master Mar 8, 2018
@ktlim ktlim deleted the tickets/DM-13534 branch August 25, 2018 06:44
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.

None yet

2 participants