Hi, I'm posting the irc log for #sage-devel here right now. I'm not going to do this regularly. The point is just to give people a sense of what goes on there on a daily basis in the hopes of encouraging more people to login to irc. Typically there are about 20-30 people logged in at any given time to #sage-devel on irc.freenode.net. I think Sage development would improve if this number were a bit higher, especially given the number of active Sage developers.
It's also interesting to see how distributed the people are on IRC. For example, today the people involved in the discussion were in Seattle (me), Oxford (SPancratz), Philippines (tim dumol), Korea (ddrake), Australia (mvngu), Thailand (mhansen), and Idaho (jason grout). ... 04:50 < williamstein> excellent progress. 04:50 < williamstein> and the next step will be more *fun*. 04:52 -!- gpannwitz [i=d5dd5...@gateway/web/freenode/x-kelkxedpcjvrhigl] has quit ["Page closed"] 04:52 < williamstein> ok, i pushed my changes... 05:01 -!- williamstein is now known as williamstein-zzz 05:12 -!- timdumol-dinner is now known as timdumol 05:22 -!- buntfalke [n=nob...@unaffiliated/buntfalke] has joined #sage-devel 06:20 -!- ncohen [n=nco...@rebelote.inria.fr] has quit ["Lost terminal"] 06:33 -!- mhansen [n=u...@61.19.67.104] has joined #sage-devel 06:49 -!- SPancratz [n=su...@129.67.184.43] has joined #sage-devel 06:49 < SPancratz> Hello 06:49 < timdumol> SPancratz: hey. 06:49 < SPancratz> I just noticed something rather disturbing with the general matrix solving code 06:50 < SPancratz> I thought I should share this, if someone is interested. 06:51 < SPancratz> Code of mine that takes about 65s to execute is heavily dominated by solving two matrix equations (matrix * vector = vector) where the coefficient ring is QQ[] 06:52 < SPancratz> Of that time, 44s (of cumtime from using %prun)are spent in the method Hom in homset.py, 17s in the method 'category' of the Ring object, and 11s in _repr_ in polynomial_ring.py 06:53 < SPancratz> Only a very small time is actually spent crunching away at the matrices 06:54 < timdumol> SPancratz: I am unfamiliar with that code, unfortunately. 06:56 < SPancratz> I think as far as my own code is concerned, I will just copy the relevant SAGE code and take away everything that _might_ be needed in general but can be ignored if one knows which ring all elements lie in and knows that this won't change. 06:57 < SPancratz> I just thought other people might perhaps have come across this 07:01 < mhansen> SPancratz: Do you have a test case that I could look at? 07:02 -!- jason [n=ja...@97-125-136-197.desm.qwest.net] has joined #sage-devel 07:02 -!- jason is now known as Guest81620 07:02 -!- Guest81620 is now known as jason- 07:08 < SPancratz> mhansen: I can quickly make on up 07:09 < mhansen> Cool. I'll be back in about 15 minutes and get hopefully get things sped up for you. 07:30 < SPancratz> mhansen: I've uploaded an example to http://sage.pastebin.com/m3203c2a7 07:35 < SPancratz> Of course, I see that the matrix and the vector are ridiculously sparse and I should take advantage of that. However, most of the standard numerical methods don't apply (they often assume the matrix is positive definite or symmetric, and in this case I am not even sure what the first notion could mean, and the matrix isn't symmetric). I am trying to find useful references for solving sparse linear equations, but I've only started that an hour ago and 07:37 < SPancratz> mhansen: I need to go to College for a few minutes, but I should be back in about 15mins. 08:03 < SPancratz> mhansen: Just to let you know, I am back. 08:03 < mhansen> Cool. I just got back as well. 08:18 < SPancratz> mhansen: Did you get my previous messages? 08:20 < mhansen> Yeah. I'm just looking at it now. 08:22 < SPancratz> Thank you 08:37 < mhansen> SPancratz: Are you using your FLINT Q(x) code? 08:39 < SPancratz> Yes 08:41 < mhansen> Let me install the latest version of that so that we're working off the same thing :-) 08:59 < mhansen> SPancratz: I get an error when running your code. But, if I switch to Frac(ZZ['t']) then it finishes in about 2s. 09:00 < SPancratz> Which error do you get? 09:01 < SPancratz> I think I fixed one small thing 09:01 < mhansen> TypeError: Rescaling row by Fraction Field of Univariate Polynomial Ring in t over Rational Field element cannot be done over Fraction Field of Univariate Polynomial Ring in t over Rational Field, use change_ring or with_rescaled_row instead. 09:01 < mhansen> 09:01 < mhansen> Which is a silly bug. 09:01 < SPancratz> Can I just let you know the fix? 09:01 < mhansen> Sure 09:02 < SPancratz> It's in the method reduce in fraction_field_element.pyx 09:03 < SPancratz> (The second occurrence, of the UnivariateRationalRational... type) 09:04 < SPancratz> The method should add another cdef Rational y, and then on about line 1054, rather than having x = ~x (which causes the bug for integer x) it should to y = ~ Rational(x), and the next two lines should be num = y * num and den = y * den 09:07 < mhansen> So, if you need this for research right away, you can work over Frac(ZZ['t']) which is the same ring. 09:08 < mhansen> Hmm... I'm getting "Error: unable to alloc/realloc memory" 09:08 < mhansen> 09:08 < SPancratz> Well, the idea behind it is that I am trying to make code computing connection matrices faster 09:09 < SPancratz> (Using basic linear algebra rather than the usual Groebner basis approach) 09:11 < SPancratz> It might be doomed to failure, but for some example I am only out by a factor of 20, which I think I can comfortably achieve by re-implementing Q(t), adding methods _addmul_ and _submul_ (similary to the ones in GMP, for computing x = r + s*t), and using the sparsity of the matrices 09:12 -!- mjturk [n=mjt...@128.54.7.241] has joined #sage-devel 09:12 < mhansen> Why do you use Q(t) instead of Z(t)? 09:13 < SPancratz> It would probably be better to use Z(t). The short answer is that I didn't think about that part. 09:14 < mhansen> That's what I did before with ZZ['t'] was much faster than QQ['t'] :-) 09:15 < SPancratz> But on trying that right now, I noticed that something else in my code doesn't work. For f definitely being equal to a monomial in S = Z(t)[X,Y,Z], I get an error from multi_polynomial_element.py: 09:15 < SPancratz> 563 if not (isinstance(mon, MPolynomial) and mon.parent() is self.parent() and mon.is_monomial()): 09:15 < SPancratz> --> 564 raise TypeError, "mon must be a monomial in the parent of self." 09:15 < SPancratz> Where my f is mon in the relevant SAGE code 09:15 < SPancratz> I am guessing the "isinstance(mon, MPolynomial)" might fail 09:16 < SPancratz> I think my f is an MPolynomial_polydict 09:17 < SPancratz> I think that inherits from MPolynomial, but the isinstance check fails, of course. 09:18 -!- opp [n=huxp...@60.168.88.177] has quit [Read error: 60 (Operation timed out)] 09:19 < mhansen> I think the isinstance should work. 09:21 < SPancratz> I'll run the code again, printing the results of the three checks before calling the method 09:26 < SPancratz> You were right 09:27 < SPancratz> I am checking Q.monomial_ 09:28 < SPancratz> I am using Q.monomial_coefficient(f) for lots of f. For various Q and f. For most Q, the parent is "Multivariate Polynomial Ring in X, Y, Z over Fraction Field of Univariate Polynomial Ring in t over Integer Ring", but for no apparent reason for one of them it turns out as "... Rational Field" 09:31 < SPancratz> I am guessing somewhere in the code must be an exact division which triggers the ring to change. Well, I guess I need to go and fix that now. 09:31 < SPancratz> Thank you for your help. By the way, is there anything I ought to do regarding QQ[] at the moment, or can I leave it as is for the time being and look at it again after the next stable release of SAGE? 09:32 < mhansen> With the latest patch at #4000 on trac, I can that memory error. 09:32 < mhansen> err, I get that 09:33 < SPancratz> Which memory error? 09:34 < mhansen> Error: unable to alloc/realloc memory 09:34 < mhansen> 09:34 < mhansen> Here's a traceback: http://sage.pastebin.com/m1ce587b9 09:36 < SPancratz> What do you have to do to get that? 09:39 < mhansen> I just ran the session that you posted with the latest patch from #4000 (and FLINT 1.5.0). 09:42 -!- prometheus1809 [n=prome...@202.3.77.11] has joined #sage-devel 09:43 < SPancratz> From the traceback, the call comes from "__fmpq_poly_den_fit_limbs", and that in turn from floor division. The former is only 7 lines long and almost surely without mistakes if I dare to say that at all. The only thing I can think of is that perhaps somewhere in floor div instead of passing an unsigned long, somewhere there is mixed operation with a signed integer and that could perhaps cause the unsigned long limbs to be ridiculously large, and that 09:43 < SPancratz> (I am looking at that now. Other than that, I would have now idea) 09:47 < SPancratz> In floor div, I can see any bad handling of unsigned longs. fmpz_size should return an unsigned long, and so should the pseudo division code. And then I am only adding and multiplying those. 09:47 < mhansen> Hmm... 09:50 < SPancratz> Could you perhaps let me know to which line in polynomial_rational_flint.pyx the line 7319 in your compiled version *.cpp corresponds? 09:51 < mhansen> /* "/opt/sage/devel/sage-main/sage/rings/polynomial/../../libs/flint/fmpq_poly_linkage.pxi":715 09:51 < mhansen> * 09:51 < mhansen> * if __fmpq_poly_den_is_one(a): 09:51 < mhansen> * __fmpq_poly_den_fit_limbs(q, limbs) # <<<<<<<<<<<<<< 09:51 < mhansen> * fmpz_pow_ui(q.den, lead, m) 09:51 < mhansen> * else: 09:51 < mhansen> */ 09:51 < mhansen> __pyx_f_4sage_5rings_10polynomial_25polynomial_rational_flint___fmpq_poly_den_fit_limbs(__pyx_v_q, __pyx_v_limbs); 09:51 < mhansen> 09:57 -!- SPancratz [n=su...@129.67.184.43] has left #sage-devel [] 09:57 -!- SPancratz [n=su...@129.67.184.43] has joined #sage-devel 09:57 < SPancratz> mhansen: I can't see anything there that should be going wrong 10:03 < SPancratz> mhansen: I just found that strange behaviour that breaks my other code right now. 10:03 < SPancratz> Say F = Frac(ZZ['t']), Q = (t-3)/(t-1), then Q has parent F. But setting R = (3/7) * Q, R has parent Frac(QQ['t']). 10:04 < SPancratz> Would you know how one can change that? 10:08 < mhansen> Yeah 10:08 -!- zirpu [n=zi...@nefud.org] has left #sage-devel [] 10:10 < SPancratz> On which level is that happening? 10:10 < SPancratz> A quick fix on my end would be to always coerce the result back into the ring I want, but that seems like creating to much overhead. (Not on this occasion, but in principle) 10:13 < mhansen> It's with the coercion system. 10:14 < SPancratz> Should I file a bug report for that? (I won't be able to do anything about it at the moment because I don't know the coercion system well enough.) 10:18 < mhansen> Let me try something. 10:22 < mhansen> sage: F = Frac(ZZ['t']) 10:22 < mhansen> sage: F.has_coerce_map_from(QQ) 10:22 < mhansen> True 10:22 < mhansen> sage: f = F.random_element() 10:22 -!- williamstein-zzz [n=willi...@66.235.51.227] has quit [] 10:22 < mhansen> sage: f 10:22 < mhansen> (t^2 + 2*t + 1)/(-t^2 + 2*t - 1) 10:22 < mhansen> sage: g = 1/2 * f; g 10:22 < mhansen> (t^2 + 2*t + 1)/(-2*t^2 + 4*t - 2) 10:22 < mhansen> sage: g.parent() 10:22 < mhansen> Fraction Field of Univariate Polynomial Ring in t over Integer Ring 10:22 < mhansen> 10:23 < mhansen> Here's one way to do it http://sage.pastebin.com/m56acd5e7 10:23 < mhansen> Not the most exact, but... 10:48 < SPancratz> mhansen: Thank you very much for the help 10:49 < mhansen> No problem. 10:49 < SPancratz> I have to leave in a few minutes; I've been in the office for long enough today I think. Perhaps I'll be online again later tonight at home. Bye! 10:51 -!- SPancratz [n=su...@129.67.184.43] has left #sage-devel [] 10:54 -!- pearu [n=pe...@82.131.23.30.cable.starman.ee] has joined #sage-devel 10:57 -!- williamstein [n=willi...@d-69-91-159-214.dhcp4.washington.edu] has joined #sage-devel 10:59 -!- williamstein [n=willi...@d-69-91-159-214.dhcp4.washington.edu] has quit [Client Quit] 11:07 -!- mnick [n=...@e181107125.adsl.alicedsl.de] has quit ["leaving"] 11:10 -!- mvngu is now known as mvngu|afk 11:15 -!- jbosman [n=quas...@132.252.150.95] has quit [Remote closed the connection] 11:35 -!- prometheus1809 [n=prome...@202.3.77.11] has quit ["Leaving"] 11:54 -!- williamstein [n=willi...@d-69-91-159-214.dhcp4.washington.edu] has joined #sage-devel 12:12 < timdumol> williamstein: You there? 12:12 < williamstein> yes 12:13 < williamstein> just got out of the faculty meeting. 12:13 < williamstein> UW math isn't broke :-) 12:13 < timdumol> Great to know :)) 12:13 < timdumol> Great timing. I think I finally got the introspection to work. 12:14 < timdumol> williamstein: Nevermind. I missed a TODO. 12:15 < williamstein> ? 12:15 < timdumol> Just need to generate a confdir, then it should work. 12:16 < timdumol> It works with access to SAGE_DOC. But since that can't be assumed, I guess a confdir will have to be generated. 12:20 < mhansen> jason-: Are you reviewing #7007? 12:20 < jason-> now, or in general? 12:21 < mhansen> In general 12:21 < mhansen> It does fix #5755 12:21 < jason-> let me look... 12:22 < mhansen> It's just basically two changes to a regex and then fallout from that. 12:22 < jason-> wow, that's quite a fallout 12:23 < jason-> so you just added "(\.0+)?" to the regex? 12:23 < jason-> it's just a printing issue? 12:24 < williamstein> timdumol -- I think SAGE_DOC can be assumed, right? 12:24 < williamstein> at least SAGE_dOC in the worksheet process. 12:25 < williamstein> If the worksheet process is a running copy of *SAGE* then we have SAGE_DOC. 12:25 < williamstein> If it isn't, then we don't do Sphinx. 12:25 < williamstein> Since without Sage we only have PYthon and no guarantee of any Sphinx stuff. 12:25 < williamstein> And anyways, Sphinx support without Sage can be added later. 12:25 < mhansen> jason-: Yeah. It removed stuff like 1*x from everything else before. 12:26 < jason-> yes, I see. So this is more consistent now. 12:26 < timdumol> williamstein: Alright. But I think I've gotten the confdir generation done already anyways. A tad inefficient though. 12:26 < williamstein> Hey, nice work. 12:26 < williamstein> That's even better of course. 12:26 < jason-> mhansen: what about the latex representation, though? 12:27 < jason-> _latex_ still has the old replace, it looks like 12:28 < mhansen> Yep, you're right. I didn't about that. 12:30 -!- pearu [n=pe...@82.131.23.30.cable.starman.ee] has quit ["Leaving."] 12:30 < mhansen> (Since it wasn't relevant to the title of the ticket :-) ) 12:30 < jason-> yeah, I know.. 12:31 < jason-> but since you're already knee-deep in the code 12:31 < mhansen> Yep -- I'll do it now. 12:41 < mhansen> jason-: New patch is up. 12:45 < timdumol> williamstein: K. Finally done with the docstrings. I'm going to post the patch on trac now. 12:45 < williamstein> excellent 12:45 < williamstein> i'll try it 12:46 < jason-> mhansen: thanks 12:50 < timdumol> williamstein: Patch up at #7076 12:50 < williamstein> ok, trying now. 12:50 < williamstein> timdumol -- and thanks for doing this, since I was really procrastinating it! 12:51 < timdumol> williamstein: No prob. It's been a great learning experience. 12:51 < williamstein> And factoring the code out like you did is awesome, since it will make it much easier to make a sphinxify command line tool, etc. 12:52 < williamstein> If you ever need a letter of recommendation, don't hesitate to ask me. 12:52 < timdumol> williamstein: Actually, I'm reasonably certain it should work as a command line tool already. 12:52 < williamstein> cool. 12:52 < timdumol> williamstein: Thanks a lot. 12:53 < jason-> mhansen: so far, it looks great. Thanks! Can you address kcrisman's comments on the ticket though? 12:53 < mhansen> Sure, but it's about bedtime for me. 12:53 < mhansen> If you'd also weigh in, that'd be good. 12:53 < jason-> okay. I'm finishing a few doctests 12:54 < jason-> I'll post positive review (since it's just a printing issue) 12:54 < timdumol> It's a bit late here (4 AM). I think I'll sleep now. Bye. 12:54 -!- timdumol is now known as timdumol-asleep 12:55 < jason-> I guess the question is if there is a distinction, if x=polygen(RR), between x the variable and the polynomial 1.0000000*x 12:55 < jason-> williamstein might be able to give a nice authoritative answer... 12:55 < mhansen> Well, we have no datatype for representing the variable itself. 12:56 < jason-> aah, okay, that does change things 12:56 < jason-> so the variables literally are the polynomials like 1.00000*x? 12:56 < williamstein> jason- -- yep 12:56 < mhansen> Yeah 12:57 < jason-> can you explain this, then: 12:57 < jason-> sage: x=polygen(RDF) 12:57 < jason-> sage: x is 1*x 12:57 < jason-> False 12:57 < jason-> sage: (1*x).variables()[0] is x 12:57 < jason-> True 12:57 < jason-> if x the variable really is 1*x 12:58 < mhansen> If the generator is cached, then you get the above behavior. 12:58 < jason-> okay 12:58 < mhansen> 1*x creates a new polynomial in memory. 12:59 < jason-> sure, okay. 12:59 < jason-> so positive review, then. 13:00 < jason-> now I have to remember what I was doing when I ran across the issue... 13:02 -!- mhansen is now known as mhansen-sleep 13:02 < jason-> thanks again mhansen-sleep -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
