Jason Grout wrote:
> Recently there was a thread that dealt with having axes of 2d plots
> cross at non-origin points. This is a "problem" (depending on who is
> talking :) of the current Sage axis code.
It appears that the next version of matplotlib supports an even easier
way to have axes
Hi Jason,
On Sun, Aug 2, 2009 at 3:38 PM, Jason Grout wrote:
>
> Minh Nguyen wrote:
>
>> Here I speak from my experience in trying to (unsuccessfully) update
>> the NetworkX spkg to version 0.99. Currently, Sage is shipped with
>> NetworkX 0.36 and I have created ticket #6041
>>
>> http://trac.sa
I'm cc'ing this to sage-combinat-devel... I have nothing to add below,
except that the interactive stuff is coming from the Symmetric
library, I think.
On Sat, Aug 1, 2009 at 6:42 PM, Jerome
Lefebvre wrote:
>
>
> Bizarre error reporting with symmetric functions;
>
> --
Minh Nguyen wrote:
> Here I speak from my experience in trying to (unsuccessfully) update
> the NetworkX spkg to version 0.99. Currently, Sage is shipped with
> NetworkX 0.36 and I have created ticket #6041
>
> http://trac.sagemath.org/sage_trac/ticket/6041
>
> in order to get NetworkX 0.99 int
Bizarre error reporting with symmetric functions;
--
| Sage Version 4.1, Release Date: 2009-07-09 |
| Type notebook() for the GUI, and license() for information.|
-
Hi folks,
The Sage 4.1.1 release cycle is now in 4.1.1.rc1, which hasn't been
released yet. As this release candidate is for stabilizing Sage and
fixing bugs, I thought I should outline below a number of bug fixes
which would be good to get into Sage 4.1.1. There are about 5 tickets
relating to s
Hi Simon,
On Sun, Aug 2, 2009 at 8:39 AM, Simon King wrote:
>
> Dear Sage developers,
>
> I asked the following question in a mail to William Stein and David
> Joyner, but William suggested the discussion should be in public.
>
> Yesterday my cohomology package became an optional spkg. But there
On Sat, Aug 1, 2009 at 4:17 PM, Juan Jose
Garcia-Ripoll wrote:
>
> On Sun, Aug 2, 2009 at 12:50 AM, Dr. David
> Kirkby wrote:
>> Juan Jose Garcia-Ripoll wrote:
>>>
>>> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David
>>> Kirkby wrote:
Following from my mail half an hour or so ago, here is what
On Sat, Aug 1, 2009 at 4:19 PM, Peter
Jeremy wrote:
> On 2009-Aug-01 20:22:09 +0100, Jason Moxham wrote:
>>So are you saying that the compilers on T2 are broken in 64bit mode ? or just
>>sage is broken ? or just mpir ? or dont we know?
>
> Sun development tools treat Solaris as "primarily a 32-bi
On 2009-Aug-01 20:22:09 +0100, Jason Moxham wrote:
>So are you saying that the compilers on T2 are broken in 64bit mode ? or just
>sage is broken ? or just mpir ? or dont we know?
Sun development tools treat Solaris as "primarily a 32-bit OS but you
can build 64-bit applications if you jump thro
On Sun, Aug 2, 2009 at 12:50 AM, Dr. David
Kirkby wrote:
> Juan Jose Garcia-Ripoll wrote:
>>
>> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David
>> Kirkby wrote:
>>>
>>> Following from my mail half an hour or so ago, here is what happens on
>>> t2 if the Sun compiler is used, but the location of the gmp
On Sat, Aug 1, 2009 at 3:50 PM, Dr. David Kirkby wrote:
>
> Hi,
>
> I copied this to sage-devel too, as clearly ECL is important. (For
> anyone else, this discussion started on ecls-l...@lists.sourceforge.net).
>
> Juan Jose Garcia-Ripoll wrote:
>> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David
>> Kir
On Sat, Aug 1, 2009 at 6:39 PM, Simon King wrote:
>
> Dear Sage developers,
>
> I asked the following question in a mail to William Stein and David
> Joyner, but William suggested the discussion should be in public.
>
> Yesterday my cohomology package became an optional spkg. But there are
> a lot
Juan Jose Garcia-Ripoll wrote:
> On Sun, Aug 2, 2009 at 12:27 AM, Juan Jose
> Garcia-Ripoll wrote:
>> On Sun, Aug 2, 2009 at 12:03 AM, Juan Jose
>> Garcia-Ripoll wrote:
Actually, inside Sage, GMP is not used, but IMPR, which, if my
understanding
of it is correct, is a GPL2 version
Hi,
I copied this to sage-devel too, as clearly ECL is important. (For
anyone else, this discussion started on ecls-l...@lists.sourceforge.net).
Juan Jose Garcia-Ripoll wrote:
> On Sat, Aug 1, 2009 at 11:36 PM, Dr. David
> Kirkby wrote:
>> Following from my mail half an hour or so ago, here is
On Sat, Aug 1, 2009 at 3:18 PM, Simon King wrote:
>
> Hi David,
>
> On 1 Aug., 23:55, David Joyner wrote:
>> 1. Be very very careful about modifying existing Python or Cython
>> files in the Sage devel tree.
>
> Is it really allowed for an SPKG to modify things in the Sage devel
> tree? This high
Dear Sage developers,
I asked the following question in a mail to William Stein and David
Joyner, but William suggested the discussion should be in public.
Yesterday my cohomology package became an optional spkg. But there are
a lot of homological algebra constructions that aren't in, yet.
Howev
Hi David,
On 1 Aug., 23:55, David Joyner wrote:
> 1. Be very very careful about modifying existing Python or Cython
> files in the Sage devel tree.
Is it really allowed for an SPKG to modify things in the Sage devel
tree? This highly surprises me. I thought that an SPKG is a package,
and the wo
Jason Moxham wrote:
>
> Hi
>
> So are you saying that the compilers on T2 are broken in 64bit mode ? or just
> sage is broken ? or just mpir ? or dont we know?
>
> I remember testing ABI=32bit before and it passed , but as T2 is a 64bit
> machine , I regarded this as not exactly what we want
Hi:
Playing around with the experimental 4ti2 package (which is not to be
confused with Marshall Hampton's very recent 4ti2 spkg) *and* Nathann
Cohen's GLPK spkg in the same version of Sage got me thinking about
some issues.
What is stopping people from (accidentally) causing havoc with their
sp
On Sat, Aug 1, 2009 at 1:50 PM, Nathann Cohen wrote:
>
> H... There is still something I did not understand, sorry ;-)
>
> Coin-or/Cbc is meant to be an optional package, and if approved it
> will stay this way : fine
> GLPK should be a standard package, but as it is customary it will be
> opt
H... There is still something I did not understand, sorry ;-)
Coin-or/Cbc is meant to be an optional package, and if approved it
will stay this way : fine
GLPK should be a standard package, but as it is customary it will be
optional for a while ( and perhaps a bit more to let us think about
l
Hi
can post
cat /proc/cpuinfo
Did you build it with
configure ABI=amd64
you should use
configure ABI=64
or just
configure
as on a 64 bit system the 64 ABI is default
Thanks
Jason
- Original Message -
From: "timcera"
To: "sage-devel"
Sent: Saturday, August 01, 2009 7:17 PM
Subjec
Hello,
Here are the relevant context and error messages...
Host system
uname -a:
Linux wanderer2 2.6.29-gentoo-r5 #2 Sat Jul 4 00:31:03 EDT 2009 x86_64
AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux
**
On Sat, Aug 1, 2009 at 12:22 PM, Jason Moxham wrote:
>
>
> Hi
>
> So are you saying that the compilers on T2 are broken in 64bit mode ? or just
> sage is broken ? or just mpir ? or dont we know?
Nobody has attempted to port Sage to 64-bit Solaris (well, since 2005
when we last tried). I don't th
Hi
So are you saying that the compilers on T2 are broken in 64bit mode ? or just
sage is broken ? or just mpir ? or dont we know?
I remember testing ABI=32bit before and it passed , but as T2 is a 64bit
machine , I regarded this as not exactly what we want , we want 64bit
goodness :)
Than
The function generic order_from_multple() does allow the information
to be cached, and the function Victor referred to should use that.
John
2009/7/31 VictorMiller :
>
> Simon, Thanks. I think that in order for this to work, that finite
> field should have a new method, something like
>
> @cach
On Sat, Aug 1, 2009 at 6:24 AM, David Joyner wrote:
>
> I think Nathann Cohen has done a very valuable service with the GLPK and
> COIN-OR-related packages.
>
> That said, I have a "point of order" question. Is is true or false that the
> process for a package to become standard we
> (1) use trac
Nathann Cohen wrote:
> Got it !
>
> I knew nothing about all this, sorry :-)
>
> I was just growing impatient because I only wrote the interface
> between GLPK/Coin and Sage to add new functions to the Graph class,
> whose docstrings I am currently writing... I already wrote :
>
> def min_domin
Got it !
I knew nothing about all this, sorry :-)
I was just growing impatient because I only wrote the interface
between GLPK/Coin and Sage to add new functions to the Graph class,
whose docstrings I am currently writing... I already wrote :
def min_dominating_set(g, value_only=False):
def min
Dear David, dear category fans,
We made some good progress on the review of the main category patch.
Most of the (hopf) algebra categories were reviewed by Florent Hivert,
and the semigroup/monoid ones by Franco Saliola. See the progress
report on:
http://sagetrac.org/sage_trac/wiki/Cate
I think Nathann Cohen has done a very valuable service with the GLPK and
COIN-OR-related packages.
That said, I have a "point of order" question. Is is true or false that the
process for a package to become standard we
(1) use trac to do nomination, testing, and acceptance as an optional
package,
I'd like LPs, too, of course.
By the way, do you know of the project http://pymprog.sourceforge.net/
that wraps GLPK with it's modelling language in python? Using PyGLPK,
as an additional layer, I'm pretty sure there is some relevant code
there.
On Aug 1, 12:46 pm, Carlo Hamalainen
wrote:
> On
Hi Golam,
On Sat, 1 Aug 2009 10:17:11 +
Golam Mortuza Hossain wrote:
> On Sat, Aug 1, 2009 at 2:54 AM, Burcin Erocal
> wrote:
> >
> > I just uploaded a new pynac package and patches which fix
> >
> > #6404 conjugate typesetting
> > #6401 typesetting real and imag
> > #6243 fderivative hash
On Sat, Aug 1, 2009 at 9:41 AM, Nathann Cohen wrote:
> Are you interested by LP features in Sage with GLPK as the native
> solver ? ( The others would have to be optional packages but we
> thought it would be smart to have a native one ).
Yes, especially if it can be used to speed up the graph co
Hi,
On Sat, Aug 1, 2009 at 2:54 AM, Burcin Erocal wrote:
>
> I just uploaded a new pynac package and patches which fix
>
> #6404 conjugate typesetting
> #6401 typesetting real and imag
> #6243 fderivative hash collision
> #6377 exp evaluation at infinity
>
> on trac. The package is here:
>
> http
Recently there was a thread that dealt with having axes of 2d plots
cross at non-origin points. This is a "problem" (depending on who is
talking :) of the current Sage axis code.
There are some *very* cool things coming up in the next release of
matplotlib that are related to this.
The relea
2009/7/30 William Stein :
> Hi,
>
> There is an article on slashdot today about the CentOS project admin being
> AWOL:
>
> http://linux.slashdot.org/story/09/07/30/130249/CentOS-Project-Administrator-Goes-AWOL?art_pos=4
>
> "Lance Davis, the main project administrator for CentOS, a popular free
>
Hello everybody !!!
Following this discussion (
http://groups.google.com/group/sage-devel/browse_thread/thread/9da47e06bcdfc49f
) about the availability of Linear Program Solvers and Mixed Integer
Program Solvers in Sage, I wrote a basic interface between Sage and
( GLPK, Coin-Or ). This patch i
39 matches
Mail list logo
