-
Notifications
You must be signed in to change notification settings - Fork 40
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
example: custom numeric type #370
base: devel
Are you sure you want to change the base?
example: custom numeric type #370
Conversation
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.
Thanks @ofloveandhate for the PR. I will make a pass on it when I have time in order to align it with the rest of the project. Is it fine for you?
765d4be
to
284a5f8
Compare
TODO:
|
I tried to use the code in this PR, and it doesn't install correctly on my Mac. I observe the following issues:
I think all of these are issues with the CMakeLists.txt file. |
I would love to be able to build upon this to work on some problems I'm seeing with custom numeric types in EigenPy, and make this example more complete, but I am finding the setup stuff is a barrier. Thanks! |
directly derived from other files inside eigenpy
for more information, see https://pre-commit.ci
284a5f8
to
6566e87
Compare
now makes a library without `lib` at front, and with `.so` at the end. I was able to get this to compile and import using libraries installed via `conda`.
for more information, see https://pre-commit.ci
* brought in the real visitor from stack-of-tasks#365 (from which I had previously derived the complex visitor). * provided the `real` and `imag` properties the code could be cleaner, but now I can actually import the built library, make a complex, get its real/imag parts, do arithmetic, and use dot-tab completion in ipython without crashes. (motivation: i'm working towards a MWE for the alignment issues I get in Bertini 2. either I can replicate it using this code, in which case we can find the bug / whatever in eigenpy, or I fail, and I reveal the bug in MY code.)
…com/ofloveandhate/eigenpy into feature/example_custom_numeric_type
for more information, see https://pre-commit.ci
`np.zeros()` crashes with my custom data type. I also added a function that tries to modify an existing eigen array, through the eigenpy interface, but my python script doesn't get that far.
I'm back for more help, and to help this example of using Eigenpy with a custom numeric type become fully functional. I just added some code that makes EigenPy / the example library crash. I think my code is missing something simple. The failing code in Python is merely this:
The problem is clearly uninitialized data, as per the assertion fail from MPC:
(This is a step towards another problem I have with alignment) I would love some help so that I can make arrays with my custom type in Numpy, and then feed them to C++ routines. I think this PR is a good place to do it, so that the resulting example code is contributed directly to EigenPy. (I am sorry it took me so long to follow up -- I switched jobs, moved continents, and am now in a full time research position 🥳) |
so works for either reals or complexes
including * making a numpy array of custom type from an existing array of built-in type * calling c++ function that takes eigen matrix which modifies its argument * making an array of zeros without conversion from existing numpy array
I'm getting closer to the problem I'm trying to identify:
This most recent set of commits shows that I can make numpy array of custom dtype (MpfrFloat and MpfrComplex) IF I FIRST make an array in built-in type, and convert to my own type.
But, the following still fails, which feels like a showstopper:
What magic sauce am I still missing to be able to directly make numpy arrays of custom type? |
much of the functions I added were me trying to get Python to crash in a specific way. I failed, which is a good thing, because it means that EigenPy doesn't have the bug I thought it does. BUT. EigenPy *does* have two issues exercised in the unit tests for the custom type, issues stack-of-tasks#519 and stack-of-tasks#520 . Additionally, this code exercises issue stack-of-tasks#521 , where I try to compute vector norms in two different ways and fail. Additionally, I bumped the C++ standard to C++14, since Boost 1.87 didn't work correctly with only C++11, and 1.87 is now distributed by homebrew (I develop on a Mac)
…stom_numeric_type
This pull request is an example of building against EigenPy to expose Eigen objects with custom numeric types from C++. This is in response to #365.
This example at time of PR builds and installs, but not fully correctly. It doesn't install usable Python bindings, so the example Python code is not runnable. Maybe you could do that last step? So that the built bindings can actually be used in Python?