วันพฤหัสบดีที่ 30 กันยายน พ.ศ. 2553

[sage-devel] building a Sage package on Debian

Since I haven't seen any updates on the work to build a Debian package
for Sage, here is a summary of the past discussions that I believe
is up-to-date:
- I was mistaken about gdmodule: it is included in the Debian package
python-gd. So no work is needed there. Good.
- The Cephes Mathematical Library is only needed for Cygwin (Windows)
and so is not required for Debian (William Stein).
- f2c is only needed for Scipy and therefore should not be required
for a Debian package because Debian already has Scipy (François Bissey,
William Stein).
- flintqs / SIMPQS issue. FlintQS should probably be removed as a SPKG
in Sage, but it may require work (qsieve). Bill Hart may be able to
comment further (William Stein).
- opencdk / gnutls. William Stein thinks it is only needed to "provide
a secure SSL mode for the Sage notebook". So we can probably use
the Debian version of gnutls, but that will require assessment.
- Issues Identified by François Bissey:
* Scipy 0.6.7, which is in sid (Debian's development branch), will
break things, at least because Sage's scipy requires this patch
http://projects.scipy.org/scipy/changeset/5790
* Sage does not yet support scipy 0.8 because it depends on numpy-1.4
and "Sage is not going there yet". Strangely, Debian sid currently
has scipy 0.7.2 (good), but includes numpy 1.4.1 (ut-oh). So that
will probably create issues.
* This pickles patch is still not integrated into Python upstream,
but it is needed for Sage: http://bugs.python.org/issue7689
* This python2.6 issue probably affects sid:
http://bugs.python.org/issue7491 which breaks stuff, witness:
http://github.com/cschwan/sage-on-gentoo/issues#issue/1
* pexpect issue (Debian pkg: python-pexpect): Debian ships version 2.3,
but Sage requires version 2.0 (though one of the necessary patches
is already in 2.4). Plotting in the notebook is likely to break with
newer versions that are in Debian; and >2.0 is reported to be slow.
* ecl is OK unless compiled with Unicode
support (http://github.com/cschwan/sage-on-gentoo/issues/closed#issue/2).
Debian may do that, so it could be an issue.
- There are still two unpackaged dependencies: ratpoints and cliquer.
- There are at least five Debian packages that should be updated to newer
upstream versions: libflint, libfplll0, gfan, lcalc, m4ri.

There are some general issues mentioned on this page:
http://wiki.debconf.org/wiki/Debconf10/Unofficial/Talks/MathematicalSoftware

There was a 10-15 minute discussion on packaging
Sage at DebConf10. Video is here:
http://penta.debconf.org/dc10_schedule/events/557.en.html
At a later talk, David Bremner gave an eloquent
summary of the challenges in packaging Sage in Debian:
http://penta.debconf.org/dc10_schedule/events/604.en.html

Giovanni Mascellani kindly put the old, buggy Debian Sage source code
into git: git://git.debian.org/git/debian-science/packages/sagemath.git
So we can build on Tim Abbott's prior work.

Did I miss any other issues?

So we need volunteers to help on at least the seven packages that are
dependencies of Sage.

It might be helpful to maintain this "list of issues for Sage in Debian"
so that it can be edited collectively. Where? How?

We also need volunteers to coordinate between the Sage, Upstream, and
Debian package maintainers to resolve each of the documented issues.

Finally, it is still not clear to me who is on the team working to
build a Debian Sage package. Is everyone interested on the debian-sage
google group? Is there another place where the team should congregate
to coordinate the work?

On Mon, Aug 09, 2010 at 08:17:43PM -0400, CJ Fearnley wrote:
> On Fri, Aug 06, 2010 at 05:44:32PM -0400, kamaraju kusumanchi wrote:
> > 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 spent some time analyzing the components of sage-4.5.2 which was released
> recently. I looked at http://www.sagemath.org/packages/standard/ and
> http://www.sagemath.org/links-components.html and used packages.debian.org to
> see what we have available. Here is my first cut assessment:
>
> * eclib is Sage's packaging of mwrank. Neither eclib nor mwrank are
> in Debian. Upstream has not changed in ages. I do not know of any
> other software that depends on eclib besides sage. So we /might/
> be able to use sage's code/packaging and skip packaging it for Debian.
> o http://www.sagemath.org/packages/standard/eclib-20080310.p10.txt
> * Cephes Mathematical Library. Not in Debian. I cannot find any licensing
> statement upstream nor in Sage's SPKG. I think it is free, but
> debian-{policy,legal} will complain if we try to package this.
> Maybe we should lobby for its removal from sage? Or maybe the license
> issues can be resolved? Or Debian's sage may just need to skip it?
> o http://www.sagemath.org/packages/standard/cephes-2.8.txt
> * Cliquer. Needs a Debian package.
> o http://www.sagemath.org/packages/standard/cliquer-1.2.p5.txt
> * Data files. I think we can ship the following SPKG's as part of Sage and
> do not need to package them for Debian, since they appear to be data files
> only:
> o http://www.sagemath.org/packages/standard/conway_polynomials-0.2.txt
> o http://www.sagemath.org/packages/standard/elliptic_curves-0.1.txt
> o http://www.sagemath.org/packages/standard/examples-4.5.2.txt
> o http://www.sagemath.org/packages/standard/extcode-4.5.2.txt
> o http://www.sagemath.org/packages/standard/graphs-20070722.p1.txt
> o http://www.sagemath.org/packages/standard/polytopes_db-20100210.txt
> * extcode: a miscellany. Appears to have Tim's debian subdirectory for
> building the package, jsMath, and tons of other stuff. Most (all?) of
> it is not a problem (jsMath is already in Debian, but which version
> is included in Sage is not clear to me), but some things may require
> finding upstream and building a Debian package. More work needed.
> o http://www.sagemath.org/packages/standard/extcode-4.5.2.txt
> * f2c: Debian (20090411-1+b1) is way newer than Sage (20070816.p2).
> We might need to push Sage to upgrade.
> o http://www.sagemath.org/packages/standard/f2c-20070816.p2.txt
> * flintqs (SIMPQS): this seems to be part of flint (in Debian but old
> version, see below) but Sage distributes it as a separate SPKG.
> Uggh, my brain hurts.
> o http://www.sagemath.org/packages/standard/flintqs-20070817.p5.txt
> * gdmodule. Needs a Debian package.
> o http://www.sagemath.org/packages/standard/gdmodule-0.56.p7.txt
> * opencdk. This ships as part of gnutls. However, sage's fork differs
> quite a bit from the code in gnutls. Do we need a package or is it
> part of gnutls with no work needed? I don't know.
> o http://www.sagemath.org/packages/standard/opencdk-0.6.6.p5.txt
> * ratpoints. Needs a Debian package.
> o http://www.sagemath.org/packages/standard/ratpoints-2.1.3.p1.txt
> * rubiks. I think these three upstream "packages" are too small to
> package for Debian. I recommend using sage's source for them.
> o http://www.sagemath.org/packages/standard/rubiks-20070912.p12.txt
> * scipy_sandbox. Seems to include a few optional/experimental scipy
> packages. They do not appear to be in Debian, but are probably too small
> to warrant separate packages.
> o http://www.sagemath.org/packages/standard/scipy_sandbox-20071020.p5.txt
>
> New versions needed in Debian:
> * I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592349
> since libflint is out of date
> * I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592349
> since libfplll0 is out of date
> * I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592425
> since gfan is out of date
> * I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592426
> since lcalc is out of date
> * I submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592429
> since m4ri is out of date
> * I did not go through all dependencies comprehensively looking for
> Sage/Debian version mismatch issues. More work needed.
>
> I believe everything else is either already in Debian or is really just
> a Sage SPKG that we can and should treat as upstream source. So the
> library situation is not too bad: most of the upstreams are actively
> maintained in Debian already!
>
> I might have enough bandwidth to package gdmodule. Anyone want ratpoints
> or Cliquer? Anyone see how to handle the headaches that I identified?

--
We are on a spaceship; a beautiful one. It took billions of years to develop.
We're not going to get another. Now, how do we make this spaceship work?
-- Buckminster Fuller

CJ Fearnley | Explorer in Universe
cjf@CJFearnley.com | "Dare to be Naive" -- Bucky Fuller
http://www.CJFearnley.com | http://blog.remoteresponder.net/

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: call for comment: matplotlib config directory in SAGE_LOCAL/etc/

On 9/30/10 3:20 PM, Georg S. Weber wrote:
>
>> Set the matplotlib configuration and cache directory to
>> $SAGE_LOCAL/etc/matplotlib
>>
>> Advantages:
>> * Each sage directory would have its own cache of font locations
>> (needed since some of those fonts are inside the sage directory).
>>
>> Disadvantages:
>> * To have a matplotlib custom configuration survive a reinstall of
>> Sage, the user must either manually copy the matplotlibrc file to the
>> new install, or set the MATPLOTLIBRC environment variable within Sage to
>> point to a location outside of the sage directory.
>>
>
> Hi Jason,
>
> please bear in mind that many Sage users don't build Sage themselves,
> but use the premade binary distributions (Sage bdist's). These bdists
> must not assume as few prerequisites as possible, e.g. cannot rely on
> some possible installation of an X server, or of certain fonts
> "outside", or whatsoever.
>

The cache files in question should be regenerated when needed. It would
be a good idea for a bdist to delete the files in this directory, as we
should ship a clean empty directory.

> Any installation-site specific contents stored under $SAGE_ROOT,
> $SAGE_LOCAL and the like do need special care and special treatment
> (at least during the creation of a bdist from that installation), this
> often forgotten.

Yep, thanks for the reminder. bdist should delete all files in the
proposed $SAGE_LOCAL/etc/matplotlib directory.


Any informations about fonts/some GUI/whatever
> "outside" of Sage should be stored outside, too. What's wrong with
> using the environment variable MATPLOTLIBRC, by the way?
>

The issue is that *other* files in the config directory, besides the
matplotlibrc config files, cache information about paths inside of the
matplotlib directory. MATPLOTLIBRC only affects the actual matplotlibrc
config file.

For example, here is an entry in my current ~/.matplotlib/fontList.cache
file.

S'/Users/grout/sage-4.5.2/local/lib/python2.6/site-packages/matplotlib/mpl-data/
fonts/ttf/VeraIt.ttf'


Note that it has a reference to the matplotlib install directory of a
specific Sage installation. Since I have multiple Sage installations
around, it seems bad to have a reference to a specific installation in
my global configuration directory. It would be much better if each Sage
installation had its own configuration/cache directory, which could
store path information relating to that specific matplotlib installation.

Thanks,

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Rewrite of LP solver interfaces, constraint generations, and..... reviews :-)

Hello everybody !

It is getting late here, and I am just out of a patch that took me
quite some time and energy.

It is a complete rewrite of the interface between Sage and the LP
solvers it supports (GLPK, Coin, CPLEX). It means that we now have
some abstract Cython interface to deal with all of them, and not these
ugly python calls from before which prevented us from using any
interesting solver-specific method (for example with Gurobi...). The
code is cleaner, more efficient, easier to change, and we can already
do more things with it.

For example, constraint generation. I do not even know of any way to
dynamically generate constraints and variables when working on LP
without actually writing C code, and it is now possible directly in
Python. Or in Cython, if you want it to be faster. This means that
some new things are possible in Sage, which leads to more efficient
algorithms for Feedback Edge set #9923 or to a new one to compute the
fractional chromatic index of a graph #10044. Many others will follow,
it will just be too easy to obtain impressive speedups using it :-)

This patch is now to be reviewed on ticket #10043, and I expect this
will take some time. It passes all tests with any solver available on
my computer, and I of course tried to think of everything, but
considering the time it is quite likely I missed a lot.... so if
anybody here is willing to help, I'll be quite glad to discuss/fix any
part of the code as soon as something odd appears... starting tomorrow
!

... and I hope this will prove useful :-)

Have fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuun !!!

Nathann

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: call for comment: matplotlib config directory in SAGE_LOCAL/etc/

> Set the matplotlib configuration and cache directory to
> $SAGE_LOCAL/etc/matplotlib
>
> Advantages:
>    * Each sage directory would have its own cache of font locations
> (needed since some of those fonts are inside the sage directory).
>
> Disadvantages:
>    * To have a matplotlib custom configuration survive a reinstall of
> Sage, the user must either manually copy the matplotlibrc file to the
> new install, or set the MATPLOTLIBRC environment variable within Sage to
> point to a location outside of the sage directory.
>

Hi Jason,

please bear in mind that many Sage users don't build Sage themselves,
but use the premade binary distributions (Sage bdist's). These bdists
must not assume as few prerequisites as possible, e.g. cannot rely on
some possible installation of an X server, or of certain fonts
"outside", or whatsoever.

Any installation-site specific contents stored under $SAGE_ROOT,
$SAGE_LOCAL and the like do need special care and special treatment
(at least during the creation of a bdist from that installation), this
often forgotten. Any informations about fonts/some GUI/whatever
"outside" of Sage should be stored outside, too. What's wrong with
using the environment variable MATPLOTLIBRC, by the way?


Cheers,
Georg

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: target date for feature freeze for the 4.6 cycle

Hi y'all!

On 30 Sep., 05:48, Mitesh Patel <qed...@gmail.com> wrote:
> It's likely that I'll release 4.6.alpha2 by the weekend, with the
> already merged tickets.

Is it possible to find someone to review #10004 and get it into 4.6?

The ticket is about the fact that Sage creates a race condition as
soon as one uses two interfaces (say, Gap and Singular) simultaneously
or uses @parallel on a function that uses an interface.

The reason is that so far, *all* interfaces of one Sage session share
the same local tmp file, which is used for sending long commands to
the Gap/Singular/... subprocess. The obvious solution is to make the
file name depend on the pid of the Gap/Singular/... subprocess, rather
than only on the pid of the Sage session.

I originally made the ticket a blocker for 4.6.1, but perhaps someone
finds it easy enough to review, so that this race condition (that bugs
me since at least two years, though I found the reason only recently)
can finally be removed.

Cheers,
Simon

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@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: changing SAGE_LOCAL/SAGE_ROOT to SPKG_LOCAL/SPKG_ROOT

On Thu, Sep 30, 2010 at 1:19 AM, Alexander Dreyer
<alexander.dreyer@itwm.fraunhofer.de> wrote:
> Hi,
>> This is just my opinion, but isn't the name SPKG (SAGE package)
>> already quite specialised?
> indeed, more generic would be something like PKG_ROOT, etc. But since
> spkg seems to be established as package system (at least in this
> case), one could think of backronyming the "S" in SPKG to something
> else.

Yes, since we want to keep using the .spkg extension, it makes sense
to use SPKG_LOCAL, and it will simply mean:
SPKG = "Software Package". That way the packaging system will be
project neutral.

We decided to go ahead and use SPKG_LOCAL from now on. I'll send a
patch to the Sage build system soon, in case you wanted to go this way
too.

Ondrej

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Substitution in symbolic expressions

On 30 sep, 16:25, rjf <fate...@gmail.com> wrote:
> The semantics of substitution as done in Maxima and probably Ginac (no
> wildcards)
> is quite clear IF you understand the representation of expressions as
> trees.
> Not strings.
I think we both agree that there is nothing weird about not replacing x
+y by z in x+y+z.
So we should also agree on the fact that the following sentence in the
examples of the documentation :
"The following seems really weird, but it is what Maple does:"
is WRONG, or at least MISLEADING.
Which is the main point of my first post.
>
> That means that some people will NOT understand substitution.
>
> A fairly safe bet is only to substitute for atoms.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Substitution in symbolic expressions

The semantics of substitution as done in Maxima and probably Ginac (no
wildcards)
is quite clear IF you understand the representation of expressions as
trees.
Not strings.

That means that some people will NOT understand substitution.

A fairly safe bet is only to substitute for atoms.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] call for comment: matplotlib config directory in SAGE_LOCAL/etc/

Background
----------

Matplotlib (our 2d plotting library) has a "configuration directory"
that includes a user-specific matplotlib settings (overriding the
matplotlib defaults) and cache files (for example, a font locations
cache). The font location cache includes locations within the sage
directory tree.

A while ago, on http://trac.sagemath.org/sage_trac/ticket/6235 and on
the relevant sage-devel discussion [1], it was pointed out that having
the matplotlib configuration and cache directory be the normal
~/.matplotlib was not satisfactory.

#6235 suggests that the directory be changed to ~/.sage/matplotlib.
However, since the directory contains a cache of font locations and
other things, having one configuration directory for multiple Sage
installs is also a problem (since the font cache would only point to one
specific Sage directory matplotlib fontset, for example).

This issue became important when we saw some problems in upgrading to
the newest matplotlib release at #9122.

Proposal
--------

Set the matplotlib configuration and cache directory to
$SAGE_LOCAL/etc/matplotlib

Advantages:
* Each sage directory would have its own cache of font locations
(needed since some of those fonts are inside the sage directory).

Disadvantages:
* To have a matplotlib custom configuration survive a reinstall of
Sage, the user must either manually copy the matplotlibrc file to the
new install, or set the MATPLOTLIBRC environment variable within Sage to
point to a location outside of the sage directory.

Comments? Votes?


Thanks,

Jason
--
Jason Grout


[1] http://www.mail-archive.com/sage-devel@googlegroups.com/msg23608.html

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

On 9/30/10 6:25 AM, maldun wrote:
> There is another thing that I want to mention another thing:
>
> Leif mentioned that it would be important that after installing of
> numpy rebuilding of sage should happen with -b, and not with -ba
> like I suggested. I can understand his thoughts because actually it is
> a good thing when sage builds the only the .pyx files which are
> concerned.


There have been times in the past when an spkg update required sage -ba.
I'm not commenting on whether that is good or not, just saying that
there is precedent for saying that an spkg update requires sage -ba. I
personally don't find it offensive to require sage -ba for an underlying
library.

Thanks,

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

There is another thing that I want to mention another thing:

Leif mentioned that it would be important that after installing of
numpy rebuilding of sage should happen with -b, and not with -ba
like I suggested. I can understand his thoughts because actually it is
a good thing when sage builds the only the .pyx files which are
concerned.

But -b doesn't do this out of the box you have to trick sage, because
there happenend no changes to the .pyx files at all, and so the .c
files don't get recompiled.
One way to this is -ba which is of course more time consuming, but
after upgrading from numpy-1.3.x to a higher version this gets
obsolete anyway because all newer numpy versions have the same size of
"flatiter". And if you build a fresh sage this wouldn't happen anyway.

An other method would be touching the numpy.pxd in cython, which
actually work, but this somehow interferes with the principle that one
package shouldn't touch the other, and numpy isn't dependend on cython
so we would artificially create one.
And then we could make the changed numpy headers dependend on the
concerned modules, which would be a better solution, but then we have
to add ALL headers to the dependend lists because, if we upgrade to
newer numpy versions, there are different or even no header changes
(what is also a problem).
One thing what we can do here would be put a "patched" header into the
patches path which only contains a small change like an additional
comment to trick sage with the timestamps and make the modules only
dependend on that header, so that we only have to add one header to
the entries.
But these solutions don't really make me happy because they have more
the taste of a bad hack then a clean solution.

Has anyone a better Idea for a clean solution?

Of course I will apply any change that are demanded by reviewers, but
I'm actually not happy with that change, for the reasons I mentioned.
I hope one can understand my concerns.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@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: Ticket #9808 for newer numpy and scipy packages would need a final decision

> Could you alse give the 1.4.1.p0 a spin? it contains the patch for
> linux ppc. (download link a few posts above) Perhaps the whole thing
> will get obsolete
> with 1.5.0 but I'm curious if that would work also, because I'm not
> sure if I get 1.5.0 ready in time.
Missed that. I will have to do that tomorrow.
Hope I won't run out of time.... Need extra an 24h a day atm.

Francois

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

Could you alse give the 1.4.1.p0 a spin? it contains the patch for
linux ppc. (download link a few posts above) Perhaps the whole thing
will get obsolete
with 1.5.0 but I'm curious if that would work also, because I'm not
sure if I get 1.5.0 ready in time.

greez
maldun

On Sep 30, 10:05 am, François Bissey <f.r.bis...@massey.ac.nz> wrote:
> > On Sep 29, 9:01 am, Marshall Hampton <hampto...@gmail.com> wrote:
> > > It looks like it might be a while before this is fixed by numpy:
>
> > >http://projects.scipy.org/numpy/ticket/1403
>
> > > Given the importance of numpy to Sage, I think it might make sense to
> > > drop support for PPC linux.  On the positive side:
>
> > > 1) There are considerable improvements to numpy and scipy in the
> > > latest version that some of our developers and users are interested in
> > > (not to mention bugfixes).
>
> > > 2) We need the latest scipy & numpy to be able to upgrade the python
> > > version in Sage.  I don't think it makes sense to freeze our version
> > > of python.  Also there are many interesting improvements to python in
> > > the 2.7 series, which will be the last 2.x version.
>
> > > The downsides of dropping support for a platform are obvious, but I
> > > really wonder how many people are running Sage on linux PPC.
>
> > Though let's be clear that the downside is there.  For instance, there
> > is also the socio impact - one of the (supposed) advantages of open
> > source is that it can run on a wider spectrum of hardware, esp. lower
> > end and older ones.  It would be nice for Sage to do this as much as
> > possible.
>
> > I think the real problem is that we never knew whether Linux PPC was
> > supported or not!  The notion of 'official support' has evolved
> > considerably over the last year, thanks largely to the efforts of Dave
> > K. - mostly in good ways, I'd say.
>
> I will put my feet in it. I never really cared if it was officially supported I
> have the hardware I have the OS. I had a crack at it, it worked. mabshoff told
> me at the time that it was supported but that was then.
>
> I will test patch for numpy-1.5.x if they become available. I know that numpy
> 1.5 works because the package from the system works so it should work in sage.
>
> I also believe in trying in testing in lesser known platforms, I just happen
> to have one at hand, Dave has several.
>
> Francois

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: changing SAGE_LOCAL/SAGE_ROOT to SPKG_LOCAL/SPKG_ROOT

Hi,
> This is just my opinion, but isn't the name SPKG (SAGE package)
> already quite specialised?
indeed, more generic would be something like PKG_ROOT, etc. But since
spkg seems to be established as package system (at least in this
case), one could think of backronyming the "S" in SPKG to something
else.

Regards,
Alexander

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Reviewer for Python's distutils patch need

Hi everybody,
on SageDays 24 in Linz a patch for Python's distutils was proposed
(see http://trac.sagemath.org/sage_trac/ticket/9536). This patch makes
it possible to globally deactivatethe a users .pydiutils.cfg file
using a global environment.

Is there somebody around, who can review this?

I also reported that upstream: http://bugs.python.org/issue9309 The
most recent response is, that they do not like the idea of adding an
environment variable. Maybe we could discuss this here?

Best regards,
Alexander

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@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: Ticket #9808 for newer numpy and scipy packages would need a final decision

> On Sep 29, 9:01 am, Marshall Hampton <hampto...@gmail.com> wrote:
> > It looks like it might be a while before this is fixed by numpy:
> >
> > http://projects.scipy.org/numpy/ticket/1403
> >
> > Given the importance of numpy to Sage, I think it might make sense to
> > drop support for PPC linux. On the positive side:
> >
> > 1) There are considerable improvements to numpy and scipy in the
> > latest version that some of our developers and users are interested in
> > (not to mention bugfixes).
> >
> > 2) We need the latest scipy & numpy to be able to upgrade the python
> > version in Sage. I don't think it makes sense to freeze our version
> > of python. Also there are many interesting improvements to python in
> > the 2.7 series, which will be the last 2.x version.
> >
> > The downsides of dropping support for a platform are obvious, but I
> > really wonder how many people are running Sage on linux PPC.
>
> Though let's be clear that the downside is there. For instance, there
> is also the socio impact - one of the (supposed) advantages of open
> source is that it can run on a wider spectrum of hardware, esp. lower
> end and older ones. It would be nice for Sage to do this as much as
> possible.
>
> I think the real problem is that we never knew whether Linux PPC was
> supported or not! The notion of 'official support' has evolved
> considerably over the last year, thanks largely to the efforts of Dave
> K. - mostly in good ways, I'd say.
>
I will put my feet in it. I never really cared if it was officially supported I
have the hardware I have the OS. I had a crack at it, it worked. mabshoff told
me at the time that it was supported but that was then.

I will test patch for numpy-1.5.x if they become available. I know that numpy
1.5 works because the package from the system works so it should work in sage.

I also believe in trying in testing in lesser known platforms, I just happen
to have one at hand, Dave has several.

Francois

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันพุธที่ 29 กันยายน พ.ศ. 2553

[sage-devel] Re: [sage-release] Re: target date for feature freeze for the 4.6 cycle

On 09/29/2010 01:28 PM, kcrisman wrote:
> On Sep 29, 1:37 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>> Is there a target date for the feature freeze? (I assume 4.6.alpha2?)
>
> This has been mentioned as the target on several Trac tickets, but not
> here.
>
>> I want to make sure that a couple of changes to sagenb get in (well, at
>> least, I want to make sure they are positively reviewed and possible for
>> the release manager to include), but I don't know when the deadline is.

It's likely that I'll release 4.6.alpha2 by the weekend, with the
already merged tickets.

I'll merge into 4.6.alpha3 whichever of

Matplotlib
http://trac.sagemath.org/sage_trac/ticket/9221

NumPy and SciPy
http://trac.sagemath.org/sage_trac/ticket/9808

Cython
http://trac.sagemath.org/sage_trac/ticket/9828

Pynac
http://trac.sagemath.org/sage_trac/ticket/9901

SageNB
http://trac.sagemath.org/sage_trac/ticket/10036

is positively reviewed by 7 October 2010. After that, 4.6 will be in
feature freeze.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: matplotlib on the Sage command line

On 9/29/10 9:26 AM, Volker Braun wrote:
> Right now, matplotlib seems to produce no output whatsover when run
> from the command line:
>
> sage: show()
> /home/vbraun/Sage/sage/local/lib/python2.6/site-packages/matplotlib/
> backends/__init__.py:41:
> Your currently selected backend, 'agg' does not support show().
>
> It would be nice to be able to run the "GTKagg" backend which opens a
> window with the plot and lets you zoom in&out, save as pdf, ... But
> right now the matplotlib spkg builds without any GUI support. One
> could
>
> 1) use the system's pyGTK if available. Pro: easy. Con: different
> behaviour on different platforms. Why is Sage not including the system
> site-packages at the end of sys.path? (of course only when it is
> possible)
>
> 2) Use wx as a GUI toolkit and show a similar dialog. Pro: wxPython is
> also a requirement for VTK/mayavi2. Con: wxPython's source is almost
> as big as Sage...
>
> and, of course,
>
> 0) do nothing and force the user to save the plot to an external
> file...
>

IIRC, the original reason we stopped building matplotlib using an
external GUI is because we didn't want to require X when building.
Unfortunately, the quick hack for "fixing" this was to disable
matplotlib GUIs unless an environment variable was set
(SAGE_MATPLOTLIB_GUI, I believe). This is a kludge, since really we
should probably be relying on matplotlib automatically detecting if X is
installed, or fix it so that it does that. This is recorded somewhere
on trac.

The new matplotlib 1.0.0 package should make these sorts of changes
easier to make. It was just merged into the next release of Sage, and
significantly cleans up the matplotlib spkg.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

Sorry, somehow I missed Volker's post and your response to it. Its
confusing to have things discussed on sage-release and sage-devel
simultaneously (one reason I'm opposed to so many sage-* discussion
groups...).

If there is already an upstream patch than we should keep supporting
linux ppc. I was mistakenly thinking that it might be a long time, if
ever, for the numpy folks to correct the problem.

-Marshall

On Sep 29, 5:17 pm, David Kirkby <david.kir...@onetel.net> wrote:
> On 29 September 2010 22:29, Marshall Hampton <hampto...@gmail.com> wrote:
>
> > Both people wrote back - one is no longer using Sage on linux ppc, the
> > other one is.
>
> > My guess would be that there are fewer than 10 people using Sage on
> > linux ppc.  I think there are more people who would be glad to have
> > updated numpy, scipy, and python versions.  Overall my personal
> > feeling is that its worthwhile to include the update from 9808 now,
> > and if the problems in numpy with ppc get fixed we should update as
> > soon as possible after that to try to restore linuc ppc
> > functionality.
>
> > Otherwise maybe we could have this update be an optional spkg.
>
> You may be right about 10 people - I've no idea of the number. But
> like Leif, I think that other platforms provide a useful test when
> problems are found. The more unusual operating systems ard platforms
> tend to highlight bugs, which lie in wait to hit anyone, but are true
> bugs.
>
> As someone who took a fairly major role in porting Sage to a different
> opreating systems (Solaris( and a different processor (SPARC), I'm
> somewhat puzzled why PPC should be presenting a particular problem.
> I've even built quite large parts of Sage under AIX on PPC. But AIX is
> a very different system to Linux, so the Linux issues should not be
> hard to solve.
>
> As there are bug report on the numpy/scipy site I can look at?
>
> I''ve little intension myself of running Linux on PPC, but I would not
> like to see the platform dropped, since 20+ years of software
> development have taught me that these rarer platforms often show real
> bugs, that can hit anyone at a later date.
>
> Perhaps even this PPC "bug" is just a bug that could hit any
> processor, but has to date only shown up on PPC.
>
> 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+unsubscribe@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: Ticket #9808 for newer numpy and scipy packages would need a final decision

On 29 September 2010 22:29, Marshall Hampton <hamptonio@gmail.com> wrote:
> Both people wrote back - one is no longer using Sage on linux ppc, the
> other one is.
>
> My guess would be that there are fewer than 10 people using Sage on
> linux ppc.  I think there are more people who would be glad to have
> updated numpy, scipy, and python versions.  Overall my personal
> feeling is that its worthwhile to include the update from 9808 now,
> and if the problems in numpy with ppc get fixed we should update as
> soon as possible after that to try to restore linuc ppc
> functionality.
>
> Otherwise maybe we could have this update be an optional spkg.

You may be right about 10 people - I've no idea of the number. But
like Leif, I think that other platforms provide a useful test when
problems are found. The more unusual operating systems ard platforms
tend to highlight bugs, which lie in wait to hit anyone, but are true
bugs.

As someone who took a fairly major role in porting Sage to a different
opreating systems (Solaris( and a different processor (SPARC), I'm
somewhat puzzled why PPC should be presenting a particular problem.
I've even built quite large parts of Sage under AIX on PPC. But AIX is
a very different system to Linux, so the Linux issues should not be
hard to solve.

As there are bug report on the numpy/scipy site I can look at?

I''ve little intension myself of running Linux on PPC, but I would not
like to see the platform dropped, since 20+ years of software
development have taught me that these rarer platforms often show real
bugs, that can hit anyone at a later date.

Perhaps even this PPC "bug" is just a bug that could hit any
processor, but has to date only shown up on PPC.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

Both people wrote back - one is no longer using Sage on linux ppc, the
other one is.

My guess would be that there are fewer than 10 people using Sage on
linux ppc. I think there are more people who would be glad to have
updated numpy, scipy, and python versions. Overall my personal
feeling is that its worthwhile to include the update from 9808 now,
and if the problems in numpy with ppc get fixed we should update as
soon as possible after that to try to restore linuc ppc
functionality.

Otherwise maybe we could have this update be an optional spkg.

Certainly in the long run, ppc is doomed and we need to stay
reasonably in sync with numpy, scipy, and python.

-Marshall Hampton

On Sep 29, 1:09 pm, Marshall Hampton <hampto...@gmail.com> wrote:
> I have written the two people I could find who might care about Sage
> on linux ppc and invited them to respond here, or I will summarize or
> forward any direct response.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Substitution in symbolic expressions

On 29 sep, 21:28, Burcin Erocal <bur...@erocal.org> wrote:
> On Wed, 29 Sep 2010 07:38:59 -0700 (PDT)
>
>
>
> Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> > Sage has the following behavior inherited from GiNaC (http://
> >www.ginac.de/tutorial/Pattern-matching-and-advanced-substitutions.html)
> > :
>
> > ----------------------------------------------------------------------
> > | Sage Version 4.5.3, Release Date: 2010-09-04                       |
> > | Type notebook() for the GUI, and license() for information.        |
> > ----------------------------------------------------------------------
> > sage: x,y,z = var('x,y,z')
> > sage: P = x+y
> > sage: P.subs({x+y:z})
> > z
> > sage: P = x+y+z
> > sage: P.subs({x+y:z})
> > x + y + z
> > sage: w0 = SR.wild(0)
> > sage: P.subs({x+y+w0:z+w0})
> > 2*z
> > sage: P = x+y
> > sage: P.subs({x+y+w0:z+w0})
> > z
> > sage:
>
> > Of course the same thing is happening with mul objects.
> > I think this is somewhat misleading and should at least be explained
> > in the documentation.
> > The above url is already give in the documentation of the match
> > function but not in the one of subs.
> > Maybe this explains the warning in the documentation of the subs_expr
> > function.
>
> The function substitute_expression() is one of the relics remaining
> from the old symbolics code. IMHO, we should merge it with the
> substitute() function and deprecate it.
>
>
>
> > However that warning refers to Maxima whereas :
>
> > sage: get_systems('P.subs_expr({x+y+w0:z+w0})')
> > ['ginac']
>
> > The weird example can also be solved using a wildcard :
>
> > sage: t = var('t')
> > sage: f(x,y,t) = cos(x) + sin(y) + x^2 + y^2 + t
> > sage: f
> > (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> > sage: f.subs_expr(x^2 + y^2 == t)
> > (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> > sage: f.subs_expr(x^2 + y^2 + w0 == t + w0)
> > (x, y, t) |--> 2*t + sin(y) + cos(x)
>
> > I don't know if such a trick should be implemented in Sage, pynac, or
> > even in GiNaC.
>
> You can definitely suggest it to the ginac developers. I'm curious to
> see what they think.
>
> Note that this might not be so straight forward, especially if the
> expression we're supposed to replace contains wildcards in the first
> place. We can add some logic to our interface to ginac and add the
> wildcard to the expression if none exists. Though I'm afraid this might
> increase the confusion if someone is trying to debug substitutions in a
> complex expression.
>
> One other point against doing this by default is that substituting with
> wildcards is slower. Even if we decide to do this, there should be an
> option not to.
I completely agree with that and am aware that it would be slower.
That is why I don't think it should be done by default, but something
in the doc should give someinsight on what is going on and what can be
done.

>
> Cheers,
> Burcin

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Substitution in symbolic expressions

On Wed, 29 Sep 2010 07:38:59 -0700 (PDT)
Jean-Pierre Flori <jpflori@gmail.com> wrote:

> Sage has the following behavior inherited from GiNaC (http://
> www.ginac.de/tutorial/Pattern-matching-and-advanced-substitutions.html)
> :
>
> ----------------------------------------------------------------------
> | Sage Version 4.5.3, Release Date: 2010-09-04 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> sage: x,y,z = var('x,y,z')
> sage: P = x+y
> sage: P.subs({x+y:z})
> z
> sage: P = x+y+z
> sage: P.subs({x+y:z})
> x + y + z
> sage: w0 = SR.wild(0)
> sage: P.subs({x+y+w0:z+w0})
> 2*z
> sage: P = x+y
> sage: P.subs({x+y+w0:z+w0})
> z
> sage:
>
> Of course the same thing is happening with mul objects.
> I think this is somewhat misleading and should at least be explained
> in the documentation.
> The above url is already give in the documentation of the match
> function but not in the one of subs.
> Maybe this explains the warning in the documentation of the subs_expr
> function.

The function substitute_expression() is one of the relics remaining
from the old symbolics code. IMHO, we should merge it with the
substitute() function and deprecate it.

> However that warning refers to Maxima whereas :
>
> sage: get_systems('P.subs_expr({x+y+w0:z+w0})')
> ['ginac']
>
> The weird example can also be solved using a wildcard :
>
> sage: t = var('t')
> sage: f(x,y,t) = cos(x) + sin(y) + x^2 + y^2 + t
> sage: f
> (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> sage: f.subs_expr(x^2 + y^2 == t)
> (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> sage: f.subs_expr(x^2 + y^2 + w0 == t + w0)
> (x, y, t) |--> 2*t + sin(y) + cos(x)
>
> I don't know if such a trick should be implemented in Sage, pynac, or
> even in GiNaC.

You can definitely suggest it to the ginac developers. I'm curious to
see what they think.

Note that this might not be so straight forward, especially if the
expression we're supposed to replace contains wildcards in the first
place. We can add some logic to our interface to ginac and add the
wildcard to the expression if none exists. Though I'm afraid this might
increase the confusion if someone is trying to debug substitutions in a
complex expression.

One other point against doing this by default is that substituting with
wildcards is slower. Even if we decide to do this, there should be an
option not to.


Cheers,
Burcin

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Substitution in symbolic expressions

On 29 sep, 20:49, rjf <fate...@gmail.com> wrote:
> Look at what ratsubst will do in Maxima.
>
> If you think you have a well-defined operation in mind, what does it
> do with
> substituting 1  for s^2+c^2  in the expression s^4+3*s^2*c^2+ c^4?
I don't think I had a well mathematically defined operation in mind.
Of course I should have read Maxima doc before but was confused by the
warning because I knew that the subs function uses Pynac and not
Maxima.
My point is that for me the meaning of "formal pattern" and
"mathematical meaning" didn't make me think of :
"b must be an atom or a complete subexpression of c" as is said in
maxima doc.
I thought : ok, it should replace it as "sed" would do with a string,
but it doesn't and it is weird, but the documentation says so...
Especially when the Sage doc then says:
"The following seems really weird, but it is what Maple does" and
"Actually Mathematica does something that makes more sense"
But knowing the internals of pynac, or just reading the doc above, it
is not weird at all, so I thought that the Sage documentation might
tell something else that "it is weird" but it is that way.
And with that in mind, I wouldn't expect it to do anything with your
example.
I would call collect(s^2) before.
But that is just my humble opinion.
>
> RJF
>
> On Sep 29, 7:38 am, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
>
> > Sage has the following behavior inherited from GiNaC (http://www.ginac.de/tutorial/Pattern-matching-and-advanced-substituti...)
> > :
>
> > ----------------------------------------------------------------------
> > | Sage Version 4.5.3, Release Date: 2010-09-04                       |
> > | Type notebook() for the GUI, and license() for information.        |
> > ----------------------------------------------------------------------
> > sage: x,y,z = var('x,y,z')
> > sage: P = x+y
> > sage: P.subs({x+y:z})
> > z
> > sage: P = x+y+z
> > sage: P.subs({x+y:z})
> > x + y + z
> > sage: w0 = SR.wild(0)
> > sage: P.subs({x+y+w0:z+w0})
> > 2*z
> > sage: P = x+y
> > sage: P.subs({x+y+w0:z+w0})
> > z
> > sage:
>
> > Of course the same thing is happening with mul objects.
> > I think this is somewhat misleading and should at least be explained
> > in the documentation.
> > The above url is already give in the documentation of the match
> > function but not in the one of subs.
> > Maybe this explains the warning in the documentation of the subs_expr
> > function.
> > However that warning refers to Maxima whereas :
>
> > sage: get_systems('P.subs_expr({x+y+w0:z+w0})')
> > ['ginac']
>
> > The weird example can also be solved using a wildcard :
>
> > sage: t = var('t')
> > sage: f(x,y,t) = cos(x) + sin(y) + x^2 + y^2 + t
> > sage: f
> > (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> > sage: f.subs_expr(x^2 + y^2 == t)
> > (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> > sage: f.subs_expr(x^2 + y^2 + w0 == t + w0)
> > (x, y, t) |--> 2*t + sin(y) + cos(x)
>
> > I don't know if such a trick should be implemented in Sage, pynac, or
> > even in GiNaC.
> > At least, it should be documented.
>
> > Best regards,

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Substitution in symbolic expressions

Look at what ratsubst will do in Maxima.

If you think you have a well-defined operation in mind, what does it
do with
substituting 1 for s^2+c^2 in the expression s^4+3*s^2*c^2+ c^4?

RJF

On Sep 29, 7:38 am, Jean-Pierre Flori <jpfl...@gmail.com> wrote:
> Sage has the following behavior inherited from GiNaC (http://www.ginac.de/tutorial/Pattern-matching-and-advanced-substitutions.html)
> :
>
> ----------------------------------------------------------------------
> | Sage Version 4.5.3, Release Date: 2010-09-04                       |
> | Type notebook() for the GUI, and license() for information.        |
> ----------------------------------------------------------------------
> sage: x,y,z = var('x,y,z')
> sage: P = x+y
> sage: P.subs({x+y:z})
> z
> sage: P = x+y+z
> sage: P.subs({x+y:z})
> x + y + z
> sage: w0 = SR.wild(0)
> sage: P.subs({x+y+w0:z+w0})
> 2*z
> sage: P = x+y
> sage: P.subs({x+y+w0:z+w0})
> z
> sage:
>
> Of course the same thing is happening with mul objects.
> I think this is somewhat misleading and should at least be explained
> in the documentation.
> The above url is already give in the documentation of the match
> function but not in the one of subs.
> Maybe this explains the warning in the documentation of the subs_expr
> function.
> However that warning refers to Maxima whereas :
>
> sage: get_systems('P.subs_expr({x+y+w0:z+w0})')
> ['ginac']
>
> The weird example can also be solved using a wildcard :
>
> sage: t = var('t')
> sage: f(x,y,t) = cos(x) + sin(y) + x^2 + y^2 + t
> sage: f
> (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> sage: f.subs_expr(x^2 + y^2 == t)
> (x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
> sage: f.subs_expr(x^2 + y^2 + w0 == t + w0)
> (x, y, t) |--> 2*t + sin(y) + cos(x)
>
> I don't know if such a trick should be implemented in Sage, pynac, or
> even in GiNaC.
> At least, it should be documented.
>
> Best regards,

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

On Sep 29, 2:10 pm, maldun <dom...@gmx.net> wrote:
> > Maldun, do you think that would be possible?  I'd be willing to retest
> > it on the OS X PPC box to make sure that didn't break anything - no,
> > Dima, I still don't have the Linux up on that yet :(
>
> > - kcrisman
>
> I packed it:http://code.google.com/p/spkg-upload/downloads/detail?name=numpy-1.4....
>
> Give me feedback if it builds on your machine, it works for me.
> I will run the long doctests during the night.

I might have to download and build a new Sage for this, we'll see (I
have applied lots of patches and new spkgs to all my current ones),
and then run doctests... so it could take until Friday or even later.
I'll do my best!

- 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

>
> Maldun, do you think that would be possible?  I'd be willing to retest
> it on the OS X PPC box to make sure that didn't break anything - no,
> Dima, I still don't have the Linux up on that yet :(
>
> - kcrisman

I packed it: http://code.google.com/p/spkg-upload/downloads/detail?name=numpy-1.4.1.p0.spkg

Give me feedback if it builds on your machine, it works for me.
I will run the long doctests during the night.

greez,
maldun

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

I have written the two people I could find who might care about Sage
on linux ppc and invited them to respond here, or I will summarize or
forward any direct response.


On Sep 29, 1:02 pm, Marshall Hampton <hampto...@gmail.com> wrote:
> I wasn't asking for a majority vote.  I'm wondering if _anyone_ still
> cares about sage on linux PPC.  We don't provide binaries for linux
> PPC, and I can't remember it happening in the past.
>
> Searching sage-support I can find questions from two people (Bin Zhang
> and Douglas Mencken) about that platform.  The latest one is from
> February, so perhaps there are some users.  But at what percentage is
> it worth stalling development?  I am sure answers to that will vary.
>
> -Marshall
>
> On Sep 29, 12:54 pm, leif <not.rea...@online.de> wrote:
>
> > Jason Grout wrote:
> > >  On 09/29/2010 08:01 AM, Marshall Hampton wrote:
> > >> It looks like it might be a while before this is fixed by numpy:
>
> > >>http://projects.scipy.org/numpy/ticket/1403
>
> > >> Given the importance of numpy to Sage, I think it might make sense to
> > >> drop support for PPC linux.  On the positive side:
>
> > >> 1) There are considerable improvements to numpy and scipy in the
> > >> latest version that some of our developers and users are interested in
> > >> (not to mention bugfixes).
>
> > >> 2) We need the latest scipy&  numpy to be able to upgrade the python
> > >> version in Sage.  I don't think it makes sense to freeze our version
> > >> of python.  Also there are many interesting improvements to python in
> > >> the 2.7 series, which will be the last 2.x version.
>
> > IIRC the same had been said for 2.6... ;-)
>
> > >> The downsides of dropping support for a platform are obvious, but I
> > >> really wonder how many people are running Sage on linux PPC.
>
> > > Let's put out a query on sage-devel and sage-support.
>
> > Yep, but dropping a platform should IMHO not depend on the opinion of
> > some majority (which I expect such will have).
>
> > It would be better to convince the numpy developers to fix this upstream.
>
> > Btw, regarding bugs, the current numpy version in Sage is
> > numpy-1.3.0.p4, i.e. a "dot zero" upstream version.
>
> > -Leif
>
> > > Harald, are there
> > > any stats for the binaries for PPC?
>
> > > 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

Yeah that's true, and I wouldn't make the final decision on that, but
it would be great if it could be tested
anyway, I think this may make porting to 1.5.1 easier when it finally
will be released,

On 29 Sep., 18:49, kcrisman <kcris...@gmail.com> wrote:
> On Sep 29, 11:46 am, maldun <dom...@gmx.net> wrote:
>
> > > Maldun, do you think that would be possible?  I'd be willing to retest
> > > it on the OS X PPC box to make sure that didn't break anything - no,
> > > Dima, I still don't have the Linux up on that yet :(
>
> > > - kcrisman
>
> > Sure why not! I give it a shot and post a patched version on trac as
> > soon as possible.
>
> > I've already working on 1.5.0 too, and I think I know already what has
> > to be fixed.
> > If I provide the package of 1.5.0 and a patch for the doctests would
> > you test, that too?
> > Peraps we could jump directly to 1.5.0. then!
>
> But I thought the reason for doing 1.4.x was because it was more
> stable?
>
> - 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

On Sep 29, 11:46 am, maldun <dom...@gmx.net> wrote:
> > Maldun, do you think that would be possible?  I'd be willing to retest
> > it on the OS X PPC box to make sure that didn't break anything - no,
> > Dima, I still don't have the Linux up on that yet :(
>
> > - kcrisman
>
> Sure why not! I give it a shot and post a patched version on trac as
> soon as possible.
>
> I've already working on 1.5.0 too, and I think I know already what has
> to be fixed.
> If I provide the package of 1.5.0 and a patch for the doctests would
> you test, that too?
> Peraps we could jump directly to 1.5.0. then!
>

But I thought the reason for doing 1.4.x was because it was more
stable?

- 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+unsubscribe@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 eating all memory when decomposing a modular symbols space

I just forwarded this to sage-nt since people might read it there who
can answer but who do not subscribe to sage-devel.

John Cremona

On 29 Sep, 10:53, "nbfr." <nunobfrei...@gmail.com> wrote:
> Hi,
>
> I've recently started using SAGE to compute some modular forms that I
> need to my thesis when I found it was consuming all my 4GB RAM when
> computing a space that I thought not to be that big. I've just joined
> this forum to explain this situation which seems strange to me.
>
> The first time this happened I was computing:
>
> D=Dirichlet(20); f=Newforms(D[7].extend(1600),2,names='a').
>
> When looking into it in more detail I found that the problem was in
> the instruction:
>
> ModularSymbols(D[7].extend(1600),
> 2,sign=1).cuspidal_subspace().new_subspace().decomposition()
>
> Trying to compute myself this decomposition step by step I got the
> following results:
>
> M=ModularSymbols(D[7].extend(1600),
> 2,sgn=1).cuspidal_subspace().new_subspace();
> B=M.T(11).decomposition()
>
> this outputs:
>
> B[0],B[1],B[2],B[3], irreducible spaces of diemension 1 and B[6]
> irreducible of dim 2 over Q(i).
>
> B[4],B[5],B[9],B[10] and B[11] reducible spaces of dimensions 2, 2, 4,
> 4 and 8. it is possible to complete their decomposition by running
> B[i].decomposition()
>
> and finally the problem appears when trying to decompose B[7] and
> B[8]. If I type B[7].decomposition() or B[8].decomposition() my
> computer will run forever until it wastes all memory. I'm not familiar
> with the implemented algorithm but I've computed the characteristic
> polynomials for the first 50 primes in B[7] and they all are of the
> form (degree two polynomial)^2 or (degree 1)^4 over Q(i) which I
> suspect it may be the reason why SAGE can't finish the computation.
>
> any idea of what is happening in this two 4-dimensional spaces?
>
> Thanks in advance,
> Nuno

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

>
> Maldun, do you think that would be possible?  I'd be willing to retest
> it on the OS X PPC box to make sure that didn't break anything - no,
> Dima, I still don't have the Linux up on that yet :(
>
> - kcrisman

Sure why not! I give it a shot and post a patched version on trac as
soon as possible.

I've already working on 1.5.0 too, and I think I know already what has
to be fixed.
If I provide the package of 1.5.0 and a patch for the doctests would
you test, that too?
Peraps we could jump directly to 1.5.0. then!

greez,
maldun

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: matplotlib on the Sage command line

>
> 0) do nothing and force the user to save the plot to an external
> file...
>


At the very least we could catch that error and print a more helpful
message to show how to do 0; I've run into this a number of times.
Can you open a ticket for that, and a separate one (if it doesn't
exist, which it may) for the other?

- 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

> One advantage of keeping rarer ports going is that it does offer something to
> compare with, when issues are found. Sometimes a problem might be thought to be
> Linux, other time Big endian, another time PPC. The ability to compare a problem
> to different platforms is very useful.

+1

> So I would suggest if this is fixed upstream, then the fix should be added to
> Sage, rather than preventing a supported linux distribution from working.
> There's no need to wait for another release of Numpy.
>

Maldun, do you think that would be possible? I'd be willing to retest
it on the OS X PPC box to make sure that didn't break anything - no,
Dima, I still don't have the Linux up on that yet :(

- 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Substitution in symbolic expressions

Sage has the following behavior inherited from GiNaC (http://
www.ginac.de/tutorial/Pattern-matching-and-advanced-substitutions.html)
:

----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: x,y,z = var('x,y,z')
sage: P = x+y
sage: P.subs({x+y:z})
z
sage: P = x+y+z
sage: P.subs({x+y:z})
x + y + z
sage: w0 = SR.wild(0)
sage: P.subs({x+y+w0:z+w0})
2*z
sage: P = x+y
sage: P.subs({x+y+w0:z+w0})
z
sage:

Of course the same thing is happening with mul objects.
I think this is somewhat misleading and should at least be explained
in the documentation.
The above url is already give in the documentation of the match
function but not in the one of subs.
Maybe this explains the warning in the documentation of the subs_expr
function.
However that warning refers to Maxima whereas :

sage: get_systems('P.subs_expr({x+y+w0:z+w0})')
['ginac']

The weird example can also be solved using a wildcard :

sage: t = var('t')
sage: f(x,y,t) = cos(x) + sin(y) + x^2 + y^2 + t
sage: f
(x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
sage: f.subs_expr(x^2 + y^2 == t)
(x, y, t) |--> x^2 + y^2 + t + sin(y) + cos(x)
sage: f.subs_expr(x^2 + y^2 + w0 == t + w0)
(x, y, t) |--> 2*t + sin(y) + cos(x)

I don't know if such a trick should be implemented in Sage, pynac, or
even in GiNaC.
At least, it should be documented.

Best regards,

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] matplotlib on the Sage command line

Right now, matplotlib seems to produce no output whatsover when run
from the command line:

sage: show()
/home/vbraun/Sage/sage/local/lib/python2.6/site-packages/matplotlib/
backends/__init__.py:41:
Your currently selected backend, 'agg' does not support show().

It would be nice to be able to run the "GTKagg" backend which opens a
window with the plot and lets you zoom in&out, save as pdf, ... But
right now the matplotlib spkg builds without any GUI support. One
could

1) use the system's pyGTK if available. Pro: easy. Con: different
behaviour on different platforms. Why is Sage not including the system
site-packages at the end of sys.path? (of course only when it is
possible)

2) Use wx as a GUI toolkit and show a similar dialog. Pro: wxPython is
also a requirement for VTK/mayavi2. Con: wxPython's source is almost
as big as Sage...

and, of course,

0) do nothing and force the user to save the plot to an external
file...

Volker

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@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: Ticket #9808 for newer numpy and scipy packages would need a final decision

On 09/29/10 03:07 PM, maldun wrote:
>
>
> On Sep 29, 3:55 pm, Volker Braun<vbraun.n...@gmail.com> wrote:
>> I thought this is fixed due to Debian people pestering numpy dev's :-)
>> But I'm not sure if the patch is already included in the newest
>> release.
>>
>> http://mail.scipy.org/pipermail/numpy-svn/2010-July/004318.html
>>
>> Volker
>
> As far as I know this will happen in 1.5.1, but this will take some
> time...
>

If its fixed in a later developer snapshot, it should be possible to get just
that fix and apply that. That's what has been done on several recent tickets
(for example Pari), where a bug was fixed upstream, but the relevant fix added
in Sage. That does not mean we need to change the version in Sage - just apply
the patch that is causing the problem on PPC Linux.

One advantage of keeping rarer ports going is that it does offer something to
compare with, when issues are found. Sometimes a problem might be thought to be
Linux, other time Big endian, another time PPC. The ability to compare a problem
to different platforms is very useful.

So I would suggest if this is fixed upstream, then the fix should be added to
Sage, rather than preventing a supported linux distribution from working.
There's no need to wait for another release of Numpy.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

On Sep 29, 9:01 am, Marshall Hampton <hampto...@gmail.com> wrote:
> It looks like it might be a while before this is fixed by numpy:
>
> http://projects.scipy.org/numpy/ticket/1403
>
> Given the importance of numpy to Sage, I think it might make sense to
> drop support for PPC linux.  On the positive side:
>
> 1) There are considerable improvements to numpy and scipy in the
> latest version that some of our developers and users are interested in
> (not to mention bugfixes).
>
> 2) We need the latest scipy & numpy to be able to upgrade the python
> version in Sage.  I don't think it makes sense to freeze our version
> of python.  Also there are many interesting improvements to python in
> the 2.7 series, which will be the last 2.x version.
>
> The downsides of dropping support for a platform are obvious, but I
> really wonder how many people are running Sage on linux PPC.

Though let's be clear that the downside is there. For instance, there
is also the socio impact - one of the (supposed) advantages of open
source is that it can run on a wider spectrum of hardware, esp. lower
end and older ones. It would be nice for Sage to do this as much as
possible.

I think the real problem is that we never knew whether Linux PPC was
supported or not! The notion of 'official support' has evolved
considerably over the last year, thanks largely to the efforts of Dave
K. - mostly in good ways, I'd say.

- 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

On Sep 29, 3:55 pm, Volker Braun <vbraun.n...@gmail.com> wrote:
> I thought this is fixed due to Debian people pestering numpy dev's :-)
> But I'm not sure if the patch is already included in the newest
> release.
>
> http://mail.scipy.org/pipermail/numpy-svn/2010-July/004318.html
>
> Volker

As far as I know this will happen in 1.5.1, but this will take some
time...

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

I thought this is fixed due to Debian people pestering numpy dev's :-)
But I'm not sure if the patch is already included in the newest
release.

http://mail.scipy.org/pipermail/numpy-svn/2010-July/004318.html

Volker

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Ticket #9808 for newer numpy and scipy packages would need a final decision

It looks like it might be a while before this is fixed by numpy:

http://projects.scipy.org/numpy/ticket/1403

Given the importance of numpy to Sage, I think it might make sense to
drop support for PPC linux. On the positive side:

1) There are considerable improvements to numpy and scipy in the
latest version that some of our developers and users are interested in
(not to mention bugfixes).

2) We need the latest scipy & numpy to be able to upgrade the python
version in Sage. I don't think it makes sense to freeze our version
of python. Also there are many interesting improvements to python in
the 2.7 series, which will be the last 2.x version.

The downsides of dropping support for a platform are obvious, but I
really wonder how many people are running Sage on linux PPC.

On Sep 29, 6:05 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
> On 09/29/10 11:46 AM wrote:
>
> > It only builds not on linux ppc, which is not on the supported list in
> > the README.txt
>
> Though if you look at:
>
> http://www.sagemath.org/doc/installation/source.htmlhttp://wiki.sagemath.org/SupportedPlatforms
>
> *both* say Linux on PPC is supported. As I've noted before, there's no agreement
> about what is and what is not supported. Pick any of the several places where
> there are lists of supported platforms I doubt you will find any two agree with
> each other.
>
> See also:
>
> http://wiki.sagemath.org/suggested-for-supported-platforms
>
> http://trac.sagemath.org/sage_trac/ticket/9487
>
> 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] SAGE eating all memory when decomposing a modular symbols space

Hi,

I've recently started using SAGE to compute some modular forms that I
need to my thesis when I found it was consuming all my 4GB RAM when
computing a space that I thought not to be that big. I've just joined
this forum to explain this situation which seems strange to me.

The first time this happened I was computing:

D=Dirichlet(20); f=Newforms(D[7].extend(1600),2,names='a').

When looking into it in more detail I found that the problem was in
the instruction:

ModularSymbols(D[7].extend(1600),
2,sign=1).cuspidal_subspace().new_subspace().decomposition()

Trying to compute myself this decomposition step by step I got the
following results:

M=ModularSymbols(D[7].extend(1600),
2,sgn=1).cuspidal_subspace().new_subspace();
B=M.T(11).decomposition()

this outputs:

B[0],B[1],B[2],B[3], irreducible spaces of diemension 1 and B[6]
irreducible of dim 2 over Q(i).

B[4],B[5],B[9],B[10] and B[11] reducible spaces of dimensions 2, 2, 4,
4 and 8. it is possible to complete their decomposition by running
B[i].decomposition()

and finally the problem appears when trying to decompose B[7] and
B[8]. If I type B[7].decomposition() or B[8].decomposition() my
computer will run forever until it wastes all memory. I'm not familiar
with the implemented algorithm but I've computed the characteristic
polynomials for the first 50 primes in B[7] and they all are of the
form (degree two polynomial)^2 or (degree 1)^4 over Q(i) which I
suspect it may be the reason why SAGE can't finish the computation.

any idea of what is happening in this two 4-dimensional spaces?

Thanks in advance,
Nuno

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันอังคารที่ 28 กันยายน พ.ศ. 2553

[sage-devel] Re: Sage: Very suitable for rapid prototyping

Well done sir! Congratulations.

On Sep 28, 5:42 pm, Carl Witty <carl.wi...@gmail.com> wrote:
> I am proud to report that Sage has been "officially" recognized as
> "very suitable for rapid prototyping".  Also, Sage is "a fine tool for
> many applications".
>
> This recognition is because I won the lightning round (for the "rapid
> prototyping" recognition) and got second place in the main contest
> (for the "fine tool" recognition) in the 2010 ICFP Programming Contest
> (http://icfpcontest.org/2010/) using Sage (the recognition is part of
> the prize).  (Normally the recognition would be for a programming
> language, but the organizers let me claim Sage rather than Python as
> the programming language I used.)
>
> From Sage, I used:
>
> * matrices over multivariate integer polynomials
> * the Polyhedron class, to find vertices of a polyhedron given its
> definition as linear inequalities
> * ZZ's arbitrary-base support, to convert integers to and from base-3 strings
>
> The prize ceremony was videotaped, but I don't know if the video will
> be available.  (If so, it would be part of the segment "Report on the
> Thirteenth ICFP Programming Contest".)
>
> 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Sage: Very suitable for rapid prototyping

Well, first off, I must say congratulations! The problem looks
extremely challenging, so this isn't just a testament to the language
but to your skill (and knowledge of the language), too.

Second... you got my hopes up a little bit -- I thought this was about
"rapid prototyping" in the making of physical objects sense. I'd love
to get a RepRap, and build things through Sage. But I'm no less
impressed.

On Tue, Sep 28, 2010 at 3:42 PM, Carl Witty <carl.witty@gmail.com> wrote:
> I am proud to report that Sage has been "officially" recognized as
> "very suitable for rapid prototyping".  Also, Sage is "a fine tool for
> many applications".
>
> This recognition is because I won the lightning round (for the "rapid
> prototyping" recognition) and got second place in the main contest
> (for the "fine tool" recognition) in the 2010 ICFP Programming Contest
> (http://icfpcontest.org/2010/) using Sage (the recognition is part of
> the prize).  (Normally the recognition would be for a programming
> language, but the organizers let me claim Sage rather than Python as
> the programming language I used.)
>
> From Sage, I used:
>
> * matrices over multivariate integer polynomials
> * the Polyhedron class, to find vertices of a polyhedron given its
> definition as linear inequalities
> * ZZ's arbitrary-base support, to convert integers to and from base-3 strings
>
> The prize ceremony was videotaped, but I don't know if the video will
> be available.  (If so, it would be part of the segment "Report on the
> Thirteenth ICFP Programming Contest".)
>
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org