Hi, Thanks for taking the time to make up this example. I think it is good to put it in the documentation. Yes you can break factorcaching (with auto_reduce=False) the way you do it. ***But*** let me point out that by rewriting your example only slightly it becomes *much* faster than the current implementation
sage: from sage.rings.fraction_field_cache import FractionField_cache sage: from sage.rings.fraction_field import FractionField_generic sage: R.<x,y,z>=QQ[] sage: T = [ZZ.random_element()*x + ZZ.random_element()*y + ZZ.random_element()*z for _ in range(10)]; sage: Q=FractionField_cache(R,auto_reduce=False) sage: TT=[Q(s,1) for s in T] sage: SS = [prod(random_sublist(TT, .2)) for _ in range(50)] sage: time f = sum([~s for s in SS]) CPU times: user 0.02 s, sys: 0.00 s, total: 0.02 s #look here Wall time: 0.06 sage: len(str(f)) 5400 sage: time f.reduce() CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.01 sage: time f(2,3,4) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.00 8215193/2109360 sage: Q=FractionField_generic(R) sage: S=[numerator(s) for s in SS] sage: time f=sum([~Q(s) for s in S]) CPU times: user 0.35 s, sys: 0.00 s, total: 0.35 s # versus here Wall time: 0.74 sage: len(str(f)) 5402 sage: time f.reduce() CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.02 sage: time f(2,3,4) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 0.01 8215193/2109360 So maybe in some (I claim non-typical) cases factorcaching requires a bit understanding from the user but the payoff is enormous. Anyway as I said factor caching should be optional. And furthermore there is an auto_reduce parameter, which when true emulates the current behaviour. Michel PS. Perhaps it is possible to make your example work out of the box by somehow using the real gcd for elements which have no cached factors, or to apply the real gcd to the factors, caching the result etc... But I would prefer to take the wrinkles out of the current implementation first. On May 29, 2:04 am, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > I don't think you want to them as doctests, they take dozens of > minutes to run! (That is, for the cached rings which take 10000 times > longer to compute.) Ideally this issue can be fixed, but I'm not sure > how... > > - Robert > > On May 28, 2007, at 4:35 PM, Nick Alexander wrote: > > > Robert Bradshaw <[EMAIL PROTECTED]> writes: > > >> I'm kind of late jumping into this thread, but I have some concerns. > >> Unless the factorization is known completely (or gcd's are taken on > >> the unknown part), I still think this can lead to combinatorial > >> explosion fairly quickly. For example, > > > Michel and I are working through the refereeing process. I will try > > to take your examples into account, and have them as doctests. Please > > ping me again if these troubles remain after the patch is applied. > > > Nick --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
