On Feb 6, 4:11 am, mabshoff <mabsh...@googlemail.com> wrote:
<SNIP>
My apologies for the double post.
> Yes, I took Singular 3-0-3 using slimgb and computed the DegRevLex as
> well as Lex basis of homogenized Karatsuba 7 for some F_p (p=31007
> maybe?) and the rationals.
>
> * For DegRevLex and F_p Singular was slightly faster and used about
> as much RAM
> * For Lex and F_p CoCoALibwas slightly faster and used about as much
> RAM
> * For DegRevLex and Q CoCoALib was faster and less RAM
> * For Lex and Q CoCoALib was significantly faster way less memory
> RAM, i.e. minutes and 50 MB vs. a computation killed after 1.5 days
> using 20GB+ RAM.
Opps, *Katsura 7* - MPIR and talking too much to Bill H. about FLINT
must have rotted by brain.
> I pointed this out to Michael Brickenstein at MEGA 2007 and he told me
> it was a known problem, but wasn't fixed due to other priorities. I
> hit this example since slimgb showed spectacular improvements over std-
> gb in Michael's Diplom thesis, but for some reason there were no
> numbers for Karatsuba 7 or higher with slimgb, so I ran some example.
> Other cases show similar tendencies and I have number to back them up,
> i.e Cyclic n, but I could not find an example with Lex over the
> rationals where the discrepancy was this bad.
Insert an "extremely" before "bad" to make it 100% clear. AFAIK the
issue remains unfixed in 3-0-4.
<SNIP>
> > Maybe someone (e.g. me) should spend some time making libSingular truely
> > accessible. Right now, it is a bit of black art (you have to know the tricks
> > or read the Sage sources).
>
> Yes, but things are getting better. Had CoCoALib been truly open in
> the early 2000s I think the situation would be different these days,
> but given the development model I don't see CoCoALib become a true
> community project. I could tell you stories about the effort it takes
> to get any non-significant piece of code into proper CoCoALib, but
> this mailing list is not the proper place for this :)
>
To illustrate my point: In 2006 I implemented the analog of the GBasis
framework found in CoCoA 4 (and something similar exists in Singular)
on top of CoCoALib, but it was much more refined IMHO. You would start
by reading in a Ideal and then go off computing the GBasis. You could
interrupt after any reduction had finished, could dump the current
elements of the GBasis found so far, could dump only the "interesting"
elements found so far (very useful when attempting to restart a
computation with an augmented ideal), could run reductions until you
hit the first or n-th non-zero reduction, do a certain number of
reductions before automatically dropping out, do reductions until you
reached a certain degree and on and on. It seemed not only to me that
this code could have come in handy when doing actual computations of
hard to attack problems since at that point I seemed to be the only
one computing hard problems with CoCoALib and not being content with
just waiting for it to finish before it ran out of memory. I had
plenty of plans to do reduction in parallel, add the ability to play
with the pair queue for example. That code bitrotted and I never even
submitted it for inclusion due to my previous experience of getting
patches into CoCoALib while *working for* the CoCoA team. Let's just
say I work for William on Sage for multiple reasons since Sage is
99.9% the way when I would run an OS math project as BDFL :)
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
-~----------~----~----~----~------~----~------~--~---
