[sage-devel] Re: Fwd: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)

I'll address some of the issues with tut.tex. See for patches. (Some of these things have already been taken care of there, and I'll post patches to others soon.) Some of the things I'm not dealing with: I don't have Opera on my Mac, and I'm no

[sage-devel] Re: SAGE + OpenOffice PyUno /OOMath

On Mon, May 12, 2008 at 5:52 AM, Kutoma Ltd <[EMAIL PROTECTED]> wrote: > > Hallo to all, > > Does anyone use OpenOffice and Sage in combination like the down > mentioned link > > describing the interface to python and the usage of the equation > editor > > > > http://documentation.openoffice.org/

[sage-devel] sage/numpy fan mail

Hi Sage-Devel, Here is a Sage fanmail blogpost about Sage "the distribution" from here: http://www.funjackals.com/blog/?p=274 "Sage Makes Me Happier Than Seems Reasonable Posted May 14, 2008 I've known about the Python-for-mathematics software stack SAGE for a while now, but I hadn't played

[sage-devel] Re: Fwd: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)

On Sat, May 17, 2008 at 7:29 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On May 18, 4:24 am, "William Stein" <[EMAIL PROTECTED]> wrote: >> Hi Sage-Devel, >> >> Can somebody volunteer to make a trac ticket and put all the following >> fixes into sage? > >> 13. When I executed >> /Applications/

[sage-devel] Re: Fwd: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)

On May 18, 4:24 am, "William Stein" <[EMAIL PROTECTED]> wrote: > Hi Sage-Devel, > > Can somebody volunteer to make a trac ticket and put all the following > fixes into sage? > 13. When I executed > /Applications/sage/local/bin/maxima > the following was displayed: > dyld: Library not loaded: >

[sage-devel] Fwd: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)

Hi Sage-Devel, Can somebody volunteer to make a trac ticket and put all the following fixes into sage? William -- Forwarded message -- From: Johann Tonsing <[EMAIL PROTECTED]> Date: Sat, May 17, 2008 at 4:17 PM Subject: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2

[sage-devel] Re: Does the '.spkg' format just cause more problems than it solves?

On May 18, 3:13 am, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote: Hi David, > I guess one could make a script to simplyify the process of making > changes to the .spkg files somewhat. But the fact the source is > distributed in large compressed files means that even the simplest > change will n

[sage-devel] Re: slightly OT: new M4RI library

I managed to get the modified version from the spkg. Nice code!! Unfortunately it is not as fast on my opteron. So more work tomorrow for me to try and get it down to the same times as I have with my version. Here are the times all on my opteron. Note your CTD version was optimal at a cutoff of

[sage-devel] Re: Does the '.spkg' format just cause more problems than it solves?

On May 18, 1:14 am, Francois <[EMAIL PROTECTED]> wrote: > > Sage is pretty unique in the way all these packages are distributed in > > source form. I'm not convinced this uniqueness is a good thing, but > > perhaps I am wrong. > > On my linux desktop, ark - the kde front end to compression progra

[sage-devel] Re: Does the '.spkg' format just cause more problems than it solves?

On May 18, 1:22 am, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote: Hi David, > Sage is distributed as a lot of files ending in .spkg, which are > basically tar files compressed with bzip2. > > I myself think it would be better if instead of using these files, > Sage was simply distributed as a se

[sage-devel] Re: slightly OT: new M4RI library

On 18 May, 00:40, Martin Albrecht <[EMAIL PROTECTED]> wrote: > My version is here: > >    http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20080516.p1.spkg > > (this needs an updated patch for Sage) > > and here: > >    http://sage.math.washington.edu/home/malb/m4ri-20080516.tar.gz > > (w

[sage-devel] Re: sed problem with Singular/flexer.sh on Solaris

On May 18, 2:45 am, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote: Hi David, > I'm getting a build problem on Solaris 10 (SPARC) The script Singular/ > flexer.sh assumes 'flex' is present, The need to have flex installed has been fixed in 3.0.2.alpha0. > then tries to extract the version > numb

[sage-devel] sed problem with Singular/flexer.sh on Solaris

I'm getting a build problem on Solaris 10 (SPARC) The script Singular/ flexer.sh assumes 'flex' is present, then tries to extract the version number. This line: TV=`echo $VERSION|sed -e s/^[0-9]*\.[0-9]*\\.//` is creating an error on Solaris. I think it tries to get the last part of the version

[sage-devel] Re: slightly OT: new M4RI library

On May 17, 2008, at 8:38 PM, Bill Hart wrote: > Of course one can go too crazy with optimisation. No surely that never happens around here. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from

[sage-devel] Re: slightly OT: new M4RI library

Here are the times I get with the different cutoffs. Magma M4RI:7200 M4RI:2048 1x1: 2.940s 3.442s 4.132s 16384x16384: 9.250s 11.47s 11.80s 2x2: 16.57s 19.3s 26.05s 32000x32000: 59.05s 71.9s 71.8s So it seems when there is not an exact cut, the higher cutoff is sub

[sage-devel] Re: Does the '.spkg' format just cause more problems than it solves?

On May 18, 11:22 am, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote: > Sage is distributed as a lot of files ending in .spkg, which are > basically tar files compressed with bzip2. > > I myself think it would be better if instead of using these files, > Sage was simply distributed as a set of sour

[sage-devel] Re: slightly OT: new M4RI library

On Sunday 18 May 2008, Bill Hart wrote: > I don't have the two Gray code tables, so it would be good to get your > version. Also my code is currently a mess, so it would be good to > clean it up by merging with a cleaner version (yours). Tomorrow I'll > check carefully what I've changed and try an

[sage-devel] Re: slightly OT: new M4RI library

P.S: yes all my times are on a 2.8Ghz Opteron. Cpuinfo says: [EMAIL PROTECTED]:~/m4ri-20080514/testsuite> cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2220 stepping: 3 c

[sage-devel] Re: slightly OT: new M4RI library

I don't have the two Gray code tables, so it would be good to get your version. Also my code is currently a mess, so it would be good to clean it up by merging with a cleaner version (yours). Tomorrow I'll check carefully what I've changed and try and merge the ideas if there are any you don't hav

[sage-devel] Does the '.spkg' format just cause more problems than it solves?

Sage is distributed as a lot of files ending in .spkg, which are basically tar files compressed with bzip2. I myself think it would be better if instead of using these files, Sage was simply distributed as a set of source files. I see several problems with these files. * Since they are compresse

[sage-devel] Re: slightly OT: new M4RI library

> I suppose that this might be due to the ends of rows all being zero as > they aren't a multiple of 64 bits long. But I checked for 16384x16384 > and we are nearly down to the speed of Magma there too. I just don't > get it. The coinflip has to be broken I think. If one uses M4RI with the new pa

[sage-devel] Re: slightly OT: new M4RI library

Woot!! On 17 May, 23:46, Martin Albrecht <[EMAIL PROTECTED]> wrote: > > Old: 64-bit Debian/GNU Linux, 2.33Ghz Core2Duo > > Matrix Dimension   Magma 2.14-13 (64-bit)  M4RI-20080517 (64-bit) > > 10,000 x 10,000    2.920                           3.610 >

[sage-devel] Re: slightly OT: new M4RI library

> Old: 64-bit Debian/GNU Linux, 2.33Ghz Core2Duo > Matrix Dimension Magma 2.14-13 (64-bit) M4RI-20080517 (64-bit) > 10,000 x 10,000 2.920 3.610 > 16,384 x 16,384 11.140 12.120 > 20,000 x 20,0

[sage-devel] Re: slightly OT: new M4RI library

t; > all rows to be 128 bit aligned if the matrices are wide enough to > > > > > > > benefit from SSE2, Then the combine function can always use SSE2 > > > > > > > and > > > > > > > there will be no need to check for alignment. > >

[sage-devel] Re: slightly OT: new M4RI library

a noticeable difference for me (on C2D). > > > > > However, > > > > > I realised that the multiplications where the target matrix is a real > > > > > matrix rather than a window (which has bad data locality). Copying > > > > > everything

[sage-devel] Re: slightly OT: new M4RI library

> > > I realised that the multiplications where the target matrix is a real > > > > matrix rather than a window (which has bad data locality). Copying > > > > everything over seems not like a good idea but it at least indicates an > > > > area for improvem

[sage-devel] Re: slightly OT: new M4RI library

t; area for improvements. > > > Okay, if I only copy when we crossover to M4RM then the memory overhead is > > constant (~ cutoff^2) and the performance still improves. > > > Old: 64-bit Debian/GNU Linux, 2.33Ghz Core2Duo > > Matrix Dimension        Magma 2.14-13

[sage-devel] Re: slightly OT: new M4RI library

area for improvements. > > Okay, if I only copy when we crossover to M4RM then the memory overhead is > constant (~ cutoff^2) and the performance still improves. > > Old: 64-bit Debian/GNU Linux, 2.33Ghz Core2Duo > Matrix Dimension        Magma 2.14-13 (64-bit)  

[sage-devel] Re: slightly OT: new M4RI library

r seems not like a good idea but it at least indicates an > area for improvements. Okay, if I only copy when we crossover to M4RM then the memory overhead is constant (~ cutoff^2) and the performance still improves. Old: 64-bit Debian/GNU Linux, 2.33Ghz Core2Duo Matrix DimensionMagma 2.

[sage-devel] Re: Maxima + ECL status

Carl Witty wrote: > I'd like to give it a try. (I can't commit for a "long haul" myself, > but I could spend some time on it in the near future.) Super -- any time you can invest is greatly appreciated. > Could you explain what the current status is, and how I could > replicate your current se

[sage-devel] Re: slightly OT: new M4RI library

> I think a better idea would be to explicitly force all matrices and > all rows to be 128 bit aligned if the matrices are wide enough to > benefit from SSE2, Then the combine function can always use SSE2 and > there will be no need to check for alignment. That doesn't seem to make a noticeable d

[sage-devel] Re: slightly OT: new M4RI library

On Saturday 17 May 2008, Bill Hart wrote: > Martin, > > The test code still passes if you change RADIX to 128. I've no idea > how it passes, but it does. Shame the results are not correct, because > this speeds the code up by a factor of 2. Since all routines use the RADIX and I only check if the

[sage-devel] Re: slightly OT: new M4RI library

Heres another idea which should speed things up a bit. For 1x1 we currently use k = 6. Instead of this, we could use k = 5 and make two Gray tables simultaneously. This will still fit in cache. Instead of doing 6 bits at a time, we can then do 10 bits at a time. We'd load the appropriate

[sage-devel] Re: slightly OT: new M4RI library

Martin, The test code still passes if you change RADIX to 128. I've no idea how it passes, but it does. Shame the results are not correct, because this speeds the code up by a factor of 2. I notice that in the SSE code, you check to see if alignment can be achieved, otherwise it doesn't use SSE.

[sage-devel] Re: About @interact and public worksheets

Thanks for the explanations ! And good news about that being in the wire. Good luck to Igor. Philippe On Sat, May 17, 2008 at 5:11 PM, William Stein <[EMAIL PROTECTED]> wrote: > > On Sat, May 17, 2008 at 5:59 AM, Philippe Saade <[EMAIL PROTECTED]> wrote: >> >> Hi all. >> >> I tried to leave pub

[sage-devel] Re: About @interact and public worksheets

On Sat, May 17, 2008 at 5:59 AM, Philippe Saade <[EMAIL PROTECTED]> wrote: > > Hi all. > > I tried to leave public worksheets on a (beta)public sagenb with code > copied from the wiki and showing some usage of the @interact. > > I was surprised that anonymous visitors of these pages could not inte

[sage-devel] Re: slightly OT: new M4RI library

Hi Martin, Here is another 10% improvement. In the loop at the bottom of mzd_combine you can explicitly unroll by a factor of 8: word * end = b1_ptr + wide; register word * end8 = end - 8; while (b1_ptr < end8) { *(b1_ptr++) = *(b2_ptr++) ^ *(b3_ptr++); *(b1_ptr

[sage-devel] About @interact and public worksheets

Hi all. I tried to leave public worksheets on a (beta)public sagenb with code copied from the wiki and showing some usage of the @interact. I was surprised that anonymous visitors of these pages could not interact ... (by the way, three processes were putting a 100% CPU load ... and i had to res

[sage-devel] [Fwd: GMP-ECM 6.2 is out]

FYI. This is no #3237 Original Message Subject:GMP-ECM 6.2 is out Date: Sat, 17 May 2008 09:48:01 +0200 From: Paul Zimmermann <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hi, for those interested in applications of GMP, a new release of GMP-ECM is out at

[sage-devel] Re: slightly OT: new M4RI library

Yes, of course, that is it. The Opteron can perform an MMX instruction at the same time as an integer instruction (even an SSE instruction if need be). We just need to set it up so that instructions get interleaved between the two units. Probably the reason Magma jumps nearly a factor of 2 at tha

[sage-devel] Re: slightly OT: new M4RI library

On Saturday 17 May 2008, Bill Hart wrote: > In going from 5000x5000 to 1x1 Magma's time increases by a > factor of less than 4. That is impossible. Strassen will never help us > there. They must be doing something else. Probably something clever. > > Bill. I was stuck there too yesterday