Tag Line

PolyBoRi was created by man. There are two developers. And they have a plan.“

Thursday, September 8, 2011

Double release PolyBoRi 0.8.0 and 0.7.2

We are proud to announce that PolyBoRi 0.8 is available at Sourceforge. The development of our 0.8 branch was driven by two major goals: stability and compatibility. Both of them are important to support ongoing attempts of full-fleshed computer algebra systems - for instance by Singular - to integrate PolyBoRi.

First of all, PolyBoRi 0.8 corrects some critical design issues. The most important change was, that we said good bye to the active ring. While each polynomial object already had a reference to its ring, default constructors of those objects used the active ring for initialization. This frequently had lead to inconsistencies which we can avoid now. For you, this means that polynomial (and likewise) objects are not default-constructible any more. Since they need a valid ring reference on construction you have to provide the latter as constructor argument.

Second we improved the scons-based build system. Among classical Linux, we officially support platforms like Cygwin, Apple's Darwin, Gentoo and  Gentoo-Prefix (even on Darwin). PolyBoRi is also prepared for generating rpm- and deb-based packages.

Finally, the compatibilty with recent release of upstream libraries like libm4ri was re-established.

We also wanted to make our improved build system and various compatibility and bug fixes available to ongoing projects, that are based on PolyBoRi 0.7.x. Hence, we backported those improvements to the 0.7 branch. The result was PolyBoRi 0.7.2 making today a double release day.

The full changelog of release 0.8.0 reads as follows:
  • improved standard-conformity, multiprocessing safety, and usability
  • renamed subdirectory polybori to libpolybori
  • new directory structure in libpolybori/include and groebner/include
  • libgroebner renamed libpolybori_groebner 
  • using only part of CUDD (linked into libpolybori)
  • officially introducing VariableBlock
  • removed all global settings and BooleEnv itself
  • added factories and RingContext to replace active/global ring
  • improved multiprocessing and pickling
  • added inSingleBlock/in_single_block to polynomials
  • for avoiding name clashes Cudd's headers install into include/polybori/cudd 
  • Introducing WeakRingPtr for managing weak references to rings on C++ level
  • python level: deprecated Ring changing routines change_ordering, set_variable_names, append_block removed, use extended arguments of Ring.__init__() and Ring.clone().
  • ipython 0.11 compatibility established (hint from the Fedora team. Thanks!)
  • libM4RI compatibility re-established (hint from Martin Albrecht. Thanks!)
  • distributed targed uses world-readable permissions
  • cluster.py: very experimental Python module for finding an overdetermined subset of equations
Binary packages are available for recent OpenSuSE, Mandriva and Fedora as well as Debian and Ubuntu distributions. Just point your package manager here.  In addition the corresponding communities bundled preliminary spkgs and Gentoo ebuild scripts.

In the next weeks, small tutorials and will follow at this place and at Singular Faces.

My best,

Wednesday, April 27, 2011

PolyBoRi 0.7.1 is just one click away

PolyBoRi 0.7-1 is out now! This release contains a few bug fixes and improved packages. The spec-file for rpm-generation is much more standard conforming now and platform independent. Therefore, automated build services can now generate distribution-specific binary rpm packages.  You may try out one of the repositories here for SuSE, Fedora and Mandriva rpms.

For instance, adding the repo to SuSE's YAST is as easy as follows:

 Then you can search for PolyBoRi in your Software Contrel Panel:

One click later you have installed PolyBoRi and all its dependencies without any hassle.

That's software installation at its best!

My Best,

Saturday, February 26, 2011

PolyBoRi 0.7

And now, here it is: Release 0.7 of PolyBoRi!

Of course, we had to change a few things since the first release candidate I mentioned last time. For instance, some paragraphs of the README file and the tutorial had to be clarified. Also, the example code listings of the latter could now be used instantly, because the multiplication character * was replaced by a nice-looking (but unusable) asterisk symbol.

But there was one real bug. Due to a mistake during refactoring the member function .nNodes() (.n_nodes() from python) for counting the decision-diagram nodes of our  internal data structures had miscounted by two. It did not influence the algorithms, so the original (black box-style) tests were not able to detect this mistake. Again it was a unit test (this time from the Sage interface), pointing out this problem.

The conclusion arising is as follows: extensive testing is mandatory. Best tests came from people with no or little knowledge about our internals. Back in high-school, we had called this Freddy testing, named after a classmate, who was fond in finding corners of our implementations. He was very creative in pushing obviously wrong buttons. Successful software development needs several Freddys.

My best,

Monday, February 14, 2011

First release candidate of PolyBoRi 0.7

Wow, that was hard! But finally we manged to complete our goals for PolyBoRi 0.7, whose first release candidate can be found at Sourceforge.

Indeed, the ChangeLog is short:
Release Name: 0.7.0:
* Polynomials, monomials, variables, and BooleSets now own a reference to

  a fully-functionally BoolePolyRing (including ordering)
* Orderings can work independently from ring
* Simplified interface: remove *Assign() variants from diagrams
* Added polybori.nf.simple_nf
* Simplification of declare_ring in ipbori
* Rename BoolePolynomials::reducibleBy ->

* Unittests for libpolybori are available, covering 98% of libpolybori
* Added experimental PolyGUI

But what does this actually mean? We completely rewrote the Boolean ring management. Each polynomial now owns a reference to a full ring (including the ordering). This erases several implicit assumptions - like having a global ordering - which were not transparent to the user. For supporting this, we added atomic unit tests for libpolybori (98% coverage, the remaining 2% correspond to unhitable C++-artifacts). A corollary of the latter is, that bugs at corner cases of the implementation had been found and fixed.

Another nice gimmick: there also a small QT-based GUI for interactive use of the groebner_basis command. People can play around without further knowledge of our text-based frontends.

For the full release, PolyBoRi 0.7 has to be tested together with Singular and Sage. For the latter the interface has to be updated for sure (the current one works around some of the issues mentioned above, also we broke the one or another internals Sage might use). For Singular the things got much easier recently: now Singular's owns a Python interface, which can be used to access PolyBoRi as I explained here.

After that, I will start collecting todos for 0.8!

My best,

Saturday, January 29, 2011

How important unit tests are

Last year we started to add pure unit tests (based on boost::test) to PolyBoRi. Albeit PolyBoRi already owns an extensive test suite (with hundreds of examples from computational algebra, cryptanalysis and electro engineering), we found several faulty routines. Most of the newly discovered problems were triggered by data, which lies slightly outside the specifications. Here, specification is not a formal term: it's merely the sum of all implicit assumptions arising from our applications. Over the last months the unit tests helped us to make those more explicit which improved our source a lot.

Finally, I fixed the last few issues tonight. So PolyBoRi 0.7 hits the road!

My best,