MuPAD-Combinat Frequently Asked Questions
- Why so much fuss about open-source?
Because we think that this is the right development model to use
for scientific and especially research software; among others because
it fosters collaboration and sharing of code.
Here are some references about open-source, development models, and best
practices that we try to follow:
- The Open Source Initiative:
http://www.opensource.org/
- The Free Software Fundation:
http://www.fsf.org/
- Eric Raymond's classical essay on open source development principles:
http://www.catb.org/~~esr/writings/cathedral-bazaar/
- Some best practices for efficient software development:
http://www.extremeprogramming.org/
- Why spending time on testing:
http://junit.sourceforge.net/doc/testinfected/testing.htm
- Does MuPAD-Combinat work on system xxx ?
Please check the requirements section at the beginning of
the README file
- Why does it help to be integrated in the MuPAD distribution ?
* This makes the life simpler for users, since they don't have to download and install yet another package.
* This ensures a wider distribution.
* This forces both parties to tightly integrate the package into MuPAD, for a smooth cooperation with other parts of MuPAD.
* This leads the MuPAD group to review the code and the documentation of the package, and to give a hand for choosing the right way of doing things.
* This reduces the risks of incompatibilities with future versions of MuPAD: the MuPAD group has to think twice before introducing backward incompatible changes in the language, since they have to do themselves the work of fixing correspondingly the package.
- Why MuPAD?
You can find more about this question in the design document
http://mupad-combinat.sourceforge.net/doc/html/index/design.html
# Why not GAP
http://www-history.mcs.st-and.ac.uk/~~gap/?
GAP (Groups, Algorithms and Programming) is great. GAP is open source. GAP is doing extremely well for the group theory community what we feel is needed in combinatorics: to provide a common platform, and gather the work of manies. Moreover, there are specialized tools in GAP that we do need.
So, why not GAP ?
To be honest, we have been hesitating for a long time. The main point is that we also have a strong need for general computer algebra tools such as linear algebra, multivariate polynomials and Gröbner basis. Our present bet is that MuPAD will offer a better integration for those general tools, and that our need for group theory tools can be fulfilled by writing a suitable interface between GAP and MuPAD. GAP could then be used as a computation server very much as the Gröbner basis package GB can be.
In any cases, we would like to collaborate closely with the GAP group.
# Why not Maple?
That was a hard decision to take, as this computer algebra system is the most widespread in the algebraic combinatorics community. However, we needed a *real* programming language, as well as reasonnable technical support from the Maple group (including not introducing backward incompatible changes with every new version).
# Why not Mathematica, Axiom, Aldor, Maxima?
Difficult question too. All of them have some nice aspects, especially Aldor. Basically, we had to choose a platform at some point, and technically MuPAD seemed to be the best choice for us. So far, we don't regret our choice, and we cross our fingers.
- Is MuPAD open-source?
No, and we are really not happy about this. But still, they are much more open than others ...
- Looking for some MuPAD documentation ?
Have a look to the GeneralDocumentation page.
You can also have a look to the UserTestimonials in order to know about different uses of the MuPAD-Combinat library on research in combinatorics.
- Trouble Shooting
Some problems of compatibility between different versions of the libgcc can occurs during loading of dynamic modules.
This correspond to the following error message (here example with the module MAPITL):
MDM_sys_load: /usr/local/MuPAD/linux/lib/libgcc_s.so.1: version `GCC_3.3" not found
(required by /usr/lib/libstdc++.so.5)
Error: Bad module, can"t load "MAPITL_test" loadmod?
In order to solve this problem, edit the running script of mupad ( MuPAD/share/bin/mupad ) and replace the following lines
if test -n "$LD_LIBRARY_PATH" ; then
LD_LIBRARY_PATH=${MuPAD_ROOT_PATH}/${SYSINFO}/lib:${LD_LIBRARY_PATH}
else
LD_LIBRARY_PATH=${MuPAD_ROOT_PATH}/${SYSINFO}/lib
fi
export LD_LIBRARY_PATH
by
if test -n "$LD_LIBRARY_PATH" ; then
LD_LIBRARY_PATH=/lib:${MuPAD_ROOT_PATH}/${SYSINFO}/lib:${LD_LIBRARY_PATH}
else
LD_LIBRARY_PATH=/lib:${MuPAD_ROOT_PATH}/${SYSINFO}/lib
fi
export LD_LIBRARY_PATH
The last step is the recompilation of the MuPAD-Combinat package (in fact only dynamical modules recompilation is needed)