Re: [sage-combinat-devel] Re: LACIM + GASCOM
Hi, On Fri, 6 Aug 2010 21:37:30 -0700 (PDT), Alexandre Blondin Massé alexandre.blondin.ma...@gmail.com wrote: - There is only one day available, which is September 1st, for this Sage Day (not official, I know, but I can still call it that way!). We have the whole day. Maybe starting around 9am and ending around 5-6pm would be good (but not mandatory), which is about the same schedule as for GASCom and LaCIM 2010. There's no such thing as an official or unofficial Sage Day; by which I mean that you do not need approval to call this event a Sage Day. It involves people who have been contributing to Sage, and people who want to learn more about Sage, so the name is very appropriate. Looking at the list of Sage Days at wiki.sagemath.org it seems that the correct numerical value would be Sage Day 25.5 :) - I have already the rights to put web pages on the LaCIM server: therefore, I can be in charge of the website for this Sage Day. It would be great if you could put a link to that website up on the Sage wiki (wiki.sagemath.org) in the list of workshops. Have fun! Alex -- Alex Ghitza -- http://aghitza.org/ Lecturer in Mathematics -- The University of Melbourne -- Australia -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: LACIM + GASCOM
- Lastly, from memory, among the developpers, there will be Sébastien, Vincent, Franco (not sure about him), Christian (Stump), you and I. I will definitely be there! Franco -- -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: LACIM + GASCOM
Hi! Thanks Florent for starting this topic. It's time to start organizing this! - I have already the rights to put web pages on the LaCIM server: therefore, I can be in charge of the website for this Sage Day. Alex, I propose not to do a web page on the LaCIM server. My opinion is that web pages are often not that practical for Sage Days because it centralizes its management. A wiki page is lot more convenient. It can be updated by anyone, people can add their pdf presentations, etc. So I will create such a page right now and will try to gather all the basic informations we have (date, people attending, objective ...). I think it can be a good way to start the organisation. Sébastien -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: LACIM + GASCOM
Hi Alexandre, I'll meet next week with Sébastien and we'll start thinking more deeply about the logistic of the event. Looking forward to seeing you again in Montreal ! Ok ! I'll contact you when I arrive in Montreal ! Good summer ! Florent -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: LACIM + GASCOM
So I will create such a page right now and will try to gather all the basic informations we have (date, people attending, objective ...). I think it can be a good way to start the organisation. The page is up (it is a first version) : http://wiki.sagemath.org/days25.5 I put the information I have and wrote a small section about the goals of the day as I see them. Please read it and edit it so that the goals become as WE see them! There is also a Projects section that you can edit. Florent : I added you as an invited speaker. Thanks for your proposal for giving an introductory talk! Sébastien -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: LACIM + GASCOM
Alex, I propose not to do a web page on the LaCIM server. My opinion is that web pages are often not that practical for Sage Days because it centralizes its management. A wiki page is lot more convenient. It can be updated by anyone, people can add their pdf presentations, etc. So I will create such a page right now and will try to gather all the basic informations we have (date, people attending, objective ...). I think it can be a good way to start the organisation. Great, I agree with you. By the way, how can I edit it ? -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: LACIM + GASCOM
We should definitely include talking about iterators, since they are very useful for enumeration purposes and the audience will be interested in that. I know that we will talk about it, but, in my opinion, it would be good to show many examples of iterators over various structures and maybe even make the audience try to create one. What do you think ? Is it reasonable to use some time for that ? Alex -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-devel] Using testscript from inside a sage session?
On 08/ 7/10 04:48 AM, Mitesh Patel wrote: We're in the *very* early stages of developing a new doctesting API at http://trac.sagemath.org/sage_trac/ticket/9224 Unifying sage-test and sage-ptest does make sense. I'm not over-impressed with the current system. I've had tests fail with zero failures and all many of other inconsistencies. Run make ptestlong and one gets a failure. Run the test from the command line and it passes. I've no idea why. I've seen a comment from I believe Dan on one of the tickets that ptest has some alful code in it. Also useful would be if the data and time of the test was recorded. Then if a failure does occur, one could look at the system log files and see if there was an I/O problem, running out of swap space or similar. Just make sure it's done in a portable way. Other useful things would be to have at the very least the host name and operating system stored. Perhaps once at the top, and once in the summary to record that information. I'd personally like to see some way of testing Sage from the browser interface. I've posted a maxima example before, where one of the examples in the Sage manaual was incredibly badly formatted (unusable) in the browser front end, yet that same doctest has passed. That however would need a totally different approach - a non-trivial one at that! But perhaps the ability to run the test scripts from inside the Sage session would go some way to resolve this. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Some feature requests on SAGE - Adding Engineering to the target audience
On Aug 3, 5:52 am, Jason Grout jason-s...@creativetrax.com wrote: 6. TRANSPOSE/CONJUGATE It seems that implementing this would just involve modifying the __pos__(self) method for complexes, matrices and complex matrices, and I think that both conjugating and transposing are common enough operations to deserve its own operator. Numpy has: m.T for transpose m.H for hermitian m.I for inverse (seehttp://www.scipy.org/NumPy_for_Matlab_Users312) I think it would be great if we had similar shortcuts. I always assumed that the lack of these was just that nobody had bothered to implement them, not that anyone were actually against them? a) At least the .T is so completely ingrained into the NumPy/SciPy community that it would at least be very strange to go with some *other* form of operator (like has been proposed) b) It's Python compatible c) It's incredibly convenient. +1 to .T and .H. BUT, -1 to .I for the inverse, because the *intent* of arr.I * x is almost certainly arr.solve_right(x). Actually taking the inverse, arr.inverse(), is something you rarely want to do, and in those cases, having to type out inverse is a good thing IMO. Just keeping shorthand syntax like that out helps reduce bad habits. (If a .I was supported I'd prefer it to be a lazy symbolic inverse that triggered solve_right on multiplication, i.e. a Python-compatible \-operator?, but obviously it's better to avoid the question currently.) Dag Sverre -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Some feature requests on SAGE - Adding Engineering to the target audience
On Fri, Aug 6, 2010 at 4:52 PM, cousteau cousteaulecommand...@gmail.com wrote: The aim of my syntax suggestion wasn't to clone Matlab's syntax, but to provide an easy way to input matrices. Speaking of syntax and matrices, let's not forget the seemingly bizarre behavior one gets when one does sage: trace(M) for a matrix M. I can imagine this putting people off... Perhaps the trace command should detect matrix inputs and print a helpful error message at the very least? -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: What components of Sage would most benefit from SPARC assembly code?
Yes, sorry for not providing email addresses. It is best to write to the contact address on the MPIR webpage, or email me and I'll pass the message on to the MPIR developers. Of course if it is not confidential, please post directly to the MPIR development list (in CC). Thanks, Bill. On 7 Aug, 00:16, Carl Witty carl.wi...@gmail.com wrote: On Fri, Aug 6, 2010 at 9:18 AM, Dr. David Kirkby david.kir...@onetel.net wrote: On 08/ 6/10 05:14 AM, Robert Bradshaw wrote: On Thu, Aug 5, 2010 at 3:25 AM, Bill Hartgoodwillh...@googlemail.com wrote: The single biggest improvement in my mind would be made to MPIR. And I know the MPIR devels would absolutely love to have them contribute. Jason and Brian have been working very hard on simplifying MPIR so that it can be more easily modified. Bill mentioned a couple of names, but no surnames and no email addresses. Could he provide a bit more information (by private email if he wishes). I should see the SPARC guru later this month and will discuss with him. I'm pretty sure he's referring to Brian Gladman and Jason Moxham, the first two names in the Contributors list athttp://www.mpir.org/. That page also has contact information (the mailing listhttp://groups.google.com/group/mpir-devel) and a list of important development directions that includes # Assembly support for Itanium, recent Sparc chips and MIPS. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: What components of Sage would most benefit from SPARC assembly code?
On 08/ 7/10 01:25 PM, Bill Hart wrote: Yes, sorry for not providing email addresses. It is best to write to the contact address on the MPIR webpage, or email me and I'll pass the message on to the MPIR developers. Of course if it is not confidential, please post directly to the MPIR development list (in CC). Thanks, Bill. It's no problem. I'll print off the relevant information and suggests he contact the developers. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Source code of sympow must makes no sense
sympow seems to have presented some problems on Solaris 10 on x86. I've tried
looking at this source code, and it makes little sense whatsoever to me.
William has tried to clean up the 'Configure' script, though it's still very
messy, with things like
SH=`whichexe sh` echo #define SH \$SH\ $CONFIG
if [ -z $SH ]; then
echo **ERROR**: Could not find sh; exit 1;
else
echo SH = $SH
fi
Anyway, that aside, lets get to the C source code.
I tried to compile this with the Sun compiler, thinking that would help trace
the problem. Well, it indicates a problem on line 68 of compute2.c
/bin/cc -O3 -c -o compute2.o compute2.c
compute2.c, line 68: void function cannot return value
Looking at line a dozen or so lines either side of line 68, in the function
pth_coeff_from_ap, we see:
void pth_coeff_from_ap(int W,llint p,int ap,int sp,QD x) /* p2^50 */
{QD t={0.0,0.0,0.0,0.0},u={0.0,0.0,0.0,0.0},v={0.0,0.0,0.0,0.0}; int i;
QD y={0.0,0.0,0.0,0.0},z={0.0,0.0,0.0,0.0}; int W2=2,W3=3,W4=4; QD ppow[16];
if (W4) {W4=W; if (W3) {W3=W; if (W2) W2=W;}}
QD_copy(wmax,QD_zero,x); if ((HECKE) (ap==0)) return;
if (HECKE) return power_trace_from_ap(W,p,ap,sp,x); /* LINE 68. !!! */
if (ap==0) {if (!(sp1)) {t[0]=(double) (-p); QD_powi(W,t,sp/2,x);} return;}
switch(sp)
{case 1: x[0]=(double) ap; return;
case 2: x[0]=(double) ap; x[0]=x[0]*x[0]-(double) p; return; /* a^2-p */
case 3: y[0]=(double) ap; x[0]=y[0]*y[0]-(double) (2*p);
QD_mul1(W2,x,y[0],x); return; /* a^3-2pa */
Se we can see that if(HECKE) this is supposed to return a value from
power_trace_from_ap
But looking at power_trace_from_ap, we see it's declared as returning noting
(void)
void power_trace_from_ap(int W,llint p,int ap,int sp,QD x) /* p2^50 */
{QD t={0.0,0.0,0.0,0.0},u={0.0,0.0,0.0,0.0},v={0.0,0.0,0.0,0.0}; int i;
QD y={0.0,0.0,0.0,0.0},z={0.0,0.0,0.0,0.0}; int W2=2,W3=3,W4=4; QD ppow[16];
if (DEBUG) printf(power_trace_from_ap %lli %i %i\n,p,ap,sp);
if (W4) {W4=W; if (W3) {W3=W; if (W2) W2=W;}}
QD_copy(wmax,QD_zero,x); if (sp==1) {x[0]=(double) ap; return;}
y[0]=(double) ap; y[0]=y[0]*y[0];
QD_copy(W4,QD_one,ppow[0]); QD_copy(W4,QD_zero,ppow[1]);
I don't know how gcc manages to compile this myself, but when it does not work,
its hard to know what one is supposed to do when the code just looks wrong to me.
Likewise pth_coeff_from_ap is declared as void, but returns a value.
To me, this is just buggy gcc compiling code it should never compile. The fact
the formatting of the code is a bit non-C like probably confuses gcc a bit.
Anyway, does anyone know how to sort this out, as I don't have a clue. It's
simply not valid C, and I have no idea what the intension is either.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Source code of sympow must makes no sense
On Sat, Aug 07, 2010 at 02:47:45PM +0100, Dr. David Kirkby wrote:
sympow seems to have presented some problems on Solaris 10 on x86. I've
tried looking at this source code, and it makes little sense whatsoever
to me.
snip
Anyway, that aside, lets get to the C source code.
I tried to compile this with the Sun compiler, thinking that would help
trace the problem. Well, it indicates a problem on line 68 of compute2.c
/bin/cc -O3 -c -o compute2.o compute2.c
compute2.c, line 68: void function cannot return value
Looking at line a dozen or so lines either side of line 68, in the
function pth_coeff_from_ap, we see:
void pth_coeff_from_ap(int W,llint p,int ap,int sp,QD x) /* p2^50 */
snip
Se we can see that if(HECKE) this is supposed to return a value from
power_trace_from_ap
snip
I don't know how gcc manages to compile this myself, but when it does not
work, its hard to know what one is supposed to do when the code just
looks wrong to me.
Likewise pth_coeff_from_ap is declared as void, but returns a value.
I may be missing something, but isn't this basically a case of the following?
void f()
{
}
void g()
{
return f();
}
You're right that it isn't valid C, but it suggests neither f nor g, (or
power_trace_from_ap or pth_coeff_from_ap) actually returns anything.
To me, this is just buggy gcc compiling code it should never compile.
The fact the formatting of the code is a bit non-C like probably confuses
gcc a bit.
Yes, gcc accepts some things which aren't valid C (or C++), but so does pretty
much every compiler out there. It can indeed be very annoying when porting
software (and I've done my fair share of that), but you can't reasonably expect
everyone to be 100% aware of all the subtleties of the C and C++ standards (let
alone the various revisions of the standards, the parts of the languages left
unspecified, and the interpretations of all the compilers/runtimes out there),
or of having easy access to multiple platforms to test things on.
From my experience, by far the most efficient way of writing cross-platform
code is being reasonably aware of the relevant standards, and then simply fix
any remaining issues as they pop up.
Please don't take this the wrong way, as I greatly appreciate how much work
you're doing on making sage and its various components more cross-platform. I
know it's very hard work, and often frustrating, but I wish you would try to be
a little bit less judgemental about standards compliance.
Sorry for going far off-topic here...
In any case, thanks for pointing out this issue. I think the fix would be
replacing
if (HECKE) return power_trace_from_ap(W,p,ap,sp,x);
by
if (HECKE) {
power_trace_from_ap(W,p,ap,sp,x);
return;
}
.
Thanks,
Willem Jan
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Source code of sympow must makes no sense
On 08/ 7/10 03:37 PM, Willem Jan Palenstijn wrote: From my experience, by far the most efficient way of writing cross-platform code is being reasonably aware of the relevant standards, and then simply fix any remaining issues as they pop up. Please don't take this the wrong way, as I greatly appreciate how much work you're doing on making sage and its various components more cross-platform. I know it's very hard work, and often frustrating, but I wish you would try to be a little bit less judgemental about standards compliance. Who are you quoting? It was not me that said anything about reasonably aware of relevant standards! I would have thought the most efficient way was to be aware of current standards and test the code on at least two compilers - ideally on two different systems. BTW, SunStudio is a free download on Linux. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Source code of sympow must makes no sense
On Sat, Aug 07, 2010 at 03:59:49PM +0100, Dr. David Kirkby wrote: On 08/ 7/10 03:37 PM, Willem Jan Palenstijn wrote: From my experience, by far the most efficient way of writing cross-platform Who are you quoting? I'm not quoting. Somewhere in the email chain the escaped From wasn't un-escaped. (Lines starting with From get an extra ' ' prepended to prevent them from being interpreted as a 'start of message' header in the mbox format.) -Willem Jan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Some feature requests on SAGE - Adding Engineering to the target audience
On Sat, Aug 7, 2010 at 5:23 AM, Robert Miller r...@rlmiller.org wrote: On Fri, Aug 6, 2010 at 4:52 PM, cousteau cousteaulecommand...@gmail.com wrote: The aim of my syntax suggestion wasn't to clone Matlab's syntax, but to provide an easy way to input matrices. Speaking of syntax and matrices, let's not forget the seemingly bizarre behavior one gets when one does sage: trace(M) for a matrix M. I can imagine this putting people off... Perhaps the trace command should detect matrix inputs and print a helpful error message at the very least? This is now trac #9704 -- I'll fix it: http://trac.sagemath.org/sage_trac/ticket/9704 -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] There are two Sage Days 26
Hi sage-devel, According to http://wiki.sagemath.org/Workshops the upcoming Sage workshops are : * Sage Days 25 -- Mumbai, India (August 9-12, 2010); funded by India * Sage Days 26 -- Kaiserslautern, Germany (August 27-31, 2010); funded by Germany But according to http://wiki.sagemath.org/MyStartingPage#sagedays those upcoming workshops are : * Sage Days 25 -- Mumbai, India (August 9-12, 2010); funded by India * Sage Days 26 -- Seattle, Washington(December 7-10 2010); theme: Women in Sage ( funded by Microsoft) We are organising a Sage Day on September 1st in Montreal Canada and I am wondering if I should choose number 25.5, 27 or 26.5 to give a name and a proper wiki adress page to our Sage Day. Any advise? Sébastien Labbé PhD Student LaCIM, Montréal -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Some feature requests on SAGE - Adding Engineering to the target audience
On Sat, Aug 7, 2010 at 10:31 AM, William Stein wst...@gmail.com wrote: On Sat, Aug 7, 2010 at 5:23 AM, Robert Miller r...@rlmiller.org wrote: On Fri, Aug 6, 2010 at 4:52 PM, cousteau cousteaulecommand...@gmail.com wrote: The aim of my syntax suggestion wasn't to clone Matlab's syntax, but to provide an easy way to input matrices. Speaking of syntax and matrices, let's not forget the seemingly bizarre behavior one gets when one does sage: trace(M) for a matrix M. I can imagine this putting people off... Perhaps the trace command should detect matrix inputs and print a helpful error message at the very least? This is now trac #9704 -- I'll fix it: http://trac.sagemath.org/sage_trac/ticket/9704 Ready for review. William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: please schedule a rebuild for sagemath on alpha architecture
On Fri, 6 Aug 2010, kamaraju kusumanchi wrote: Removing the package from unstable doesn't prevent you from working on the package. It's just a way to clean up Debian. It will be very easy to re-upload when you will have something that builds in i386 and amd64 (though it might be better to upload to experimental, as I doubt that you will have something in a releasable state before a few months). I agree. Actually removing the package might do some good in this case. We can concentrate on just i386 and amd64 and worry about other architectures later on. This might actually speed up things a bit. I spent basically no time on non-x86 architectures; and as it turned out, the package built successfully on most of them anyway. Ignoring everything except x86 is probably the right approach. As for the strategy of working on the 3.X release or on the 4.X release, I don't think that we should try to release something which is not closer to the latest upstream release than 3.0.5. Yes. The software released in Debian should be close to the latest 4.X release. I am thinking of having the intermediate versions somewhere in a private repository. I certainly made extensive use of private repositories when developing the 3.0.5 package. -Tim Abbott -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] There are two Sage Days 26
On Sat, Aug 7, 2010 at 10:34 AM, slabbe sla...@gmail.com wrote: Hi sage-devel, According to http://wiki.sagemath.org/Workshops the upcoming Sage workshops are : * Sage Days 25 -- Mumbai, India (August 9-12, 2010); funded by India * Sage Days 26 -- Kaiserslautern, Germany (August 27-31, 2010); funded by Germany The Kaiserslautern one already happened. I've fixed the above wiki page. But according to http://wiki.sagemath.org/MyStartingPage#sagedays those upcoming workshops are : * Sage Days 25 -- Mumbai, India (August 9-12, 2010); funded by India * Sage Days 26 -- Seattle, Washington(December 7-10 2010); theme: Women in Sage ( funded by Microsoft) We are organising a Sage Day on September 1st in Montreal Canada and I am wondering if I should choose number 25.5, 27 or 26.5 to give a name and a proper wiki adress page to our Sage Day. 25.5 Any advise? Sébastien Labbé PhD Student LaCIM, Montréal -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: please schedule a rebuild for sagemath on alpha architecture
On Fri, 6 Aug 2010, kamaraju kusumanchi wrote: Kamaraju, Overall I like your plan. And I'd like to help. I do not like starting with version 3.0.6. I think such an old version is unlikely to attract many users and hence testing will be suboptimal. In addition, upstream reports that upgrading to 4.5 is currently broken (http://sagemath.org/mirror/src/changelogs/sage-4.5.1.txt), so we know that older releases will incur substantial development challenges that even upstream is not supporting. Moreover, upstream releases very frequently (lately releases have occurred more often than once per month), so by the end of the squeeze+1 cycle we will experience many, many upgrade tests. So adding to the testing burden by doing a dry run with legacy versions seems to me to be a very inefficient use of volunteer time. Indeed, until the packaging process becomes very efficient (which might take substantial time), I think it would be smarter to conserve limited volunteer resources by not packaging some of the upstream releases. You have a point. But the way I see it is this. Sagemath is constantly updated at a rate greater than debian can cope up. I highly doubt we will ever be releasing the .deb packages as fast as they release the .tgz files. So, at some point we have to skip releases and provide as latest debs as possible. I understand that. But now the situation is a bit different. Are we sure that we have all the deps of sagemath packaged into Debian? If the answer is yes, then I am happy to start with 4.5 right away. I think there are a couple new dependencies that are not in Debian; there weren't any as of version 4.0 or so. I would recommend first getting sagemath working building the copies contained in the sagemath tarball, and then package them separately for Debian and switch over later in development (this is how I did the original development, and it was much easier to debug problems incrementally). I suspect that starting by doing the work incrementally with 3.0.6 first might be easier than starting with 4.5 to begin with. There's a good chance you'll want to switch tacts once you get the hang of it, but I think if you try migrating the current package to 4.5, you'll end up feeling overwhelmed by the problems and give up. Some partial progress of mine on updating direct to 3.4.1 (shortly before 4.0) is available, in case you find it useful (I don't think I was very far along): http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz My experience is that one spends most of your time working on sagemath packaging on (1) debugging and (2) waiting for it to build (it took about 30 minutes to build on the server I was using). When I tried to update direct from 3.0.5 to 3.4.1, I found debugging problems resulting from upstream changes took most of the time. I bet it would be much easier when you can find the upstream change that caused the problem; since each sagemath version has relatively small changes, that can make life easier, especially if you're still getting used to dealing with the Sage build system. One thing that I should warn you about is that now Debian has substantially newer versions of various packages than Sage 3.0.5 was designed for, and in some cases that will break things. The current Sage 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it compiling on newer stuff. So it's possible that the incremental approach will prove to be painful and you don't want to do it. But if I were you, I would probably start by just trying to do 3.0.5 - 3.0.6, just because I think that'll help build confidence and give you a better sense of the nature of the challenge than going straight to 4.5. But it's really up to you. I don't have the time to help more than just providing background information on how I did it and what problems I encountered. -Tim Abbott If the answer is no then the next question is what is the minimal version that we can package given the current set of packages available in Debian. There is no clear cut approach. we need to go back and forth a bit. We may need to file some ITPs and work on some transitions which is where the team becomes important. As for the support requests from users, sooner or later they realize that if there is a problem they have to go with the later version anyway. A bit of that frustration is probably good as it will drive some to come and take part in packaging sage for Debian. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: please schedule a rebuild for sagemath on alpha architecture
On Sat, Aug 7, 2010 at 10:49 AM, tabb...@ksplice.com wrote: On Fri, 6 Aug 2010, kamaraju kusumanchi wrote: Kamaraju, Overall I like your plan. And I'd like to help. I do not like starting with version 3.0.6. I think such an old version is unlikely to attract many users and hence testing will be suboptimal. In addition, upstream reports that upgrading to 4.5 is currently broken (http://sagemath.org/mirror/src/changelogs/sage-4.5.1.txt), so we know that older releases will incur substantial development challenges that even upstream is not supporting. Moreover, upstream releases very frequently (lately releases have occurred more often than once per month), so by the end of the squeeze+1 cycle we will experience many, many upgrade tests. So adding to the testing burden by doing a dry run with legacy versions seems to me to be a very inefficient use of volunteer time. Indeed, until the packaging process becomes very efficient (which might take substantial time), I think it would be smarter to conserve limited volunteer resources by not packaging some of the upstream releases. You have a point. But the way I see it is this. Sagemath is constantly updated at a rate greater than debian can cope up. I highly doubt we will ever be releasing the .deb packages as fast as they release the .tgz files. So, at some point we have to skip releases and provide as latest debs as possible. I understand that. But now the situation is a bit different. Are we sure that we have all the deps of sagemath packaged into Debian? If the answer is yes, then I am happy to start with 4.5 right away. I think there are a couple new dependencies that are not in Debian; there weren't any as of version 4.0 or so. I would recommend first getting sagemath working building the copies contained in the sagemath tarball, and then package them separately for Debian and switch over later in development (this is how I did the original development, and it was much easier to debug problems incrementally). I suspect that starting by doing the work incrementally with 3.0.6 first might be easier than starting with 4.5 to begin with. There's a good chance you'll want to switch tacts once you get the hang of it, but I think if you try migrating the current package to 4.5, you'll end up feeling overwhelmed by the problems and give up. Some partial progress of mine on updating direct to 3.4.1 (shortly before 4.0) is available, in case you find it useful (I don't think I was very far along): http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz My experience is that one spends most of your time working on sagemath packaging on (1) debugging and (2) waiting for it to build (it took about 30 minutes to build on the server I was using). When I tried to update Sage 4.5.x will take a lot longer than 30 minutes if you don't build in parallel. If you build the sagemath package in parallel in can take as little as 3 or 4 minutes on sage.math.washington.edu -- William direct from 3.0.5 to 3.4.1, I found debugging problems resulting from upstream changes took most of the time. I bet it would be much easier when you can find the upstream change that caused the problem; since each sagemath version has relatively small changes, that can make life easier, especially if you're still getting used to dealing with the Sage build system. One thing that I should warn you about is that now Debian has substantially newer versions of various packages than Sage 3.0.5 was designed for, and in some cases that will break things. The current Sage 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it compiling on newer stuff. So it's possible that the incremental approach will prove to be painful and you don't want to do it. But if I were you, I would probably start by just trying to do 3.0.5 - 3.0.6, just because I think that'll help build confidence and give you a better sense of the nature of the challenge than going straight to 4.5. But it's really up to you. I don't have the time to help more than just providing background information on how I did it and what problems I encountered. -Tim Abbott If the answer is no then the next question is what is the minimal version that we can package given the current set of packages available in Debian. There is no clear cut approach. we need to go back and forth a bit. We may need to file some ITPs and work on some transitions which is where the team becomes important. As for the support requests from users, sooner or later they realize that if there is a problem they have to go with the later version anyway. A bit of that frustration is probably good as it will drive some to come and take part in packaging sage for Debian. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more
Re: [debian-sage] Re: [sage-devel] Re: please schedule a rebuild for sagemath on alpha architecture
On Sat, 7 Aug 2010, William Stein wrote: On Sat, Aug 7, 2010 at 10:49 AM, tabb...@ksplice.com wrote: I think there are a couple new dependencies that are not in Debian; there weren't any as of version 4.0 or so. I would recommend first getting sagemath working building the copies contained in the sagemath tarball, and then package them separately for Debian and switch over later in development (this is how I did the original development, and it was much easier to debug problems incrementally). I suspect that starting by doing the work incrementally with 3.0.6 first might be easier than starting with 4.5 to begin with. There's a good chance you'll want to switch tacts once you get the hang of it, but I think if you try migrating the current package to 4.5, you'll end up feeling overwhelmed by the problems and give up. Some partial progress of mine on updating direct to 3.4.1 (shortly before 4.0) is available, in case you find it useful (I don't think I was very far along): http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz My experience is that one spends most of your time working on sagemath packaging on (1) debugging and (2) waiting for it to build (it took about 30 minutes to build on the server I was using). When I tried to update Sage 4.5.x will take a lot longer than 30 minutes if you don't build in parallel. If you build the sagemath package in parallel in can take as little as 3 or 4 minutes on sage.math.washington.edu Yeah, unfortunately, the server I was using had only 2 cores. Also, I should note that the 30 minutes was just the time to build the ~10 spkgs that weren't being dealt with as packages -- this was with using system packages for all the dependencies (I imagine your number is for building the whole thing?) -Tim Abbott -- William direct from 3.0.5 to 3.4.1, I found debugging problems resulting from upstream changes took most of the time. I bet it would be much easier when you can find the upstream change that caused the problem; since each sagemath version has relatively small changes, that can make life easier, especially if you're still getting used to dealing with the Sage build system. One thing that I should warn you about is that now Debian has substantially newer versions of various packages than Sage 3.0.5 was designed for, and in some cases that will break things. The current Sage 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it compiling on newer stuff. So it's possible that the incremental approach will prove to be painful and you don't want to do it. But if I were you, I would probably start by just trying to do 3.0.5 - 3.0.6, just because I think that'll help build confidence and give you a better sense of the nature of the challenge than going straight to 4.5. But it's really up to you. I don't have the time to help more than just providing background information on how I did it and what problems I encountered. -Tim Abbott If the answer is no then the next question is what is the minimal version that we can package given the current set of packages available in Debian. There is no clear cut approach. we need to go back and forth a bit. We may need to file some ITPs and work on some transitions which is where the team becomes important. As for the support requests from users, sooner or later they realize that if there is a problem they have to go with the later version anyway. A bit of that frustration is probably good as it will drive some to come and take part in packaging sage for Debian. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups debian-sage group. To post to this group, send email to debian-s...@googlegroups.com. To unsubscribe from this group, send email to debian-sage+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [debian-sage] Re: [sage-devel] Re: please schedule a rebuild for sagemath on alpha architecture
On Sat, Aug 7, 2010 at 11:03 AM, Tim Abbott tabb...@mit.edu wrote: On Sat, 7 Aug 2010, William Stein wrote: On Sat, Aug 7, 2010 at 10:49 AM, tabb...@ksplice.com wrote: I think there are a couple new dependencies that are not in Debian; there weren't any as of version 4.0 or so. I would recommend first getting sagemath working building the copies contained in the sagemath tarball, and then package them separately for Debian and switch over later in development (this is how I did the original development, and it was much easier to debug problems incrementally). I suspect that starting by doing the work incrementally with 3.0.6 first might be easier than starting with 4.5 to begin with. There's a good chance you'll want to switch tacts once you get the hang of it, but I think if you try migrating the current package to 4.5, you'll end up feeling overwhelmed by the problems and give up. Some partial progress of mine on updating direct to 3.4.1 (shortly before 4.0) is available, in case you find it useful (I don't think I was very far along): http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz My experience is that one spends most of your time working on sagemath packaging on (1) debugging and (2) waiting for it to build (it took about 30 minutes to build on the server I was using). When I tried to update Sage 4.5.x will take a lot longer than 30 minutes if you don't build in parallel. If you build the sagemath package in parallel in can take as little as 3 or 4 minutes on sage.math.washington.edu Yeah, unfortunately, the server I was using had only 2 cores. Also, I should note that the 30 minutes was just the time to build the ~10 spkgs that weren't being dealt with as packages -- this was with using system packages for all the dependencies (I imagine your number is for building the whole thing?) I was just thinking about the sage core Python/Cython library. E.g., what gets built by sage -ba William -Tim Abbott -- William direct from 3.0.5 to 3.4.1, I found debugging problems resulting from upstream changes took most of the time. I bet it would be much easier when you can find the upstream change that caused the problem; since each sagemath version has relatively small changes, that can make life easier, especially if you're still getting used to dealing with the Sage build system. One thing that I should warn you about is that now Debian has substantially newer versions of various packages than Sage 3.0.5 was designed for, and in some cases that will break things. The current Sage 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it compiling on newer stuff. So it's possible that the incremental approach will prove to be painful and you don't want to do it. But if I were you, I would probably start by just trying to do 3.0.5 - 3.0.6, just because I think that'll help build confidence and give you a better sense of the nature of the challenge than going straight to 4.5. But it's really up to you. I don't have the time to help more than just providing background information on how I did it and what problems I encountered. -Tim Abbott If the answer is no then the next question is what is the minimal version that we can package given the current set of packages available in Debian. There is no clear cut approach. we need to go back and forth a bit. We may need to file some ITPs and work on some transitions which is where the team becomes important. As for the support requests from users, sooner or later they realize that if there is a problem they have to go with the later version anyway. A bit of that frustration is probably good as it will drive some to come and take part in packaging sage for Debian. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups debian-sage group. To post to this group, send email to debian-s...@googlegroups.com. To unsubscribe from this group, send email to debian-sage+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en. -- You received this message because you are subscribed to the Google Groups debian-sage group. To post to this group, send email to debian-s...@googlegroups.com. To unsubscribe from this group, send email to debian-sage+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/debian-sage?hl=en. -- William Stein Professor of Mathematics University of
Re: [sage-devel] Odd bug in notebook magma interface
On Fri, Aug 6, 2010 at 12:37 PM, Nils Bruin nbr...@sfu.ca wrote:
When I paste the following code into a notebook worksheet in magma
mode, I consistently get Syntax Error. When I paste the same code
directly into magma, it works properly:
{{{
_x:=PolynomialRing(Rationals());
repeat
g:=3*b*x^4+18*c*x^3-6*b^2*x^2-6*b*c*x-b^3-9*c^2 where
b:=Random([-10..10]) where c:=Random([-10..10]);
until Roots(g) ne [];
}}}
[note: the whole definition of g is on one line]
If I replace the line by something shorter, like
{{{
g:=x^3+b*x+c where b:=Random([-10..10]) where c:=Random([-10..10]);
}}}
there is no error.
When I place a newline before the first where I also do not get an
error.
So it seems like notebook+magma interface+long lines+multiple
statements is unstable.
Open a trac ticket and post the link here. And put a more precise traceback.
-- william
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Odd bug in notebook magma interface
http://trac.sagemath.org/sage_trac/ticket/9705 exact traceback in ticket. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sage 4.5.2 released
Hi folks, We're releasing Sage 4.5.2. Many thanks to everyone for their contributions, including numerous patches, packages, reviews, troubleshooting, emails posts, and build test reports! Source archive: http://sage.math.washington.edu/home/release/sage-4.5.2/sage-4.5.2.tar Upgrade path: http://sage.math.washington.edu/home/release/sage-4.5.2/sage-4.5.2/ Binaries for sage and t2.math are available at http://sage.math.washington.edu/home/release/sage-4.5.2/ Full release notes: Sage 4.5.2 was released on 7 August 2010. It is available at http://www.sagemath.org/download.html * About Sage (http://www.sagemath.org) Sage is developed by volunteers and combines over 90 open source packages. It is available for download from www.sagemath.org and its mirrors in source or binary form. If you have any questions and/or problems, please report them to any of these Google groups: * sage-support: http://groups.google.com/group/sage-support * sage-devel: http://groups.google.com/group/sage-devel You can also drop by in #sage-devel on freenode. Please report build and doctest results to the Google group * sage-release: http://groups.google.com/group/sage-release You are invited to update the build farm wiki page * http://wiki.sagemath.org/devel/BuildFarm with results of builds and doctests. The following 83 people contributed to this release. Of those, 15 made their first contribution to Sage: * Adam Webb * Alex Ghitza * Alexandre Blondin Massé * Alyson Deines * Andrey Novoseltsev * Anna Haensch [first contribution] * Anne Schilling * Armin Straub [first contribution] * Brant Jones * Burcin Erocal * Carl Witty * Chris Hall [first contribution] * Chris Wuthrich * Clément Pernet * Craig Citro * Dan Christensen * Dan Drake * Daniel Bump * David Harvey * David Kirkby * David Loeffler * David Roe * Eric Webster [first contribution] * Erin Beyerstedt [first contribution] * Florent Hivert * Francis Clarke * Franco Saliola * Fredrik Johansson * Georg S. Weber * Harald Schilly * Håkan Granath * Jamie Weigandt [first contribution] * Jason Bandlow * Jason Grout * Jeremy West [first contribution] * Jeroen Demeyer [first contribution] * Jim Stankewicz * John Cremona * John Palmieri * Justin Walker * Karl-Dieter Crisman * Kwankyu Lee * Leif Leonhardy * Leonardo Sampaio [first contribution] * Lloyd Kilford * Luis Felipe Tabera Alonso * Marco Streng [first contribution] * Mariah Lenox * Mark Jordan * Marshall Hampton * Martin Albrecht * Michael Schneider [first contribution] * Miguel Marco [first contribution] * Mike Hansen * Minh Van Nguyen * Mitesh Patel * Nathann Cohen * Nicolas M. Thiéry * Nils Bruin * Ondrej Certik * Oscar Gerardo Lazo Arjona * Paul Zimmermann * Radoslav Kirov * Richard Lindner [first contribution] * Rishikesh * Rob Beezer * Robert Bradshaw * Robert Mařík * Robert Miller * Ross Kyprianou * Sebastian Pancratz * Simon King * Steve Pon * Sébastien Labbé * Thierry de Montgolfier [first contribution] * Thomas Lam [first contribution] * Tim Dumol * Tom Boothby * Vincent Delecroix * Volker Braun * Willem Jan Palenstijn * William Stein * Yann Laigle-Chapuy * Release managers * Dan Drake * Mitesh Patel * Bug statistics We closed 159 tickets. For details see http://trac.sagemath.org/sage_trac/milestone/sage-4.5.2 or check out the closed ticket section at the end of this announcement. * Doctesting coverage * Overall weighted coverage score: 83.8% (82.7% for 4.5.1) * Total number of functions:26139 (25764 for 4.5.1) * Closed tickets #8489: Nicolas M. Thiéry: New `sageexample` environment for sagetex #8667: Simon King: New version of modular group cohomology spkg Merged in sagenb: #8369: Mitesh Patel: Mistake in text on data file upload page [Reviewed by Robert Mařík; merged in sagenb-0.8] #9554: Leif Leonhardy: Doctest failure in SageNB's sageinspect.py with #8988 [Reviewed by Volker Braun; merged in sagenb-0.8.2] #9580: Tim Dumol: Check in, ignore, or delete sagenb.po in SageNB package [Reviewed by Mitesh Patel; merged in sagenb-0.8.2] Merged in sage-4.5.2.alpha0: #1396: Simon King: Ideal.groebner_basis should accept keyword arguments for strategy parameters [Reviewed by Martin Albrecht] #5467: Andrey Novoseltsev: The sage/macaulay2 interface doesn't work at all on large input [Reviewed by Mike Hansen] #6409: Mark Jordan: srange inconsistent when including endpoints [Reviewed by Luis Felipe Tabera Alonso] #6449: David Loeffler: Additive abelian groups [Reviewed by John Cremona, Jim Stankewicz] #6904: Clément Pernet: change ring broken over QQ and GF(2) [Reviewed by William Stein] #6922: Kwankyu Lee: Matrix term ordering [Reviewed by Martin Albrecht] #7859: Håkan Granath: bug in QQbar (easy to fix!) [Reviewed by Robert Bradshaw] #7889: Oscar Gerardo Lazo Arjona: revolution plot [Reviewed
Re: [sage-devel] Sage 4.5.2 released
On Sat, Aug 7, 2010 at 2:13 PM, Mitesh Patel qed...@gmail.com wrote: Hi folks, We're releasing Sage 4.5.2. Many thanks to everyone for their contributions, including numerous patches, packages, reviews, troubleshooting, emails posts, and build test reports! Thanks. I'm building binaries for the following systems, which will appear in http://wstein.org/home/wstein/binaries/4.5.2/ as they get built: * OS X 10.5 PPC * OS X 10.5 Intel * OS X 10.6 Intel * Ubuntu 32, 64 * Mandriva 32, 64 * OpenSuse 32, 64 -- William Source archive: http://sage.math.washington.edu/home/release/sage-4.5.2/sage-4.5.2.tar Upgrade path: http://sage.math.washington.edu/home/release/sage-4.5.2/sage-4.5.2/ Binaries for sage and t2.math are available at http://sage.math.washington.edu/home/release/sage-4.5.2/ Full release notes: Sage 4.5.2 was released on 7 August 2010. It is available at http://www.sagemath.org/download.html * About Sage (http://www.sagemath.org) Sage is developed by volunteers and combines over 90 open source packages. It is available for download from www.sagemath.org and its mirrors in source or binary form. If you have any questions and/or problems, please report them to any of these Google groups: * sage-support: http://groups.google.com/group/sage-support * sage-devel: http://groups.google.com/group/sage-devel You can also drop by in #sage-devel on freenode. Please report build and doctest results to the Google group * sage-release: http://groups.google.com/group/sage-release You are invited to update the build farm wiki page * http://wiki.sagemath.org/devel/BuildFarm with results of builds and doctests. The following 83 people contributed to this release. Of those, 15 made their first contribution to Sage: * Adam Webb * Alex Ghitza * Alexandre Blondin Massé * Alyson Deines * Andrey Novoseltsev * Anna Haensch [first contribution] * Anne Schilling * Armin Straub [first contribution] * Brant Jones * Burcin Erocal * Carl Witty * Chris Hall [first contribution] * Chris Wuthrich * Clément Pernet * Craig Citro * Dan Christensen * Dan Drake * Daniel Bump * David Harvey * David Kirkby * David Loeffler * David Roe * Eric Webster [first contribution] * Erin Beyerstedt [first contribution] * Florent Hivert * Francis Clarke * Franco Saliola * Fredrik Johansson * Georg S. Weber * Harald Schilly * Håkan Granath * Jamie Weigandt [first contribution] * Jason Bandlow * Jason Grout * Jeremy West [first contribution] * Jeroen Demeyer [first contribution] * Jim Stankewicz * John Cremona * John Palmieri * Justin Walker * Karl-Dieter Crisman * Kwankyu Lee * Leif Leonhardy * Leonardo Sampaio [first contribution] * Lloyd Kilford * Luis Felipe Tabera Alonso * Marco Streng [first contribution] * Mariah Lenox * Mark Jordan * Marshall Hampton * Martin Albrecht * Michael Schneider [first contribution] * Miguel Marco [first contribution] * Mike Hansen * Minh Van Nguyen * Mitesh Patel * Nathann Cohen * Nicolas M. Thiéry * Nils Bruin * Ondrej Certik * Oscar Gerardo Lazo Arjona * Paul Zimmermann * Radoslav Kirov * Richard Lindner [first contribution] * Rishikesh * Rob Beezer * Robert Bradshaw * Robert Mařík * Robert Miller * Ross Kyprianou * Sebastian Pancratz * Simon King * Steve Pon * Sébastien Labbé * Thierry de Montgolfier [first contribution] * Thomas Lam [first contribution] * Tim Dumol * Tom Boothby * Vincent Delecroix * Volker Braun * Willem Jan Palenstijn * William Stein * Yann Laigle-Chapuy * Release managers * Dan Drake * Mitesh Patel * Bug statistics We closed 159 tickets. For details see http://trac.sagemath.org/sage_trac/milestone/sage-4.5.2 or check out the closed ticket section at the end of this announcement. * Doctesting coverage * Overall weighted coverage score: 83.8% (82.7% for 4.5.1) * Total number of functions: 26139 (25764 for 4.5.1) * Closed tickets #8489: Nicolas M. Thiéry: New `sageexample` environment for sagetex #8667: Simon King: New version of modular group cohomology spkg Merged in sagenb: #8369: Mitesh Patel: Mistake in text on data file upload page [Reviewed by Robert Mařík; merged in sagenb-0.8] #9554: Leif Leonhardy: Doctest failure in SageNB's sageinspect.py with #8988 [Reviewed by Volker Braun; merged in sagenb-0.8.2] #9580: Tim Dumol: Check in, ignore, or delete sagenb.po in SageNB package [Reviewed by Mitesh Patel; merged in sagenb-0.8.2] Merged in sage-4.5.2.alpha0: #1396: Simon King: Ideal.groebner_basis should accept keyword arguments for strategy parameters [Reviewed by Martin Albrecht] #5467: Andrey Novoseltsev: The sage/macaulay2 interface doesn't work at all on large input [Reviewed by Mike Hansen] #6409: Mark Jordan: srange inconsistent when including endpoints [Reviewed by Luis Felipe Tabera
Re: [sage-devel] Sage 4.5.2 released
On Aug 7, 2010, at 14:13 , Mitesh Patel wrote: Hi folks, We're releasing Sage 4.5.2. Many thanks to everyone for their contributions, including numerous patches, packages, reviews, troubleshooting, emails posts, and build test reports! Source archive: http://sage.math.washington.edu/home/release/sage-4.5.2/sage-4.5.2.tar Upgrade path: http://sage.math.washington.edu/home/release/sage-4.5.2/sage-4.5.2/ Upgraded from .rc1 which was in turn upgraded from .rc0, on Mac OS X, 10.5.8 (Dual Quad Xeon), w/o problems. One test failed (ptestlong): devel/sage/sage/plot/plot3d/base.pyx 4 instances of _imaging C module is not installed. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Men are from Earth. Women are from Earth. Deal with it. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Some feature requests on SAGE - Adding Engineering to the target audience
Maurizio's function is pretty nice! It's exactly what I was looking for. I think it should be included in future releases. But it's a bit slow (at least for the 1..1e9 range), maybe it should be rewritten or compiled. The only thing I didn't like is that it saves the image to the current directory, while plot() saves it to a temporary directory and displays it immediately, even when called from the command line. About dagss idea of an object that worked as the inverse of a matrix, but without actually inverting the matrix, I think it would be a good idea. This is, a function inv(M) that returned a symbolic inverse of M. This way: N = inv(M) N * a # returns M \ a N \ a # returns M * a matrix(N) # calculates the inverse, or the pseudo-inverse, of M And if .T and .H would be possible, I think they're a good solution. And about trace()... yes, it's weird that trace(M) and M.trace() behave differently. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage 4.5.2 released
Upgraded from .rc1 which was in turn upgraded from .rc0, on Mac OS X, 10.5.8 (Dual Quad Xeon), w/o problems. One test failed (ptestlong): devel/sage/sage/plot/plot3d/base.pyx 4 instances of _imaging C module is not installed. Try a search for imaging C module not installed mac - it turns out that (like me) you are probably missing some small piece of something that PIL needs to install. I also think there are some comments about this elsewhere on Trac or here, but I can't find them easily : ( Anyway, it's known in that sense. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sympow on Linux Itanium
In your opinion, is it better to leave the current behavior of including fpu.c on Itanium Linux systems, or just remove that since it will be safer? Be a bit careful with the language here. If someone has an older (pre-Montecito) Itanium, then from what I understand it is perfectly plausible that they may either purposely or accidentally install an x86-based Linux. I.e., uname -m and uname -p will mismatch. But yes, for uname -m equal to ia64, I would argue that including fpu.c is not safe. In my experience, I don't know of a way to reliably prune the /proc/cpuinfo file on Itaniums in order to determine the hardware support for x86/ia32. (/proc/cpuinfo for Itaniums and older Opterons appear to be problem childs.) IMHO, It would have been simpler to just assume 'rm', 'grep', uname and other similar programs just exist. At least uname -m appears to be standard, but uname -p -i and -M don't appear to be so. E.g., newer Linux, Mac OS-X, several variants of BSD and IRIX (OK... the last one is a stretch), don't support some of the latter options... while I can find at least one OS that does any of them. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
