GSoC Progress - Week 5Programming · GSoC · SymPy
Hello, this post contains the fourth report of my GSoC progress. We hit
the highlight of this week.
We were able to reach
Piranha's speed. At an average
14-ish ms to the benchmark, we are happy enough (still can be improved) to start wrapping this low-level implementation to a
Polynomial class. Last week I had reported speed
23ms and this week we are better.
We had missed out a compiler flag,
DNDEBUG to indicate
Release mode of
Piranha leading to slow-down, #482.
Adding this compiler flag means we should not be using
assert statement, which
SymEngine does in
SYMENGINE_ASSERT and test files too. These had to be sorted out if
Piranha were to be a hard dependency of
SymEngine's polynomial module.
Hence, the issue of moving the tests suite from
asserts to a well-developed test framework came up again, #282. We explored a couple, but
Catch still seemed to be the best option.
Catch was implemented, which is a benefit to
SymEngine in the long run too.
As for the
SYMENGINE_ASSERT, we decided to change our macro to raise an exception or just abort the program.
Catch is a very good tool. We thank Phil Nash and all the contributors for making it.
Next up, wrapping into
We need some functionality to convert a
Basic) into one of
hashsetrepresentations directly. Now I convert
polyand then to
hashsetas just getting the speed right was the issue.
Domains of coefficients need to be thought of.
Sagewill be need to looked into and their APIs need to be studied. We need
EX, the work for
EXhas been done by Francesco Biscani, this will be patched for the latest master and commited in his name. There could also be an automatic mode, which figures out the fastest representation for the given expression, at the price of a little slower conversion, as it needs to traverse the expression to figure out what representation fits.
packedconversion when exponents don't fit. Also
encodesupports signed ints which is a boon to us, as we don't have to worry about negative exponents. For
rationalexponents we use tuple.
I still haven't figured out the reason for slow down of
expand2b in my
packint branch. I have been suggested to use
git bisect. Will do next week.
Result of 10 execution:
evaluate_sparsity() gave the following result for the
Piranha has the following results
A more detailed report of benchmarks and comparisons can be found here
A minor PR where MPFR was added as a Piranha dependency, 472 was merged.
Another PR in which the tests where moved to
Catch is good to play with and merge, minor build nits remaining, 484.
Targets for Week 5
- Figure out the reason for slow down in benchmarks, fix that.
- Change the
SYMENGINE_ASSERTmacro to raise an exception.
- Add the
DNDEBUGflag for with
Piranhabuilds, as now
assert, close issue #482.
@bluescarni's work of
- Wrap the lower-level into
Polynomialfor signed integer exponents in
ZZdomain with functionality atleast that of
That's all this week.