SAGE Bug Squash Day 6
The event will take place on SATURDAY, December 1, 2007 and officially start at 9 am pacific standard time.
Remember the "Twisted Rule" -- Don't work on anything unless there is a trac ticket for it.
The base version of SAGE we'll start with is 2.8.14.
Write to [email protected] for an account on the bug tracker.
- We'll all be on #sage-devel at irc.freenode.net.
From Linux you can chat via a text console by installing "irssi", running it, and typing /SERVER add irc.freenode.net /SERVER irc.freenode.net /join #sage-devel
If you are using Konversation (the KDE IRC client), you can set up an auto-replace rule that lets you type #1322 (for trac #1322) and what everyone sees is http://trac.sagemath.org/sage_trac/ticket/1322 (which lets people click on the link and see the bug you are talking about).
To configure this, go to Settings -> Configure Konversation -> Behavior -> Auto Replace and create a rule with Find as "#([0-9]+)" and Replace with as "http://trac.sagemath.org/sage_trac/ticket/%1" (both without the quotes). You can select whether this rule is applied to incoming posts, your outgoing posts, or both.
Participants (with area they would like to work on)
- Michael Abshoff (Solaris port, build issues in general)
- William Stein
- David Harvey --- yeah I'll probably be there, just tackling random bugs
- Mike Hansen
- Craig Citro (after 1PM)
- Josh Kantor -ATLAS issues.
- Robert Bradshaw --- I might be around a bit.
A mugshot of a Sage bug
IRC
06:32 < cwitty> mabshoff_, are you here? 06:36 < mabshoff_> Yep 06:36 < mabshoff_> I have had some trouble with your qqbar patch. 06:36 < mabshoff_> Either a mismerge or bits are missing. 06:36 < mabshoff_> http://sage.math.washington.edu/home/mabshoff/test-2.8.15.alpha0.log 06:37 < mabshoff_> Caution, 14MB 06:37 < mabshoff_> There is also a alpha0 tarball in that directory. I am writing release notes right now. 06:38 -!- jason_____ [[email protected]] has joined #sage-devel 06:40 < mabshoff_> cwitty: I am currently working on Solaris. 06:41 < mabshoff_> Somebody hardcoded int_fast64_t to be an int! 06:41 -!- jason_____ [[email protected]] has quit [Remote closed the connection] 06:46 < cwitty> If "ctypedef int int_fast64_t" fails, I think that would probably be considered a Cython bug. Cython isn't supposed to look at typedefs. 06:46 < mabshoff_> it doesn't fail to compile, but at startup it complains that the 64 bit int is the wrong size 06:46 < cwitty> The above just tells Cython "int_fast64_t is some type that has the same operations as int"; but Cython isn't supposed to believe that the two types have the same values. 06:47 < mabshoff_> when I set int_fast64_t to long long somewhere else. 06:47 < mabshoff_> That typedef is in *our* code 06:47 -!- dmharvey [[email protected]] has joined #sage-devel 06:47 < dmharvey> g'day 06:47 < mabshoff_> I am not sure that that is the whole story. 06:47 < cwitty> Yes, I know. But it doesn't get into the C code. 06:47 < mabshoff_> hi David 06:48 < mabshoff_> Well, I am trying with long long. 06:48 < cwitty> Yes. 06:48 < mabshoff_> Otherwise it is probably a cython bug. 06:48 < mabshoff_> as you wrote 06:48 < dmharvey> any bugs for me? 06:48 < mabshoff_> Nothing in trac for you? :) 06:49 < dmharvey> hehe #1293, "sage is too big", I know how to fix that....... 06:49 < mabshoff_> rm -rf ? 06:49 < dmharvey> ok I'll just start picking off some easy ones 06:49 < mabshoff_> Have fun. 06:50 < mabshoff_> cwitty: any idea yet why QQbar is a problem with alpha0 06:50 < mabshoff_> You can just untar, copy over the new mpfi.spkg and sage-2.8.15-alpha0.spkg and build. 06:50 < cwitty> It looks to me like you didn't do "sage -b" after merging qqbar-full.hg . 06:50 < mabshoff_> Well, I merged more patches and build then. 06:50 < cwitty> Consider this excerpt from test-2.8.15.alpha0.log: 06:51 < cwitty> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha0/local/lib/python2.5/site-packages/sage/rings/algebraic_real.py", line 1105, in __init__ 06:51 < mabshoff_> I even did a ./sage -ba 06:51 < cwitty> But algebraic_real.py should have been deleted by qqbar-full.hg . 06:51 < mabshoff_> I assume it was somehow mismerged, but qqbar.py exist and if I attach it manually I can 06:51 < mabshoff_> instantiate elements. 06:51 < cwitty> So alpha0 does have the patch? 06:51 < mabshoff_> Ok, that is why I assume mismerge right now. 06:52 < mabshoff_> It is in the log. 06:52 -!- malb [[email protected]] has quit [Remote closed the connection] 06:52 < mabshoff_> And unbundle did not complain. 06:52 < mabshoff_> It was actually the first think to go in ;) 06:53 < dmharvey> #280 is already fixed, but not marked as such. 06:54 < mabshoff_> What also makes me wonder is that bugs that mike hansen fixed are still there. 06:54 < dmharvey> Do I have the power to remove it? 06:54 < mabshoff_> You should be able to close it as fixed, but attach a working example session as the comment. 06:54 < dmharvey> ok will do 06:57 -!- ondrej [[email protected]] has quit [Remote closed the connection] 06:57 < mabshoff_> cwitty: Ok, I am taking the 2.8.13 binary, upgrading it to 2.8.14, applying qqbar-full.hg + the new mpfi.spkg and see if the problem still exists then. 06:58 < mabshoff_> I really, really dislike bundles - I have been screwed by them too many times by now. 06:59 < cwitty> mhansen, are you here? 06:59 < cwitty> mabshoff_, I'm confused: 07:00 -!- mabshoff_ is now known as mabshoff 07:00 < cwitty> test-2.8.15.alpha0.log includes at least two -testall runs, and qqbar.py succeeds in the last one. 07:00 < cwitty> Where is the problem? 07:01 < mabshoff> I guess it is a mismerge in the somewhere that screwed with your bundle. 07:01 < cwitty> What makes you think something is wrong? 07:01 < mabshoff> And I did kill one of the testall runs early on. 07:02 < mabshoff> algebraic_real.py still exists in my tree. 07:03 < mabshoff> And according to you it shouldn't be there any more. 07:03 < cwitty> When I look at test-2.8.15.alpha0.log, I don't see anywhere that it tries to doctest algebraic_real.py; are you sure it's there? 07:03 < mabshoff> Yep, I just checked. 07:04 < cwitty> Where is this tree? 07:04 < mabshoff> in /tmp/Work-mabshoff 07:04 < mabshoff> release-cycle-2.8.15/sage-2.8.15-try1 07:05 < cwitty> I don't see an algebraic_real.py in that tree. 07:05 < mabshoff> I did find it with "find" 07:06 < mabshoff> Let me look 07:07 < cwitty> There's a copy in your "build" tree, which is annoying; but I don't think that copy actually affects anything. 07:07 < mabshoff> ok, that might have been it. 07:07 < cwitty> (As long as you don't try to explicitly import the module, which nothing should.) 07:08 < mabshoff> You were right about the int_fast64_t issue, it seems to be a Cython bug. 07:08 < mabshoff> changing it to "long long" didn't make a difference. 07:09 < mabshoff> I wonder what the following means: 07:09 < mabshoff> int_fast32_t INTEGER_MOD_INT32_LIMIT 07:09 < mabshoff> int_fast64_t INTEGER_MOD_INT64_LIMIT 07:09 < mabshoff> cython macros? 07:09 < dmharvey> I'm taking over #1211 "NTL crash in polynomial remainder over ZZ" from malb, marked as critical, I know how to fix it 07:10 < mabshoff> Oh, I am sure he won't mind. 07:13 < cwitty> mabshoff, look at sage/rings/stdint.h 07:18 < mabshoff> ok 07:18 < mabshoff> I just remembered what went wrong: one file miscompiled, I didn't catch that and run testall. 07:18 < mabshoff> it failed all over the place. Then I fixed the issue but I looked at the initial testall run. 07:18 < mabshoff> Ergo: I am the idiot ;) 07:19 < mabshoff> looking 07:19 < cwitty> This is your bug, right? "typedef long int_fast64_t;" 07:19 < mabshoff> Which installation? 07:19 < mabshoff> On sun it is different. 07:19 < cwitty> In sage/rings/stdint.h . 07:19 < mabshoff> I am on neron, but let me check there, too. 07:20 < cwitty> That's a part of Sage; it's not going to be different on different platforms. 07:20 < mabshoff> ok, it might have been me :( 07:20 < cwitty> I checked; William wrote that line of code :) 07:20 < mabshoff> pfft. 07:21 < mabshoff> Hey, it is excellent to blame somebody else. 07:21 < mabshoff> It is correct in 64 bit mode, just not 32 bits. 07:22 < mabshoff> I am actually failry certain that I saw that code before it went in, so I didn't pay attention either. 07:24 < mabshoff> Ok, rebuilding all of sage-2.8.14.spkg on Solaris, just to be on the sage side. 07:26 < mabshoff> I am also rerunning testall after deleting the old test.log, but it looks like mhansen's patches had some side effects in the code. 07:26 < cwitty> Yes. 07:26 < cwitty> The last testall run had several failures caused by mhansen's patches (that I gave positive reviews to :( ). 07:26 < mabshoff> But calculus.py certainly passes doctests. 07:27 < mabshoff> See, now I can blame you :) 07:27 < mabshoff> We need parallel testall, so running it on sage.math only takes a couple minutes. 07:27 < mabshoff> That way I would apply 3, 4 patches and do a testall. 07:28 < mabshoff> Not like now where I have nearly 20 and then I can start guessing which one[s] caused the problem. 07:31 < cwitty> mhansen has patches to speed up testall: 07:31 < cwitty> <mhansen> I just did the equivalent of -testall in 8minutes which is a bit better. 07:31 < mabshoff> :) 07:31 < mabshoff> gimme, gimme, gimme ;) 07:32 < mabshoff> But isn't that with nose, and there were still a couple problems? 07:32 < cwitty> Yes. We need to get him to fix those problems (or at least post what he has so far). 07:33 < mabshoff> Sure, I certainly agree. 07:33 < cwitty> That was from early October... 07:33 < mabshoff> ok 07:34 < mabshoff> It looks like SymbolicConstant is somehow broken, that causes some recursion that is stopped after 1000 iterations. 07:37 < cwitty> Yes. I'm hoping mhansen will show up soon to fix it :) 07:37 < mhansen> Good morning -- I just got what. 07:37 < mhansen> err, up 07:37 < mabshoff> At least he broke it, your QQbar patch seems to work. 07:37 < mhansen> What patch are we talking about. 07:37 < mhansen> ? 07:37 < mabshoff> So, are your ears burning? 07:38 < mabshoff> We aren't sure yet, but the series of three patches fixing expand, symbolic parent and the third one 07:38 < mabshoff> broke some doctests outside of calculus.py 07:38 < mabshoff> I am running clean doctests and can upload them shortly. 07:39 < mabshoff> There is also 2.8.15.alpha0 in sage.math/home/mabshoff 07:39 < mabshoff> One problem is this: 07:39 < mabshoff> return self._ser() * SR(right) 07:39 < mabshoff> File "element.pyx", line 1372, in sage.structure.element.RingElement.__mul__ 07:39 < mabshoff> File "coerce.pxi", line 124, in sage.structure.element._mul_c 07:39 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha0-try1/local/lib/python2.5/site-packages/sage/calculus/calculus.py", line 3009, in _mul_ 07:39 < mabshoff> return SymbolicConstant( operator.mul(self._obj, right._obj) ) 07:39 < mabshoff> File "element.pyx", line 1374, in sage.structure.element.RingElement.__mul__ 07:40 < mabshoff> File "coerce.pyx", line 252, in sage.structure.coerce.CoercionModel_cache_maps.bin_op_c 07:40 < mabshoff> File "element.pyx", line 1372, in sage.structure.element.RingElement.__mul__ 07:40 < mabshoff> File "coerce.pxi", line 124, in sage.structure.element._mul_c 07:40 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha0-try1/local/lib/python2.5/site-packages/sage/functions/constants.py", line 350, in _mul_ 07:40 < mabshoff> return self._ser() * SR(right) 07:40 < mabshoff> return self._coerce_impl(x) 07:40 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha0-try1/local/lib/python2.5/site-packages/sage/calculus/calculus.py", line 401, in _coerce_impl 07:40 < mabshoff> return SymbolicConstant(x) 07:40 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha0-try1/local/lib/python2.5/site-packages/sage/calculus/calculus.py", line 2842, in __init__ 07:40 < mabshoff> Symbolic_object.__init__(self, x) 07:40 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha0-try1/local/lib/python2.5/site-packages/sage/calculus/calculus.py", line 2736, in __init__ 07:40 < mabshoff> SymbolicExpression.__init__(self) 07:40 < mabshoff> RuntimeError: maximum recursion depth exceeded 07:40 < mabshoff> That is in plot.py, doctest 4 07:41 < mhansen> Okay 07:42 < mabshoff> The whole log is at http://sage.math.washington.edu/home/mabshoff/test-2.8.15.alpha0.log 07:42 < mabshoff> but that is from a number of runs. 07:44 < mabshoff> #645 also seems to cause trouble here and there. 07:44 < mabshoff> But you should check in the alpha0 tarball that all your patches have been applied correctly. 07:44 < mabshoff> I still think that at some point some mismerges happened. So blame me. 07:45 < mhansen> I get that on my local one though. 07:45 < mabshoff> ok, good for me, bad for you ;) 07:45 < cwitty> #645 provokes a failure in piecewise.py: 07:45 < cwitty> ValueError: the number of arguments must be less than or equal to 0 07:45 < mabshoff> I read that one and I thought: What? 07:49 < mhansen> Piecewise.py passes for me. 07:49 < mabshoff> ok, which patches did you apply? 07:50 < mhansen> Well, I'm still downloading 2.8.15. This branch has 847, 1345, 645, and 644 in that order. 07:51 < mhansen> (I guess also 1111 and 1280 before those too.) 07:51 < mabshoff> ok, maybe I am missing one of them. There was some dependencies. 07:51 < mabshoff> I didn't merge #644 07:52 < mabshoff> #1280 is also not merged yet. 07:52 < mhansen> I think that 644 will fix that. 07:53 < mhansen> I'm working on the plot.py one now. 07:53 < mabshoff> ok, you can reproduce that locally? 07:53 < mhansen> Yeah 07:53 < mabshoff> ok, you wrote that a couple minutes ago, sorry. 07:54 < dmharvey> when I change ntl_wrap.h in c_lib, why does sage -b not recognise the change? Do I need to do some scons thing manually? 07:55 < mabshoff> Probably, let me check. 07:57 < mabshoff> I guess you can touch the right pyx - but can't you also add a dependecy in setup.py? 07:57 < dmharvey> ah no it's okay, I forgot to declare the new function to cython 07:57 < mabshoff> :) 08:02 -!- kedlaya [[email protected]] has joined #sage-devel 08:03 < mhansen> I figured out the plot.py issue. It came from a combination of patches. Is there a ticket for it? 08:03 < mabshoff> Not yet. Open one please. 08:03 < mabshoff> I assume you have a fix :) 08:04 < mhansen> Yeah, I think so. I need to think it through first. 08:04 < mabshoff> np, I am applying #644 and #1280 to alpha1 right now. 08:06 < mabshoff> A comment about #644: "This patch should be applied after #644" 08:06 < mhansen> Oops, I meant 645. 08:06 < mabshoff> Well, I assume so now, too. 08:07 < mabshoff> We really can't afford it any more not to do any merges for 6 days like after 2.8.14. 08:07 < mabshoff> Too many tickets and patches pile up. 08:08 < dmharvey> grrr..... i change decl.pxi in libs/ntl and like everything has to rebuild.... 08:09 < cwitty> mabshoff, we should think some about totally new procedures for sage releases. 08:10 < cwitty> Like (brainstorming): if people on a whitelist give a positive review to a patch in TRAC, 08:10 < cwitty> then a bot automagically applies it to a "testing" tree. 08:10 < mabshoff> :) 08:10 < mabshoff> That would be quite nice. 08:10 < cwitty> Then a tinderbox (automatically compile and test) setup notices that tree has changed, 08:10 < mabshoff> build bot ;) 08:10 < cwitty> and tests the new version on 5 platforms. 08:11 < dmharvey> I keep getting the following linker warning: 08:11 < dmharvey> /usr/bin/ld: warning can't open dynamic library: libpari-gmp.dylib referenced from: /Users/david/sage-2.8.14/local//lib/libcsage.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) 08:11 < dmharvey> what's that all about? 08:11 < mabshoff> relocation problem. 08:12 < mabshoff> rebuild NTL, then the problem should go away. 08:12 < mabshoff> I have a fix, but it isn't in 2.8.15 yet. 08:12 < dmharvey> oh ok 08:12 < was__> hi 08:12 < dmharvey> this is from a clean sage.2.8.14 08:12 < mabshoff> NTL gets build with "stupid" linker options on OSX. 08:12 < mabshoff> Did you move it? 08:12 < dmharvey> no 08:12 < mabshoff> hi was__ 08:12 < dmharvey> i cloned it though 08:12 < dmharvey> i mean I cloned my sage tree 08:12 < mabshoff> ok, that might be a problem. 08:13 < mabshoff> Nope, it isn't the problem. 08:13 < was__> regarding bug day -- I think we should start with 2.8.14, since 2.8.15 doesn't seem ready? 08:13 < was__> Or? 08:13 < mabshoff> John Hanke had the same thing. 08:13 < was__> I just woke up after getting a lot of sleep. 08:13 < mabshoff> alpha0 is out, alpha1 is being worked on. 08:13 < mabshoff> We could work on 2.8.14, but I could merge patches into alphaX 08:14 < was__> libpari-gmp.dylib -- ?? That looks to me more like a problem with pari not NTL. 08:14 < dmharvey> it's only a warning: it still builds and runs 08:14 < was__> mabshoff -- that would be very safe. 08:14 < mabshoff> It is NTL, for some reason it doens't pick libgmp.dylib. 08:14 < was__> Try forcing a rebuild of libcdsage. 08:14 < mabshoff> Never figured out why. 08:14 < mabshoff> Yep, I will be merging and build testing most of the night - at least the way it looks. 08:14 < was__> But why *libpari-gmp.dylib" ???? PARI and GMP both have absolutely nothing to do with NTL. 08:15 < mabshoff> NTL needs gmp, I think. 08:15 < was__> dmharvey -- force a rebulding of libcsage. 08:15 < was__> Yes. But PARI doesn't need NTL. 08:15 < dmharvey> i'll try later.... debugging something else right now 08:15 < was__> And libpari-gmp.dylib is the pari library, but linked against gmp. 08:16 < was__> OK. 08:16 < was__> Anyway, I'll be back by 9am and we can start bug day. I'm going to go to a coffee shop... 08:17 < mabshoff> cu 08:17 < mabshoff> I think the problem is the OSX linker, it sees gmp symbols on libpari-gmp.dylib and links against those symbols. 08:22 -!- dmharvey_ [[email protected]] has joined #sage-devel 08:22 < dmharvey_> hmmm so #1211 is not as easy as I had thought 08:23 < dmharvey_> the problem is quo_rem semantics 08:23 < dmharvey_> If x and y are elements of a ring R 08:23 < dmharvey_> and q, r = x.quo_rem(y) 08:23 < dmharvey_> are q and r required to be elements of R? 08:23 < dmharvey_> If so, then this is very difficult to pull off with the functionality provided by NTL 08:24 < dmharvey_> I can fix the bug to make the segfault go away, but it won't be able to handle divisions by non-monic polynomials 08:24 < mabshoff> mhansen: with #644 and #1280 piecewise.py passes 08:25 < mabshoff> dmharvey: Can you raise an Error, too? 08:25 < mabshoff> Not segfaulting would certainly be a plus. 08:26 < dmharvey_> I guess avoiding the segfault is the number one priority, but I don't want to do this in a way that cripples existing functionality 08:26 < wjp> hm, magma actually complains if you take the quotient of PolynomialRing(Integers()) by 2*x-1 08:26 < mabshoff> Sure. 08:26 < wjp> Runtime error in quo< ... >: Polynomial must be monic 08:27 < cwitty> Pari's number field functions require that the defining polynomial is monic. 08:27 < dmharvey_> hmmmm 08:27 < cwitty> I can think of at least 3 possibilities for #1211: 08:27 < cwitty> 1) raise an error 08:27 < mabshoff> I am running out for some last minute shopping. 08:27 < cwitty> 2) return an element of QQ['x'] 08:27 < mabshoff> back in 30 minutes or so 08:27 -!- mabshoff is now known as mabshoff|afk 08:27 < cwitty> 3) return the pseudoremainder 08:28 < dmharvey_> I think (1) is the only way to go. 08:28 < cwitty> And I have no particular opinion which should be the behavior of "%" :) 08:28 < cwitty> OK, sounds good to me. 08:28 < dmharvey_> (3) doesn't make sense, since quo_rem is defined for lots of types, and there's no reason it should be a pseudo-remainder in this case 08:28 < dmharvey_> I don't like (2) because the return type is unpredictable 08:29 < cwitty> True. (Although there are precedents in Sage, like RR(x).sqrt() .) 08:31 < dmharvey_> the really weird thing is that the current implementation eventually uses NTL's DivRem function, but the NTL documentation explicitly says that this only works for monic divisors 08:35 -!- was__ [[email protected]] has quit [] 08:35 < dmharvey_> ok here's what I'm going to do. The underlying issue is the implementation of f.quo_rem(g). If g is monic (or -g is monic), then I just do the usual division/remainder. If g is not monic, I test divisibility. If it divides exactly, I return (quotient, 0). If it doesn't divide, I raise an error. Does that sound reasonable? 08:35 < cwitty> Yes. 08:38 -!- dmharvey [[email protected]] has quit [Read error: 110 (Connection timed out)] 08:39 < mhansen> mabshoff: A patch is up for #1350 08:39 < cwitty> When returning (quotient, 0), be sure to coerce the 0 into the polynomial ring. 08:40 < mabshoff|afk> ok, 08:41 < dmharvey_> cwitty: ok thanks 08:42 < cwitty> mhansen, is there a reason your #1350 patch doesn't touch the __pow__ case? 08:44 -!- jason- [[email protected]] has joined #sage-devel 08:44 < mhansen> Because I didn't work on the __pow__ case for any of these patches. I still need to think about it since there are a lot of things that you do "need" to keep symbolic when doing powers. 08:44 < cwitty> OK. 08:45 < mabshoff|afk> Is Robert going to be around later? 08:46 < mhansen> So, we probably still would get an error with 2^2^2...^2 (1000 times). 08:46 < mhansen> (in SR, that is) 08:53 -!- was_ [[email protected]] has joined #sage-devel 08:54 < cwitty> Hi, was_. 08:54 < was_> hi. 08:54 < was_> I'm now at starbucks, with a great net connection -- fortunately I have noise canceling headphones so I don't have to listen to their christmas music. 09:02 < mhansen> Haha 09:04 < mhansen> was_: Could you look at my patch for #645 and give your thoughts on it. There was a lot of discussion on how things should be handled. 09:04 < cwitty> Do you mean #644? 09:05 < mhansen> Yeah, 644. 09:05 < was_> OK, bug day 6 is on! 09:05 < dmharvey_> ok I've fixed #1211... patch will be uploaded momentarily. I also fixed this amusing crash: 09:05 < dmharvey_> sage: R.<x> = PolynomialRing(ZZ); x^2 % 0 09:05 < was_> Please change your nick to the # you're working on. 09:06 < was_> And, congrats to everybody on trophees du libre. 09:07 -!- was_ is now known as was-1349 09:07 < was-1349> I intend to do #1349 -- which is to change the *default* notebook location to $HOME/.sage/notebook 09:07 < was-1349> Though I think it's crystal clear and sensible that the default is in the current directory, it seems like this confuses the heck out of most new users. 09:08 < was-1349> One can still specify a location -- it would just be that the default would be $HOME/.sage/notebook. 09:08 < was-1349> Thoughts? 09:08 < mhansen> I think that sounds like a good idea. I always run it from one directory. 09:09 -!- mabshoff|afk is now known as mabshoff 09:09 < wjp> agreed; sounds like a much more sensible default to me 09:09 < was-1349> Could everybody say "hi" and where they are right now, and maybe something briefly about their Bug day goals today? 09:09 < mabshoff> Hi 09:10 < was-1349> I'm in Seattle in Starbucks and intend to fix a bunch of bugs I've noticed in the last week or two that are all kind of random and sucky. 09:10 < mabshoff> I plan to work on merging patches, Solaris build issues and misc stuff 09:10 < was-1349> E.g., residue_field being broken. 09:10 < mabshoff> So hopefully at the end of the night we will have something close to 2.8.15.final 09:10 < mhansen> Hello, I'm in Madison, WI and have been working on calculus stuff. 09:11 < burcin> Hi, I'm in Linz, Austria.. and I will be leaving soon :) 09:12 -!- mabshoff is now known as mabshoff-2 09:12 -!- mabshoff-2 is now known as mabshoff2 09:12 < cwitty> I'm in Renton, WA; my plan is to fix a few easy bugs and then switch over to working on new features. (Sorry, guys. :) 09:12 -!- mabshoff2 is now known as mabshoff 09:12 -!- burcin [[email protected]] has quit ["Leaving"] 09:13 < jason-> I'm in Ames, iowa (where we are having an ice storm right now!). Depending on how time works out, I'd like to work on a few bugs related to a new feature in #1322 (interactive widgets). 09:14 < was-1349> jason- -- no fair -- you introduce a few bugs so you can fix them :-) 09:14 < jason-> :) 09:14 < dmharvey_> boston MA, I'm fixing whatever random stuff I feel like (just uploaded patch for #1211) 09:14 < jason-> I'll probably need some help from the notebook gurus, though. 09:14 < dmharvey_> what we really need is an IRC plugin that links directly from strings like #1211 to the page on trac 09:14 < was-1349> dmharvey_ -- That would be awesome 09:16 < jason-> test: #1322 09:16 < mhansen> I can write an xchat plugin that does that ( and in Python even ;-] ) 09:17 < was-1349> wow. 09:17 < jason-> I'm trying to configure Konversation to do it...it has regexp autoreplacing. 09:17 < dmharvey_> oh guys I'm sorry I didn't intend that comment to halt progress on sage development 09:17 < was-1349> :-) 09:19 -!- dmharvey_ is now known as dmharvey-1334 09:19 < mabshoff> mhansen: patch #1350 solved the issues in arith.py and plot.py, so now my alpha1 passes all doctests again ;) 09:19 < was-1349> nice!! 09:20 < mabshoff> I will be merging the LLL stuff Martin posted next. 09:20 < mhansen> Well, a combination of my patches caused those problems, so... ;) 09:20 < mabshoff> I had hoped for a PolyBoRi.spkg for compiler testing purposes only, but burcin is gone for now. 09:20 < cwitty> was-1349, I'm looking at #75. Does the last comment (from you) have anything to do with the rest of the ticket? 09:21 < was-1349> nothing that I can discern :-) 09:22 < mabshoff> How will we be handling merges? Somebody posts, somebody else reviews and I apply against alphaN? 09:22 < was-1349> yes. 09:22 < was-1349> Actually, somebody posts; somebody reviews and finds the post is broken, somebody fixes, somebody reposts;, then you merge. 09:22 < mabshoff> ok, then let me know what is mergable, I might be doing something else and not pay attention to IRC. 09:23 < was-1349> via email? 09:23 < was-1349> or? 09:23 < mabshoff> I got 2.8.14 to build on solaris with int_fast64_t declared as a long long. 09:23 < was-1349> excellent. 09:23 < mabshoff> Nope, here is fine, I will set my nick to afk if I am gone for a while. 09:23 < mabshoff> doctesting Solaris now. Hopefully once malb fixes the issue with mv polynomials matrices it will be close to perfect again. 09:24 < cwitty> Somebody (perhaps was-1349) should review #1292; it fixes a "critical" bug. 09:24 -!- cwitty is now known as cwitty-75 09:25 < jason-> what does afk stand for? 09:25 < mabshoff> away from computer 09:25 < was-1349> no clue. 09:25 < cwitty-75> "away from keyboard" 09:25 < was-1349> away from komputer -- dang germans :-) 09:25 < mabshoff> damn Germans, indeed 09:25 < was-1349> damn smart Germans. 09:26 < mabshoff> :) 09:26 < jason-> testing again: http://trac.sagemath.org/sage_trac/ticket/1322 09:26 < was-1349> nice. 09:26 < jason-> did it show the URL to you? 09:27 < mabshoff> Yep 09:27 < was-1349> yep 09:27 < jason-> I typed "# 1322" (without the space) and konversation replaced it with the URL. 09:27 < mabshoff> ok, can you post the replacement rule? 09:27 < mabshoff> Unless it gets mangled ;) 09:28 < was-1349> post the rule to the wiki page for bug day 6 09:28 < jason-> #([0-9]+) -> http://trac.sagemath.org/sage_trac/ticket/%1 09:28 < mabshoff> thanks 09:28 < jason-> Oh, and I just realized I can set it to replace on outgoing, incoming, or both. 09:28 < jason-> I guess I'll do both so ya'll can still use # 1322 (without the space) :) 09:29 < mabshoff> Ok, is anybody reviewing http://trac.sagemath.org/sage_trac/ticket/1292? 09:29 < jason-> wow, you're using konversation already? 09:29 < mabshoff> Sure, which other clients besides irssi should I use? 09:30 < jason-> good point. 09:30 < mabshoff> :) 09:31 < jason-> testing just the incoming rule: #1322 09:31 < jason-> hmmm, doesn't seem to work as well. Oh well. 09:33 < mabshoff> It works for me outgoing and incoming. 09:34 < jason-> So you could click on the above "# 1322" and it brought you to the web page? 09:35 < mabshoff> Well, it is an url. 09:36 < mabshoff> Yep, and it works, except that it launches konqueror, while I prefer firefox, but that is a local config issue. 09:36 < cwitty-75> was-1349, for #75, you can already specify the name of the variable (but not the ring). Is that good enough to close the ticket? 09:37 < was-1349> The entire point of the ticket was that specifying the name of the variable is not good enough. 09:37 < was-1349> Or at least, that became the point... after a while. 09:37 < was-1349> Maybe I'm wrong, actually #75 is pretty old. 09:38 < cwitty-75> And the example in the description is obsolete. It says "f and g have different parents", but in current Sage, they have the same parent. 09:38 < was-1349> I think one must specify the ring ... 09:38 < was-1349> But that could be another trac ticket. 09:38 < was-1349> The problem with that is that charpoly is just one case -- there are lots of situations like this (e.g., minpoly). 09:38 < was-1349> So I agree, this can be closed. 09:38 < was-1349> Something else can be opened if somebody feels it is really really necessary (I'm ok with the current behavior) 09:39 < was-1349> I've closed it. 09:44 < mhansen> was-1349: Could you look at #644? 09:45 -!- cwitty-75 is now known as cwitty-1154 09:46 < dmharvey-1334> #1334 is done 09:46 < dmharvey-1334> i'm taking a break 09:46 -!- dmharvey-1334 is now known as dmharvey-resting 09:46 < was-1349> ok, thanks. 09:47 < cwitty-1154> I will review #1334. 09:48 < mabshoff> http://trac.sagemath.org/sage_trac/ticket/1292 looks go to me, but it might be better if somebody else reviews it. 09:51 < mabshoff> cwitty: Do I need to apply both patches for http://trac.sagemath.org/sage_trac/ticket/1148? 09:52 < cwitty-1154> mabshoff, yes, both patches. 09:52 < mabshoff> ok, applying. 09:53 -!- giniu [[email protected]] has joined #sage-devel 09:54 < mabshoff> cwitty: re http://trac.sagemath.org/sage_trac/ticket/1275 - What do you think about Robert's patch? 09:55 < cwitty-1154> I like about a third of it. I posted a comment on the ticket. 09:56 < mabshoff> ok, maybe be should close http://trac.sagemath.org/sage_trac/ticket/1275 and open a new ticket for Robert's improvement. 09:56 < mabshoff> Because once you have more than 4 patches or bundles attached to a ticket it starts to gets confusing. 09:56 < was-1349> is #1275 in sage-2.8.15 now? 09:57 < mabshoff> I will merge it once testall finishes. 09:57 < mabshoff> Any objections? 09:57 < was-1349> no. 09:57 < mabshoff> Opps, it is. 09:57 < was-1349> no objections, that is. 09:57 < mabshoff> All, but Robert's patch. 09:57 < mabshoff> The new mpfi.spkg is also in. 09:58 -!- mhansen is now known as mhansen-962 10:01 < mhansen-962> I put a new patch up for #962 . 10:02 < cwitty-1154> mhansen-962, I'll look at it. 10:02 < was-1349> ok, I finished #1349. 10:03 < mabshoff> oops, doctest failure with sage/rings/polynomial/polynomial_element.pyx due to one of 10:03 < mabshoff> mhansen's patches: 10:03 < mabshoff> sage: f(x=sqrt(2)) 10:03 < mabshoff> leads to: IndexError: tuple index out of range 10:03 < cwitty-1154> mabshoff, I reviewed #1334 -- looks good. 10:04 < mabshoff> ok, I am now merging again ;) 10:04 < mhansen-962> mabshoff: I'll fix that. 10:04 -!- was-1349 is now known as was-1342 10:05 < was-1342> I'm going to try to deal with the serious bug I found in residue_field Thursday now -- #1342. 10:05 -!- kedlaya [[email protected]] has left #sage-devel [] 10:05 < mabshoff> ok 10:05 < was-1342> Actually, I better finish up #787 now. That's lingered way way too long. 10:05 -!- was-1342 is now known as was-787 10:06 -!- dmharvey [[email protected]] has joined #sage-devel 10:22 -!- dmharvey-resting [[email protected]] has quit [Read error: 110 (Connection timed out)] 10:26 -!- was_ [[email protected]] has joined #sage-devel 10:26 -!- was-787 [[email protected]] has quit [Read error: 104 (Connection reset by peer)] 10:32 < jaap> Hi mabshoff, I'm here watching this interesting happening! 10:32 < jaap> Waiting for alpha1! 10:33 < mhansen-962> mabshoff: I fixed that doctest in #1352. 10:33 < mabshoff> ok, we plan that in the future the release manager can push out the changes to some devel repo, so people 10:33 < mabshoff> do not have to recompile from scratch each time. 10:33 < mabshoff> mhansen-962: Excellent, will merge momentarily. 10:33 < was_> That would be very good -- i've planned that for a while. 10:34 < was_> You just would have to set the SAGE_SERVER enviro variable and do "sage -upgrade' to get the latest devel version. 10:34 < cwitty-1154> That's #463, right? 10:35 -!- craigcitro [[email protected]] has joined #sage-devel 10:35 < craigcitro> hey all 10:35 < craigcitro> what release are we working from? 10:35 < was_> 2.8.14 10:35 < craigcitro> k 10:35 < was_> set your nick to your ticket. 10:35 < craigcitro> grin ... that's a smart system ;) 10:36 < was_> cwitty suggested it. 10:36 -!- was_ is now known as was-787 10:36 < craigcitro> i actually suggested it during the last bug day 10:36 < was-787> oh, sneaky. 10:36 < craigcitro> grin 10:36 < was-787> one of those "c" nicks suggested it. 10:37 < mhansen-962> Oh, if anyone uses x-chat, I have a plugin that coverts things like #123 to the appropriate link. 10:37 < craigcitro> hahaha 10:37 < jaap> Yep 10:37 < mhansen-962> It has a really nice Python scripting interface. 10:37 < craigcitro> it makes me pretty proud to be grouped with carl ;) 10:39 -!- jec [[email protected]] has joined #sage-devel 10:39 < was-787> Hi John (jec) 10:39 < mabshoff> Anybody up to look at http://trac.sagemath.org/sage_trac/ticket/1352 ? 10:39 < mhansen-962> http://sage.math.washington.edu/home/mhansen/sage_trac.py -- it's a bit of a quick hack. 10:39 < jec> Hi William -- won't be staying long... 10:39 < mabshoff> Hi 10:40 < mhansen-962> By the way, can you upgrade binary releases without building anything from source? 10:41 < mabshoff> In theory yes, in practise I wouldn't want to try it, 10:41 < mabshoff> copying over the old install should mostly work. 10:41 < was-787> mhansen-962: absolutely not 10:41 < was-787> it is not in any way implemented. 10:42 < mabshoff> But it should work. 10:42 < mhansen-962> I think that'd be something good to have in the future. 10:42 < was-787> The plan for implementing that has been to have the binary release master somewhere be upgraded. 10:42 < was-787> Then you would rsync from that. 10:42 < mabshoff> Well, if we have debs we can just untar them into the root directory. 10:42 < mabshoff> $SAGE_ROOT that is. 10:42 < mabshoff> I would do something similar for windows, very much like the current cygwin installer. 10:43 -!- jason- is now known as jason-|afk 10:43 < mabshoff> hmm, http://trac.sagemath.org/sage_trac/ticket/1249 has some open questions from cwitty. jason- are you around? It is graph theory related. 10:44 < cwitty-1154> mhansen-962, in 962-2.patch, it seems like the "#Strip extra zeros from the left" part is now redundant (just from reading the source). Is that right, or am I missing something? 10:45 -!- jec [[email protected]] has quit ["Konversation terminated!"] 10:45 < mhansen-962> Yep, that should go. I'll update things. 10:48 < mhansen-962> The patch of #962 has been updated. 10:50 -!- craigcitro is now known as craigcitro-1129 10:53 < was-787> Finishing #787 is pretty complicated. 10:53 < mabshoff> How is it going? 10:53 < was-787> (I mean actually doing everything *right*.) 10:53 < was-787> Very good -- it's fun. But I have to create new classes, etc. 10:54 < mabshoff> Okay, so the patch won't be very simple, but would produce false results extremely quickly ;) 10:54 < was-787> :-) 10:54 < mabshoff> I am about to run out of reviewed patches. 10:54 < was-787> Actually a big part of "doing things right" to me in this case means lots of comments explaining what is going on. 10:54 < mabshoff> ok 10:54 < was-787> E.g., this line in nils patch: 10:54 < was-787> M=sub.basis_matrix().transpose().restrict_domain(self).kernel().basis_matrix().transpose() 10:54 < was-787> SUCKS. 10:55 < mabshoff> lol 10:55 < mhansen-962> Haha 10:55 < was-787> Instead I have paragraphs of comments about what that is doing. 10:55 < was-787> It's the sort of thing perl people might like... 10:55 < mabshoff> bada bing! 10:55 < was-787> But it's not for me. 10:55 < was-787> (sorry -- no flame war intended.) 10:55 < mabshoff> josh isn't around ;) 10:56 < cwitty-1154> mhansen-962, I don't understand the purpose of "#Ignore the extra zeros at the end" in your new version of str(). 10:57 < cwitty-1154> (That is, why did you change from "n = len(t)"?) 10:57 < was-787> I'm off to http://www.espressovivace.com/retail.html -- I should be back in irc in about 30 minutes. 10:57 -!- was-787 [[email protected]] has quit [] 10:59 < mhansen-962> cwitty-1154: Let me figure out if I remember why I did that -- it's been awhile since I wrote it ;-] 10:59 < cwitty-1154> And without that change, I think that the "#Pad the end with zeros" chunk is also not needed. 11:00 -!- dmharvey [[email protected]] has quit [] 11:00 -!- giniu [[email protected]] has quit ["ChatZilla 0.9.79 [Firefox 2.0.0.10/2007120102]"] 11:02 < mhansen-962> The "ignore the extra zeros at the end" has to do with t which comes from mpfr's internal representation. I did the "pad the end" part so that you'd keep about the same precision by doing RealNumber(repr(x)). 11:04 < cwitty-1154> Well, len(t) should either be mpfr's "how many digits do we need to represent this number", or our calculated "how many digits do we want to round this number to". 11:04 < cwitty-1154> In either case, I don't see why we want to change it. 11:07 < mhansen-962> Hmm... 11:09 < mhansen-962> Let me play around without it. 11:10 < mabshoff> mhansen-962: any opinion on http://trac.sagemath.org/sage_trac/ticket/1249, i.e. the comment at the end? 11:10 -!- jkantor [[email protected]] has joined #sage-devel 11:11 < cwitty-1154> The thing I really want to avoid is rounding the number (by specifying reqdigits), and then adding an incorrect "0" instead of whatever the correct digit would have been. 11:11 < mabshoff> hi jkantor 11:11 < jkantor> hey 11:11 < mabshoff> I am about to start merging all your ATLAS spkg in a special branch to test out. 11:12 < jkantor> ok 11:12 < mabshoff> Then if/when they work I will merge them back into my main alpha2 or something around there. 11:12 < jkantor> ok 11:12 < cwitty-1154> mabshoff, cool. I noticed last night that linear algebra on my laptop is much slower than on sage.math, when usually my laptop is faster; hopefully ATLAS will help. :) 11:12 < mabshoff> The new fortran.spkg: did you add more then the fortran detection script? 11:13 < mabshoff> :) 11:13 < jkantor> no 11:13 < mabshoff> jkantor did most of the work, I just complain if something breaks ;) 11:13 < jkantor> just that script. I don't use it yet 11:13 < mabshoff> Ok, I will stick the new fortran into alpha1 so it is done. 11:13 < jkantor> But it will simplify all spkg-installs in other packages 11:13 < mhansen-962> cwitty-1154: Can you come up with a case where that happens? 11:13 < jkantor> and let me remove redundant code 11:14 < mabshoff> In which spkgs? 11:15 < jkantor> like the atlas and numpy and cvxopt, anything using fortran I need some test 11:15 < jkantor> for gfortran or g95 11:15 < mabshoff> ok, let me know when you are ready. 11:15 < mabshoff> I am testing alpha1 right now (minus the new fortran, but that is a no-brainer) 11:16 < mabshoff> It that passes tests I will build from source to have a new, clean alpha2 basis. 11:16 < mabshoff> So that is about 1.5 hours from now. 11:16 < jkantor> I think its easier to just include the script and I will switch to using it when each package is updated 11:16 < mabshoff> Ok, that is fine with me. 11:17 < mhansen-962> cwitty-1154: Now, that I think about it, I'm okay with not padding at the end. 11:17 -!- was_ [[email protected]] has joined #sage-devel 11:17 < mabshoff> I am wondering if I can figure out where to get complex.h on Solaris. 11:17 < mabshoff> That breaks cvxopt compilation on Solaris 11:17 < jkantor> complex.h? 11:17 < jkantor> ia that a c99 header 11:17 < mabshoff> But there is a binary distribution of cvxopt for Solaris, so it must be possible. 11:18 < mabshoff> Yep. I will check out Solaris 10 and steal from there ;) 11:18 < was_> Hi; I'm back. 11:18 < mabshoff> Fixing the "long" vs. "long long" issue seems to fix a lot of doctests on Solaris ;) 11:18 < mabshoff> Hi was_ 11:19 < mabshoff> was_: I merged http://trac.sagemath.org/sage_trac/ticket/1352 - can you take a quick look? 11:19 < was_> I'm across the street from Seattle REI... 11:19 < mabshoff> The coffee shop you mentioned? 11:20 < was_> yep. 11:20 < mabshoff> ok 11:20 < jkantor> is it in the REI 11:20 < mhansen-962> I've been to Vivace :-) 11:20 < was_> no, it is directly across the street. Good wifi; nice environment; not too crowded. 11:20 < jkantor> oh from the REI, vivace 11:20 < cwitty-1154> mhansen-962: yes, I have an example. 11:20 < was_> yep, that's it. 11:20 < cwitty-1154> sage: str(RealField(3000000)(1/3))[-10:] 11:20 < cwitty-1154> '3333333330' 11:21 < was_> lame 11:21 < was_> re: cwitty's thing 11:21 < cwitty-1154> ? 11:21 < was_> I don't like the 0 at the end. 11:22 < mhansen-962> Yep -- it shouldn't be there. 11:22 < mhansen-962> #962 is up without the padding at the end. 11:22 < was_> sage: magma.eval('RealField(903090)!(1/3)')[-10:] 11:22 < was_> '3333333333' 11:22 -!- was_ is now known as was-787 11:23 < was-787> #1352 looks good to me, I think. 11:23 < mabshoff> ok,I tend to trust mhansen. If it breaks stuff, he fixes it too ;) 11:23 < mhansen-962> Heh 11:23 < mabshoff> I am doctesting all, to do alpha1 now. 11:24 < mhansen-962> was_: Does the behavior of #644 seem okay to you? 11:24 < mhansen-962> mabshoff: I think #1249 is okay. 11:25 < cwitty-1154> mhansen-962: but now you need to change back to "n = len(t)", right? 11:25 < cwitty-1154> sage: 1.0000000000000000000000000000000000 11:25 < cwitty-1154> 1. 11:25 < mabshoff> mhansen-962: ok, will merge then. 11:32 < mabshoff> was-787: I got a patch for Solaris that makes the lazy rings no longer run in an inifinte loop 11:32 < mabshoff> Now if we fix crashes in coercion.pyx and element.pyx we should look much better :) 11:32 < mhansen-962> cwitty-1154: I think this makes things a bit more complicated. Do you have any ideas for just redoing the whole thing? I was pretty much just working within the framework of the existing functions. 11:34 < cwitty-1154> What's wrong with just taking the "#Ignore the extra zeros at the end" chunk back out and reverting to "n = len(t)"? 11:35 < mhansen-962> sage: 0.00000000000001 11:35 < mhansen-962> 0.0000000000000100000000000000 11:37 < cwitty-1154> mabshoff, looks like you didn't actually read my review for #1279? 11:37 < cwitty-1154> mhansen-962: OK, so you want to change the condition for switching to exponential notation? That's fine with me. 11:38 < cwitty-1154> We can do that by changing this conditional: 11:38 < cwitty-1154> (-exponent > digits or exponent > 2*digits) 11:38 < cwitty-1154> For instance, we could use: not (-6 <= exponent <= 6) 11:38 < mhansen-962> I thought that repr(RealNumber(0.00000000000001)) should be 0.00000000000001. 11:39 < mabshoff> cwitty-1154: So I assume I should back out the patch itself. 11:39 < cwitty-1154> I don't think so. It should have significant figures. 11:39 < cwitty-1154> mabshoff, I think so. (The patch just adds an error message that's unlikely to be hit in actual usage, so it doesn't hurt much; but the case it forbids is technically valid.) 11:40 < cwitty-1154> mhansen-962, just like 1.000000000000 should print with zero's after the 1, so should 0.0000000001. 11:41 < mabshoff> ok, will back it the patch out then and make it clear on the ticket that only the spkg went in. 11:41 < mabshoff> Sorry for the snafu. 11:42 < mhansen-962> ciwtty-1154: Okay, well, I thought someone mentioned in a thread that that was not what we wanted. I have no strong feelings on this subject since I never really use it ;-] 11:43 -!- jason-|afk is now known as jason- 11:43 -!- jason- is now known as jason-- 11:44 < jkantor> mabshoff: regarding 1327, I have a new numpy that may fix the problem, of course I couldn't test it 11:45 < jkantor> note you have to insall the numpy package and then scipy 11:46 < was-787> mabshoff -- did you see the linbox-use message just now. 11:47 < was-787> A guy can't build linbox, googles "a lot", and finally finds Clements linbox build/test directory on sage.math, gets files from there, and builds linbox... 11:47 < was-787> with success. 11:48 < mabshoff> Yep 11:48 < mabshoff> Funny, I just looked at the make files and it looks like they should work, 11:48 < mabshoff> but the maple headers probably aren't properly detected. 11:49 -!- roed_ [[email protected]] has joined #sage-devel 11:49 < mabshoff> jkantor: ok, I am about done with alpha1 11:49 < roed_> hello 11:50 < mabshoff> hi roed_ 11:50 < craigcitro-1129> was-787: i have a pari question for you. if it says: "factor: reducible modulus in factornf", that's trying to tell me that somewhere in the process of factoring, it ran into a polynomial as a modulus that wasn't irred, right? 11:50 < mabshoff> I fixed that annoying NTL bug you showed me in Bristol. 11:50 < craigcitro-1129> (it says that they use "trager's trick" which involves changing modulus and factoring over Q) 11:58 < mhansen-962> cwitty-1154: Another version of #962 is up ;-] 11:59 < mabshoff> alpha1 is up: http://sage.math.washington.edu/home/mabshoff/sage-2.8.15.alpha1.tar 11:59 -!- fabio_ [[email protected]] has joined #sage-devel 12:00 < was-787> ok, building now. 12:01 < mabshoff> ok, then I can skip building it on bsd? 12:01 < was-787> yes. 12:01 < mabshoff> I will try on fermat then. 12:02 < was-787> good. 12:02 < mabshoff> Josh said he fixed the cvxopt issue - it failed on my laptop when I tried, but that was an update. 12:02 < mabshoff> So I hope that a fresh build will pass all tests on 10.4 PPC. 12:02 < mabshoff> It has been a while since that worked :( 12:09 < was-787> ok, I have 5 "make check"'s going -- debian32, debian64 (minimal), ubuntu 32-bit; rhel 32-bit; osx 10.4 intel 12:09 < was-787> and osx 10.5 intel (so 6 builds.) 12:10 < mabshoff> Cool, a lot for an alpha1, but I guess we want to release in roughly two days? 12:10 < was-787> It took me 3 minutes to start, so we can just see what happens. Screen makes stuff like this so easy. 12:10 < mabshoff> :) 12:10 < mabshoff> It looks like it will be another stable release - at least so far. 12:10 < mabshoff> I am curious how the ATLAS merge will go. 12:11 < cwitty-1154> mhansen-962: the patch looks good reading it; let me run some tests. 12:13 -!- rlm [[email protected]] has joined #sage-devel 12:13 < jason--> hi robert 12:13 < mabshoff> Hi rlm 12:14 < rlm> hello 12:14 < jason--> rlm: I've been working on the interactive widget stuff. 12:14 < jason--> I have a (very) alpha patch up at http://trac.sagemath.org/sage_trac/ticket/1322 12:16 < rlm> ineresting 12:16 < was-787> rlm -- you may want to email emily about san diego to get her up to speed with what we've planned. 12:17 < mhansen-962> was-787: For the funding page, can I run the server on a high port on sage.math? 12:17 < was-787> mhansen-962: yes, definitely. 12:18 < was-787> I hope you can give a little django tutorial to me too sometime, say at sd7... 12:18 < mhansen-962> Yeah, I can do that. 12:20 < cwitty-1154> was-787: by the way, I ported sage3d to jython last night. 12:20 < was-787> cwitty -- FRICKIN' AWESOME. 12:20 < was-787> Post something somewhere. 12:20 < was-787> I just want to see what the code looks like. 12:20 < was-787> It doesn't have to run or anything. 12:21 < jason--> cwitty: wow, that sounds great! 12:21 < cwitty-1154> was-787: sage.math:/home/cwitty/ObjectViewer*.py 12:21 < cwitty-1154> This is just a straight port of ObjectViewer*.java, from the java3d spkg. 12:25 < was-787> This is *great*. 12:25 < was-787> This really extends the number of people who will be comfortable working on the java3d-based 3d graphics for sage. 12:25 < was-787> Very nice. 12:26 < jkantor> the sage alpha1 just errored out on flint 12:27 < mabshoff> Really? I didn't touch that spkg. 12:27 < mabshoff> Which platform/compiler/etc? 12:27 < mabshoff> We ought to update to 1.0 anyway ... 12:29 < was-787> cwitty-1154: how do you like Jython now that you've tried it out? 12:30 < cwitty-1154> Well, I would probably like it more for doing anything besides a Java applet. 12:30 < cwitty-1154> In a Java applet, most of the interesting (dynamic) features don't work, so it feels more like a crippled Java 12:30 < cwitty-1154> than like Python. 12:31 < jkantor> it was on sage.math 12:31 < mabshoff> jkantor: I see it too, 12:31 < mabshoff> the solution was to make it depend on python. 12:32 < cwitty-1154> But still, there are nice features of Jython. 12:32 < cwitty-1154> Python dictionaries are much nicer to use than Java HashMaps. 12:33 < cwitty-1154> And porting a small amount of Java code to Jython while simultaneously learning Jython, all late at night, is probably not the best way to form an opinion on the language. :) 12:34 < cwitty-1154> Also, it's pretty annoying to debug Jython-in-an-applet. 12:34 < cwitty-1154> The only debugging information I figured out how to get was stack traces. 12:35 < mabshoff> Do we already have a ticket to make FLINT dependent on Python? 12:37 < cwitty-1154> mhansen-962, was-787: I would like to make floating-point printing switch to scientific notation more often (say, whenever abs(exponent)>=6). 12:37 < was-787> ok 12:38 < cwitty-1154> And it seems like it makes sense to make this change along with #962. 12:38 < cwitty-1154> mhansen-962, would you be willing to add that in to your #962 patch, or is that more doctest-fixing than you signed on for? 12:40 < rlm> hmm 12:40 < rlm> was -787 -- i just fixed a small bug in graph_database.py that never would have shown up in the first place if the doctests hadn't been replaced with "..."s 12:41 < cwitty-1154> mhansen-962, the current version of #962 looks good to me; although I hope we can get the scientific notation change in too. 12:41 < mabshoff> jkantor: do you want an updated deps for the FLINT issue? 12:41 < jkantor> yeah 12:42 < mabshoff> hmm, my addition didn't fix it, very odd. 12:43 < was-787> fyi -- all of my 6 builds have got past flint. 12:44 < mabshoff> I was about to ask. I don't understand why this is suddenly an issue. 12:44 -!- fabio_ [[email protected]] has quit ["Konversation terminated!"] 12:44 < mabshoff> There is a python 2.5.1 on sage.math 12:45 < mabshoff> Bill said that the problem no longer exists with 1.0, unless I mixed that up. 12:45 < rlm> was-787 -- was the only reason you replaced those doctests with "..." to make the source more readable? 12:46 < was-787> where? 12:46 < rlm> graph_database.py 12:46 < was-787> oh, in graph theory. 12:46 < jkantor> mabshoff, the cvxopt you have is not the updated one 12:46 < was-787> Yes, it makes it much more readable, and also wastes less space. 12:46 < mabshoff> in alpha1? 12:47 < jkantor> yeah 12:47 < rlm> i just fixed a small bug that never would have shown up in the first place 12:47 < mabshoff> I know that, but p3 didn't work without ATLAS, so I rolled back to p2. 12:47 < jkantor> you should use p4 12:47 < mabshoff> I will update to p4 or whatever is current. 12:47 < mabshoff> :) 12:47 < rlm> doctests != waste of space! 12:47 < jkantor> sorry 12:47 < mabshoff> I figured not too many changes at once ;) 12:48 < jkantor> I know, but I know that p2 won't fix the ppc isse 12:48 < jkantor> issue 12:49 < mabshoff> ok, does p4 do it? 12:49 < jkantor> yes 12:49 < mabshoff> And work without ATLAS on OSX? 12:49 < jkantor> yes 12:49 < mabshoff> ok, I will drop it in before I build on fermat. 12:51 < jkantor> actually, can you also drop in the updated lapack so lapack build is not skipped on OSX 12:51 < mabshoff> ok, but I figured I will wait for that for alpha2. 12:52 < jkantor> ok maybe make all those changes at once and just realize cvxopt will still be broken in alpha1 12:52 < mabshoff> :) 12:52 < mabshoff> That's why it is still called alphaN :) 12:52 < jkantor> i see 12:52 < jkantor> :) 12:53 < rlm> was-787 - I'd like to put some of those doctests back in - I just fixed a bug that those doctests would have discovered 12:53 < was-787> ok. 12:53 < was-787> just don't go overboard. 12:53 < rlm> was-787 maybe at the bottom of the file, so it's still readable? 12:54 < mabshoff> I think we removed them because they made the doctest to time out easily on slower boxen. 12:54 < was-787> Many of the doctests weren't even being doctested before I made those changes. 12:54 < was-787> No, he's talking about OUTPUT. 12:54 < mabshoff> ok, sorry. 12:56 < jkantor> actually never mind cvxopt-0.9.p4 should work without the new lapack, the new lapack only affects osx intel 12:56 < jkantor> building 12:58 < mabshoff> I am curious about what to do about FLINT failing because of python. 12:58 < jkantor> I changed standard/deps and it didn't do anything 12:58 < jkantor> its using the system pthon 12:58 < jkantor> python 12:58 < jkantor> if you start sages python and do import re it fails 12:59 < jkantor> sage.math's python 13:05 -!- jkantor is now known as jkantor_brb 13:05 -!- roed_ [[email protected]] has quit [Read error: 104 (Connection reset by peer)] 13:06 -!- roed_ [[email protected]] has joined #sage-devel 13:10 < was-787> it's snowing! 13:10 < craigcitro-1129> whoa! that's pretty awesome. 13:10 < mhansen-962> We just got about 5 inches here. 13:10 < was-787> wow. 13:11 < mhansen-962> But now it's sleeting. 13:12 < mhansen-962> cwitty-1154: I can add the scientific notation thing if others are fine with that. 13:12 < cwitty-1154> Well, was-787 said "ok"; I'm not sure who else to ask. 13:12 < mhansen-962> That's good enough for me :) 13:12 < cwitty-1154> Switching to scientific notation sooner makes us more like Mathematica and Maple. 13:16 < mhansen-962> New patch for #962 is up. 13:21 < cwitty-1154> mhansen-962, looks like you accidentally deleted an "o" from "nonzero" a couple of versions back. 13:22 < mhansen-962> Fixed. 13:27 < cwitty-1154> Oops... looks like I forgot what exponent meant. How about changing abs(exponent) to abs(exponent-1)? (Sorry...) 13:29 -!- jkantor_brb is now known as jkantor 13:29 < mhansen-962> Done. 13:29 < mhansen-962> I wonder how many doctests this will break ;-] 13:30 < was-787> 1000's 13:30 < cwitty-1154> Actually, I'm just doing doctesting in sage/rings/, and it doesn't look nearly so bad. 13:31 < was-787> every single one of my builds failed because of mpfi, I think. 13:31 < was-787> cd . && autoheader 13:31 < was-787> make[3]: *** [mpfi_config.h.in] Error 127 13:31 < was-787> make[3]: Leaving directory `/home/was/sage-2.8.15.alpha1/spkg/build/mpfi-1.3.4-cvs20071125.p1/src' 13:31 < was-787> There is some autoconf crapiness. 13:31 < mabshoff> That is with cwitty's latest, i.e. the CVS version? 13:31 < was-787> actually, one build where autoheader is installed hasn't stopped yet. 13:32 < was-787> well it is broken and needs to have the autoconf stuff correctly pre-generated. 13:32 < mabshoff> I thought cwitty added "-c" to the flags. 13:34 < cwitty-1154> No; I just copied the files in by hand, instead of symlinking them. (Which should have the same effect.) 13:34 < mabshoff> ok, I think last time I tried that it wasn't a good idea. 13:36 < jason--> quick notebook question: in the worksheet directory (e.g., admin/4), there are directories for cells, code, data, and snapshots. I understand that the cells directory holds the input for the cells that are currently under evaluation. What's the purpose for the code directory? 13:37 < was-787> the code directory "holds the input for the cells that are currently under evaluation." 13:37 < jkantor> mabshoff: did you figure what is up with flint 13:37 < was-787> cells/n/ holds the *output* for cell n. 13:38 < mabshoff> not yet. 13:38 < mabshoff> If I take the system's python and import re it works. 13:38 < jkantor> yea 13:38 < mabshoff> If I take Sage's python and import re it works. 13:38 < jason--> how come the cells/n/ directories are empty, but the code directory contains files even if I am not currently evaluating cells? 13:38 < jkantor> yeah 13:38 < mabshoff> But that was with a clean shell. 13:38 < mabshoff> I didn't try inside FLINT so to speak 13:39 < jason--> (i.e., it appears that the cells/n/ directories are cleared, but the input files in code/ are not cleared) 13:39 < cwitty-1154> was-787, can you post a build log somewhere? (for the autoheader problem) 13:39 < was-787> jason-- : (1) code/... contains files since otherwise foo?? will break. 13:39 < mabshoff> jkantor: I have build from source plenty of time since we updated FLINT, but today is the first time I hit that problem. 13:39 < was-787> cells/n/ directories contain *output* 13:39 < jkantor> weird 13:40 < was-787> there will be nothing there are no images or other files created. 13:40 < mabshoff> Yep. So far I have no idea what goes wrong. 13:40 < mabshoff> But we can deactivate the tuning code in FLINT, it isn't used yetl 13:41 < jason--> ah, I didn't realize cells/n/ directories contained the output *except* for the text sent back to the notebook. Thanks, that helps me a lot. 13:42 < jason--> ls 13:45 < mabshoff> jkantor: I am looking into http://trac.sagemath.org/sage_trac/ticket/1327 13:45 < was-787> jason -- the output text is *never* written to disk. 13:45 < was-787> It's ready magically via a pseudo-tty as it is written out. 13:46 < jason--> okay, that makes sense. 13:47 < cwitty-1154> was-787, did you see my request for a build log? 13:48 < jason--> Is there any way to pause Sage in middle of a computation and have it run another computation? Sort of pre-emptively interrupt Sage and ask a question? 13:49 < was-787> it's /home/was/tmp/install.log 13:49 < jkantor> mabshoff: ok 13:49 < was-787> jason-- certainly not. 13:50 < was-787> how could one possibly even hope to implement something like that? 13:50 < was-787> you could use a separate sage session for that though. 13:50 < jason--> I don't know. It would make things a lot easier, though. I realize it's something of a dream, though. 13:50 < jason--> I want the variables and everything shared, though. 13:50 < was-787> oh. 13:50 < was-787> Then definitely not. 13:51 < was-787> maybe via forking it could be done for some sorts of programs. 13:51 < was-787> But not sage, since Sage is so complicated. 13:52 -!- was-787 [[email protected]] has quit [] 13:52 < rlm> does anyone know why eigenspaces sometimes returns an empty sequence associated to an eigenvalue? 13:53 < jason--> Well, I guess there are complicated systems that do allow interruption, but it would seem particularly hard in Sage since there are so many hter++ 13:53 < jason--> heterogeneous component 13:54 < mhansen-962> The eigenvalue has a trivial eigenspace ;) 13:54 < cwitty-1154> mhansen-962, #962 looks good to me. (And I said so on the ticket.) 13:54 < rlm> so it is not an eigenvalue? 13:54 < mhansen-962> I was just joking around. 13:54 < rlm> me too 13:54 < rlm> i guess that must be what it means though 13:54 < mhansen-962> Heh 13:54 < mhansen-962> Can you give an example? 13:55 < mabshoff> jkantor: The new scipy didn't fix the import issue. 13:55 < rlm> sage: M = random_matrix(CC, 4) 13:55 < rlm> sage: M.eigenspaces() 13:55 < mhansen-962> cwitty-1154: I'll apply it to alpha1 and figure out what doctests need fixing. 13:55 < rlm> i guess a random matrix isn't likely to have many eigenvalues, so... 13:55 < jkantor> you istalled numpy and then scipy 13:56 < mabshoff> numpy was installed, but do I need to update that, too? 13:57 < mabshoff> I guess that was your point. 13:57 < mabshoff> But where is the updated numpy? 13:57 < mhansen-962> Is there a Jordan canonical form method in Sage? 13:57 < jkantor> in the ticket for solaris 13:57 < jkantor> scipy 13:57 < mabshoff> I installed http://sage.math.washington.edu/home/jkantor/spkgs/numpy-20071020-1.0.3.1.p2.spkg 13:58 < jkantor> right, but then you need rebuild scipy 13:58 < rlm> apparently not 13:58 < mabshoff> :) - evetually I will figure that out. 13:58 < mabshoff> numpy & scipy are one ;) 13:58 -!- kedlaya [[email protected]] has joined #sage-devel 13:58 < mhansen-962> Yeah, the eigenspaces seems to need a lot of work. 13:58 < craigcitro-1129> hey kiran 13:58 < mabshoff> It certainly picked gfortran this time, it took much longer to build. 13:58 < mabshoff> Hi 13:59 < kedlaya> hey. i'm just lurking; the Putnam is going on, and I'm working on my usual sols for it 13:59 < rlm> speaking of improving linear algebra, how about implementing the main result of linear algebra? ;) 13:59 < mabshoff> rlm: What would that be? 14:00 < jason--> rlm: I'm curious too. 14:00 < craigcitro-1129> whoa ... i didn't realize the putnam was today. how is it? 14:00 < mabshoff> Because I don't think we will agree on that. 14:00 < rlm> jordan canonical form 14:00 < mabshoff> We don't have jordan canonical forms? 14:00 < rlm> apparently not 14:00 < mhansen-962> :) 14:00 < mabshoff> I tend to agree that JNF would be "it" 14:00 < rlm> sage: search_src('Jordan') 14:00 < rlm> ---------------------------------------------------------------------- 14:00 < rlm> | SAGE Version 2.8.14, Release Date: 2007-11-24 | 14:00 < rlm> | Type notebook() for the GUI, and license() for information. | 14:00 < rlm> ---------------------------------------------------------------------- 14:00 < rlm> quadratic_forms/genera/genus.py: # Construct the blocks for the Jordan decomposition [F,X;X,A_new] 14:00 < rlm> quadratic_forms/genera/genus.py: symbol -- the list of invariants for Jordan blocks A_t,...,A_t 14:01 < rlm> quadratic_forms/genera/genus.py: of the Jordan blocks A_1,...,A_t. 14:01 < rlm> making a ticket... 14:01 < rlm> nevermind 14:01 < mabshoff> :) 14:01 < rlm> #874 14:01 < rlm> very old ticket 14:02 < mabshoff> Jep, I am surprised nobody complained until now. 14:02 < jason--> well, good thing today is fix-the-tickets-day 14:02 < rlm> technically, a new feature isn't a bug, but... 14:02 < mabshoff> Oh, a volunteer ;) 14:02 < jason--> well, missing *the* result of linear algebra, I'd consider that a bug. 14:03 < rlm> i disagree, but there's no point arguing semantics 14:03 < mabshoff> I guess if one wanted to teach linear algebra with Sage the people would have to write their own implementation anyway. 14:03 < jason--> you've got a good point too. 14:04 < rlm> if someone were teaching linear algebra with sage right now, they could assign this ticket as homework....... 14:04 < rlm> wouldn't that be nice for us 14:04 < jason--> I'll be teaching next semester... 14:04 < rlm> I'm very happy about this- UW arts & sciences is hiring me as a "sage ta" next quarter 14:05 < jason--> If it's not done by next april, I may have a class competition 14:05 < mhansen-962> Does someone with a university internet connection want to get this for me: http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6WM7-45M2XHC-M&_user=10&_coverDate=09%2F30%2F1997&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=751b55e81560d2929d5900ba589224e6 14:06 < jason--> grr, there goes my homework assignment ;) 14:06 < craigcitro-1129> i've got it for you mike -- emailing right now 14:07 < mhansen-962> It's annoying how all those site stop working on a regular connection. 14:07 < craigcitro-1129> yeah ... i've got things set to work over a proxy on my laptop, which is wildly helpful. sometimes ucla doesn't have the right subscriptions, though -- which is when it pays to have friends at harv & mit. ;) 14:08 < roed_> :-) 14:08 < rlm> ok, so which package sage includes is most likely to do rational and jordan form? 14:09 < jason--> gap? 14:11 < mabshoff> jkantor: It looks like scipy prefers Sun's F77 compiler on Solaris if it finds it: 14:11 < mabshoff> sage_fortran:f77: scipy/optimize/minpack2/dcsrch.f 14:11 < mabshoff> Which would explain why those F77 symbols are missing ;) 14:13 < jkantor> did it get to the end 14:13 < mabshoff> Not yet, still building. 14:13 < jkantor> ok 14:14 < mabshoff> Ok, it finished building and not complains about a missing cvxopt.so which isn't 14:14 < mabshoff> there due to missing complex.h. 14:15 -!- jason-- is now known as jason--|afk 14:15 < jkantor> cvxopt complains 14:16 < mabshoff> Yep. But Solaris 10 has a complex.h, not sure if it will work. 14:16 < mabshoff> Giving it a shot anyway. 14:18 < mabshoff> Nope doesn't work as planned. We need a compiler provided _Imaginary_I 14:20 < jkantor> did the scipy not work either 14:20 < mabshoff> Scipy compiled and the import of scipy works, i.e. umfpack. 14:20 < mabshoff> But since there is no cvxopt.so the test still failed. 14:21 < jkantor> right 14:21 < jkantor> but the scipy tests work? 14:21 < mabshoff> I only ran the doctest, I can import scipy manually - one sec. 14:21 < mabshoff> import scipy works ;) 14:22 < jkantor> how about 14:22 < mabshoff> One more annoying Solaris bug squashed 14:22 < jkantor> from scipy import optimize 14:22 < mabshoff> works ;) 14:22 < jkantor> sweet 14:23 < mabshoff> I am merging the updated numpy.spkg now into alpha2. 14:23 < mabshoff> I have seen cvxopt binary builds for Solaris, so it must be possible, 14:23 < jkantor> its just complex.h, that its upset with 14:24 < mabshoff> I could try in Solaris 10, but I don't want to try that before updating FLINT and fixing fplll 14:24 -!- was_ [[email protected]] has joined #sage-devel 14:24 < mabshoff> Well, it is the first issue that pops up, never got further. 14:24 < jkantor> ok 14:24 < mabshoff> Where is the latest scipy? 14:24 < mabshoff> I mean: which ticket? 14:25 < jkantor> no new scipy 14:25 < jkantor> it was just numpy 14:25 < jkantor> that fixed scipy 14:25 < mabshoff> ok. Also the ATLAS issue? 14:25 < jkantor> that was only for numpy 14:26 < mabshoff> ok, but then we need to force a rebuild of scipy anyway. 14:26 < jkantor> for an upgrade yes 14:26 < mabshoff> Yes, but people will do that an fail. 14:27 < jkantor> right 14:28 < was_> ok, I'm back at home... 14:28 < mabshoff> :) 14:28 < mabshoff> Any news on http://trac.sagemath.org/sage_trac/ticket/787? 14:28 < was_> Yes, I'm still working on it. That complicated line from Nils turned out to even be theoretically wrong. 14:28 < was_> I'm not creating a new algorithm 14:28 < was_> which is of course much simpler. 14:28 < was_> I hope. 14:28 < mabshoff> At least nor tonight ;) 14:28 < was_> pain in the butt. 14:29 < cwitty-1154> "not" -> "now"? 14:29 < was_> I mean "now" 14:29 < was_> Yes, now. 14:29 < mabshoff> That does make sense. 14:29 < mabshoff> It looks like one issue in libSingular is causing about 100 doctests on Solaris to fail. 14:29 < mabshoff> So if that is fixed we are getting very, very close 14:30 < mabshoff> I just committed the int64 build fix so that modp works properly. 14:32 < mabshoff> Who did package FLINT last time? 14:32 < mabshoff> I only ever updated. But I want to go up to 1.0 to fix a whole bunch of issues. 14:36 < cwitty-1154> OK, I've got a new MPFI spkg. 14:36 < cwitty-1154> sage.math:/home/cwitty/mpfi-1.3.4-cvs20071125.p2.spkg 14:36 < mabshoff> What did you do differently? "-c" 14:36 < cwitty-1154> It no longer runs autoheader during the build, on my laptop; so I think at least that problem is fixed. 14:36 < mabshoff> ok 14:37 < cwitty-1154> No. I just did "touch src/mpfi_config.h.in". 14:37 < jkantor> mabshoff: for atlas you need lapack-20071123, atlas-3.8.p2, cvxopt-0.9.p4, and numpy-20071020-1.0.3.1.p2 14:37 < mabshoff> ok, I got cvxopt.p2, the numpy.p2. 14:37 < jkantor> cvxopt.p4? 14:38 < mabshoff> The p4 you mentioned above. 14:38 < jkantor> yeah 14:39 < mabshoff> So except for Lapack we are nearly ready to drop in ATLAS. 14:39 < jkantor> what about lapack isn't ready 14:39 < mabshoff> cwitty: the new mpfi.p2 is in. 14:40 < mabshoff> Oh, I just haven't tried Lapack yet. 14:40 < jkantor> it just removes the if [uname = 'Darwin' 14:40 < jkantor> ] 14:40 < was_> where is the new mpfi that you made? I can test it. 14:40 < jkantor> so lapack is built on OSX 14:40 < cwitty-1154> sage.math:/home/cwitty/mpfi*.p2.spkg 14:40 < mabshoff> I just figured to do an incremental process instead of dumping it all in. 14:40 < jkantor> intel 14:40 < jkantor> makes sense 14:41 < mabshoff> Yep, I have been burned too many times. 14:41 < mabshoff> Something is fishy with libcsage on OSX: 14:41 < mabshoff> usr/bin/ld: warning can't open dynamic library: libpari-gmp.dylib referenced from: /Users/mabshoff/sage-2.8.15.alpha1/local//lib/libcsage.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) 14:41 < jkantor> on osx the atlas won't really be used yet 14:42 < mabshoff> Do we even build it or do we skip right over it? 14:42 < jkantor> we build it, but I could change that 14:42 < jkantor> or you could, its your call 14:42 < mabshoff> Ok, let's build it as long as we don't do the final release. 14:42 < mabshoff> That way we flush out build issues now and not when we release a final build which uses ATLAS. 14:43 < jkantor> ok 14:43 < mabshoff> Does anybody know which timezone Bill Hart is is at the moment? GMT? 14:43 < mabshoff> If so he gets up very early ;) 14:43 < was_> england. 14:43 < mabshoff> ok 14:44 < mabshoff> ok, back in 20 14:44 -!- mabshoff is now known as mabshoff|afk 14:44 < mabshoff|afk> I hope somebody will be bored and do patch review ... 14:44 < was_> the new mpfi package works. 14:45 < cwitty-1154> Cool, thanks for testing. 14:53 -!- kedlaya [[email protected]] has quit ["Leaving."] 14:56 < rlm> #1353 should be effortless to review 14:59 < cwitty-1154> OK, I'll look at #1353. 14:59 < was_> `I'm enjoying not doing patch reviews -- this is my first bug day to just fix bugs :-) 15:00 < mabshoff|afk> :) 15:01 < mabshoff|afk> It would be excellent if somebody reviewed http://trac.sagemath.org/sage_trac/ticket/1211 15:01 < mabshoff|afk> After all: It is critical. 15:01 < cwitty-1154> I'll look at it next. 15:02 < mabshoff|afk> http://trac.sagemath.org/sage_trac/ticket/1292 looks like you got some feedback - reading the comments now. 15:03 < rlm> I'm looking at #1258 15:03 < mabshoff|afk> 1287, 1290 and 1239 also seem worthwhile. 15:05 < mabshoff|afk> Ok, I will work on my 1184 ticket for a while. 15:09 < cwitty-1154> mabshoff|afk, #1353 is good. 15:18 < rlm> #1258 is NOT ready 15:20 < rlm> should i move it to sage-2.9? 15:20 < mabshoff|afk> rlm: Leave it there for now, maybe it will get sorted out. 15:21 < mabshoff|afk> Once we close 2.8.15 all the open tickets will get moved to another milestone. 15:21 < mabshoff|afk> And since there are 80+ open a lot of them won't be closed. 15:22 < rlm> ok 15:22 < mabshoff|afk> We might want to create a "negative review milestone" in the future. 15:22 < rlm> that's a really good idea 15:23 < mabshoff|afk> It depends on how much reaction is going to come and if all those tickets improve .. 15:23 < rlm> well, at least it makes the current milestone less cluttered 15:23 < mabshoff|afk> If trac notifiction worked we would also probably get better feeback from people who don't follow rack every day. 15:23 < mabshoff|afk> I will list the tickets with bad reviews in the next alpha 15:24 < rlm> and then if someone wants to resubmit, they can move it back to the current milestone for review 15:24 < mabshoff|afk> Sure 15:24 < rlm> i can't wait for rwb's patch for hg comprehension 15:24 < mhansen-962> Did we figure out the mpfi compile error? 15:25 < cwitty-1154> mhansen-962: yes, I have an updated spkg in my home directory on sage.math. 15:25 < mhansen-962> Okay, thanks. 15:29 < craigcitro-1129> so i fixed 1129, but i think there's a bug in pari still 15:29 < craigcitro-1129> alex ghitza mentioned it in the trac ticket too; can someone who knows pari (i.e. was_ or wstein) glance at that and tell me i'm not missing something obvious? 15:30 < mabshoff|afk> http://trac.sagemath.org/sage_trac/ticket/1353 is merged 15:31 < craigcitro-1129> also, if someone wants to comment on 1129, please do 15:31 < craigcitro-1129> it should work just fine now 15:32 < cwitty-1154> mabshoff|afk, #1211 is good 15:33 -!- cwitty-1154 is now known as cwitty-1162 15:36 -!- craigcitro-1129 is now known as craigcitro-1231 15:38 < mabshoff|afk> ok, cwitty-1154: will merge 1211 15:38 -!- mabshoff|afk is now known as mabshoff 15:42 < rlm> cyu later everyone 15:42 < cwitty-1162> bye, rlm 15:42 < craigcitro-1231> lates robert 15:43 < mabshoff> cu 15:43 -!- rlm [[email protected]] has left #sage-devel [] 15:47 -!- zachi_ [[email protected]] has quit ["Leaving"] 16:03 < cwitty-1162> I will review 1129 now. 16:03 < mabshoff> Excellent. 16:03 < cwitty-1162> I've posted a new patch for #1162, if anybody wants to review it. 16:04 < craigcitro-1231> cool ... thanks cwitty-1162 16:05 < mabshoff> was_ - still around? 16:05 < was_> yes. 16:05 < mabshoff> Do you have a test log from bsd? 16:05 < was_> maybe almost done with #787. 16:06 < mabshoff> Justin reported some mwrank crashes - if you have a log I will take a look. 16:06 < mabshoff> Cool 16:06 < was_> ok, put it at /home/was/tmp/test.log 16:07 < mabshoff> ok, your log is fine. At least non of the errors are there. 16:08 < mabshoff> Maybe his RAM/hardware is wonky. 16:08 < was_> probably. 16:09 < mabshoff> Yep, we didn't touch mwrank in ages. 16:10 -!- jkantor is now known as jkantor_brb 16:10 < cwitty-1162> craigcitro-1231: nfinit() is potentially a very slow operation; if we can't figure out a way to avoid calling it, we should at least cache the result. 16:10 < craigcitro-1231> oh, that's a good point 16:11 < craigcitro-1231> yeah, doing F._pari_() caches that 16:11 < craigcitro-1231> but the problem is that we need to switch the variable here and tehre 16:11 < craigcitro-1231> there 16:11 < craigcitro-1231> lemme look at how to make that faster. 16:13 < craigcitro-1231> (though, to be fair, it's likely that the nfinit was getting done before anyway) 16:13 < craigcitro-1231> (since it was factoring it in the number field in pari) 16:13 < mabshoff> 1211 is merged 16:15 < cwitty-1162> I think factornf probably doesn't call nfinit(). (At least, by my understanding of the algorithm, there would be no reason to.) 16:19 < craigcitro-1231> you're right, that's quite possible 16:19 -!- jkantor_brb is now known as jkantor 16:19 < craigcitro-1231> did you try out the pari question i had at the bottom? 16:20 < craigcitro-1231> was_ or wstein: do you know an easy way to change the variable used in a pari nf? 16:20 < was_> no. 16:21 < cwitty-1162> Craig, when I try the example from your last comment, I get a different result: 16:21 < cwitty-1162> ? factor(f) 16:21 < cwitty-1162> *** factor: bug in GP (Segmentation Fault), please report 16:21 < craigcitro-1231> interesting 16:21 < craigcitro-1231> are you running pari directly? or did you do sage -gp ? 16:21 < craigcitro-1231> because i just copy-pasted that from my sage -gp session 16:21 < cwitty-1162> That was "sage -gp". 16:21 < craigcitro-1231> hmm 16:21 < craigcitro-1231> that's pretty odd. 16:22 < cwitty-1162> Was that your whole session? (Did you type anything before the "f=" line?) 16:23 < craigcitro-1231> no, that's the entire session. i just checked again, and got the same result. 16:23 < cwitty-1162> I'm on 32-bit x86 Linux (Debian testing). How about you? 16:23 < craigcitro-1231> 32-bit PPC OSX. 16:23 < craigcitro-1231> well, it's definitely the case that *both* are bad. 16:23 < craigcitro-1231> right? 16:24 < cwitty-1162> With the Sage in /usr/local on sage.math, I get the same result as you. 16:24 < cwitty-1162> Yes, I think so. 16:25 < cwitty-1162> With the Debian gp binary in /usr/bin on my laptop, I get the segmentation fault again. 16:25 -!- roed_ [[email protected]] has quit [Read error: 104 (Connection reset by peer)] 16:25 < cwitty-1162> Let me paste a session as a comment on the ticket. 16:25 -!- roed_ [[email protected]] has joined #sage-devel 16:26 < craigcitro-1231> cool 16:27 < craigcitro-1231> this is weird ... if you make the degree any smaller, it starts working. 16:27 < craigcitro-1231> or, more to the point, it's very specific to that polynomial 16:31 < craigcitro-1231> in fact, i can't find another polynomial that fails! 16:32 < craigcitro-1231> (well, except a multiple of that one.) 16:35 < cwitty-1162> Multiplying by a scalar, or a polynomial? 16:35 < craigcitro-1231> scalar 16:35 < craigcitro-1231> i hadn't tried by a polynomial 16:36 < craigcitro-1231> but multiplying by a poly kills it, too 16:38 < craigcitro-1231> cwitty-1162: have you used number fields in pari much? 16:38 < craigcitro-1231> do you know if i can just manually edit the vector nfinit returns and still have a legal number field? 16:39 < cwitty-1162> I think that's very likely to work. 16:41 -!- rlm [[email protected]] has joined #sage-devel 16:43 < was_> craig -- yes. 16:43 -!- was_ is now known as was-787 16:44 < craigcitro-1231> cool. a more basic pari question: is there an easy way to switch the variable name in a polynomial, or get the list of coefficients? 16:44 < craigcitro-1231> (i'm assuming the answer has to be yes to the last of those, i just don't know it.) 16:46 -!- rlm is now known as rlm-1137 16:46 < craigcitro-1231> nevermind, i can just do it in sage 16:47 < was-787> #787 -- done and posted! 16:47 < mabshoff> So, anybody want to review this ;) 16:47 < mabshoff> I guess craigcitro-1231 would be the perfect candidate 16:47 -!- mabshoff is now known as mabshoff-1184 16:48 < craigcitro-1231> for which? 787? 16:48 < mabshoff-1184> Yep. 16:48 < was-787> Look at this -- http://trac.sagemath.org/sage_trac/attachment/ticket/787/trac787.patch 16:48 < was-787> It implements V/W where V and W are vector space. 16:48 < craigcitro-1231> lemme get 1129 re-cleaned up first (i.e. fix this nfinit issue), and then i'm on it 16:49 -!- was-787 is now known as was-1342 16:49 < was-1342> I'm going to look into #1342 now. 16:50 < mabshoff-1184> The current alpha build: 16:50 < mabshoff-1184> Overall weighted coverage score: 34.5% 16:50 < mabshoff-1184> Total number of functions: 17697 16:50 < was-1342> we really really need a doc day. 16:50 < mabshoff-1184> 200 more functions, 0.1% better coverage. 16:50 < mabshoff-1184> Compared to 2.8.13 that is. 16:51 < mabshoff-1184> Yes, we do. 16:51 < mabshoff-1184> Hej, only another 140 releases at the current pace to get to 40% 16:52 < mabshoff-1184> ehh, 50% 16:55 < mabshoff-1184> Just got a bunch of numerical noise doctest failures on fermat in sage/rings/polynomial/complex_roots.py 16:55 < mabshoff-1184> and sage/rings/polynomial/polynomial_element.pyx 16:56 < mabshoff-1184> I guess I can fix those ;) 16:56 < cwitty-1162> What OS/processor is fermat? 16:56 < mabshoff-1184> It is an XServer, so my guess is G4 with OSX 10.4.11 16:57 < mabshoff-1184> It is only the last two digits in a couple of places. 16:57 < mabshoff-1184> 0.18123244446987518 vs. 0.18123244446987521 for example. 16:58 < rlm-1137> is there a global precision option in sage? 16:58 < mabshoff-1184> I have seen doctests that would fail due to numerical noise on Ultra Sparc 3, but not Ultra Sparc 4 16:58 < mabshoff-1184> Not that I know. bober wrote some FPU fiddeling code. 16:58 < mabshoff-1184> re Sparc: But also the other way around, i.e. different tests would fail. 16:58 < rlm-1137> it seems hard to implement 16:59 < cwitty-1162> You mean "do everything at higher precision"? 16:59 < rlm-1137> cwitty-1162 -- no, like my e-mail to you this morning 16:59 < mabshoff-1184> Well, it is compiler dependent, i.e. change to another compiler release and the results can change 16:59 < rlm-1137> i.e. i only want to see a few digits 16:59 < mabshoff-1184> due to optimization and so on. 17:00 < rlm-1137> then doctests could do the answer up to some precision that would be stable 17:00 < mabshoff-1184> Well, we add "..." for the unstable digits for now. 17:01 < rlm-1137> oh of course 17:01 < mabshoff-1184> If we were to use the mpfr anywhere in that are Paul would be very unhappy. 17:01 < mabshoff-1184> are->area 17:03 < cwitty-1162> rlm-1137, I just read your e-mail. 17:03 < cwitty-1162> It would be an easy thing to add, but there should be some discussion first. 17:04 < cwitty-1162> The fear is that when you add global settings like that, it makes it harder to reproduce bugs, etc. 17:04 < rlm-1137> even a local option would be nice 17:04 < rlm-1137> and i'm only requesting it for display 17:05 < cwitty-1162> Well, for a quick hack, you can always just change this: 17:06 < cwitty-1162> repr(CIF(self._value)) 17:06 < cwitty-1162> change CIF to ComplexIntervalField(15), for instance. 17:06 < cwitty-1162> (Or ComplexField(15), if you don't want to see the intervals.) 17:06 < rlm-1137> oh ok 17:06 < rlm-1137> that's easy 17:07 < cwitty-1162> Actually, if you don't want to see intervals, you probably need something like: 17:07 < cwitty-1162> ComplexField(15)(self._value.center()) 17:16 -!- was-1342 is now known as was-afk-eating 17:25 -!- cwitty-1162 is now known as cwitty 17:27 -!- cwitty is now known as cwitty-1357 17:33 < jkantor> mabshoff: regarding making shared libraries on OSX, I spent some more time trying to make the libf77blas 17:33 < mabshoff-1184> And? 17:33 < jkantor> but I'm stuck with the same linker erroros 17:34 < jkantor> Probably someone who actually understands whats going on on OSX should look at it 17:34 < mabshoff-1184> :) 17:34 < mabshoff-1184> I should be done with 1184 and 1355 in a couple minutes. 17:34 < mabshoff-1184> Once 787 is reviewed I will merge that and push out alpha2 17:34 < mabshoff-1184> Then the interesting stuff like ATLAS, Singular and PolyBori should happen in the next 24 hours. 17:35 < jkantor> ok 17:35 < mabshoff-1184> At least that is the plan, but "tomorrow ATLAS" has been the plan for 5 days now :( 17:35 < jkantor> :) 17:35 < craigcitro-1231> ok, i'm afk for two hours 17:35 < mabshoff-1184> At least we got a bunch of merges done and a resonable stable alpha2, I didn't believe it would happen after alpha0 17:39 < mabshoff-1184> ok, 1355 done. 17:39 < mabshoff-1184> Arrg, Craig is gone for two hours. 17:47 -!- robertwb [[email protected]] has joined #sage-devel 17:47 < roed_> hey Robert 17:47 < robertwb> hi 17:47 < roed_> Have you been working at all on the coercion project? 17:47 < mabshoff-1184> hi robertwb 17:47 < robertwb> I haven't done much since about a week ago, what about you? 17:48 < roed_> no, I've been working on padics 17:50 < cwitty-1357> robertwb, I just looked at your latest comment on #1275. The answer is yes, you get an exact result of 5/4. 17:50 < robertwb> Good. Why isn't it able to resolve it the other way? 17:51 < cwitty-1357> It just doesn't try to do the exact computation. 17:52 < cwitty-1357> (I could change sqrt() to notice rational arguments, and immediately create a quadratic number field; but I didn't write that code.) 17:52 < cwitty-1357> Of course, either way, if it decides it actually needs an exact result, it will get it. 17:53 < cwitty-1357> The practical difference is mostly in the printing. (There's probably a speed difference too, but I honestly don't know which way is faster.) 17:54 < robertwb> It would be nice if the sqrt/pow noticed a rational argument, how hard would that be? 17:54 < robertwb> I just thought on that patch having to import a special function just for that case seemed kind of odd... 17:54 < cwitty-1357> Not hard. 17:55 < robertwb> (And then the code could work for something like K = NumberField(x^2-5, 'a'). golden_ratio._algebraic_(K) ) 17:56 < rlm-1137> robertwb -- 17:56 < rlm-1137> i'm looking at a strange problem with visualize_structure 17:57 < robertwb> yeah? 17:58 < rlm-1137> can you imagine a situation where you use val = colorExact((v,v,v)) for a color, and it comes out magenta? 17:58 < robertwb> I don't know what the colorExact function is, but magenta is FFFF00 17:59 < rlm-1137> i'm looking at matrix2.pyx, around l.2890 or so 17:59 < rlm-1137> it looks like you modified this function to fit several matrix entries into a single pixel 18:00 < cwitty-1357> robertwb, when you're done with rlm... I didn't understand your last suggestion. 18:01 < robertwb> The modification I did was to get cython to compile (explicitly casting the double to an int), I didn't write that bit of code myself 18:01 < rlm-1137> oh ok 18:01 < rlm-1137> do you know anything about gd? 18:01 < robertwb> cwitty - I meant for sqrt or pow, it could create a number field x^n - a and return a generator 18:02 < robertwb> No, I don't know much about GD. Getting magenta could be a result of wrapping around or something though. 18:02 < rlm-1137> that's my guess 18:04 < mhansen-962> I get a weird number field error after #962. 18:04 < robertwb> oh, not I understand your question. colorExact((v,v,v)) should always return a shade of grey I think. Have you tried printing out the values for v? 18:04 < rlm-1137> yeah : 254 18:05 < rlm-1137> so wraparound seems likely, maybe, since they're high 18:05 < mhansen-962> File "number_field.py", line 3770: 18:05 < mhansen-962> sage: f = K.embeddings(ComplexField(58)); f 18:05 < mhansen-962> Expected: 18:05 < mhansen-962> [Relative number field morphism: 18:05 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its base field 18:05 < mhansen-962> To: Complex Field with 58 bits of precision 18:05 < mhansen-962> Defn: a |--> -0.62996052494743676 - 1.0911236359717214*I 18:05 < mhansen-962> b |--> -0.00000000000000019428902930940239 + 1.0000000000000000*I, 18:05 < mhansen-962> ... 18:05 < mhansen-962> To: Complex Field with 58 bits of precision 18:05 < mhansen-962> Defn: a |--> 1.2599210498948731 18:05 < mhansen-962> b |--> -0.99999999999999999*I] 18:05 < mhansen-962> Got: 18:05 < mhansen-962> [Relative number field morphism: 18:05 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its base field 18:05 < mhansen-962> To: Complex Field with 58 bits of precision 18:05 < mhansen-962> Defn: a |--> -0.62996052494743676 - 1.0911236359717214*I 18:05 < mhansen-962> b |--> -1.9428902930940239e-16 + 1.0000000000000000*I, Relative number field morphism: 18:05 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its base field 18:05 < mhansen-962> To: Complex Field with 58 bits of precision 18:05 < mhansen-962> Defn: a |--> -0.62996052494743657 - 1.0911236359717214*I 18:05 < mhansen-962> b |--> -1.0000000000000000*I, Relative number field morphism: 18:05 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its base field 18:05 < mhansen-962> To: Complex Field with 58 bits of precision 18:05 < mhansen-962> Defn: a |--> -0.62996052494743657 + 1.0911236359717214*I 18:05 < mhansen-962> b |--> 1.0000000000000000*I, Relative number field morphism: 18:05 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its base field 18:05 < mhansen-962> To: Complex Field with 58 bits of precision 18:05 < mhansen-962> Defn: a |--> -0.62996052494743676 + 1.0911236359717214*I 18:06 < mhansen-962> b |--> -1.9428902930940239e-16 - 1.0000000000000000*I, Relative number field morphism: 18:06 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its base field 18:06 < mhansen-962> To: Complex Field with 58 bits of precision 18:06 < mhansen-962> Defn: a |--> 1.2599210498948731 18:06 < mhansen-962> b |--> 0.99999999999999999*I, Relative number field morphism: 18:06 < mhansen-962> From: Number Field in a with defining polynomial x^3 - 2 over its 18:06 < robertwb> rlm -- what exactly is the error? The whole thing magenta? 18:07 < mhansen-962> Never midn, I missed the ... in there. 18:08 < mabshoff-1184> you mean the precison issue? 18:08 < mabshoff-1184> 0.0000000000xx->xxe-16? 18:09 < robertwb> looking at the docstring for colorExact((r,g,b)) 18:09 < robertwb> return an exact color index match for (r,g,b) (returns -1 if unable to) 18:09 < robertwb> Is the returned value -1? 18:10 < rlm-1137> where are you getting colorExact? 18:10 < robertwb> http://newcenturycomputers.net/projects/gd-ref.html 18:10 < rlm-1137> there it is! 18:10 < rlm-1137> thanks 18:11 < robertwb> thank google :) 18:11 < cwitty-1357> robertwb, I ported sage3d.jar to Jython last night. 18:11 < rlm-1137> i kept running into the C project 18:12 < robertwb> well...it is a c project. We just use a python wrapper 18:13 < rlm-1137> got it! 18:14 < mhansen-962> cwitty-1357: I added a patch for #962 fixing all the doctest failures. 18:14 < robertwb> we're creating a truecolor image, so colorExact((v,v,v)) should always succede 18:15 < mabshoff-1184> mhansen-962: 27kb, that wasn't too bad. 18:15 < mhansen-962> It was much easier than I thought. 18:16 < mabshoff-1184> Yep, that is also my impression. 18:17 -!- rlm-1137 is now known as rlm 18:17 < rlm> #1137 is ready for review 18:18 < cwitty-1357> mhansen-962, I don't understand why the numbers that start "0." got one digit shorter. 18:19 < robertwb> I'll look at #1137 now 18:20 < mabshoff-1184> robertwb: have you seen the new comment on http://trac.sagemath.org/sage_trac/ticket/1325. 18:20 < robertwb> yes, I was thinking about starting to work on that one 18:20 < mabshoff-1184> Well, thanks. 18:21 < mabshoff-1184> It would also suffice to tell me that it is all malb's fault. 18:21 < rlm> #1137 was his too:-) 18:21 < mabshoff-1184> There is at least another issue in libSingular that manifests itself on Solaris. 18:21 < mabshoff-1184> :) 18:21 < mabshoff-1184> He went home over the weekend. 18:22 < robertwb> OK, I cant get #1137 to work, but I think it's a gd issue. 18:22 < mabshoff-1184> cwitty-1137: I discovered another relocaiton issue on OSX - see http://trac.sagemath.org/sage_trac/ticket/1358 18:22 < mabshoff-1184> It should be fairly easy to fix. 18:23 < robertwb> BTW, #1325 is on solaris only? 18:23 < mhansen-962> cwitty-1357: I'll look into that. 18:23 < mabshoff-1184> Yep, at least it crashes there. 18:24 < mabshoff-1184> I thought of compiling with "-O2" or even "-O0" to see if the problem goes away if nothing obvious happens. 18:24 < robertwb> works fine on my computer, and I don't have a solaris account to test it on. 18:24 < mabshoff-1184> :) 18:25 < cwitty-1357> mhansen-962, before your patch, those numbers somehow ended up being 56-bit precision. 18:25 < mabshoff-1184> I will valgrind it on PPC Linux to see if there is an endianess issue. 18:25 < mabshoff-1184> symmetrica also has issues on PPC linux and Sparc/Solaris 18:25 < mhansen-962> They should only be 53-bit, right? 18:25 < cwitty-1357> I'd think so. That's the default. 18:25 < cwitty-1357> Before your patch: 18:25 < cwitty-1357> sage: asin(1+I*1.0).real()._obj.prec() 18:25 < cwitty-1357> 56 18:25 < cwitty-1357> sage: asin(1+I*1.0).imag()._obj.prec() 18:25 < cwitty-1357> 56 18:25 < cwitty-1357> After your patch: 18:25 < mabshoff-1184> robertwb: Do you see anything obvious that might be wrong? 18:26 < cwitty-1357> sage: asin(1+I*1.0).real()._obj.prec() 18:26 < cwitty-1357> 54 18:26 < cwitty-1357> sage: asin(1+I*1.0).imag()._obj.prec() 18:26 < cwitty-1357> 57 18:26 < mabshoff-1184> If it isn't coercion it could still be libSingular. 18:26 < robertwb> I suspect libSingular 18:26 < mabshoff-1184> And in that case malb is much more qualified. 18:26 < mabshoff-1184> :) 18:26 < mabshoff-1184> blame malb I guess. 18:26 < robertwb> he's not here :) 18:26 < rlm> mabshoff-1184: is #1179 as easy as it sounds? 18:27 < mabshoff-1184> I initially thought that there were issues in coercion, too, but I was suprised that it immdetiately pointed to libSingular. 18:27 < mabshoff-1184> The bt is nearly identical. 18:27 < mhansen-962> cwitty-1357: So, it looks like it's an issue with reading in a string? 18:27 < robertwb> I'm going to look at it a bit more, but very little coercion stuff is platform dependant 18:27 < mabshoff-1184> rlm: Not sure if we are going to do it, but it is trivial. 18:27 < cwitty-1357> mhansen, yes. It's reading the output of maxima: 18:27 < cwitty-1357> sage: maxima(asin(1+I*1.0)) 18:27 < cwitty-1357> 1.061275061905036*%i+.6662394324925153 18:27 < mabshoff-1184> On Solaris you really have the original "sh", it causes problems all over the map. 18:28 < mabshoff-1184> So William replaced sh with bash on neron, but on other systems people don't generally do that. 18:28 < mabshoff-1184> So: since we already require bash we might as well change all the scripts. 18:28 < mabshoff-1184> Klas from some university in Sweden reported the issue to me, so I figured it is worth fixing. 18:29 < mabshoff-1184> Please post a patch, I hope was can be convinced to apply it. 18:29 < rlm> ok 18:29 < cwitty-1357> And really, the current behavior is fine with me. (I was worried when I thought it was all "0." numbers, but if it's only numbers that we read from maxima, then it doesn't affect me, at least :) 18:29 < mabshoff-1184> thanks. 18:29 < mabshoff-1184> didn't somebody just review a ticket? 18:30 < mhansen-962> cwitty-1357: I'm fine with how it is now too ;-] If someone complains, then we can change it. 18:30 < robertwb> BTW, about sage: asin(1+I*1.0).real()._obj.prec() == 56 18:30 < robertwb> There it a ticket http://sagetrac.org/sage_trac/ticket/1286 18:31 < robertwb> (Not the same issue issue, but relevant) 18:33 < cwitty-1357> I agree with Paul's comment on #1286: we shouldn't be doing this automatic precision extension at all. But I already fought and lost that battle, so oh well. 18:33 < mhansen-962> Actually, #1286 on alpah1 + #962 18:34 < mhansen-962> err, #1286 works is what I meant 18:34 < mabshoff-1184> Because of your fixes to the calculus code? 18:35 < mhansen-962> I'm not quite sure ;-] 18:35 < mabshoff-1184> Well, it works for me, too. 18:35 < mabshoff-1184> So, you can have the honors :) 18:35 < mabshoff-1184> Instead if creating odd issues we get them fixed. 18:36 < mhansen-962> Do you want me to close it? 18:36 < mabshoff-1184> It might be that William's sqrt(n) patch fixed that by avoiding maxime altogether. 18:36 < mabshoff-1184> Sure, go ahead. 18:36 < mabshoff-1184> We are really making progress today. 18:38 < mhansen-962> I can fix the documentation issues after I eat. I'm having low-hanging fruit for dinner ;-) 18:39 < mabshoff-1184> hehe 18:39 < mabshoff-1184> I might have another 2, 3 hours in me. 18:39 < mabshoff-1184> Maybe 5 if I drink enough tea. 18:40 < mabshoff-1184> I wont to get very close to a release. 18:40 < mabshoff-1184> So if we wait for PolyBoRi and the new Singular the release will be a couple days out. 18:40 < mabshoff-1184> Otherwise we do one tomorrow :) 18:42 < cwitty-1357> OK, I reviewed #962: looks great! 18:42 < mhansen-962> Finally :) 18:43 < mabshoff-1184> w00t 18:45 < mabshoff-1184> So: merge it? 18:45 < mabshoff-1184> I didn't pay much attention during that part of the discussion. 18:46 -!- jason--|afk is now known as jason-- 18:46 < jason--> cwitty-1357: did you see that your URLs are all ending in a colon? 18:47 < jason--> (you guys have been having lots of fun, it seems!) 18:47 < cwitty-1357> Yes. Please merge 962-2.patch and 962-doctests.patch. 18:47 < mabshoff-1184> Yeah, it is like a party here ;) 18:47 < cwitty-1357> jason--, I'm not typing urls; I'm typing "# 962:". 18:47 < mabshoff-1184> cwitty-1357: Ok, I will be merging shortly. 18:47 < mhansen-962> cwitty-1357: I fixed the 32-bit issue. 18:47 < mabshoff-1184> anybody out there with a mac willing to test an updated ntl.spkg? 18:48 < mabshoff-1184> it fixes http://trac.sagemath.org/sage_trac/ticket/1184 :) 18:48 < jason--> hmmm, so its my konversation that is picking up the colon as part of the URL...my bad. 18:49 < jkantor> I can test if it builds, though I know nothing of ntl 18:49 < mabshoff-1184> Well, it only changes the Darwin makefile. 18:49 < jkantor> ok, so just looking for erros? 18:49 < mabshoff-1184> It twiddles with the linker options and fixes some issues with the link order in setup.py 18:49 < mabshoff-1184> pretty much. 18:49 < jkantor> where is the spkg 18:50 < mabshoff-1184> one sec. 18:50 < mabshoff-1184> The OSX linker otherwise picks libpari-gmp.dylib instead of libgmp.dylib 18:50 < mabshoff-1184> It automatically resolves symbols, which is just crazy. 18:51 < mabshoff-1184> http://sage.math.washington.edu/home/mabshoff/ntl-5.4.1.p7.spkg 18:51 < mabshoff-1184> is the updated NTL spkg 18:52 < jkantor> I just realized, on my osx machine, I didn't rebuild 2.6.15, will 2.6.13, suffice? 18:52 < mabshoff-1184> Should work. The issue is about moving installs. 18:52 < jkantor> ok 18:53 -!- was-afk-eating is now known as was-1342 18:53 < mabshoff-1184> But for sage -b to work you need to apply a patch which I will post shortly to http://trac.sagemath.org/sage_trac/ticket/1184 18:54 < rlm> mabshoff-1184: There is a patch for #1179 but I am not sure how to test it. 18:55 < mabshoff-1184> Well, if it passes testall it should be enough for now. 18:55 < mabshoff-1184> It should be so trivial that reviewing it should catch any potential issue. 18:55 < mabshoff-1184> But if anything pops up it should be very obvious. 18:56 < mabshoff-1184> It might also be interesting if we should change "sage -sh" to "sage -bash" 18:57 < mabshoff-1184> Anybody know when was is going to be back? 18:57 < rlm> ok, i'll do a testall right now, while i'm eating dinner 18:57 < cwitty-1357> No! don't do that. 18:57 < was-1342> I am back. 18:57 < was-1342> I like sage -sh 18:57 < cwitty-1357> Half of the point of "sage -sh" is that it works even if your login shell is tcsh. 18:57 < mabshoff-1184> Well, it should still work. 18:58 < mabshoff-1184> On pretty much any decently modern system sh is a link to bash. 18:58 < cwitty-1357> "sage -sh" already gives you bash if your login shell is bash. 18:58 < cwitty-1357> Or tcsh if your login shell is tcsh, or zsh if your login shell is zsh. 18:58 < mabshoff-1184> Doe it use $SHELL? 18:59 < cwitty-1357> Yes. 18:59 < mabshoff-1184> Ok, I guess rlm's patch doesn't change that. 18:59 < cwitty-1357> Right. 18:59 -!- rlm is now known as rlm|afk|testing 18:59 < mabshoff-1184> But does the export of all the Sage env-stuff still work with all those different shells? 18:59 < cwitty-1357> Yes. 18:59 < mabshoff-1184> ok 19:00 < cwitty-1357> (Because sage-env is actually processed with /bin/sh (or with /bin/bash, after the patch).) 19:01 < mabshoff-1184> ok, 19:01 < mabshoff-1184> I will be merging 962-2.patch and the doctest patch. That is what you guys want? 19:01 < cwitty-1357> Yes. 19:01 < mabshoff-1184> ok. 19:03 < jkantor> I applied the patch and am install the ntl package, do I need to do sage -b afterwards? 19:03 < mabshoff-1184> Yep 19:03 < jkantor> ok 19:03 < mabshoff-1184> I did test it on three platforms, but you never know :) 19:05 < mabshoff-1184> ok, 962 merged and closed. 19:06 < mabshoff-1184> Any news on the 787 review? 19:06 < mabshoff-1184> Or are we waiting for Craig to come back? 19:06 < was-1342> regarding 787, I just had to post one trivial 2-line patch to fix a doctest. 19:06 < mabshoff-1184> :) 19:07 < mabshoff-1184> Is there anything else in the review que? 19:07 < mabshoff-1184> I would like to do 1183, 787. Anything else? 19:08 < mabshoff-1184> was-1342: If malb is online later and we get Singular 3-0-4 we could do a release on monday 19:08 < was-1342> I'm about to post #1342. 19:08 < was-1342> That's a major bug. 19:08 < was-1342> (in my opinion.) 19:08 < mabshoff-1184> with PolyBoRi.spkg as a compile test only. 19:08 < mabshoff-1184> And ATLAS goes in either way after alpha2. 19:09 < jkantor> Just a thought, since you buld on ppc linux so much, would it be possible to have binaries for that, even skipping every few releases 19:09 < mabshoff-1184> Sure, I don't see any problem with your patch. 19:09 < mabshoff-1184> sure, but it is usually a pain to upload. 19:09 < jkantor> I see 19:09 < mabshoff-1184> I only got excellent bandwidth at the office, and people tend to pester me if I show up there. 19:10 < jkantor> ah 19:10 < mabshoff-1184> But I am usually there once every two weeks, so I can push the latest current release then. 19:10 < mabshoff-1184> Does anybody care about those PPC Linux binaries? 19:10 < jkantor> me, 19:10 < mabshoff-1184> ok 19:11 < mabshoff-1184> the PPC Linux build tends to expose bugs in the code. 19:11 < mabshoff-1184> So I should build every release ;) 19:12 < jkantor> I have an ibook g3 and I never build sage on it because its so slow, but upgrading from a relatively recent binary would be manageable. 19:13 < jkantor> regarding 1184: I installed patch, installed the package, and did sage -b. No errors, do you need a testall? 19:13 < mabshoff-1184> nah, I know it works ;) 19:13 < jkantor> cool 19:13 < mabshoff-1184> You could do a "sage -ba" followed by moving the install and rebuilding cremona ;) 19:14 < mabshoff-1184> That is what I did, but that takes a while ... 19:14 < jkantor> only, if you really want me too? 19:14 < mabshoff-1184> If you have time to waste. 19:14 < jkantor> well I have another laptop right next too the macbook 19:14 < mabshoff-1184> We will see if the reports about failed updates will stop on OSX 10.4 19:14 < jkantor> so I don't mind it being busy 19:15 < mabshoff-1184> Just rebuild cremona, if that works I will merge it. 19:15 < jkantor> after moving 19:15 < jkantor> how doing I rebuld cremona? 19:15 < mabshoff-1184> Either way. 19:15 < mabshoff-1184> ./sage -f spkg/standard/cremona-200711xx 19:15 < jkantor> oh, the package ok 19:16 < mabshoff-1184> Yep, then touch the cremona directory in libs and do a sage -b 19:16 < mabshoff-1184> That should test it well enought. 19:16 < mabshoff-1184> The really odd thing is that once I fixed NTL to be a proper dylib I needed to change the link order for all the libSingular stuff. 19:16 < mabshoff-1184> That's why the patch was needed for setup.py 19:17 < jkantor> i see 19:17 < mabshoff-1184> the really odd thing: This is a non issue on OSX 10.5, but there the linker has a different bug. 19:17 < jkantor> I don't understand linking on osx, they have these weird flat namespaces and two level namespaces 19:18 < mabshoff-1184> http://trac.sagemath.org/sage_trac/ticket/1358 - it is unbelievable. 19:18 < mabshoff-1184> Yep, to put it midly: It looks like it was designed by monkeys. 19:19 < jkantor> It seems that they made an initial crappy design, and then a hack that sort of fixed it, but has lots of shortcomings 19:19 < jkantor> its seems far lest robust than how linux works 19:19 < mabshoff-1184> Well, they changed the linker concept woth 10.0, 10.1, 10.2 and it is incompatible in many ways. 19:20 < mabshoff-1184> woth->with 19:20 < jkantor> yeah 19:21 < mabshoff-1184> I just don't understand: Take elf and Unix standard libraries - all the problems have been solved a decade ago, 19:21 < mabshoff-1184> but no: design your own NIH idiotic linker concept and then not fix the bugs in the linker. 19:22 < mabshoff-1184> lazy symbol lookup at runtime? What an excellent idea. 19:26 < jkantor> I rebuilt hte cremona package, no problems 19:27 < mabshoff-1184> Excellent. 19:27 < mabshoff-1184> was-1342: I cannot reproduce or find any problem with mwrank on bsd. So it must be Justin's fault ;) 19:27 < was-1342> yep. 19:28 < mabshoff-1184> I also run all the mwrank test on the shell, no dice. 19:29 < mabshoff-1184> Ok, I am brewing some more tea, back in a fiffy or two. 19:29 < mabshoff-1184> Then hopefully the final three tickets to merge and alpha2 here we come. 19:38 < was-1342> #1342 -- done. 19:39 < mabshoff-1184> Is anybody reviewing this? Not that I think that there is the need to do so :) 19:40 < cwitty-1357> was-1342, in #1342, should "input idea" be "input ideal"? 19:40 < mabshoff-1184> Oh, I guess we do ;) 19:41 < cwitty-1357> I wasn't planning to run it, or look at the math, or anything... but at least I can find typos in the error messages! 19:41 < mabshoff-1184> :9 19:42 < mabshoff-1184> How about http://trac.sagemath.org/sage_trac/ticket/1160 - anybody willing to tackle that? 19:42 < was-1342> yep. 19:42 < mabshoff-1184> There is also that bug that Kate reported. 19:42 < jason--> /nick jason--|afk 19:44 < was-1342> ok, I posted another #1342 patch... 19:45 < mabshoff-1184> Kate's is 1324. 19:45 < mabshoff-1184> But I haven't looked at it. 19:46 < mabshoff-1184> Was there any consensus about http://trac.sagemath.org/sage_trac/ticket/1129? 19:47 < mabshoff-1184> An new Pyrex has been released. 19:49 -!- was-1342 is now known as was-1160 19:49 < roed_> William, I'm taking a look at trac1342 19:49 < cwitty-1357> Re: #1129: I pointed out that Craig's code should cache the results of nfinit(), and he agreed. 19:49 < cwitty-1357> I think he's working on a new version of the patch. 19:50 < mabshoff-1184> ok, I think he should be back soonish. 19:50 < roed_> was-1342 Are the two patches you've put up supposed to fix things? 19:50 < mabshoff-1184> lol 19:50 < roed_> oops, he moved on 19:50 < roed_> was-1160 19:50 < was-1160> yes. 19:50 < was-1160> roed -- my patches should 100% fix things, and increase doctest coverage. 19:51 < was-1160> I just want to make sure it looks ok to you. 19:53 < roed_> sure. I'm reading through them now 19:54 < mabshoff-1184> roed_: let me know when you are done with 1342 19:54 < roed_> will do 19:54 < mabshoff-1184> If you want to also check out 787 19:56 < roed_> was-1160, has someone fixed residue fields so that they work without computing the maximal order? 19:56 < was-1160> NO -- #1342 is completely unrelated to that. 19:57 < roed_> ok 19:57 < was-1160> Actually, we haven't even fixed things so residues fields work even with a maximal order -- this issue isn't maximal vs non-maximal but whether [O_K : Z[a]] is divisible by p. 19:58 < rlm|afk|testing> regarding sh ---> bash, testall goes fine 19:58 -!- rlm|afk|testing is now known as rlm 19:58 < mabshoff-1184> rlm: ok 19:58 < roed_> yeah 19:58 < roed_> I know 19:58 < mabshoff-1184> was-1160 should give us input on that patch. 19:59 < was-1160> which patch? 19:59 < was-1160> I like the sh --> bash patch. 19:59 < was-1160> It seems very sensible. 19:59 < mabshoff-1184> ok 19:59 < roed_> mabshoff-1184 and was-1160: 1342 looks good to me. 19:59 < was-1160> ok, cool. make a comment in trac. 19:59 < mabshoff-1184> ok, once my testalll finished I will apply 20:00 < mabshoff-1184> was-1160: could you then officially comment on http://trac.sagemath.org/sage_trac/ticket/1179, i.e. the sh patch? 20:00 < mabshoff-1184> It is also trivial to merge then. 20:01 < was-1160> I did officially comment on it. 20:01 < mabshoff-1184> ok, sorry. 20:02 < rlm> on #1179 there are some files in bin that i changed, but didn't show up in the patch 20:03 < was-1160> some files that go in bin are not in the hg repo. 20:03 < was-1160> But *anything* that starts with sage-* will be put in the sage_scripts*.spkg when one does sage -sdist. 20:03 < was-1160> But of course many scripts in local/bin/ might be installed by other programs during "make install". 20:04 < rlm> there were many files that didn't start with sage- that used #!/bin/sh 20:04 < was-1160> It's not a priori bad to use /bin/sh 20:04 < was-1160> It's only a problem if the file uses bash-isms. 20:04 < rlm> ok, so further problems will be case-by-case 20:04 < rlm> just wondering 20:05 < roed_> mabshoff-1184: did you want me to take a look at something? 20:05 < mabshoff-1184> 787 if you have time and know something about the area. 20:06 < mabshoff-1184> Ok, I got an extremely odd doctest failure: 20:06 < mabshoff-1184> sage -t devel/sage-main/sage/rings/fraction_field_element.pyTraceback (most recent call last): 20:06 < mabshoff-1184> File ".doctest_fraction_field_element.py", line 96, in <module> 20:06 < mabshoff-1184> globs=globals()) 20:07 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 1798, in testmod 20:07 < mabshoff-1184> for test in finder.find(m, name, globs=globs, extraglobs=extraglobs): 20:07 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 823, in find 20:07 < mabshoff-1184> self._find(tests, obj, name, module, source_lines, globs, {}) 20:07 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 877, in _find 20:07 < mabshoff-1184> globs, seen) 20:07 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 865, in _find 20:07 < mabshoff-1184> test = self._get_test(obj, name, module, globs, source_lines) 20:07 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 949, in _get_test 20:07 < mabshoff-1184> filename, lineno) 20:07 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 578, in get_doctest 20:07 < mabshoff-1184> return DocTest(self.get_examples(string, name), globs, 20:08 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 592, in get_examples 20:08 < mabshoff-1184> return [x for x in self.parse(string, name) 20:08 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 554, in parse 20:08 < mabshoff-1184> self._parse_example(m, name, lineno) 20:08 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 624, in _parse_example 20:08 < mabshoff-1184> lineno + len(source_lines)) 20:08 < mabshoff-1184> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/doctest.py", line 710, in _check_prefix 20:08 < mabshoff-1184> (lineno+i+1, name, line)) 20:08 < mabshoff-1184> ValueError: line 29 of the docstring for __main__.example_2 has inconsistent leading whitespace: 'AUTHOR:' 20:08 < mabshoff-1184> [1.6 s] 20:08 < mabshoff-1184> exit code: 256 20:08 < mabshoff-1184> That fraction_field_element.py is in sage.math/home/mabshoff 20:10 < rlm> mabshoff-1184: what is the valgrind tool for profiling? 20:11 < cwitty-1357> rlm, I've used callgrind. 20:11 < mabshoff-1184> valgrind is just an alias for memcheck. 20:12 < cwitty-1357> There are some notes here: 20:12 < cwitty-1357> http://wiki.sagemath.org/ValgrindingSage 20:12 < rlm> i think i'm going to take a look at graph_isom again 20:12 < rlm> thanks 20:13 < mabshoff-1184> Yep, if you have any questions ping us here. 20:13 < mabshoff-1184> We should add more info and especially write some debugging chapter for the manual. 20:14 < mabshoff-1184> ok, 1179 and 1184 are merged. 20:16 < was-1160> I'm making good progress on #1160, fortunately. 20:18 < roed_> mabshoff-1184: 787 looks sane, but I don't have time at the moment to work through it in detail 20:18 < roed_> I can probably get to it later tonight if that's early enough 20:18 < was-1160> Did you try applying the bundle? 20:18 < roed_> I don't have a fully upgraded version of sage 20:18 < was-1160> The best thing would be if you could just try it out at least. 20:18 < roed_> so I doubt it will work 20:18 < was-1160> You can apply the text patches to even a fairly old sage. 20:18 < mabshoff-1184> was-1160: which bundle 20:19 < roed_> Sure 20:19 < roed_> I'll apply the text patches and try it out 20:19 < was-1160> linear algebra "quotient" -- It is a patch against code that has barely changed in a year. 20:19 < was-1160> most of the patch is a new file, even. 20:20 < mabshoff-1184> I don't understand what is wrong with "sage -t devel/sage-main/sage/rings/fraction_field_element.py" 20:20 -!- rlm is now known as rlm-1360 20:20 < mabshoff-1184> I diffed it against a working version on bsd. and it is the same except for line "3" and the doctest fix. 20:20 < was-1160> maybe ValueError: line 29 of the docstring for __main__.example_2 has inconsistent leading whitespace: 'AUTHOR:' 20:21 < mabshoff-1184> Yep 20:21 < mabshoff-1184> bsd:sage-2.8.14-moved mabshoff$ diff fraction_field_element.py devel/sage/sage/rings/fraction_field_element.py 20:21 < mabshoff-1184> 3c3 20:21 < mabshoff-1184> < 20:21 < mabshoff-1184> --- 20:21 < mabshoff-1184> > 20:21 < mabshoff-1184> 128c128 20:21 < was-1160> maybe tabs versus spaces or something. 20:21 < was-1160> I would just delete the whole weird line 20:21 < mabshoff-1184> I already did. It doesn't fix it. 20:22 < mabshoff-1184> I don't understand where the change comes from. 20:22 < mabshoff-1184> But I will take the working version and reapply the failed hunk. 20:22 < mabshoff-1184> not failed, but the doctest fix hunk. 20:25 < mabshoff-1184> Ahh, it isn't my patch that was at fault, it is mhansen-962's :) 20:26 < craigcitro-1231> hey all ... back 20:26 < rlm-1360> what directory does valgrind output get put in again? 20:26 < mabshoff-1184> Hey Craig. 20:26 < mabshoff-1184> ~/.sage 20:26 < was-1160> (but it should be .sage/valgrind/ hint hint ) 20:26 < mabshoff-1184> :) 20:26 < mabshoff-1184> I never heard about that. lalalalalalala 20:28 < mabshoff-1184> Ok, the problem with that failed doctest is when I updated line 130 to the expected output. 20:29 < mabshoff-1184> Then the problem about "leading whitespace" appears. 20:29 < was-1160> can somebody look at #1349. 20:29 < was-1160> It changes the default notebook directory. 20:30 < was-1160> The tricky part is that it also cd's to the parent directory before running the twisted server. 20:30 < was-1160> pretty simple patch though, and will avoid a lot of confusion. 20:33 < craigcitro-1231> i have a pari question (again): does pari just not handle number fields defined by non-integral polynomials? 20:33 < mabshoff-1184> mhansen-962: Can you reproduce the problem with doctesting "fraction_field_element.py"? 20:34 < was-1160> craigcitro -- yes, I think it doesn't. 20:34 < was-1160> So we have to translate back and forth. 20:34 < mabshoff-1184> Ok, I am merging 1342 now unless somebody things I should wait. 20:35 < mabshoff-1184> And also 787 20:36 < was-1160> sounds good to me :-) 20:37 < mabshoff-1184> was-1160: I think you were right, there was a tab in there. 20:37 < was-1160> excellent. 20:37 < mabshoff-1184> Arrg, still failing. 20:38 < mabshoff-1184> Maybe another tab somewhere else. 20:38 < roed_> was-1160: I'm not convinced the repr string for a quotient module should have "V/W" in it 20:38 < roed_> It gets really confusing when you try to take quotients of quotients 20:39 < was-1160> That's a good point. What would you prefer. 20:39 < was-1160> It's really hard to read "quotient of %s by %s" where %s and %s are V and W, since they are also complicated. 20:39 < rlm-1360> any chance i could get a trac admin to install a "graphs" component? 20:39 < roed_> agreed 20:40 < was-1160> It could be "Vector space quotient of dimension 2 over Rational Field:" 20:41 < was-1160> [indentation] Module: Vector space of dimension 3 over Rational Field 20:41 < was-1160> [indentation] Submodule: Vector space of degree 3 and dimension 1 over Rational Field 20:41 < roed_> Yeah 20:41 < roed_> I like that better than what I was about to suggest 20:41 < was-1160> Then the entire Module and Submodule descriptions are uniformly indented. 20:41 < was-1160> Could you implement what I just suggested. 20:41 < was-1160> I spent way too long on #787 today, and am in the midst of another bug fix right now involving the notebook... 20:42 < roed_> Sure 20:42 < was-1160> Thanks! 20:42 < roed_> what file did FreeModule_ambient_field_quotient get put in? 20:42 < was-1160> modules/quotient_module.py, I think. 20:42 < roed_> ok 20:43 < roed_> yup 20:43 < was-1160> That should eventually get several other quotient classes, e.g., over a PID. 20:44 < mabshoff-1184> o,k, fixed that doctest. 20:44 < mabshoff-1184> I put the AUTHOR: on top and now it works. 20:44 < was-1160> excellent work. 20:44 < mabshoff-1184> damn python, I like C much better 20:44 < was-1160> I have 1160 working fine now. 20:45 < mabshoff-1184> I should write more python ;) 20:46 < was-1160> With C you can easily shoot yourself in the foot. 20:46 < was-1160> With Python, you can't find the trigger. 20:46 < mabshoff-1184> :) 20:46 < mabshoff-1184> But I have done C for close to 20 years now ;) 20:46 < was-1160> I've done C for 16 years. 20:47 < mabshoff-1184> :) 20:47 < mabshoff-1184> ok, 787 is merged. 20:47 < was-1160> excellent. 20:47 < mabshoff-1184> 1342 is next 20:48 < mabshoff-1184> 1349 is also on my list. 20:48 < mabshoff-1184> And I guess 1160 is next. 20:49 < was-1160> I already did 1160. 20:49 < mabshoff-1184> Well, I meant to merge. 20:49 < was-1160> But i haven't posted the patch, since I'm adding a few doctests to maxima.py "while I'm there". 20:49 < mabshoff-1184> ok, fine with me. 20:49 < was-1160> I figure I should always increase coverage with my patches. 20:49 < mabshoff-1184> Now doing 1342 20:49 < mabshoff-1184> I agree 20:49 < craigcitro-1231> ok, i need an opinion here. 20:49 < craigcitro-1231> if you have a polynomial defined over a number field, and you ask to factor it, we have pari actually do the factoring 20:49 < mabshoff-1184> 1342: both patches I assume. 20:50 < craigcitro-1231> unforttunately, the function we were using caused a weird error (that we're going to report to pari) 20:50 < craigcitro-1231> this was the content of #1129 20:50 < was-1160> yes, both patches. 20:50 < craigcitro-1231> so i changed this to a different function, which the documentation actually claims is faster in general 20:50 < mabshoff-1184> ok 20:50 < craigcitro-1231> so it's a good thing all around 20:50 < craigcitro-1231> but now i have a weird problem with variable priorities in pari 20:51 < craigcitro-1231> we create the pari version of the polynomial with whatever name the variable had 20:51 < was-1160> craig -- good work. 20:51 < was-1160> But regarding variable priorities, there are/were/have been/ lots of places in sage where we have to change the variables 20:51 < was-1160> in a funny way in order to use pari, then change them back. 20:51 < was-1160> it's a pain in the ass. 20:52 < craigcitro-1231> yeah, it's a pain 20:52 < cwitty-1357> Maybe we should just always translate the variables when we go to pari? Never, ever try to preserve the name? 20:52 < craigcitro-1231> so as i was typing that, i realized i was confused about where i was having a variable collision 20:53 < mabshoff-1184> 1342 is done 20:53 < roed_> mabshoff-1184: I have another patch coming for 787 20:53 < craigcitro-1231> ah, but i do still have the problem. the point is that if the number field's defining polynomial is in x, it causes us trouble 20:54 < mabshoff-1184> roed_: No problem. make sure it is relative to the bundle ;) 20:54 < mabshoff-1184> best to send me a patch, that way I can dry-run before I apply. 20:54 < roed_> I'll just send you a patch. It won't be relative to the bundle 20:54 < mabshoff-1184> ok, we will work it out. 20:54 < roed_> Since I can't apply the bundle: I don't have a fully upgraded version of sage 20:54 < craigcitro-1231> it's just not clear what a clean way to do it is. 20:55 < mabshoff-1184> roed_: np 20:55 < was-1160> craigcitro -- pari is a pain in the ass. 20:55 < roed_> It will be against 2.8.13 with the three patches applied 20:55 < craigcitro-1231> was-1160: snic ... exactly. 20:55 < mabshoff-1184> That should do the trick. 20:55 < was-1160> But vastly less a pain in the ass than writing everything from scratch would be. 20:56 < craigcitro-1231> true 20:57 < mabshoff-1184> was-1160: 1349 is also going in? 20:57 < mabshoff-1184> Patch looks good to me. 20:57 < mabshoff-1184> Did you test it ;) 20:58 < was-1160> I hope so. 20:58 < was-1160> I tested it a lot myself. 20:58 < was-1160> it was actually more difficult than expected as I found from testing. 20:58 < mabshoff-1184> ok, ... this is alpha2, so something needs to be broken. 20:58 < was-1160> But I think somebody besides me better at least try it. 20:59 < mabshoff-1184> After all, otherwise people get spoiled. 20:59 -!- mabshoff-1184 is now known as mabshoff 20:59 < jkantor> does this include the atlas stuff? 20:59 < mabshoff> Nope, that is coming next. 20:59 < jkantor> ok, I'll wait till that one :) 20:59 < mabshoff> i.e. once I catch some sleep, but if somebody else wants to take over. 20:59 < mabshoff> It really depends on PolyBoRi and Singular. 21:00 < mabshoff> If they don't show up tomorrow and ATLAS works: release tomorroe. 21:00 < mabshoff> Otherwise: release one or two days later. 21:00 < mabshoff> We closed 45 tickets, so it is certainly a solid release. 21:00 < jkantor> cool 21:01 < mabshoff> And there will be another release in a couple days anyway. 21:01 < mhansen-962> #1290 can go in. 21:01 < mabshoff> mhansen-962: ok. 21:01 -!- mhansen-962 is now known as mhansen 21:01 < mabshoff> Currently re-building NTL, but that should be done soon. 21:02 < mabshoff> I am no longer sleepy, so I can probably work on this release for a couple more hours ;) 21:02 < mabshoff> I think it is 9pm on the west coast? 21:02 < mhansen> Yep 21:02 < cwitty-1357> Yes. 21:03 < mabshoff> Well, in that case we can keep going :) 21:03 < mabshoff> somebody idle should test 1349 locally. 21:04 < mhansen> Will do 21:04 < mabshoff> mk 21:04 < mabshoff> Excellent 21:06 < cwitty-1357> Somebody should review 1292, since the bug is marked "critical". 21:06 < mhansen> #1349 works for me. 21:06 < mabshoff> ok, it is merged. 21:07 < mhansen> I'm looking at #1292 21:08 < mabshoff> ok, 1290 is going in next. 21:08 < mabshoff> On the short list: 1292 and 1160. 21:08 < mhansen> cwitty-1357: Where is the implementation of the naive method for 1292? 21:08 < mhansen> Was it already in? 21:08 < cwitty-1357> Yes, it was already there. 21:09 < mhansen> Oh, okay. 21:09 < mhansen> Then #1292 looks good to me. 21:09 < mabshoff> Good, I am getting a bite for breakfast, back in 10-15. Then I will merge 21:12 < mhansen> mabshoff: I think #1201 can go in too. 21:14 < jason--> is the request in 1347 implemented in 1349 (is the directory containing the notebok printed?) It looks like it from the patch.. 21:16 < was-1160> I make it print the notebook directory on startup indeed. 21:16 < jason--> okay, I'll mark 1347 as a dup. 21:17 < mhansen> I'd mark it as fixed and say the patch for #1349 fixed it. 21:17 < jason--> okay, I'll do that instead. 21:17 < was-1160> sounds good. 21:17 < roed_> was-1160: the rest of 787 looks good 21:17 < was-1160> thanks for refereeing it! 21:17 < roed_> sure 21:18 < roed_> :-) 21:18 < roed_> I'm sure you'll be willing to return the favor for the upcoming padic patch 21:18 < roed_> ;-) 21:18 < was-1160> noooooo!!!!! 21:18 < was-1160> :-) 21:19 < roed_> Hey. At least I won't bunch the p-adic patch and Robert and my coercion patch into one 21:19 < roed_> ;-) 21:20 < mabshoff> that would be truly evil ;) 21:20 < roed_> :-D 21:20 < mhansen> mabshoff: #1208 works for me. 21:23 < mabshoff> mhansen: you mean applying the bundle and testing it? 21:24 < mhansen> Yeah (against alpha1) 21:24 < mabshoff> Sure, nobody did touch matrix[n].pyx, so it should be smooth 21:25 < jason--> General question: are there any objections to using the threading module in python? Or more specifically, the Timer module? It allows for multiple threads that take turns with the global interpreter lock in python. 21:26 < mabshoff> There are 3 doctest failures in sage/modules/quotient_module.py 21:26 < mabshoff> see http://trac.sagemath.org/sage_trac/ticket/1364 21:27 < mabshoff> I guess the 2 hashing issues are trivial, but I am not sure about the other one. 21:27 < was-1160> I've posted the fix for #1160. 21:28 < mhansen> mabshoff: #1201 works for me against alpha1. 21:28 < cwitty-1357> jason-- I'm afraid that there may be lots of code in Sage that's not thread-safe. 21:28 < mabshoff> mhansen: ok 21:28 < cwitty-1357> Maybe if the extra threads only do very restricted things, it would be OK. 21:28 < jason--> My understanding is that python will not interrupt a c extension. Would that take care of things? 21:28 < mabshoff> ok: merge after testall finishes: 1160, 1201, 1208, 1290, 1292 21:28 < roed_> I doubt it 21:29 < mabshoff> wait for fix for 1364 21:29 < was-1160> jason--: sage is very very very non-thread safe because of the interfaces, among other things. 21:29 < was-1160> Two sage threads talking to one copy of the maxima interpreter -- it just doesn't make sense. 21:30 < jason--> right. hmm. 21:30 < cwitty-1357> And anything that uses a global variable would have to be checked. 21:30 < was-1160> I've posted #1160, and will now move on. 21:30 < mabshoff> om 21:30 < mabshoff> ok 21:31 < mabshoff> was-1160: Did you see http://trac.sagemath.org/sage_trac/ticket/1364 ? 21:31 < was-1160> Oh, that's not surprising. 21:32 < was-1160> Those doctests for hashing always have to be done on both 32 and 64-bit. 21:32 < was-1160> I forgot to do that. 21:32 < was-1160> I'll post a patch in a second. 21:32 < mabshoff> the hashing is a non issue, the switched sign? 21:32 < mabshoff> ah, ok 21:32 < was-1160> When you compare objects of different types then the result is platform dependent. 21:32 < mabshoff> good to know. 21:34 < was-1160> patch up for #1364 21:34 < mabshoff> mk 21:35 -!- was-1160 is now known as was-799 21:36 < was-799> I'm going to look at http://trac.sagemath.org/sage_trac/ticket/799 which is about some funny issue with the tachyon ray tracer. 21:36 -!- cwitty-1357 is now known as cwitty-1363 21:36 < was-799> Somebody wrote in a solution, so implementing it should be easy. 21:36 < cwitty-1363> mabshoff, I've created new tickets for the issues robertwb raised on #1275. Should I go ahead and close 1275? 21:37 -!- roed_ is now known as roed-1128 21:37 < mabshoff> sure 22:00 < craigcitro-1231> so i need one more opinion 22:01 < craigcitro-1231> if i'm asking to factor, say, x^2-1/36 22:01 < craigcitro-1231> what should it return? 22:01 < mabshoff> ok, I merged 1160, 1201, 1208, 1290, 1292 and 1364 22:01 < cwitty-1363> This is for number fields, right? 22:01 < craigcitro-1231> (x-1/6) * (x+1/6) ... (1/6*x-1/36)(6x+1) ... 22:02 < craigcitro-1231> yeah, number fields 22:02 < was-799> craigcitro -- I think it is ok to return unit * blah. 22:02 < cwitty-1363> I think it should return (x - 1/6) * (x + 1/6), the same as over QQ['x']. 22:02 < craigcitro-1231> well, it's really for factoring any polynomial over number fields 22:02 < was-799> Where the unit isn't well defined. 22:02 < was-799> Though the *optimal* choice would be 1 for QQ. 22:02 < was-799> So year, do what cwitty says. 22:02 < craigcitro-1231> k 22:02 < cwitty-1363> Over QQ, it always returns monic polynomials, and whatever other factor there is gets returned as the unit. 22:02 < was-799> that's definitely most expected. 22:03 < craigcitro-1231> nod 22:04 < was-799> I've posted a fix for #799. 22:04 < was-799> Maybe cwitty would like to look at it. 22:04 < was-799> I just basically implemented what Lief wrote in to suggest. 22:05 < mabshoff> Anybody want to review http://trac.sagemath.org/sage_trac/ticket/1296? 22:05 < mabshoff> It is a 4400x times speedup by robertwb 22:06 < mhansen> I'll look at it now. 22:06 < cwitty-1363> I'll look at #799 in a few minutes. 22:06 < was-799> re, #1296 -- Finally!!!!! 22:06 < was-799> I've asked people to implement this like 20 times over the last year. 22:07 < mabshoff> :) 22:07 < was-799> mhansen -- you're definitely the person to look at that patch by the way. 22:07 < mabshoff> Maybe you should complain in IRC liek I do ;) 22:07 < was-799> 1296-fast-permgroup.patch is funny -- it's so red (so much code deletion) 22:07 < mabshoff> was-799: Jen also posted an interesting patch. 22:08 < was-799> which one? 22:08 < mabshoff> http://trac.sagemath.org/sage_trac/ticket/1287 22:08 < mabshoff> And there is also that Simon-Descent ticket by Robert. 22:08 -!- was-799 is now known as was-1287 22:08 < was-1287> OK, I'll referee it now. 22:08 < mabshoff> :) 22:08 < mabshoff> There are only a couple patches left. 22:09 < mabshoff> Might as well merge the good ones :) 22:09 < mabshoff> I doctested after I merged the last 6 patches, so I can merge again in about 15 minutes. 22:09 < mabshoff> mhansen: If you want to do me a really, really big favor get the fast doctesting working. 22:10 < cwitty-1363> Yes! Please work on fast doctesting, mhansen. 22:10 < mabshoff> It would help tremendously to doctests much more often, i.e. every 3,4 patches. 22:10 < mhansen> I was working with that earlier, but the newer version of nose broke some things. 22:10 < mabshoff> ok 22:10 < mhansen> I'll do it some more after I look at #1296 22:10 < mabshoff> Well, next time I chair I won't wait 4 days until I start merging. 22:11 < mhansen> I'd like to do a release when I have a bit more time later in December. 22:14 < roed-1128> Anyone want to review http://trac.sagemath.org/sage_trac/ticket/1128? 22:14 < was-1287> mhansen -- you should definitely do a release -- let us know as soon as you want to do it. 22:15 < was-1287> By the way, any thoughts on http://trac.sagemath.org/sage_trac/ticket/1366 22:15 < was-1287> sage has functors? 22:16 < mabshoff> lol 22:16 < mhansen> The functors used in the new coercion model? 22:16 < was-1287> road-1128: There are four new functions in #1128 that don't have any doctests. 22:16 < craigcitro-1231> robertwb, you still around? 22:17 < robertwb> yep 22:17 < mabshoff> was-1287: I think your maxima patch reverted something from mhansen's patches. 22:17 < was-1287> Also, doctests are supposed to be indented 4 spaces more than EXAMPLES: but they aren't indented in #1128. 22:17 < robertwb> well, actually I'm not "still" around--I just got back litterally 5 min ago 22:17 < cwitty-1363> I'm thinking that 1366 looks a lot like 1332... 22:17 < craigcitro-1231> the comment you made in 1129 -- "it seems to work for me" -- was that about the patch or the bit of pari? 22:17 < was-1287> Ah, I figured it was a dup, but couldn't find 1332. 22:18 < was-1287> I'm makring 1332 as a dup. 22:18 < robertwb> I applied the patch, and the factor command worked for me. 22:18 < was-1287> mabshoff -- what do you think I reverted? 22:18 < robertwb> But I though someone more knowledgable about pari might want to comment on the change of functions 22:18 < was-1287> My maxima patch only touched maxima I think. 22:18 < was-1287> I wonder what mhansen touched. 22:18 < mabshoff> I don't know yet. Looking. 22:19 < mabshoff> It shouldn't have merged cleanly if it was a direct conflict. 22:19 < craigcitro-1231> yeah ... cwitty pointed out earlier that i'm often making multiple calls to nfinit, which i fixed. however, there's an annoying issue coming up still that i'm having to write more than i'd like to fix, namely with non-integral polynomials and pari ;) 22:19 < mhansen> was-1287: Which patch was yours? I can take a look 22:19 < mabshoff> But the same thing about recursion depth exceeded in two tests. 22:19 < roed-1128> cwitty-1363: I'm looking at 1144 (coercion between real quad double field and real_mpfr) 22:20 < cwitty-1363> roed-1128: I don't like the name "algebraic closure"; because my new QQbar is the algebraic closure of QQ, but it's not at all the same operationally. 22:20 < roed-1128> It should only coerce from real fields of precision >= 215 22:20 < mhansen> robertwb: I get a Cython error with your permgroup stuff. "cdef MonoidElement _mul_c_impl(left, MonoidElement _right):" -- Syntax error in C variable declaration. Does it need to know about MonoidElement somehow? 22:20 < roed-1128> what is QQbar? 22:20 < cwitty-1363> roed-1128: the algebraic closure of QQ (with an embedding into the complex numbers). sage/rings/qqbar.py 22:21 < mhansen> mabshoff: Which of William's patches do you think broke things? 22:21 < mabshoff> http://trac.sagemath.org/sage_trac/ticket/1160 I believe 22:21 < cwitty-1363> For #1128, how about calling it the AdjoinIFunctor, or something like that? 22:21 -!- rlm-1360 is now known as rlm-1361 22:21 < roed-1128> I don't see sage/rings/qqbar.py 22:22 < cwitty-1363> It's new in 2.8.15. It's in alpha1 and alpha2. 22:22 < mabshoff> mhansen: maybe not, but I think that is the only one related to calculus. 22:22 < roed-1128> I don't like AdjoinIFcuntor 22:22 < cwitty-1363> I mean alpha0 and alpha1. 22:22 < roed-1128> It's more general than that 22:22 < mhansen> mabshoff: I don't see anything in #1160 that'd do it. 22:23 < mabshoff> Me neither. Let's wait for the doctest to finish, so I can out the log up. 22:23 < cwitty-1363> Do you mean that "algebraic closure" is more general than "adjoining I"? 22:24 < roed-1128> yes 22:24 < mabshoff> File "sage_object.pyx", line 312, in sage.structure.sage_object.SageObject._maxima_ 22:24 < mabshoff> File "sage_object.pyx", line 252, in sage.structure.sage_object.SageObject._interface_ 22:24 < cwitty-1363> If so, that's sort of my point; I want to use the less general concept for pragmatic reasons. 22:24 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/site-packages/sage/interfaces/maxima.py", line 378, in __call__ 22:24 < mabshoff> return Expect.__call__(self, x) 22:24 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/site-packages/sage/interfaces/expect.py", line 738, in __call__ 22:24 < mabshoff> return cls(self, x) 22:24 < mabshoff> File "/tmp/Work-mabshoff/release-cycles-2.8.15/sage-2.8.15.alpha2/local/lib/python2.5/site-packages/sage/interfaces/expect.py", line 989, in __init__ 22:24 < mabshoff> raise TypeError, x 22:24 < mabshoff> So it is about the maxima interface. 22:24 < roed-1128> I'm want to take a look at qqbar 22:24 < roed-1128> just a bit 22:25 < cwitty-1363> Otherwise I'm afraid the coercion model will end up automatically constructing coercions that go through QQbar, which will probably be very inefficient. 22:26 < mabshoff> Yep, just hand another one of the "recusion depth exceeded" and it points to the maxima interface. 22:26 < roed-1128> I don't think it will 22:26 < roed-1128> Well, maybe 22:27 < roed-1128> Is there somewhere I can read the qqbar.py code without waiting for sage-2.8.15-alpha1 to finish building? 22:27 < robertwb> mhansen: did you apply all the patches? 22:27 < mabshoff> There is a patch at 1275 22:27 < mhansen> robertwb: Yep, and they all applied cleanly. 22:28 < robertwb> but it won't compile? 22:28 < mhansen> Nope 22:28 -!- jason-- [[email protected]] has quit [Remote closed the connection] 22:28 < mhansen> That line is the only place MonoidElement is referenced. 22:28 < robertwb> is it cimported in the pxd file? 22:28 < cwitty-1363> roed-1128, or to read the whole file, it's at http://sage.math.washington.edu/home/cwitty/sage-2.8.15.alpha0/devel/sage-main/sage/rings/qqbar.py 22:30 < mhansen> robertwb: Is there supposed to be a permgrp_element.pxd file? 22:31 < robertwb> yes. Oh, is it not there? 22:31 < mhansen> Nope 22:31 < robertwb> d'oh. I'll add it 22:31 < mhansen> Then, if I get everything to work, I'll make one big patch. 22:31 < robertwb> uh huh 22:31 < robertwb> I did patches 'cause it was on top of something else 22:32 < robertwb> btw, was, did you ever get the hg inspection to work? 22:33 < cwitty-1363> I have some patches posted, that I forgot to ask for reviews on. 22:33 < cwitty-1363> Does anybody want to review #1162 (RQDF->RealField coercion)? 22:34 < robertwb> mhansen: it's there now. BTW, MonoidElement is the superclass of GroupElement 22:34 < mhansen> Yeah, I knew that ;-] 22:34 < cwitty-1363> Or #1357 (add support for ring=QQbar to the polynomial .roots() command)? 22:34 < cwitty-1363> Or #1363 (add .sqrt() to complex intervals)? 22:35 < robertwb> roed, cwitty: I think AlgebraicClosureFunctor is probably the right thing, it is the algebraic closure of R. 22:36 < was-1287> #1287 -- I refereed it; it has a serious bug, so can't go in until it gets addressed. 22:36 < cwitty-1363> It's certainly mathematically correct; I'm just worried about the pragmatic issues. 22:36 < mabshoff> mk 22:36 < roed-1128> So the problem would be if there were two construction towers 22:37 < mabshoff> was-1287: your maxima patch causes doctest failures. 22:37 < mabshoff> recusion depth exceeded ... 22:37 < roed-1128> And we eventually implement QQ.algebraic closure as QQbar 22:38 < roed-1128> I suspect it will depend on the relative ranks of algebraic closure and completion 22:38 < roed-1128> If completion happens first then we never go through QQbar implicitly 22:39 < roed-1128> cwitty-1363: can you actually come up with an example one would get an element of QQbar implicitly? 22:41 < cwitty-1363> Probably not. 22:41 < cwitty-1363> I didn't really understand the "ranks" part of the new coercion stuff; so if you say it can be tweaked to work, I believe you. 22:42 < roed-1128> robertwb, my intuition is that it should be fine 22:42 < robertwb> it being ? 22:43 < roed-1128> We won't implicitly be constructing elements of QQbar if we use the same construction functor for RDF->CDF, RR->CC, and QQ->QQbar 22:43 < robertwb> No, though the rank of CompletionFunctor needs to be lower 22:43 < roed-1128> lower than algebraic completion you mean 22:43 < robertwb> yes 22:43 < robertwb> which it isn't now 22:44 < roed-1128> Right. I made it 3 so that algebraic completion would subsume algebraic extensions 22:44 < robertwb> Actually, if you have CC 22:45 < robertwb> Then you have QQ -> RR -> CC, so completion would always happen first, not matter what the ranks 22:45 < roed-1128> right 22:47 < cwitty-1363> So it will do something sensible with QQbar(1) + CC(1) (give a CC result)? 22:47 < robertwb> This makes more sense than QQ -> QQbar -> CC, because there is only a single (binary) choice for RR -> CC, but a huge unwieldily group of choices for QQbar -> CC 22:47 < cwitty-1363> Well, there's only one choice for MY QQbar -> CC. 22:47 < robertwb> Yes, as long as the coercion QQbar(1) -> CC is defined 22:47 < cwitty-1363> If somebody wants a QQbar without embedding, they'll have to write it themselves. 22:48 < robertwb> cwitty: do you ever expose your embedding (other than in printing?) 22:48 < mabshoff> Ok, failed doctests: 22:48 < mabshoff> sage -t devel/sage-main/sage/misc/functional.py 22:48 < mabshoff> sage -t devel/sage-main/sage/calculus/calculus.py 22:48 < mabshoff> sage -t devel/sage-main/sage/calculus/wester.py 22:48 < mabshoff> sage -t devel/sage-main/sage/interfaces/maxima.py 22:48 < cwitty-1363> All over the place. 22:48 < mabshoff> 2.8MB log at: http://sage.math.washington.edu/home/mabshoff/test-2.8.15.alpha2.log 22:48 < mabshoff> patches welcome :) 22:48 < robertwb> or could Gal(Qbar/Q) actually act on elements of (your) QQbar? 22:48 < cwitty-1363> QQbar can be (explicitly or implicitly) coerced to CC. 22:49 < cwitty-1363> The __pow__ method on QQbar uses the embedding to select a particular root to return. 22:49 < robertwb> ah 22:49 < cwitty-1363> To construct a QQbar, you need to select a particular root of a polynomial with a complex interval. 22:49 < robertwb> yes, it does make a choice that sqrt(-3) * sqrt(-2) == -sqrt(6) 22:50 < cwitty-1363> QQbar objects have a "conjugate()" method. 22:50 < cwitty-1363> (That implements the complex conjugate.) 22:51 < cwitty-1363> QQbar objects have "abs" and "norm" methods that act like CC. 22:52 < cwitty-1363> Really, my entire interest in the subject is in defining the real varieties of systems of polynomials with rational coefficients. 22:52 < cwitty-1363> So a version of AA without the embedding is useless to me. 22:53 < robertwb> makes sense 22:53 < was-1287> mabshoff -- my patch must do that -- I'll take a look. 22:54 < mabshoff> Thanks. 22:54 < mabshoff> Do we have any more patches qued to go in? 22:54 < mhansen> I'm just going through #1296 now. 22:54 < mabshoff> ok 22:54 < cwitty-1363> I'll probably have #799 reviewed in a few minutes. 22:55 < mabshoff> Excellent. 22:55 < mabshoff> I already mentioned in the alpha2 announcement that Bug Day 6 rocked! 22:55 -!- was-1287 is now known as was-1160-revisit 22:55 < mabshoff> :) 22:56 < robertwb> I'm looking at #1174, very small and looks good 22:57 < mabshoff> Well, we can certainly merge another batch of patches :) 22:59 < cwitty-1363> I'm still looking for reviewers for 1162, 1357, and 1363. 22:59 -!- roed-1128 is now known as roed-1242 23:00 < roed-1242> was-1160-revisit: I think I'm going to try to fix residue fields 23:00 < was-1160-revisit> Which fix? 23:01 < was-1160-revisit> Do you mean implement general quotients, or do you mean fix the printing? 23:01 < roed-1242> general quotients 23:01 < roed-1242> what's wrong with the printing? 23:01 < was-1160-revisit> 'cause I was just thinking about implementing residue fields in general too? 23:01 < roed-1242> Maybe I can fix that along the way 23:01 < roed-1242> Well then. :-) 23:01 < was-1160-revisit> roed -- we discussed printing above and came up with a nicer way to print them, remember. 23:01 < was-1160-revisit> But I would be fine doing something else. 23:01 < was-1160-revisit> I have thought through how to do general reduction though. 23:01 < was-1160-revisit> At least in theory. 23:02 < was-1160-revisit> Unfortunately, that was a month ago. 23:02 < roed-1242> Yeah, same 23:02 < was-1160-revisit> But I thought about how to reduce it all to just linear algebra mod p, basically. 23:02 < was-1160-revisit> Did you? 23:02 < roed-1242> why don't we figure out what should be done 23:02 < was-1160-revisit> ype. 23:02 < roed-1242> nope 23:02 < was-1160-revisit> ok. let me upload a fix for the 1160 breakage first. 23:02 < mhansen> robertwb: I get a few minor formatting errors and a segfault. 23:02 < robertwb> argh 23:03 < robertwb> do you have an example? 23:03 < roed-1242> I already fixed the quotient of vector spaces printing problems 23:03 < mhansen> Finding it now. 23:03 < was-1160-revisit> chris wuthrich also ran into a roadblock in his research because of missing residue fields in general. 23:03 < was-1160-revisit> So it is really really needed. 23:03 < was-1160-revisit> roed-1242: good. 23:04 < roed-1242> Alright. So, we start with an order which may or may not be maximal 23:04 < roed-1242> And a prime ideal 23:04 < was-1160-revisit> We start with a prime p and an order that definitely *is* p-maximal. 23:04 < roed-1242> Does pari automatically construct the maximal order when you do prime factorization? 23:05 < roed-1242> Fine: I was going back one step 23:05 < was-1160-revisit> We have to worry about how a prime ideal is represented -- let's just say an HNF basis. 23:05 < was-1160-revisit> Regarding whether or not pari forces maximal when factoring -- it's not too important, since we could easily implement 23:05 < roed-1242> Is that the default output of factor from pari? 23:06 < was-1160-revisit> an algorithm for factoring from scratch that doesn't force factoring. 23:06 < roed-1242> sure 23:06 < was-1160-revisit> which trac ticket are we working on? 23:06 < roed-1242> 1183 or 1242 23:06 < roed-1242> I think they're basically the same problem 23:07 -!- was-1160-revisit is now known as was-1183 23:07 < was-1183> let's call it #1183. 23:07 -!- roed-1242 is now known as roed-1183 23:08 < was-1183> sage: K.<z> = CyclotomicField(7) 23:08 < was-1183> sage: P = K.factor_integer(13)[0][0] 23:08 < was-1183> sage: P.pari_hnf() 23:08 < was-1183> [13, 0, 1, 10, 8, 10; 0, 13, 3, 5, 8, 12; 0, 0, 1, 0, 0, 0; 0, 0, 0, 1, 0, 0; 0, 0, 0, 0, 1, 0; 0, 0, 0, 0, 0, 1] 23:08 < was-1183> I think the first thing we should implement is a function I.free_module() that returns a ZZ-module that represents the ideal 23:08 < was-1183> as a ZZ-submodule of K.vector_space(). 23:09 < roed-1183> ok 23:09 < was-1183> Alternatively, I.free_module() could be in terms of K.maximal_order().basis() 23:09 < was-1183> I'm not sure which is best. 23:09 < was-1183> I don't like the latter actually, since it could be very expensive to compute, *and* it is confusing. 23:09 < roed-1183> yes 23:09 < was-1183> Since you have to think about multiple bases. It's what MAGMA/PARI do, though. 23:09 < was-1183> OK. so we implement I.free_module() first. 23:10 < was-1183> We also implement O.free_module() for O any order. 23:10 < roed-1183> Though one should be able to also create I as a submodule of a given order 23:10 < was-1183> creating ideals in orders isn't implemented at all at present. 23:10 < mhansen> robertwb: The error is pretty sporadic. 23:10 < was-1183> I think we should worry about that latter, though we should keep it in mind when designing. 23:10 < mhansen> *** glibc detected *** /opt/sage-2.8.15.alpha1/local/bin/python: munmap_chunk(): invalid pointer: 0x0000000001b8ed20 *** 23:10 < mhansen> ======= Backtrace: ========= 23:10 < mhansen> /lib/libc.so.6(cfree+0x1b6)[0x2b285e527826] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x435704] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x434164] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0xb35)[0x481d75] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x693e)[0x487b7e] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalCodeEx+0x830)[0x488ca0] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x4d2bac] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyObject_Call+0x13)[0x417b03] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x41e29d] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyObject_Call+0x13)[0x417b03] 23:10 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x1c12)[0x482e52] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalCodeEx+0x830)[0x488ca0] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x4d2c0e] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyObject_Call+0x13)[0x417b03] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x41e29d] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyObject_Call+0x13)[0x417b03] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x4599d8] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python[0x45c8d2] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyObject_Call+0x13)[0x417b03] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x1c12)[0x482e52] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalCodeEx+0x830)[0x488ca0] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x5ee4)[0x487124] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalCodeEx+0x830)[0x488ca0] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x5c32)[0x486e72] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalCodeEx+0x830)[0x488ca0] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x5c32)[0x486e72] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalCodeEx+0x830)[0x488ca0] 23:11 < mhansen> /opt/sage-2.8.15.alpha1/local/bin/python(PyEval_EvalFrameEx+0x5c32)[0x486e72] 23:11 < mhansen> /opt/sage-2. 23:11 < mhansen> Oops -- sorry about that everyone. 23:11 < mhansen> *** glibc detected *** /opt/sage-2.8.15.alpha1/local/bin/python: free(): invalid next size (fast): 0x000000000244fbe0 *** 23:11 < mhansen> *** glibc detected *** /opt/sage-2.8.15.alpha1/local/bin/python: munmap_chunk(): invalid pointer: 0x0000000001b8ed20 *** 23:11 < was-1183> roed -- http://wiki.sagemath.org/bug6/1183 23:12 < was-1183> roed-1183: 23:13 < roed-1183> ok 23:13 < robertwb> hmm.... 23:13 < was-1183> the basic idea is that to compute O/I we instead first compute (O mod p) and (Ibar subset O mod p). 23:13 < was-1183> Then we have two F_p vector spaces and compute the quotient of one by the other -- hey we just finished implementing that nicely :-) 23:13 < roed-1183> :-) 23:13 < roed-1183> Though presumably we only do this once 23:13 < was-1183> Once we have that, we "impose* the field structure on Obar/Ibar coming from the ring structure on O. 23:14 < was-1183> That's just a theoretical thing. 23:14 < roed-1183> And find a minimal polynomial 23:14 < mabshoff> was-1183: Did I miss a fix for 1160? 23:14 < was-1183> But if we just choose one random element of O, map it to Obar/Ibar, and see what it's minpoly is, we'll get an isomorphic finite field. 23:14 < was-1183> Viola! 23:14 < roed-1183> Right. Though we would like to have it be deterministic 23:14 -!- mhansen is now known as mhansen|brb 23:14 < was-1183> mabshoff -- yes, I posted a fix for #1160. 23:15 < mabshoff> ok, testing that now. 23:15 < was-1183> roed -- yep, replace "random" by an element found in order. 23:15 < was-1183> Either you or Robert Bradshaw made exactly the same comment last time this was discussed. 23:15 < roed-1183> And the first thing that we try is the generator of the number field 23:16 < roed-1183> So if the same polynomial reduced mod p works, then we use it 23:16 < was-1183> yep. 23:16 < was-1183> Assuming the nf gen is in O. 23:16 < roed-1183> right 23:16 < was-1183> This algorithm will work for any ideal in any order. 23:17 < roed-1183> yes 23:17 < was-1183> (I.e., it makes sense in more generality...) 23:17 < was-1183> So it's the right way to go. 23:17 < roed-1183> agreed. So the algorithm: 23:17 < was-1183> When computing the minpoly, I think we do that by computing the matrix whose rows are the powers of the reduction of our candidate. 23:17 < roed-1183> Agreed 23:17 < was-1183> We will have to invert that matrix to write down an explicit isomorphism to a GF(q). 23:17 < was-1183> See the wiki page I posted. 23:18 < roed-1183> (reloaded) 23:18 < was-1183> reload again. 23:18 < was-1183> Let's divvy up the work. 23:18 < cwitty-1363> mabshoff, I like #799. 23:18 < roed-1183> Is I a fractional ideal of K? 23:18 < mabshoff> Ok, the four doctests that used to fail now work again with william's fix. 23:18 < roed-1183> Or is I an ideal of the order 23:19 < was-1183> I is an ideal of the order. 23:19 < roed-1183> I guess it doesn't matter 23:19 < mabshoff> cwitty-1363: ok should I merge now? 23:19 < was-1183> Otherwise it doesn't work. 23:19 < roed-1183> Whatever I is, we just intersect with O 23:19 < was-1183> We could. 23:19 < cwitty-1363> Yes. 23:19 < mabshoff> ok, anybody else? 23:19 < roed-1183> Will intersecting with O cause any problems? 23:20 < was-1183> For everything to work, we'll want it to be a prime ideal for now, since we wnat to just use linear algebra over GF(p). 23:20 < was-1183> We should just require an ideal in O. 23:20 < mabshoff> Ok, looks like we need both patches for http://trac.sagemath.org/sage_trac/ticket/799? 23:20 < roed-1183> Okay. We can add on more functionality later. 23:21 < was-1183> yep. 23:21 < cwitty-1363> mabshoff, yes, both patches. 23:21 < was-1183> refresh again. 23:21 < mabshoff> np, going in. 23:21 < was-1183> roed -- I can do 1-2, why you do 3-4 assuming 1-2? 23:21 < robertwb> #1174 is ready to merge 23:21 < roed-1183> ok 23:21 < was-1183> 3-4 is the funnest, but 1-2 will be easy for me given what I've been working on today. 23:21 < was-1183> Ok, go. 23:22 < mabshoff> 799 is in. 23:23 < was-1183> great. 23:23 < was-1183> ! 23:24 < mabshoff> Well: any more prospects? Otherwise I am about to dump alpha2. 23:24 < robertwb> I'm testing #1128 now, but it looks good 23:25 < mabshoff> ok 23:25 < mabshoff> proof by induction: there is always one more patch to merge ;) 23:26 < robertwb> :), doesn't apply cleanly 23:26 < mabshoff> :( 23:26 < robertwb> roed: abort: unable to find sage/modules/quotient_module.py or sage/modules/quotient_module.py for patching 23:26 < robertwb> I bet I can edit the patch 23:27 < cwitty-1363> Looking at the patch, it doesn't seem like the quotient_module.py portion of it is vital :) 23:27 < mabshoff> ok, let me know if you have anything ready. Doctesting one last time. 23:28 < was-1183> :-) 23:28 -!- cwitty-1363 is now known as cwitty-1365 23:28 < was-1183> it's a space you added?1 23:30 < robertwb> ok, #1128 works great and is ready to go in 23:30 < mabshoff> :) 23:30 < was-1183> (robertwb -- by the way I have to say again I have a strangely very good feeling about that java3d stuff and sage...) 23:31 < rlm-1361> cwitty-1363: since you originally merged in the graph generators, could you please review #1361? 23:31 < rlm-1361> in your leisure... 23:31 < robertwb> :). I plan to get back to it a bit over the break 23:32 < cwitty-1365> robertwb, did you see me mention that I ported sage3d.jar to Jython? 23:32 < robertwb> yeah, pretty interesting 23:32 < robertwb> so, how does one run a Jython script? 23:32 < robertwb> (let alone a Jython applet?) 23:33 < cwitty-1365> Well, to get it to run as an applet, you use the "jythonc" compiler (which compiles to Java source, and then to .class files). 23:33 < cwitty-1365> And then it's just a normal applet. 23:33 < robertwb> huh 23:33 < cwitty-1365> There's also an interactive jython interpreter, that looks and acts a lot like Python. 23:33 < robertwb> well, I'm a fan 23:34 < cwitty-1365> Unfortunately, a lot of stuff (like eval) doesn't work in an applet, due to Java's security restrictions. 23:34 < robertwb> I guess Jython will be another jar to ship load with the applet though 23:34 < cwitty-1365> Yes. 1.2MB 23:35 < was-1183> Is there a Jython runtime jar? 23:35 < robertwb> I think there's hope to to have the client cache it though 23:36 < was-1183> It is amazing how fast every single thing I did with your java3d window has been so far. 23:36 < cwitty-1365> The 1.2 megabytes is the runtime jar. 23:36 < was-1183> It's quite smooth. 23:36 < was-1183> Ah, ok. 23:36 < cwitty-1365> (Well, it includes a lot of stuff that's not useful to us, so we could trim it by hand.) 23:40 < robertwb> mhansen: any more info on that segfault for permutation group elements? 23:40 < was-1183> roberwb -- by the way, thanks for finally implementing fast permutation group elements -- I've asked maybe 20 times for this from many different people... 23:41 < robertwb> It was so insanely slow for what it was doing (I was actually just cleaning up #444) and I figured I could do it faster... 23:41 < mhansen|brb> robertwb: Nothing yet although I had to take a bit of the break. 23:42 < robertwb> New tagline for cython: "speed up your code 4400x by implementing it in Cython" 23:43 < mabshoff> talk about speed: how about rewriting parts of cython in cython? :) 23:43 < was-1183> I really interesting benchmark would be your permutations versus native gap versus native magma. 23:44 < mhansen|brb> robertwb: It occurs most often in the direct_product_permgroups() function, but that doctest passes fine from the interpreter. 23:45 < robertwb> :( 23:46 < craigcitro-1231> man ... the fact that pari doesn't deal with number fields defined by a non-integral polynomial is incredibly painful at this point. the amount of bookkeeping i have to do to deal with something like factoring x^3-1/5 over x^4 - 1/7 is incredible. 23:48 < cwitty-1365> Craig, there's an implementation of that in qqbar.py; I don't know if there's anything you can use there. 23:48 < was-1183> Now imagine doing all that book-keeping in a painful C code with weird memory "management", and you see why PARI still doesn't do it... 23:48 < was-1183> At least you get to use Python. 23:48 < craigcitro-1231> hah true 23:49 < cwitty-1365> rlm-1361, mabshoff: 1361 looks good. 23:49 < craigcitro-1231> >cwitty-1365: do you move back and forth between pari and python there? 23:50 < mabshoff> cwitty-1365: ok, will merge. 23:50 < cwitty-1365> Yes. (Not necessarily efficiently, but I do.) 23:51 < craigcitro-1231> sweet. where should i look in here? 23:52 < cwitty-1365> Well, it's sort of scattered. 23:53 < cwitty-1365> Look at the .union() method on AlgebraicGenerator, 23:53 < cwitty-1365> and the exactify() method of ANRoot. 23:53 < cwitty-1365> Plus, I may be doing things totally stupidly anyway. 23:56 < cwitty-1365> And the actual factoring is in the exactify() method of AlgebraicPolynomialTracker, which looks like it uses factornf anyway. 23:56 < cwitty-1365> So maybe the whole "look at qqbar.py" thing was a waste of time. 23:56 < cwitty-1365> (I've been awake too long...) 23:56 < craigcitro-1231> well, something akin to what you do in do_polred is what i want ... but i'm (maybe stupidly) sticking with whatever polynomials pari chooses for these numberfields 23:57 < rlm-1361> ok, i'm done for tonight. thanks for the help everyone 23:57 < cwitty-1365> do_polred can be very slow. 23:57 < craigcitro-1231> it at least confirms that i'm not missing something obvious ;) 23:57 -!- rlm-1361 [[email protected]] has quit [] 23:57 < mabshoff> cu Robert 23:57 < craigcitro-1231> well, it's more serious than what i need 23:57 < craigcitro-1231> but the two maps between generators are good 23:57 < was-1183> cu 23:58 < craigcitro-1231> i mean, if i have a polynomial in T over a number field in a, and i want to change the representation for the number field 23:58 < craigcitro-1231> there's no painless way to do that, right? 23:58 < was-1183> yes, there is. 23:58 < was-1183> there is a painless way. 23:58 < craigcitro-1231> what's the painless way? 23:58 < was-1183> I added a bunch of nice stuff like that. 23:59 < craigcitro-1231> where? ;) 23:59 < craigcitro-1231> you didn't happen to also write code that deals with switching between integral and non-integral defining polynomials by chance, did you? ;) 23:59 < was-1183> sage: K.<w> = NumberField(x^4 + 1) 23:59 < was-1183> sage: L = K.change_generator(w^3 + 3) --- Day changed Sun Dec 02 2007 00:00 < was-1183> You could trivially do that using the code I wrote, I think. 00:00 < was-1183> That L above is really a 3-tuple with isomorphisms in both directions. 00:00 < was-1183> So if the defining poly is non-integral, just rescale the gen, then use change_generator. 00:00 < was-1183> I wrote that functionality for your application... 00:00 < was-1183> Cool, eh? 00:01 < craigcitro-1231> yeah, that seems pretty handy 00:01 < was-1183> I probably should have mentioned that before. 00:01 < craigcitro-1231> the only worry i have is that pari seems to be picking other weird polynomials when i give it a non-monic polynomial 00:01 < craigcitro-1231> (not weird, obv ... just not a scaled version) 00:02 < craigcitro-1231> but i think i could have pari tell me what it wants the number field to look like, create the new NumberField with change_generator 00:02 < craigcitro-1231> and that might be exactly what i need 00:07 < was-1183> you'll have to understand what pari is doing, since change_generator takes as input the generator (not its minpoly), and you want to avoid having to factor. 00:07 < was-1183> 00:08 < mabshoff> 1128 & 1361 have been merged. 00:11 < craigcitro-1231> when you call nfinit with a non-monic polynomial, it returns a vec of length 2, with the first element a pari_nf, and i'm pretty sure the second is exactly what i need to pass to your change_generator above (except that it's a pari gen, which i need to convert back to python) 00:11 < was-1183> cool. 00:11 < craigcitro-1231> actually, while i'm on the subject -- when you do, it prints a warning message. can we suppress that somehow? 00:11 < was-1183> yes it's possible. open source :-) 00:13 < craigcitro-1231> hahahahah 00:13 < craigcitro-1231> k 00:13 < craigcitro-1231> well, i'll either have to go make it optional in the pari source, or every time someone factors over a number field with a non-integral poly, they'll get a weird error message 00:14 < cwitty-1365> Craig, look at the documentation for nfinit(). I think in the non-monic case, you want to call it with flags=3. 00:14 < was-1183> it might be that the pari c library has an option to turn of the warning... 00:14 -!- mabshoff_ [[email protected]] has joined #sage-devel 00:15 < craigcitro-1231> >cwitty-1365: yeah, i think that'll kill the warning, since i'll then be explicitly asking it to do what it implicitly does anyway 00:16 < craigcitro-1231> yep. awesome. 00:27 < mabshoff_> ok, alpha2 is out: http://sage.math.washington.edu/home/mabshoff/sage-2.8.15.alpha2.tar 00:27 < mabshoff_> roughly 167MB 00:27 < was-1183> I'll build it on bsd. 00:28 < mabshoff_> Ok, I also announced on sage-devel. 00:28 < mabshoff_> I am catching some sleep now, it is 9:30 am locally. 00:28 < mabshoff_> cu guys in about 8 hours, or maybe not :) 00:28 < was-1183> ok. 00:28 < was-1183> cu 00:28 < mabshoff_> I will go through the tickets and ask for reviews 00:28 < was-1183> good idea. 00:29 < was-1183> should i also start a build on ppc or will you? 00:29 < was-1183> ie on fermat? 00:29 < mabshoff_> If malb or burcin don't answer I would suggest doing 2.8.15 tomorrow. 00:29 < was-1183> ok. 00:29 < was-1183> I'm for that. 00:29 < mabshoff_> Feel free to start onm fermat. I will build on PPC Linux locally. 00:29 < mabshoff_> We can 2.8.16 in a week then. 00:29 < was-1183> I think getting polybori in sage, and changing licenses (to not be gpl v2 compatible anymore) is 2.9 material. 00:29 < mabshoff_> ok 00:30 < was-1183> I don't think we should change license in the 2.8.x series. 00:30 < mabshoff_> If malb fixes http://trac.sagemath.org/sage_trac/ticket/1325 we are very close to 32 bit Solaris. 00:30 < mabshoff_> Yep, that is a good point. 00:30 < mabshoff_> I don't really care about the numbers, but the GPL change should be 2.9. 00:30 < mabshoff_> Oh well, tonight has been fun and really productive. 00:30 < was-1183> definitely very very productive. 00:31 < mabshoff_> :) 00:31 < mabshoff_> I will try to sort out some more Solaris issues in the short term. 00:31 < was-1183> excellent. 00:31 < mabshoff_> If Bill Hart pops up in the next couple hours we should do a FLINT 1.0 spkg - that should build on Solaris. 00:32 < mabshoff_> ok well. cu 00:32 -!- mabshoff_ is now known as mabshoff|asleep 00:33 -!- mabshoff [[email protected]] has quit [Read error: 110 (Connection timed out)] 00:46 < was-1183> I just found a serious bug in my #787 (quotients of vector spaces) implementation while working on #1183. My quotients of vector spaces implementation 00:46 < roed-1183> yeah? 00:46 < was-1183> need not work over a finite field, since it assumes that dot product of a vector with itsellf is nonzero! 00:46 < roed-1183> ah... 00:47 < was-1183> roed -- by the way, I finisshed step 1and was was working on step 2 trying several example to make sure things were good. 00:47 < roed-1183> That would be an issue for us. 00:47 < was-1183> I need to change the code that extends a list of independent vectors to a basis... 00:47 < roed-1183> ::nod:: 00:48 < roed-1183> I'm trying to figure out what the best strategy to search for the necessary element in 4 is 00:48 < was-1183> ah. 00:48 < roed-1183> Start with the number field generator 00:48 < roed-1183> And then you want an element whose powers span O tensor Q 00:49 < was-1183> I would do that, then just use the iterator over GF(p)^n (i.e., O tensor F_p) 00:51 < roed-1183> Is there an easy map from GF(p^n) back to O? 00:52 < was-1183> There *will* be. 00:52 < was-1183> But it's not GF(p^n) -- it's GF(p)^n. 00:52 < was-1183> Let me paste in the spec. 00:52 < roed-1183> ok 00:53 < was-1183> see http://wiki.sagemath.org/bug6/1183 00:53 < was-1183> not done 00:53 < was-1183> but should give you an idea. 00:53 < roed-1183> k 00:59 < roed-1183> will quotient_char_p be a class function of an order? 00:59 < roed-1183> Or a module function in residue_field.py 01:00 < was-1183> refresh the wiki. 01:00 < was-1183> it will be a method of an ideal. 01:00 < was-1183> That's for internal use. 01:01 < was-1183> Maybe it should be of an ideal. 01:01 < was-1183> I'm not too worried about that now. I just want it to work. 01:01 < roed-1183> Okay. It should return the two morphisms... 01:01 < roed-1183> (which it doesn't in the example) 01:01 < was-1183> yes, but it doesn't yet. but it will. 01:01 < roed-1183> k 01:01 < was-1183> not implemented. 01:02 < roed-1183> Our design should eventually work for relative extensions, giving a relative extension of residue fields 01:02 < roed-1183> But not yet 01:02 < roed-1183> :-) 01:03 < was-1183> yes. 01:04 < was-1183> ok, I fixed the quotient bug. 01:09 < roed-1183> good 01:25 -!- burcin [[email protected]] has joined #sage-devel 01:32 -!- jkantor [[email protected]] has quit ["leaving"] 01:33 < was-1183> roed-1183: how's it going? 01:33 < roed-1183> Not bad 01:33 < was-1183> I think I'm done with 1 and 2. 01:33 < roed-1183> I'm working on residue_field.pyx 01:34 < roed-1183> 3 is done 01:34 < roed-1183> I'm using a slightly different method for 4: 01:34 < roed-1183> Just use coordinates_in_terms_of_powers from number_field_element 01:36 < craigcitro-1231> man ... i think i'm just about done with this factorization thing. 01:36 < craigcitro-1231> it'd be so much faster if it didn't take upwards of 100 seconds to recompile this one file. ;) 01:36 < roed-1183> yeah, that sucks 01:37 < was-1183> which file? 01:37 < craigcitro-1231> not as bad as changing a decl.pxi in libs/pari or libs/ntl, of course ;) 01:37 < craigcitro-1231> polynomial_element.pyx 01:37 < was-1183> maybe you could copy the relevant code into python, work on it there, then copy it back? Is it really cython code? 01:38 < was-1183> Sometimes too much of sage code is in cython for no real reason... 01:39 < craigcitro-1231> well, this particular chunk of code ends up making a few pari library calls ... seems better to do that from cython 01:39 < roed-1183> I put up #3 01:41 < was-1183> I'll put up 1/2 in a moment -- I have to fix some doctest failures caused by changing how quotient works. 01:45 < was-1183> This fixes the quotient issue: http://trac.sagemath.org/sage_trac/ticket/1368 01:47 < was-1183> where did you post 3? 01:48 < was-1183> I posted 1-2 here: http://trac.sagemath.org/sage_trac/ticket/1183 01:48 < was-1183> ah, in the wiki. 01:49 < was-1183> roed-1183 -- something looks weird about 3, since it's double spaced partly?? 01:49 -!- jkantor [[email protected]] has joined #sage-devel 01:50 < roed-1183> I noticed that. I don't know why 01:50 < jkantor> did anybody build alpha-2? 01:52 < was-1183> I am trying. 01:52 < was-1183> I actually had a build and am now doctesting it. 01:52 < was-1183> on osx 10.5 intel. 01:53 < was-1183> I did a 64-bit linux build and it built fine and passed all tests. 01:53 < jkantor> on sage.math it fails 01:53 < jkantor> flint still fails 01:54 < jkantor> and even after I disabled that it still failed 01:55 < was-1183> roed-1183 -- you seem to have ignored the changes I made to residue_field.pyx ? 01:55 < roed-1183> yeah, i realized that. I will stick them in 01:55 < was-1183> e.g., I changed to use names which is very important so the notation K.<a> = blah... works. 01:55 < roed-1183> I haven't been keeping up to date 01:55 < roed-1183> Yeah, I know 01:55 < roed-1183> I'll fix it 01:55 < roed-1183> :-) 01:55 < was-1183> It was quite hard getting the names stuff right actually; there are lots of little subtle things that can go wrong... 01:56 < was-1183> or maybe I just was slow when I wrote it since the code you wrote was new to me. 02:00 < craigcitro-1231> wahoo! i think i'm done with this crazy changing bases in number fields. 02:01 < was-1183> yeah! 02:04 < was-1183> roed-1183, I did a little cleanup of ResideField (the names and some imports) 02:04 < was-1183> I put it at http://wiki.sagemath.org/bug6/1183 02:04 < roed-1183> cool 02:04 < was-1183> You can take it or ignore it (depending on what you're doing). 02:04 < was-1183> I didn't get it to "work" though. 02:04 < was-1183> It will run but it says the charpoly you get is reducible. 02:04 < roed-1183> I'm still editing the rest of residue_field.pyx 02:05 < was-1183> what are you doing to it? 02:05 < roed-1183> oh 02:05 < roed-1183> no, that shouldn't be the case 02:05 < was-1183> I also added a lot of doctests to it so the coverage is 100% 02:05 < roed-1183> good 02:05 < was-1183> (for the rest of the file.) 02:05 < was-1183> So if you're editing a different version that could be bad. 02:06 < roed-1183> I am, but only source code 02:06 < roed-1183> Not documentation 02:06 < was-1183> ok. 02:06 < was-1183> maybe. 02:06 < was-1183> scary. 02:06 < roed-1183> Can you give me a .patch file or something? 02:07 < was-1183> I was working with people at Reed on Thursday and ran into some major issues with residue_field, which is what I fixed... 02:07 < roed-1183> ok 02:07 < was-1183> It was unpleasant actually... 02:07 < roed-1183> :-/ 02:07 < was-1183> since I was in front of several peole. 02:07 < roed-1183> yeah 02:07 < was-1183> http://trac.sagemath.org/sage_trac/ticket/1342 02:08 < was-1183> It turned out to be just that there was an assumption you made (very natural) that stupidly wasn't satisfied by 02:08 < was-1183> pari_ext elements. 02:08 < was-1183> Fixing it wasn't so hard. 02:11 < was-1183> your algorithm for determining if x generates is wrong, I think. 02:11 < was-1183> I had thought that would work at first. 02:12 < was-1183> never mind, I may be confused. 02:12 < craigcitro-1231> cwitty-1365: you still around? 02:12 < roed-1183> You should figure it out. :-) I think it works, though I'm a little uneasy 02:13 < was-1183> deal. 02:14 < craigcitro-1231> well, cwitty-1365 -- if you read this in the morning, could you look at 1129 again and comment on it? i fixed the nfinit thing you pointed out, and (finally) got it working with non-integral polynomials 02:15 < craigcitro-1231> or anyone else reading this, you're welcome to comment on it. 02:19 < craigcitro-1231> was-1183: the version of pari included with sage is the stable branch, right? 02:20 < was-1183> yes. 02:20 < craigcitro-1231> k 02:20 < roed-1183> was-1183: where did you put 1 and 2? 02:21 < roed-1183> Is there a .patch file for those? 02:21 < was-1183> http://trac.sagemath.org/sage_trac/ticket/1183 02:23 < was-1183> roed -- I'm working on the ResidueField function, fyi... 02:25 < roed-1183> what about it? 02:25 < roed-1183> I'm not working on it more at this point 02:25 -!- jkantor [[email protected]] has quit ["leaving"] 02:25 < was-1183> dang; now I have to figure it out :-) 02:30 < was-1183> it's working now, maybe. 02:30 < was-1183> sage: K.<a> = NumberField(x^3-875); P = K.ideal(5).factor()[0][0]; k = K.residue_field(P); k 02:30 < was-1183> Residue field in abar of Fractional ideal (5, -2/25*a^2 - 1/5*a + 2) 02:30 < was-1183> sage: k.polynomial() 02:30 < was-1183> abar^2 + 3*abar + 4 02:30 < was-1183> sage: k.0^3 - 875 02:30 < was-1183> 2 02:31 < was-1183> Of course "abar" isn't the reduction of a. 02:35 < roed-1183> ::nod:: 02:35 < roed-1183> I found a bug. Fixing it now 02:35 < roed-1183> (raising 0^0) 02:35 < was-1183> I got that already. 02:35 < roed-1183> ok 02:35 < was-1183> I should send you an update. 02:35 < roed-1183> Sounds good 02:36 < was-1183> how? 02:36 < was-1183> I can give you a patch or the whole file or? 02:36 < roed-1183> patch probably 02:36 < roed-1183> Though I don't understand why it's working for you unless you changed other things 02:36 < was-1183> the patch will be against vanilla + #1342, ok? 02:36 < roed-1183> sure 02:36 < roed-1183> Then I'll put up a patch too 02:39 < was-1183> ok, I've posted it at http://trac.sagemath.org/sage_trac/ticket/1183 02:39 -!- robertwb [[email protected]] has left #sage-devel [] 02:39 < was-1183> it is: trac-1183-through_step_3.patch 02:40 < was-1183> O 02:40 < was-1183> I'm just working on the explicit maps now. 02:45 < roed-1183> what explicit maps? 02:45 < roed-1183> I already have some of that 02:45 < craigcitro-1231> fixed 1231 (it was a <20 char fix) -- can someone look at it when they have a spare min? 02:45 < was-1183> roed -- I almost almost done implementing explicit maps. 02:46 < roed-1183> what do you mean by explicit maps? 02:46 < was-1183> Given P we need explicit (partial) maps and sections from K --> O_K/P and from O_K/P --> O_K. 02:47 < roed-1183> You mean to fix NFHomomorphism 02:47 < roed-1183> I've already done that 02:47 < was-1183> I think it would be good to have available a partial map from K (not just from O_K). 02:47 < roed-1183> sure 02:48 < roed-1183> certainly OK.residue_field(5)(K(4/7)) or something should work 02:48 < was-1183> ok. 02:49 < was-1183> so you've rewritten NFResidueFieldHomomorphism. 02:49 < roed-1183> yeah 02:49 < was-1183> Did you do that by computing the power basis matrix again and inverting it? 02:49 < roed-1183> And the __init__ methods for the different residue fields 02:50 < was-1183> Did you do that by computing the power basis matrix again and inverting it? 02:50 < roed-1183> I used coordinates_in_terms_of_powers 02:50 < was-1183> ??? 02:50 < was-1183> How can that possibly work. 02:50 < was-1183> Oh, since the its the powers of something arbitrary. 02:50 < roed-1183> def __init__(self, k, p, x, im_gen): 02:50 < roed-1183> self.im_gen = im_gen 02:50 < roed-1183> if not is_FiniteFieldElement(im_gen): 02:50 < roed-1183> raise TypeError, "im_gen must be a finite field element" 02:50 < roed-1183> (<Element>self.im_gen)._set_parent_c(k) 02:50 < roed-1183> self.p = p 02:50 < roed-1183> self.x = x 02:50 < roed-1183> self.R = PolynomialRing(k, 'x') 02:50 < roed-1183> self.to_list = x.coordinates_in_terms_of_powers() 02:51 < roed-1183> ResidueFieldHomomorphism.__init__(self,Hom(p.number_field().maximal_order(), k, Rings())) # should eventually change to p.order() 02:51 < roed-1183> Where are you editing? 02:52 < roed-1183> My import of 1342 failed and I had to do some stuff manually. So I can offer a patch against sage without 1342 or any of our work. Or I can just put things for you to insert manually and then you can release a final patch 02:53 < was-1183> Probably safest right now is the latter. 02:53 < roed-1183> ok 02:53 < roed-1183> I'll put them on the wiki page at the bottom 02:53 < was-1183> ok. 02:53 < was-1183> I am having some small worry about the coordinates_in_terms_of_powers function, for efficiency reasons. 02:54 < was-1183> Typically power basis can be vastly more nasty size-wise than say the basis for the ring of integers. 02:54 < was-1183> Also, all the data needed to do the reduction using the ring of integers basis is already computed (in order to those to_vs and to_order maps). 02:54 < was-1183> I think coordinates_in_terms_of_powers basically takes all the powers of an element and inverts the matrix of those powers. 02:55 < was-1183> It seems to me that it would be better to do that arithmetic mod p. 02:55 < was-1183> Do you know what I mean. 02:55 < craigcitro-1231> was-1183: i have a modular symbols question for you when you have a sec. (i'm going to start glancing in your book in the interim.) 02:57 < was-1183> If PB is the power basis matrix mod p, then: 02:57 < was-1183> # The reduction map is just x |--> k(to_vs(x) * (PB**(-1))) 02:57 < was-1183> # The lifting map is just x |--> to_order(x * PB) 02:57 < craigcitro-1231> actually -- do you talk about modular symbols over an arbitrary base ring in your book? 02:57 < was-1183> no 02:58 < craigcitro-1231> grin ... k 02:58 < craigcitro-1231> lemme dig out gabor's notes. ;) 03:00 < roed-1183> sure. That sounds better 03:00 < roed-1183> So if you want you can just ignore my changes if you've already done that 03:01 < was-1183> But I can see why you liked coordiantes_in_terms_of_powers since it fits so well with the rest of your code. 03:01 < was-1183> And in the special case when the gen works, we have to not do something inefficient. 03:02 < roed-1183> yeah 03:02 < was-1183> So I guess we need two types of NFResidueFieldHomomorphism? 03:02 < was-1183> Then we pass one of those into the __init__ for each wrapper class. 03:03 < roed-1183> can't do it that way 03:03 < was-1183> why? 03:03 < roed-1183> The field has to be created first 03:03 < roed-1183> since it's the domain of the morphism 03:03 < roed-1183> Well, I guess you could do something tricky 03:03 < roed-1183> like resetting the domain after creating the map 03:03 < roed-1183> ::shrug:: 03:04 < was-1183> No. 03:04 < was-1183> You're right. 03:05 < was-1183> We just make NFResidueFieldHomomorphism a factor function that constructs two possible types of objects. 03:07 < roed-1183> sure. And we'll need another object for the morphism defined on the localization away from P, and another one for the section 03:07 < roed-1183> :-) 03:07 < was-1183> yes. 03:07 < was-1183> That makes sense. 03:08 < was-1183> But I'm very tempted to make fake-ish partial maps defined as much as possible, then implement all the structural ones in terms of those, just to keep the code organized. 03:08 < was-1183> (No duplication.) 03:08 < roed-1183> what do you mean fake-ish partial maps? 03:08 < was-1183> By "defined as much as possible" I guess I just mean on the localization. 03:08 < was-1183> class's that aren't official homomorphisms. 03:09 < was-1183> They are for internal use only. 03:09 < roed-1183> sure 03:09 < roed-1183> I like that plan 03:09 < was-1183> How about if I make two callable classes like that, then give you clean code that 100% works with those, then you could rewrite the sructural stuff to use them? 03:10 < roed-1183> sure 03:10 < was-1183> I think I could do that in < 15 minutes. 03:10 < roed-1183> Sounds good 03:10 < was-1183> I'll give it a shot. 03:10 < roed-1183> I'll work on p-adics for a little bit 03:10 < was-1183> :-) 03:12 < craigcitro-1231> was-1183: you have a sec for a modsym question? 03:12 < was-1183> you can write the question. I might answer it. 03:12 < craigcitro-1231> namely, what happens to the atkin-lehner involution at 2? 03:13 < was-1183> at 2? 03:13 < craigcitro-1231> because suddenly there aren't two different eigenspaces 03:13 < was-1183> what's "at 2" 03:13 < craigcitro-1231> mod 2 03:13 < craigcitro-1231> sorry 03:13 < was-1183> ahh. 03:13 < was-1183> I don't know. 03:14 < was-1183> by the way, I started a google group called bsd-research -- you might want to join. 03:14 < was-1183> http://groups.google.com/group/bsd-research 03:14 < craigcitro-1231> nods ... i'll do that right now 03:31 < craigcitro-1231> wow ... karim belabas already fixed the bug in factornf ; that means i could have just *not bothered* with that numberfield code i wrote. *sigh* 03:31 < was-1183> wow. 03:32 < was-1183> is it still valuable for something? 03:32 < was-1183> e.g., could you easily make it so number fields constructed with funny polynomials work. 03:32 < was-1183> I.e., psychologically you could do that? 03:32 < craigcitro-1231> yeah, it shouldn't be too hard. 03:33 < craigcitro-1231> it'd just be basically copy-pasting that code into anything that uses pari within the number field code. 03:33 < craigcitro-1231> (or making an interface and using it everywhere, rather.) 03:33 < was-1183> it's mainly a design thing, I hope. 03:36 < craigcitro-1231> yeah. i mean, nffactor is also supposed to be faster than factornf in general (they use different algorithms, despite having basically the same name ... because that's not confusing at all). 03:36 < craigcitro-1231> so it's not all for naught. 03:36 < was-1183> :-) 03:37 < was-1183> factornf and nffactor?! 03:37 < craigcitro-1231> yeah 03:38 < craigcitro-1231> alright, i'm gonna head to bed, i think. 1129 and 1231 are done, and i commented in 1232 that once we know if something is true mathematically, it's easy to fix the code. 03:39 < was-1183> thanks. cu 03:39 < roed-1183> goodnigth 03:39 < craigcitro-1231> lates 03:39 -!- craigcitro-1231 [[email protected]] has quit [] 04:01 < roed-1183> was-1183: how's it going? 04:01 < was-1183> ok. 04:01 < was-1183> I ran into a problem with _ext_pari when testing large cases. 04:01 < was-1183> I don't know if it was there before or not. 04:02 < roed-1183> what's happening? 04:02 < was-1183> it says the defining poly is reducible. 04:02 < roed-1183> Is it? 04:03 < was-1183> yes. 04:03 < roed-1183> hm 04:03 < roed-1183> So can we just insert that check after (rank == n)? 04:03 < was-1183> the poly has the wrong degree. 04:05 < was-1183> oh, of course, I forgot. 04:06 < roed-1183> oh 04:06 < roed-1183> You have to strip the zero 04:06 < was-1183> There was a problem in your code for the gen reduction case -- one still has to pick out the right factor... 04:06 < roed-1183> ah 04:06 < roed-1183> right 04:06 < roed-1183> Which I had before 04:06 < roed-1183> But deleted 04:06 < was-1183> yes. 04:06 < roed-1183> I think the way to solve the other problem 04:06 < was-1183> or maybe not. 04:07 < was-1183> I'm going to comment that case out for now. 04:07 < was-1183> Since I want to hand you something that fully works. 04:07 < roed-1183> is to change f = R((-M.column(n)).list() + [1]) 04:07 < was-1183> Gees it is slow without that case... 04:07 < roed-1183> to f = R((-M.column(n)).list()[:-1] + [1]) 04:08 < roed-1183> no, never mind 04:08 < roed-1183> I was thinking there was a row of zeros at the bottom 04:08 < roed-1183> But there isn't 04:08 < was-1183> that is wrong too. 04:10 < roed-1183> If M has rank n 04:11 < roed-1183> Then there is no relation between the powers of x 04:11 < roed-1183> of degree less than n 04:11 < was-1183> the degree of the poly is wrong. 04:12 < roed-1183> The degree of f isn't the residue_class_degree? 04:13 < was-1183> yes 04:13 < was-1183> it makes no sense. 04:14 < was-1183> I made a dumb mistake. 04:14 < roed-1183> what? 04:15 < was-1183> I had refactored some code so that I could keep the powerbasis mod p around. 04:15 < was-1183> But I donly did it correctly in 1 of the 2 (lamely) duplicated places. 04:15 < roed-1183> ah 04:21 < roed-1183> Alright. I should go to sleep 04:21 < was-1183> same here. 04:21 < was-1183> I'll send you an email before I go to sleep to let you know what happened. 04:21 < roed-1183> sounds good 04:22 < roed-1183> goodnight 04:24 -!- roed-1183 is now known as roed-asleep