These are chat archives for symengine/symengine

12th
Aug 2015
Shivam Vats
@shivamvats
Aug 12 2015 00:42
@certik #578 now passes all the tests. It doesn't yet work properly without piranha. Do we want to merge it now or after adding unordered_set functions?
Ralf Stephan
@rwst
Aug 12 2015 08:53
@certik @isuruf I confirm a speedup figure of 5x (repeated application of %timeit). What's remarkable when profiling is the complete absence in symengine runs of
  • ~1 million calls to __dynamic_castcoming from Pynac
  • 10 million calls to lookdict_stringcoming from Python dict lookups
  • 6 million calls to PyType_isSubtype this is Sage's elaborate coercion system
    There is no single function burning the CPU however. The dynamic casts eg use 40ms of the total 750ms.
Sumith Kulal
@Sumith1896
Aug 12 2015 10:47
We'll need to setup WITH_PIRANHA tests on travis, @shivamvats says.
I started it here #585
Sumith Kulal
@Sumith1896
Aug 12 2015 13:06
@bluescarni A query regarding encode and decode.
If I encode a vector of length n and try to decode it to a length larger than n, what happens?
Francesco Biscani
@bluescarni
Aug 12 2015 14:28
@Sumith1896 you will get the wrong result, possibly an exception depending on the circumstances
an encoded number has zero knowledge where it was encoded from
Sumith Kulal
@Sumith1896
Aug 12 2015 14:29
Cool, thanks
Francesco Biscani
@bluescarni
Aug 12 2015 14:29
it is like if you take a decimal number like 123456. You can see it as 123 and 456 packed together, or 12, 34 and 56 packed together
no way to discriminate
no problem
you will need to save the information somewhere about the size of the packed vector of ints
Sumith Kulal
@Sumith1896
Aug 12 2015 14:30
Yes, I'll save the number of variables
Hence, the size of the packed vector will be that
Francesco Biscani
@bluescarni
Aug 12 2015 14:31
yep that'll work
Sumith Kulal
@Sumith1896
Aug 12 2015 14:31
Also I wanted to ask
Francesco Biscani
@bluescarni
Aug 12 2015 14:31
piranha's polynomial objects store a vector of strings alongside with the hash_set of terms
representing the polynomial symbols
Sumith Kulal
@Sumith1896
Aug 12 2015 14:32
Is there hard dependency on Boost for the part I use?
Francesco Biscani
@bluescarni
Aug 12 2015 14:32
that is where the vector size information is coming from
which part?
encode/decode?
Sumith Kulal
@Sumith1896
Aug 12 2015 14:32
encode, decode, hash_set
Yes, even I am using a vector of SymEngine symbols for the variables
Francesco Biscani
@bluescarni
Aug 12 2015 14:33
You need to check the headers for a definitive answer... keep in mind that Piranha does not require any linking to boost currently, the headers will be just fine
I think there might be a hard dependency on boost::numeric_cast in many places
Sumith Kulal
@Sumith1896
Aug 12 2015 14:34
Yes, I'll look into it. I needed to setup Travis for Piranha dependence.
Francesco Biscani
@bluescarni
Aug 12 2015 14:34
right ok. For the testing a bunch of boost libraries needs to be linked in, but that's just for Piranha testing
not for normal usage of the library
Sumith Kulal
@Sumith1896
Aug 12 2015 14:35
Yes, I'll have a look
Francesco Biscani
@bluescarni
Aug 12 2015 14:36
btw did you have a chance to look at the links I sent you? just let me know if you need more info to get started, I will send you an email with additional details in the next few days
Sumith Kulal
@Sumith1896
Aug 12 2015 14:40
I've been crammed for the last few days. I'll have a look as soon as possible.
Francesco Biscani
@bluescarni
Aug 12 2015 14:40
There's no rush, I am swamped as well
Ondřej Čertík
@certik
Aug 12 2015 18:52
@rwst thanks for verifying it. Which particular benchmark shows 5x speedup? The bicycle one? Yes, I noticed significant slowdown in Sage due to the Python calls --- it's actually really hard to make sure there is no slowdown coming from the Python wrappers. This is the reason why I decided to just stick to C++ and actually make the Python wrappers optional. That way all this Python complexity goes off the table, you don't have to worry about it at all, we just need to make sure the C++ code itself is performing. That's why I benchmark it against ginac itself, which is also raw C++ and symengine seems to be a bit faster, depending on the benchmark. Then, we still want to be able to provide a Python class (e.g. some kind of special function implemented in Python) and use it in C++. We do that using FunctionWrapper which is just a C++ class where the user can provide a simple C callback to do things. And the Python wrappers then hook in a Python callback. Of course this will then be slow, but it's possible, and the C++ code itself doesn't care about Python.