I'll open a PR first (symengine/symengine#1549) with an addition to the dump/save test to verify it fails and the test is working as intended, then I'll push the fix
I'm trying to get a symengine development environment set up and I'm having some trouble. SymEngine builds and the test binaries pass, but when I try to build symengine.py, I get
(calphadpy3) rotis@x86_64-conda_cos6-linux-gnu ~/git/symengine.py (master) $ python setup.py install build_ext --symengine-dir=$HOME/git/symengine/build --inplace
running install
running build
running build_ext
SymEngine_DIR : /home/rotis/git/symengine/build/lib/cmake/symengine
SymEngine Version : 0.4.0
-- Python include path: /home/rotis/anaconda3/envs/calphadpy3/include/python3.7m
-- Python version: 3.7
-- Python install path: /home/rotis/anaconda3/envs/calphadpy3/lib/python3.7/site-packages
-- Found CYTHON: cython
CMAKE_BUILD_TYPE : Release
CMAKE_CXX_FLAGS : -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe
CMAKE_CXX_FLAGS_RELEASE : -Wall -Wextra -Wno-unused-parameter -fno-common -O3 -march=native -funroll-loops -std=c++11 -fPIC -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DNDEBUG -fopenmp
CMAKE_CXX_FLAGS_DEBUG : -Wall -Wextra -Wno-unused-parameter -fno-common -g -ggdb -std=c++11 -fPIC -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fopenmp
HAVE_SYMENGINE_MPFR : False
HAVE_SYMENGINE_MPC : False
HAVE_SYMENGINE_PIRANHA : False
HAVE_SYMENGINE_FLINT : False
HAVE_SYMENGINE_LLVM : True
Copying source of python wrappers into: /home/rotis/git/symengine.py
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rotis/git/symengine.py
[ 25%] Building CXX object symengine/lib/CMakeFiles/symengine_wrapper.dir/symengine_wrapper.cpp.o
In file included from /home/rotis/git/symengine/build/lib/cmake/symengine/../../../include/symengine/mp_class.h:7:0,
from /home/rotis/git/symengine.py/symengine/lib/symengine_wrapper.cpp:620:
/home/rotis/git/symengine/build/lib/cmake/symengine/../../../include/symengine/mp_wrapper.h:5:10: fatal error: gmp.h: No such file or directory
#include <gmp.h>
^~~~~~~
compilation terminated.
gmake[2]: *** [symengine/lib/CMakeFiles/symengine_wrapper.dir/build.make:69: symengine/lib/CMakeFiles/symengine_wrapper.dir/symengine_wrapper.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:177: symengine/lib/CMakeFiles/symengine_wrapper.dir/all] Error 2
gmake: *** [Makefile:130: all] Error 2
error: error building project
I am on master for both
specifically,
cmake -DCMAKE_CXX_FLAGS="-I/usr/include -L/usr/lib64" seemed to do the trick
I did eventually fix it and can run lambdify from symengine.py. The problem was some "mixing" between my conda toolchain (gcc 7) and my system toolchain (gcc 9). I rebuilt symengine completely isolated from conda. The line I used was
cmake -DCMAKE_INSTALL_PREFIX=$HOME/git/symengine/build -DINTEGER_CLASS=boostmp -DWITH_LLVM=8.0 -DWITH_OPENMP=yes .
Then, still isolated from conda, I went to symengine.py and manually ran
cmake -DSymEngine_DIR=$HOME/git/symengine/build . && make
Only at that point did I activate my conda environment and run
pip install -e . to make symengine.py available to conda. Everything was built using my system gcc
Hello there. Thanks for your awesome library.
Please have a look to this:
#include <symengine/expression.h>
int main(int argc, char* argv[]) {
auto x = SymEngine::symbol("x");
std::cout << "#1: " << SymEngine::Expression(SymEngine::abs(SymEngine::abs(x))) << "\n";
std::cout << "#2: " << SymEngine::Expression(SymEngine::abs(SymEngine::mul(x, SymEngine::sign(x)))) << "\n";
std::cout << "#3: " << SymEngine::Expression(SymEngine::floor(SymEngine::ceiling(x))) << "\n";
std::cout << "#4: " << SymEngine::Expression(SymEngine::ceiling(SymEngine::floor(x))) << "\n";
return 0;
}Output:
#1: abs(abs(x))
#2: abs(x*sign(x))
#3: ceiling(x)
#4: floor(x)Maybe I'm doing something wrong, but I'd expect #1 = #2 = abs(x)
What do you think about that?
@isuruf thank you very much. To be honest I wouldn't even need the second one if the truncate function (aka static_cast<int>) was implemented. In fact, as a temporary solution, I solved it using
SymEngine::mul(SymEngine::sign(lhs), SymEngine::floor(SymEngine::abs(lhs))) in its place.
Any chance that truncate function will be implemented?
@isuruf Not sure if this is a big favor to ask, but would it be possible to cut a new release of symengine.py? Our downstream project would like to take advantage of symengine/symengine.py#288 to make some performance improvements
And @bocklund reminds me there's a quality-of-life improvement in main symengine too, symengine/symengine#1549, which we'd love to use as well
@richardotis, if you could help write the release notes at https://github.com/symengine/symengine/wiki/Release-notes-for-v0.4.1 that'll speedup a new release
@torshind_gitlab, I don't have the time to do that, but I'll review a PR if you send one
@isuruf I added a bit to your draft release notes. I started from symengine/symengine@cab0213 and worked my way to master HEAD. Let me know what you think and if there's anything else I can do to help.
I have a March-April conference slot I've been looking to replace with a SciPy-type conference, though.
r1 = add(add(real_double(0.), x), y);
std::cout << *r1 << std::endl;
r1 = expand(add(add(real_double(0.), x), y));
std::cout << *r1 << std::endl;
r1 = expand(add(x, mul(real_double(4.), y)));
std::cout << *r1 << std::endl;
r1 = expand(add(x, mul(real_double(4.), add(y, z))));
std::cout << *r1 << std::endl;
r1 = expand(add(x, mul(integer(4), add(y, z))));
std::cout << *r1 << std::endl;
r1 = expand(mul(real_double(4.), add(y, z)));
std::cout << *r1 << std::endl;
r1 = expand(mul(integer(4), add(y, z)));
std::cout << *r1 << std::endl;
Output:
x + y
x + y
x + 4.0*y
0.0 + x + 4.0*y + 4.0*z
x + 4*y + 4*z
0.0 + 4.0*y + 4.0*z
4*y + 4*z
Do you have any idea how to eliminate the spurious 0.0 when the coefficients are double?
You can eliminate 0.0 in the final expression by checking if the expression is an
Add and if the coefficient is 0.0, remove it
But that doesn't fix 0.0 in intermediate expressions
On second thought, returning
0 for expand(4.0*(x + y - (x+y))) is totally fine
thanks again @isuruf
I could use some help in fixing the tests of symengine.py at symengine/symengine.py#289
@stevenleeS0ht, yes, we usually only support one version of symengine recorded at https://github.com/symengine/symengine.py/blob/master/symengine_version.txt
@isuruf Hi Isuru, long time no see! Was wondering if the following behavior is expected. Thanks!! (master, ed7479baf59a36636061acc35b676bcf9073a932)
int main() {
RCP<const Basic> a = symbol("a"), b = symbol("b"), c = symbol("c");
map_basic_basic d {{mul(a,b), c}};
RCP<const Basic> r1 = mul(SymEngine::integer(2), mul(a, b)),
r2 = add(SymEngine::integer(1), r1);
std::cout << *r1 << " -> " << *r1->subs(d) << std::endl;
std::cout << *r2 << " -> " << *r2->subs(d) << std::endl;
return 0;
}produces
2*a*b -> 2*a*b
1 + 2*a*b -> 1 + 2*c
Note that, we have
2*a*b*c -> 2*a*b*c
1 + 2*a*b*c -> 1+2*a*b*c