Hi John! Thanks. This was one of the systems behaving ugly with incremental strategies. Considering this, your result is excellent. Did you check for the result being [1]? I was referring to "termination in reasonable time". This makes it a little bit easier to "believe in F5". Would it be possible to modify the algorithm, in such a way, that it doesn't work incrementally (maybe affecting the theoretical "no reduction to zero"-property)? As you might have seen in your protocol, the most computation should have been done in the penultimate step.
Michael On 23 Okt., 18:28, john_perry_usm <[EMAIL PROTECTED]> wrote: > Michael, > > I can answer one of your challenges: The non-homogenized system > terminated correctly in about 139 minutes on my home computer, a > 1.7GHz P4 w/512MB. I used a sugar variant, having modified Martin's > basic F5 sometime last week. No other changes were made to F5. > > I realize this isn't worth a pizza, but I wasn't gunning for one > either. If you want, I'll try the homogenized system on the basic F5 > at work. > > regards > john perry > > On Oct 23, 4:14 am, Michael Brickenstein <[EMAIL PROTECTED]> wrote: > > > > > Hi Simon! > > > Am 23.10.2008 um 10:53 schrieb Simon King: > > > > Dear Michael, > > > > On Oct 23, 7:47 am, Michael Brickenstein <[EMAIL PROTECTED]> wrote: > > >> Nevertheless. I just uploaded some nice example to the wiki, for > > >> testing your F5 implementation. > > >> I was originally provided by Gema Diaz. > > >> It is inhomogeneous and the GB is [1]. > > > >>http://wiki.sagemath.org/days10/CodingSprint? > > >> action=AttachFile&do=get... > > > >> Slimgb takes about 0.2s (2.2 Ghz Thunderbird). > > > > The test is unfair, in the sense that our F5 implementations rely on > > > homogeneous input (hence, this inhomogeneous example would be > > > homogenized). > > > You can argue about fairness. But slimgb doesn't require systems to be > > homogenized. > > > > So, making the test fair, I tested slimgb on the homogenisation of > > > Gema's example. Slimgb took 4:05 minutes on my machine. > > > > On the other hand, John Perry told me that homogenisation might be > > > avoidable in F5. > > > > Anyway. Clearly I do not expect to beat slimgb or std or anything else > > > with a toy implementation. > > > Nevertheless, it would be really great, if you get an result at all > > (say in a day): really, really great. > > I doubt, that the original F5 implementation can beat the 0.2s of > > slimgb (maybe not finish at all with incremental strategy). > > > I gave you the example not for competition, but for the reason, that > > you should have some other example than Faugere's standard examples. > > In general, I think, that F5 is an (theoretically) interesting algorithm > > On the other hand, I would like to point out, that there exist much > > more effects in GB computations than useless pairs. > > This example should show quite well the effects of the incremental > > strategy (this is the context in which we got the example). > > > As you have a toy implementation, you can add a good constant factor. > > Nevertheless, you can use this toy implementation > > to observe, on which kind of systems F5 might be good or not. Of > > course, GB calculations are quite sensitive to heuristics, > > so final conclusions will be difficult. > > > Michael > > > > Cheers > > > Simon --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
