Currently I'm about to support a student's projects for collecting and categorizing examples arising from technical applications of computer algebra. Our benchmark examples from formal verification of digital systems and cryptoanalysis mark a (proper) subset of these use cases. But from my experience such projects prosper from a wider example base.
Are there readers around which use computer algebra techniques in industrial, biological, medical, or chemical applications? Would you like to direct our attention to some examples from your area? Of course, one of our goals is proper citing of the contributed stuff as well as mentioning the contributor itself.
If you are interested to drop us a message at industrial@3r4u.de.
My best,
Alexander
Monday, March 5, 2012
Tuesday, January 10, 2012
C++-ification for upcoming release
Developing PolyBoRi 0.8.1 started right after finishing double releases 0.8 and 0.7.2. Albeit, the next release will contain some new features, the main idea is to stabilize current functionality and to make it more reliable, extendable and sane.
The idea is to have proper C++ code of the specialized Gröbner routines. Therefore, we will learn from the experiences of the integration of PolyBoRi 0.8 in upcoming Sage and Singular.
The idea is to have proper C++ code of the specialized Gröbner routines. Therefore, we will learn from the experiences of the integration of PolyBoRi 0.8 in upcoming Sage and Singular.
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:
In the next weeks, small tutorials and will follow at this place and at Singular Faces.
My best,
Alexander
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
In the next weeks, small tutorials and will follow at this place and at Singular Faces.
My best,
Alexander
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:
One click later you have installed PolyBoRi and all its dependencies without any hassle.
That's software installation at its best!
My Best,
Alexander
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:
That's software installation at its best!
My Best,
Alexander
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,
Alexander
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,
Alexander
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 ->
BoolePolynomials::firstReducibleBy
* 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,
Alexander
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 ->
BoolePolynomials::firstReducibleBy
* 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,
Alexander
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,
Alexander
Finally, I fixed the last few issues tonight. So PolyBoRi 0.7 hits the road!
My best,
Alexander
Subscribe to:
Posts (Atom)