On Wed, Dec 2, 2009 at 1:01 AM, Mike Hansen wrote:
> On Wed, Dec 2, 2009 at 12:57 PM, William Stein wrote:
>> WTF? Regular expressions?!?!
>
> The following messages are probably relevant for the fast conversion
> between singular polynomial rings:
Thanks. There's also regular expression stuf
On Dec 2, 5:36 am, William Stein wrote:
> On Tue, Dec 1, 2009 at 7:18 PM, Dr. David Kirkby
>
>
>
> wrote:
> > Trying to create a binary distribution on Solaris, I find some rather
> > suspicious
> > looking files are being added:
>
> > sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/te
On Wed, Dec 2, 2009 at 12:57 PM, William Stein wrote:
> WTF? Regular expressions?!?!
The following messages are probably relevant for the fast conversion
between singular polynomial rings:
On Sat, Oct 18, 2008 at 2:55 AM, Michael Brickenstein
wrote:
> In Singular the same thing is essentially
WTF? Regular expressions?!?!
On Tue, Dec 1, 2009 at 6:57 PM, Simon King wrote:
> Hi!
>
> Here is a first ticket, with patch:
> http://trac.sagemath.org/sage_trac/ticket/7578
>
> It reduces the computation time of the original example of this thread
> to the time that is needed to convert the un
On Wed, Dec 2, 2009 at 12:26 AM, Robert Bradshaw
wrote:
> On Dec 1, 2009, at 9:21 PM, William Stein wrote:
>
>> On Tue, Dec 1, 2009 at 6:29 PM, Dr. David Kirkby
>> wrote:
>>> Harald Schilly wrote:
It would be a small change in the sage-bdist script, but i don't
know
if there are an
On Tue, Dec 1, 2009 at 7:18 PM, Dr. David Kirkby
wrote:
> Trying to create a binary distribution on Solaris, I find some rather
> suspicious
> looking files are being added:
>
> sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/symmetrica/
> sage-4.2.1-
On 12-02-2009, at 12:26 AM, Robert Bradshaw wrote:
>
> Would that make bzip2 a dependancy (so we wouldn't have to ship our
> own?)
Not necessarily. For instance, on OS X, I have various GUI tools
to decrypt .bz2 files, without bzip2 installed on my system. In my
case, I have it installed thr
On Dec 1, 2009, at 9:21 PM, William Stein wrote:
> On Tue, Dec 1, 2009 at 6:29 PM, Dr. David Kirkby
> wrote:
>> Harald Schilly wrote:
>>> It would be a small change in the sage-bdist script, but i don't
>>> know
>>> if there are any other considerations? Adding "--best" is also wise,
>>> since
On Tue, Dec 1, 2009 at 6:29 PM, Dr. David Kirkby
wrote:
> Harald Schilly wrote:
>> It would be a small change in the sage-bdist script, but i don't know
>> if there are any other considerations? Adding "--best" is also wise,
>> since it just expands the moving window when compressing.
>>>From me +
Hi,
I think I like David Kirkby's suggestion that we ship libstdc++. Even
on Linux, not having it *does* cause trouble sometimes. At least, if
we ship it then a sage binary built for LinuxDistro x.y will be more
likely to work on LinuxDistro x'.y'. There have been numerous
times over the ye
On Wed, 02 Dec 2009 at 02:28AM +, Dr. David Kirkby wrote:
> I would have thought it sensible to build Sage on old versions of the
> operating system, to ensure it works on later revisions. You are
> basically saying that does not happen. I'd find that pretty
> frustrating if I updated the opera
Last time I tried to upload this, there was an error in the ftp upload
interface. It's been a while, maybe they've fixed it in the meantime.
(Does anyone know of similar sites?)
On Dec 1, 2009, at 3:06 PM, Dr. David Kirkby wrote:
> http://www.sagemath.org/download.html says:
>
> "You can also
Dan Drake wrote:
> On Wed, 02 Dec 2009 at 12:16AM +, Dr. David Kirkby wrote:
>> The current script for building a binary does not copy over either
>> libgcc_s or libstdc++ runtime libraries. Yet Sage will be linked
>> against them. I suspect you can get away with this on Linux, as those
>> libr
On Wed, 02 Dec 2009 at 12:16AM +, Dr. David Kirkby wrote:
> The current script for building a binary does not copy over either
> libgcc_s or libstdc++ runtime libraries. Yet Sage will be linked
> against them. I suspect you can get away with this on Linux, as those
> libraries will be present i
Dr. David Kirkby wrote:
> Trying to create a binary distribution on Solaris, I find some rather
> suspicious
> looking files are being added:
>
> sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/symmetrica/
> sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sa
Trying to create a binary distribution on Solaris, I find some rather
suspicious
looking files are being added:
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4u-2.6/sage/libs/symmetrica/
sage-4.2.1-Solaris-10-sun4u-SunOS/devel/sage-main/build/temp.solaris-2.10-sun4
The current script for building a binary does not copy over either libgcc_s or
libstdc++ runtime libraries. Yet Sage will be linked against them. I suspect
you
can get away with this on Linux, as those libraries will be present in a
directory searched at runtime.
You can't get away without cop
Hi!
Here is a first ticket, with patch:
http://trac.sagemath.org/sage_trac/ticket/7578
It reduces the computation time of the original example of this thread
to the time that is needed to convert the underlying finite
polynomials. Hence, as long as the conversion does not improve, it
seems to m
Harald Schilly wrote:
> It would be a small change in the sage-bdist script, but i don't know
> if there are any other considerations? Adding "--best" is also wise,
> since it just expands the moving window when compressing.
>>From me +1 ;)
>
> H
>
I'm just in the process of updating the file, a
It would be a small change in the sage-bdist script, but i don't know
if there are any other considerations? Adding "--best" is also wise,
since it just expands the moving window when compressing.
>From me +1 ;)
H
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscr
http://www.sagemath.org/download.html says:
"You can also get a copy of Sage on DVD."
with a link to Lulu, but when one goes to the Lulu site, one gets
"We're sorry, the item you requested is not available."
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsub
> Here's the latest list:
>
> algebra AlexGhitza
> algebraic geometry AlexGhitza
> algebraic topology jhpalmieri
> basic arithmetic AlexGhitza
> build tbd
The trac component "build" is certainly one, th
On 1 Dez., 21:57, Nick Alexander wrote:
[...]
> I'm certain you are aware, but there is an art to optimizing regular
> expressions. It might be that a tuned regex is necessary, rather than
> avoiding a regex altogether.
Can you suggest some manual that can teach me about optimizing regular
e
Dr. David Kirkby wrote:
> To my knowledge, Linux, OS X and Solaris all come with bzip2 as standard.
>
> Would it not be more sensible to distribute Sage binaries as .bzip2
Sorry, I mean as .bz2 - i.e. use bzip2 to compress, not gzip as currently done
in the sage-bdist file.
Dave
--
To post to
Hi!
I just found that part of the problem is coercion -- or actually
conversion -- for classical polynomial rings:
sage: R1 = PolynomialRing(QQ,'x',10001)
sage: R2 = PolynomialRing(QQ,'x',10002)
sage: x1 = R1('x1')
sage: %prun a = R2(x1)
160026 function calls in 5.073 CPU sec
> Nevertheless, the regular expression business isn't good either. I'll
> see what I can do -- recent sage-devel/sage-support threads indicated
> some improvements.
I'm certain you are aware, but there is an art to optimizing regular
expressions. It might be that a tuned regex is necessary, rat
To my knowledge, Linux, OS X and Solaris all come with bzip2 as standard.
Would it not be more sensible to distribute Sage binaries as .bzip2, as it will
save download time? I'd also suggest using the '--best' option, which will give
the best compression, at the expense of CPU time during the co
Hi Martin!
On 1 Dez., 20:30, Martin Albrecht
wrote:
[...]
> Sure, but up to 50 seconds for a simple coercion seems way way too much even
> in that case.
Agreed. Let's try to find out what happens here.
My first thought was that it is due to the huge polynomial rings. But
the following seems to
On Wed, 02 Dec 2009 04:17:50 strogdon wrote:
> Hey Francois. I too thought that perhaps the spkg supplied flags would
> override any changes with custom flags. However the custom flags seem
> to be appended to the spkg provided ones. For example
>
> with custom CFLAGS
> building 'sage.algebras.qua
On Tue, Dec 1, 2009 at 8:56 AM, Nathann Cohen wrote:
> Hmmm... If we can make Sage's C graphs as fast as NetworkX's , I
> assure you it will be very hard for them to compete with LP on our
> side and so many features around in Sage... As most of NetworkX's
> functions are not very hard to rewrite
On Tue, Dec 1, 2009 at 4:40 AM, William Stein wrote:
> One potential problem is that all the Sage graph theory code is GPL'd,
> but Networkx is now BSD licensed (it used to be GPL'd). Given that
> graph theory in Sage is an area with a lot of possibly unfriendly
> competition with Magma and Mat
On Tuesday 01 December 2009, Simon King wrote:
> Hi Martin!
>
> On 1 Dez., 19:02, Martin Albrecht
>
> wrote:
> > Hi there,
> >
> > the following code is really, really really (REALLY!) slow:
>
> Well, the default implementation creates a polynomial ring with 1
> variables in the background
Hi Robert!
On 1 Dez., 19:18, Robert Bradshaw
wrote:
[...]
> Ouch, that is pretty bad. Looks like something changed in 4.2, it's
> doing a huge amount of regular expressions stuff...
It does a lot of regular expressions in the background. I did not see
a way to do it better. However, the code d
Hi Martin!
On 1 Dez., 19:02, Martin Albrecht
wrote:
> Hi there,
>
> the following code is really, really really (REALLY!) slow:
Well, the default implementation creates a polynomial ring with 1
variables in the background when you say x[1], and another ring
with 10001 variables if you th
On Dec 1, 2009, at 10:02 AM, Martin Albrecht wrote:
> Hi there,
>
> the following code is really, really really (REALLY!) slow:
>
> sage: IP = InfinitePolynomialRing(QQ)
> sage: x = IP.gen()
> sage: x1 = x[1]
> sage: %time 1/2*x1
> CPU times: user 0.86 s, sys: 0.00 s, total: 0.86 s
> W
Hi there,
the following code is really, really really (REALLY!) slow:
sage: IP = InfinitePolynomialRing(QQ)
sage: x = IP.gen()
sage: x1 = x[1]
sage: %time 1/2*x1
CPU times: user 0.86 s, sys: 0.00 s, total: 0.86 s
Wall time: 0.87 s
1/2*x1
Alright, so that was slow. Let's try somet
Georg S. Weber wrote:
>> cp: cannot access *.sage
>
> In short: that does not seem to be a new problem.
>
> I've seen this line before (I think I get it every time I build a
> bdist on my Macs), and I admit, that I never cared.
That's fine if it's ok to ignore it, but it could worry someone bui
Hmmm... If we can make Sage's C graphs as fast as NetworkX's , I
assure you it will be very hard for them to compete with LP on our
side and so many features around in Sage... As most of NetworkX's
functions are not very hard to rewrite once the basis is set ( graph
structure, neighbors, etc ) I am
Hey Francois. I too thought that perhaps the spkg supplied flags would
override any changes with custom flags. However the custom flags seem
to be appended to the spkg provided ones. For example
with custom CFLAGS
building 'sage.algebras.quatalg.quaternion_algebra_element' extension
gcc -DNDEBUG -
On Dec 1, 2009, at 4:45 AM, William Stein wrote:
> On Tue, Dec 1, 2009 at 5:59 AM, Fernando Perez
> wrote:
>> On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw
>> wrote:
>>> I think the basic idea was that one could write a faster (sparse and
>>> dense) graph "core," and then run all the Networ
On Dec 1, 2009, at 2:59 AM, Fernando Perez wrote:
> On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw
> wrote:
>> I think the basic idea was that one could write a faster (sparse and
>> dense) graph "core," and then run all the NetworkX algorithms on top
>> of it as long as it supported the interf
Hi William!
On Dec 1, 12:33 pm, William Stein wrote:
[...]
> I would call the code in the Sage notebook that is used to *implement*
> tab completion.
If I see correctly, the notebook tab completion is different from the
tab completion on the command line, which can be seen in the following
examp
Hi William!
On Dec 1, 12:33 pm, William Stein wrote:
[...]
> > But how to doc test tab completion? Is there a better way than to call
> > the relevant underscore method (here: _getAttributeNames) directly?
>
> I would call the code in the Sage notebook that is used to *implement*
> tab completion
Hi everybody !
When inheriting from Element, copy does not copy the dictionary:
sage: from sage.structure.element import Element
sage: class Demo(Element): pass
:
sage: bla = Demo(parent = ZZ)
sage: bla.a = [1,2,3]
sage: blo = copy(bla)
sage: blo is bla
False
sage: blo.__dict__ is bla.
Just a stupid remark:
> Here's the latest list:
>
>algebraAlexGhitza
[...]
> graphicswas
> graph theoryrlm
> group_theoryjoyner
> interactitolkov
[...]
> website/wikischilly
Why group_theory vs g
On Tue, Dec 1, 2009 at 7:40 AM, William Stein wrote:
> On Tue, Dec 1, 2009 at 5:59 AM, Fernando Perez wrote:
>> On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw
>> wrote:
>>> I think the basic idea was that one could write a faster (sparse and
>>> dense) graph "core," and then run all the Networ
On Tue, Dec 1, 2009 at 5:59 AM, Fernando Perez wrote:
> On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw
> wrote:
>> I think the basic idea was that one could write a faster (sparse and
>> dense) graph "core," and then run all the NetworkX algorithms on top
>> of it as long as it supported the in
On Tue, Dec 1, 2009 at 5:59 AM, Fernando Perez wrote:
> On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw
> wrote:
>> I think the basic idea was that one could write a faster (sparse and
>> dense) graph "core," and then run all the NetworkX algorithms on top
>> of it as long as it supported the in
Dan Drake wrote:
> On Tue, 01 Dec 2009 at 09:51AM +, Dr. David Kirkby wrote:
>> My point was, since MPFR seems to be pretty good at finding compiler
>> bugs, it was one worth running every time, whereas other tests may be
>> less useful.
>
> Checking the spkg-install file, I think they *are* r
On Mon, Nov 30, 2009 at 5:19 PM, Simon King wrote:
> Hi!
>
> At #6854 (ready for review, I think), I implemented introspection and
> tab completion for elements of Infinite Polynomial Rings. This became
> necessary since they have a __getattr__ method that allows to use
> methods of the underlying
On Tue, 01 Dec 2009 at 09:51AM +, Dr. David Kirkby wrote:
> My point was, since MPFR seems to be pretty good at finding compiler
> bugs, it was one worth running every time, whereas other tests may be
> less useful.
Checking the spkg-install file, I think they *are* run every time: at
the bott
On Mon, Nov 30, 2009 at 9:01 PM, Robert Bradshaw
wrote:
> I think the basic idea was that one could write a faster (sparse and
> dense) graph "core," and then run all the NetworkX algorithms on top
> of it as long as it supported the interface (for manipulating and
> querying vertices and edges).
On Mon, Nov 30, 2009 at 10:14:27PM -0800, William Cauchois wrote:
>That's awesome!! I found your patch (#6354), and conveniently enough its
>been merged in sage-4.3.alpha0. I tested it out on matrix2.pyx, which as
>you might expect is one of the files most affected by the displayhook, a
On Tue, 01 Dec 2009 14:42:43 strogdon wrote:
> Now when I unpack the sage-4.2.1.spkg tarball and insert
>
> unset CFLAGS
> unset CXXFLAGS
>
> near the top of the spkg-install script, repackage the tarball and
> issue the above 'make' with custom CFLAGS; both sage and the
> documentation build an
Robert Bradshaw wrote:
> Isn't there an option to set to run all the spkg internal tests?
>
> - Robert
My point was, since MPFR seems to be pretty good at finding compiler bugs, it
was one worth running every time, whereas other tests may be less useful.
There is for example a bug in gcc 4.4.0
Hi!
Another question related with http://trac.sagemath.org/sage_trac/ticket/6854
Reading the documentation of "dir", I expected
"""
...
If the object supplies a method named __dir__, it will be used;
otherwise
the default dir() logic is used and returns:
...
"""
But in fact, __dir__ is i
On Mon, 30 Nov 2009 at 09:25PM -0800, Robert Bradshaw wrote:
> Isn't there an option to set to run all the spkg internal tests?
Export SAGE_CHECK=yes before starting a build, which will run the spkg's
internal tests, as defined by the spkg-check script.
Last I knew, there were several spkgs which
57 matches
Mail list logo
