- Join over
**1.5M+ people** - Join over
**100K+ communities** - Free
**without limits** - Create
**your own community**

- 12:07isuruf review_requested #1632
- 11:32YoshikawaMasashi starred symengine/symengine
- 09:00isuruf synchronize #1632
- 08:45isuruf synchronize #1632
- 06:43isuruf-bot commented #1632
- 06:43isuruf synchronize #1632
- 06:42isuruf-bot commented #1632
- 06:42isuruf edited #1632
- 06:41isuruf opened #1632
- 06:16isuruf commented #1631
- 06:16isuruf opened #1631
- 05:40isuruf opened #1630
- Jan 18 20:15
- Jan 17 16:17IanBoyanZhang starred symengine/symengine
- Jan 17 16:15cheginit starred symengine/symengine
- Jan 17 15:58inducer starred symengine/symengine
- Jan 14 14:28krasi0 starred symengine/symengine
- Jan 08 10:23vishalbelsare starred symengine/symengine
- Jan 05 17:33HaiDang2001VN starred symengine/symengine
- Dec 31 2019 23:23ThomasHickman starred symengine/symengine

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've been trying to convince @bocklund to go and present on his work

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
```

The new as_ctypes API enables some really nice solver accuracy improvements for us downstream

What's the difference between this and the cython one?

@darioizzo, it's at https://symengine.github.io/classSymEngine_1_1Add.html , but it has close to zero documentation