On Feb 6, 2:28 am, parisse <bernard.pari...@ujf-grenoble.fr> wrote:
<SNIP>
> > So, you are using Cocoa or cocoalib?
>
> cocoalib
>
> > Being an expert for the groebner
> > bases functionality, I can say,
> > that Singular's biggest strength in this area, is supporting many,
> > many implementations
> > of different algorithms and many monomial orderings
> > (you need flexibility in this area).
>
> > So, if you are interested, we can discuss this (probably this threat
> > is not very suited).
>
> yes, maybe a thread in gb computation with singular would be more.
Well, having used both system extensively and even more importantly
having spend a lot of time with the code I am not convinced
libSingular has a clear cut advantage over CoCoALib. A couple data
points:
* libSingular is significant more effort to build and the interface
isn't exactly clean
* CoCoALib is beautifully designed and tight., modern C++ code
without going nuts with templates. I have build it using g++, MSVC and
the Sun compiler.
* license: CoCoALib is GPL V3 while Singular is GPL V2 or V3.
* CoCoALib is exception save code, no such thing in Singular
* CoCoALib did not leak memory at all while I was around and I
believe this is still the case. Between Martin and I we have found and
fixed about half a dozen memory leaks in Singular over the last year
and a half.
* CoCoALib is significantly smaller than libSingular, i.e. oMalloc by
itself is half as large as all of CoCoALib
* CoCoALib's ideal and module operations are faster than Singulars
* GBasis computations for DegRevLex and F_p are about comparable with
a slight advantage for slimgb, but switching to the rational and Lex
makes CoCoALib look *much* better
* libSingular's memory management is better, i.e. when doing large
non-GB computations using CoCoALib the memory manager eats more and
more memory, but does not give it back to the system once the
computation is over. The issue is side stepped during GB computations
because each GB computation has its own memory manager that gets
destroyed once the GB computation is over
* regardless which monomial ordering you choose in CoCoALib there is
no speed penalty while Singular is optimized for DegRevLex.
* CoCoALib's non-commutative side is way underdeveloped compared to
Singular, i.e. even for Weyl algebras (the only non-commutative ring
implemented in CoCoALib) the code by Victor Levandovsky in Singular
blows it away.
* my main issue with Singular: arithmetic and GBasis computations for
F_p are limited to wordsize modulus. This is quite annoying and an
issue with Sage since we fall back on some generic implementation.
* Singular can do Gbases over rings, CoCoALib still cannot do it
despite me telling the CoCoALib team since *2006* that this would be
the quickest way to get them into Sage. Now that Singular can do it
that advantage has gone.
* CoCoALib is significantly more open, i.e. development snapshots are
regularly posted. When I worked for the ApCoCoALib group I actually
posted hg repos of the complete CoCoALib history converted from CVS.
They no longer do that, I still do in theory have access to CoCoA[Lib]
s CVS [probably not any more after his email :)], but I am not
touching that code for obvious reasons. The CVS of Sinuglar not
available to the public, in the last 14 months or so there has been
one snapshot of 3.1 available to the public.
I could rave on, but you get the idea. Given the licensing situation
and the above facts using [lib]Singular is the right call even though
the use of libSingular on Solaris, OSX 64 bit, Cygwin and so on has be
a constant source of pain for me. But it looks like we have gotten
over the hump there, so what is in the past is in the past. Now there
is the obvious large problem with libSingular on Fedora 9 and 10, but
we will get that fixed, too.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
