On Tue, Nov 23, 2010 at 6:26 PM, William Stein wrote:
>
> Another good thing to do as part of this sprint would be to greatly
> improve the logging ability of the notebook server. The logs could,
> of course, get stored to a database, for increased flexibility and
> ease of querying. They could
On Tue, 23 Nov 2010 at 06:26PM -0800, William Stein wrote:
> Another good thing to do as part of this sprint would be to greatly
> improve the logging ability of the notebook server. The logs could,
> of course, get stored to a database, for increased flexibility and
> ease of querying. They coul
On Sat, Nov 20, 2010 at 4:30 PM, Alex Leone wrote:
> I've been thinking about architecture for a while. I'll copy some of
> my ideas to that page when I get a chance. Hopefully we can nail down
> a general structure before the bug days in January.
That would be good. It's important that things
That's great news! I think it has the potential to greatly increase
the usership of Sage.
On Nov 23, 3:56 pm, emil wrote:
> I am proud to announce sagelive-511-46.exe, which will install the
> Sage system on Windows systems.
>
> I tested it with Windows XP and Windows 7, it should also work on
>
I am proud to announce sagelive-511-46.exe, which will install the
Sage system on Windows systems.
I tested it with Windows XP and Windows 7, it should also work on
Vista and Windows 9x.
It will not work with Windows ME
This works similar to a WUBI install, so the sage system is installed
paralle
On Tue, Nov 23, 2010 at 10:43 AM, Martin Albrecht
wrote:
> Hi,
>
> at #1956 an implementation of multivariate power series is provided. The patch
> has been sitting idle for quite some time now and I would like to push it
> forward. I did take a look (I'm not the author, just a reviewer!) and I th
Em 23 de novembro de 2010 16:21, Paulo César Pereira de Andrade
escreveu:
> Hi,
Doing the bad netiquette of replying to myself, but now I am sure this
is not specific to my sagemath package.
> Sorry if this was already asked/answered as I did not read all threads
> about sagemath
> and jmol. T
On Tue, Nov 23, 2010 at 11:30 AM, David Roe wrote:
>
>> Yep. Since this is such a common case, I wonder if we should modify
>> the Sage integer __richcmp__ method to be more sophisticated, and
>> allow direct comparisons with builtin Python types, without first
>> requiring them to be converted to
On Tue, Nov 23, 2010 at 11:37 AM, David Roe wrote:
> I think that while we're still using Python 2.x, where 2r/3r = 0, we
> absolutely need the preparser.
Yes. Without it, it is far to easy to type something like
x^3 + 2*x^2 - 1/2*x + 5/3
and having that give x^3 + 2*x^2 + 1 would be a tota
On Tue, Nov 23, 2010 at 11:37 AM, David Roe wrote:
> I think that while we're still using Python 2.x, where 2r/3r = 0, we
> absolutely need the preparser. The coercion framework can work with Python
> ints just fine: it's the automatic rounding that kills us. Much better
> speed for large intege
I think that while we're still using Python 2.x, where 2r/3r = 0, we
absolutely need the preparser. The coercion framework can work with Python
ints just fine: it's the automatic rounding that kills us. Much better
speed for large integers is another benefit that you mentioned. Also, there
are l
> Yep. Since this is such a common case, I wonder if we should modify
> the Sage integer __richcmp__ method to be more sophisticated, and
> allow direct comparisons with builtin Python types, without first
> requiring them to be converted to Sage integers?
That's such a good idea that I did it.
h
Hi,
at #1956 an implementation of multivariate power series is provided. The patch
has been sitting idle for quite some time now and I would like to push it
forward. I did take a look (I'm not the author, just a reviewer!) and I think
the patch is ready to go in. However, I don't use multivaria
Thanks !
I see there is a second issue then: when I used
%run script.sage
from the ipython console, there is no preprocessing. That's why there
was "no penalty in the sage console". Of course, there is a penalty
when running the script as in:
sage script.sage
BTW: how do you guys run scripts f
John Cremona writes:
> There is a lesson to be learned here, which is in fact very similar to
> one which William explained very well recently: beware the Sage
> preprocessor which converts every integer it sees to an Integer, which
> can have serious performance consequences and is often not ne
On Tue, Nov 23, 2010 at 8:51 AM, John Cremona wrote:
> So: in Pablo's first version the problem was not in computing
> len(results), but in the comparison between that value (a Python int)
> and the Sage Integer cota, which involves creating a temporary Sage
> integer and then doing the compariso
Hi,
Sorry if this was already asked/answered as I did not read all threads
about sagemath
and jmol. This is related to mandriva sagemath package, but,
downloading the binary for
mandriva 2009.0 I get the same results.
I have this strange behavior, where in both notebook and tutorial
sample, it ap
On Nov 23, 4:22 pm, Jason Grout wrote:
> On 11/23/10 7:19 AM, dagss wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 23, 3:54 am, Jason Grout wrote:
> >> On 11/22/10 1:48 PM, Ethan Van Andel wrote:
>
> >>> In my development, I'm attempting to parallelize some code. However,
> >>> the bottleneck is a call to n
On 11/23/10 10:46 AM, javier wrote
I don't know if I'd call it "easy" but one thing you can do is to
transform your group to a permutation group and the translate that
into sage:
sage: gg = gap.AllSmallGroups(60)
sage: gg1 = gg[1]
sage: iso = gg1.IsomorphismPermGroup()
sage: gg2 = iso.Image()
s
What is the status of the dot2tex spkg?
* I see a vote for it here:
http://www.mail-archive.com/sage-devel@googlegroups.com/msg42273.html
* I see a closed trac ticket for it here:
http://trac.sagemath.org/sage_trac/ticket/7004
* I don't see it in the optional spkg listing:
http://sagemath.
So: in Pablo's first version the problem was not in computing
len(results), but in the comparison between that value (a Python int)
and the Sage Integer cota, which involves creating a temporary Sage
integer and then doing the comparison between two of those.
In Pablo's second version there is no
Hi Jason,
On Nov 23, 3:42 pm, Jason Grout wrote:
> I'm trying to get a list of all groups of order 60. After searching for
> a bit, I see in Gap that (if I install the optional spkg
> database_gap-4.4.12.p0.spkg) we have the AllSmallGroups command, which
> seems to do what I want. But then I'm
The problem is not with len(), merely with the conversion from an int
to an Integer required in comparing len(results) wrote:
> Hello:
> A colleague was working in code for a certain projecteuler problem,
> and found that using "len" of a list has a severe penalty on the sage
> notebook, which do
Hi Jason!
On 23 Nov., 16:42, Jason Grout wrote:
> Question 2: Is there an easy way to convert a GAP group to a Sage group?
>
I don't know if this is always possible. But at least it should be
possible for permutation groups (at least generatorwise).
So, you could do:
sage: G = gap.SmallGroup(60
I'm trying to get a list of all groups of order 60. After searching for
a bit, I see in Gap that (if I install the optional spkg
database_gap-4.4.12.p0.spkg) we have the AllSmallGroups command, which
seems to do what I want. But then I'm having problems converting those
groups to Sage groups:
On 11/23/10 7:19 AM, dagss wrote:
On Nov 23, 3:54 am, Jason Grout wrote:
On 11/22/10 1:48 PM, Ethan Van Andel wrote:
In my development, I'm attempting to parallelize some code. However,
the bottleneck is a call to numpy.linalg.lapack_lite.zgesv, that is
the point where numpy calls LAPACK to s
On Nov 23, 3:25 pm, Dima Pasechnik wrote:
> I wonder why zgesv comes here from lapack_lite rather than from Atlas,
> which might have much faster zgesv.
> Is it a feature (or a bug) of Sage configuration of Numpy?
> Or in fact it does come come Atlas?
It's just a strange feature of NumPy, I think
I wonder why zgesv comes here from lapack_lite rather than from Atlas,
which might have much faster zgesv.
Is it a feature (or a bug) of Sage configuration of Numpy?
Or in fact it does come come Atlas?
Dima
On Nov 23, 9:19 pm, dagss wrote:
> On Nov 23, 3:54 am, Jason Grout wrote:
>
> > On 11/22
Here is the ticket
http://trac.sagemath.org/sage_trac/ticket/10289
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group
Hi,
I uploaded a patch to this ticket.
Please do experiments with it, and leave comments.
Kwankyu
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group
On Nov 23, 3:54 am, Jason Grout wrote:
> On 11/22/10 1:48 PM, Ethan Van Andel wrote:
>
> > In my development, I'm attempting to parallelize some code. However,
> > the bottleneck is a call to numpy.linalg.lapack_lite.zgesv, that is
> > the point where numpy calls LAPACK to solve my complex system
Ok, the file is up on the server,
http://boxen.math.washington.edu/home/emil/sagelive/sagelive-511-46.iso
Screenshot:
http://boxen.math.washington.edu/home/emil/sagelive/screenshot.jpg
I added also
http://boxen.math.washington.edu/home/emil/sagelive/md5sum.xt
http://boxen.math.washington.edu/hom
Hello:
A colleague was working in code for a certain projecteuler problem,
and found that using "len" of a list has a severe penalty on the sage
notebook, which doesn't happen on either the sage or the python console.
The two versions of the code below differ only in a call to the function
len.
Hi,
i built a new Live CD version from Sage 4.6.
I am currently uploading to
boxen.math.washington.edu/home/emil/sagelive/sagelive-511-46.iso
The iso is based on Ubuntu binaries and it is just 580 MB.
It can be used as classical Live CD, but it is also possible to make
very easy USB installs (
34 matches
Mail list logo
