sympy build

[mmaz]

Thanks for this really great library! I'm excited to start using it! I was able to run the first example but I had to work around a couple of spots in sympy_utils.py which didn't work on my platform, anaconda python 2.7.15 with sympy 1.2 on OSX (with Apple's gcc).

Any advice on what I should change or what dependencies I should add on my platform? Thanks!

The workarounds I needed to run the first example are as follows:

First, after changing build_sympy_modules_on_import = True, line 476 raised an error:

'module' object has no attribute '_get_code_wrapper_class'

My hasty workaround for 476(without support for other backends):

-    CodeWrapperClass = sympy.utilities.autowrap._get_code_wrapper_class(backend)
+    if backend == "f2py":
+        CodeWrapperClass = sympy.utilities.autowrap.F2PyCodeWrapper
+    elif backend == "cython":    
+        CodeWrapperClass = sympy.utilities.autowrap.CythonCodeWrapper

Nominally, should build_module_autowrap not be running down that codepath? (I haven't taken any time to understand what's going on inside of it yet.)

I also am using osx's clang-/llvm gcc, without openmp installed, and had to edit a few other items:

1) I had to remove the compile and link arguments to openmp, and also -fno-var-tracking-assignments in this template, since clang raises an error:

clang: error: unknown argument: '-fno-var-tracking-assignments'

2) similarly I had to remove -fno-var-tracking-assignments and also remove the second instance of include_dirs here due to the following error:

extra_compile_args=['-std=c99','-fno-var-tracking','-fno-var-tracking-assignments'], include_dirs=[numpy.get_include()],
SyntaxError: keyword argument repeated

After these changes, the first example on the homepage worked.

Again, thanks so much for providing this library!

Update, 9/4/18

I did also try linking to openmp on my platform with brew install libomp. The brew formula comes with "caveat" instructions, quoting:

"On Apple Clang, you need to add several options to use OpenMP... This usually looks like -Xpreprocessor -fopenmp -lomp"

So now my sympy_utils.py looks like this (in a blind attempt to follow the instructions without knowing proper OpenMP linking procedures):

-extra_compile_args = [ "-fopenmp", "-fno-var-tracking", "-fno-var-tracking-assignments" ]
-extra_link_args    = [ "-fopenmp" ]
+extra_compile_args = [ "-fno-var-tracking", "-Xpreprocessor", "-fopenmp", "-lomp" ]
+extra_link_args    = [ "-Xpreprocessor", "-fopenmp", "-lomp" ]

This does generate some clang warnings after setting build_sympy_modules_on_import = True (this time in quadrotor_3d.py which I did not build as part of my initial issue posting, since the first example on the homepage uses quadrotor_2d.py):

clang: warning: -lomp: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-Xpreprocessor -fopenmp' [-Wunused-command-line-argument]

In any case, I'm able to run the examples in this notebook so in the short-term I will wait to dig in further.

[mikeroberts3000]

Hello there. I apologize for the delayed reply. For some reason, I did not get a notification that you had submitted this issue.

Thank you for creating these useful workarounds.

1. I don't need this workaround with sympy 1.0, which is the latest available in the Canopy package manager. But it is good to know how to fix this code snippet for sympy 1.2.

2. I don't need this workaround with gcc 4.9 installed via Homebrew. I also don't remember exactly what these extra compiler arguments do. I think I copied the openmp flag from some cython reference example, or possibly some cython code that was auto-generated by sympy. I think I found the other flags as a way to speed up the compilation of very large complicated mathematical expressions. Regardless, if you can get up and running with your modifications using clang, that is great news.

I'll leave this issue open because I should document the sympy dependencies better. Depending on your system configuration, you will need to rebuild the sympy expressions. Rebuilding the sympy expressions means that you need a matching version of sympy and gcc (or in your case clang).

[mikeroberts3000]

I've decided to close this issue because the relevant workarounds are documented here, and it will be a while before I get a chance to further improve the documentation.