> On Tue, Jul 6, 2010 at 2:10 AM, Dr. David Kirkby
> > > BTW, the use of 'which' is not a good idea. First its non portable.
> > Secondly, do we not know the patch of cython? If so, why is it not
> > hard-coded? That will save some time. One a 3.33 GHz machine, the
> > overhead in calling 'which' i
On Wed, Jun 30, 2010 at 11:20 AM, Robert Miller wrote:
> On Wed, Jun 30, 2010 at 10:01 AM, William Stein wrote:
>> On Wed, Jun 30, 2010 at 9:48 AM, Robert Miller wrote:
>>> I was recently searching through the source and I noticed that some
>>> loads/dumps doctests say #indirect doctest, and oth
On Mon, Jul 12, 2010 at 3:15 AM, Simon King wrote:
> What does "closing a ticket" mean? Is it the same as providing a
> resolution such as "fixed", "wontfix", "duplicate"? Or is closing the
> ticket something that comes *after* providing a resolution?
I think for clear cut cases, it's reasonable
On Tue, Jul 6, 2010 at 7:41 AM, Ryan Hinton wrote:
> On Jul 2, 4:25 pm, Burcin Erocal wrote:
>> On Fri, 2 Jul 2010 09:21:25 -0700 (PDT)
>>
>> Ryan Hinton wrote:
>> > Well, it's a little dangerous for someone (me) who doesn't really
>> > understand how to *use* the tool to *design the interface*
On Tue, Jul 6, 2010 at 2:10 AM, Dr. David Kirkby
wrote:
> Since building packages in parallel has speeded up the build process
> immensely, I thought I'd have a look at what stops it running even quicker.
> Although I've not done any systematic tests, on my OpenSolaris Ultra 27,
> I've come to the
On Sun, Jul 11, 2010 at 3:29 PM, David Kirkby wrote:
> On 6 July 2010 19:39, Mike Hansen wrote:
>> On Tue, Jul 6, 2010 at 11:34 AM, Dr. David Kirkby
>> wrote:
>>> For both of us, the Sage library is taking a long time. For you, the longest
>>> items is in fact Singular, which I think is good new
On Mon, Jul 12, 2010 at 5:20 PM, Dr. David Kirkby
wrote:
> I created
>
> http://trac.sagemath.org/sage_trac/ticket/9487
>
> to try to clarify exactly what are "supported platforms" and precisely what
> we mean by them. We also need to resolve the problem that different sources
> of information giv
On Sat, Jul 3, 2010 at 11:30 AM, William Stein wrote:
> On Saturday, July 3, 2010, Volker Braun wrote:
>> On Jul 3, 4:54 pm, Mike Hansen wrote:
>>> 1) The src/ directory needs be under Mercurial version control. This
>>> would increase the size of the spkgs by quite a bit.
>>
>> But you don't n
On Tue, Jul 6, 2010 at 12:46 AM, David Kirkby wrote:
> Whilst trying to debug a Solaris issue, I came across a bit of code
> which appears on every platform, but which looks suspicious.
>
> The code is in rings/finite_rings/stdint.h
>
> http://trac.sagemath.org/sage_trac/ticket/9399
>
> where it s
On Wed, Jul 7, 2010 at 11:30 AM, Volker Braun wrote:
> While trying to subclass QuotientRing, I noticed that this class does
> not follow the coercion model: It overrides __call__ and _coerce_impl,
> which the reference manual frowns upon.
Yes. QuotientRing was implemented ages before the new coe
I finally got a chance to test this on a clean 64-bit Ubuntu 10.04
(lucid) install.
I began by apt-get'ing the icedtea6-plugin, which pulls in a lot of
other packages such as the OpenJDK version of Java. A simple 3d plot
would not render in JMOL in the notebook, though the black square did
have a
On Jul 12, 12:59 pm, William Stein wrote:
> On Monday, July 12, 2010, kcrisman wrote:
>
> >> This would be a good reason for us to setup a separate trac server for
> >> the notebook. It's tempting. There's probably also a way to make it
> >> so
>
> >> http://trac.sagemath.org/sage_notebook
>
I created
http://trac.sagemath.org/sage_trac/ticket/9487
to try to clarify exactly what are "supported platforms" and precisely what we
mean by them. We also need to resolve the problem that different sources of
information give different lists of supported platforms.
Dave
--
To post to th
I think there lies the problem :
sage: mcl_v = mcl.vertices()
sage: mclc_v = mcl.complement().vertices()
sage: mcl_v == mclc.v
False
So they are not equal. Do they contain the same elements ?
sage: Set(mcl_v) == Set(mclc_v)
True
So it seems... But then, what does THAT mean ?
sage: sorted(mclc_
I realize this thread is 4 months old, but let me respond to this one
technical question:
On Thu, Mar 4, 2010 at 2:10 AM, Simon King wrote:
> Hi!
>
> On Mar 4, 8:24 am, Robert Bradshaw
> wrote:
>> I believe there is also some randomized testing that is done in the
>> category code that takes ran
If G is a graph and A = G.am() is its adjacency matrix and B =
G.complement().am() is
the adjacency matrix of its complement, then A+B should be a 01-
matrix. The code below
shows that sage does not always share this viewpoint.
Cheers
Chris
#
##
---
On 12 jul, 18:54, William Stein wrote:
> On Monday, July 12, 2010, Marco Streng wrote:
> > Hi all,
>
> > I'm getting a bit confused about Parent objects and why
> > sage.schemes.generic.scheme.Scheme extends Parent.
>
> > Schemes are not really "containers" of anything, right?
>
> A scheme is b
On Monday, July 12, 2010, kcrisman wrote:
>
>
>> This would be a good reason for us to setup a separate trac server for
>> the notebook. It's tempting. There's probably also a way to make it
>> so
>>
>> http://trac.sagemath.org/sage_notebook
>>
>> is a trac just for the notebook.
>
> However, at
On Jul 12, 10:20 am, Marco Streng wrote:
> Hi all,
>
> I'm getting a bit confused about Parent objects and why
> sage.schemes.generic.scheme.Scheme extends Parent.
>
> Schemes are not really "containers" of anything, right? Calling
> S.an_element() currently gives a NotImplementedError for most sc
On Monday, July 12, 2010, Marco Streng wrote:
> Hi all,
>
> I'm getting a bit confused about Parent objects and why
> sage.schemes.generic.scheme.Scheme extends Parent.
>
> Schemes are not really "containers" of anything, right?
A scheme is by definition a locally ring topological space. Thus a
Hi all,
I'm getting a bit confused about Parent objects and why
sage.schemes.generic.scheme.Scheme extends Parent.
Schemes are not really "containers" of anything, right? Calling
S.an_element() currently gives a NotImplementedError for most schemes,
and TestSuite(S).run() will give lots of failur
> This would be a good reason for us to setup a separate trac server for
> the notebook. It's tempting. There's probably also a way to make it
> so
>
> http://trac.sagemath.org/sage_notebook
>
> is a trac just for the notebook.
However, at the very least one would want to have intense integrat
Dear sage-devel
this is continuation of
http://groups.google.cz/group/sage-support/browse_thread/thread/527f12e3b859bbb3/203fca703ceb1741
I would like to modify interact so that changing the input of interact
with auto_update=False does NOT remove the output computed for
previous data from the sc
On Mon, Jul 12, 2010 at 12:15 PM, Simon King wrote:
> Hi Robert and William,
>
> What does "closing a ticket" mean? Is it the same as providing a
> resolution such as "fixed", "wontfix", "duplicate"? Or is closing the
> ticket something that comes *after* providing a resolution?
>
> If "providing
Hi Robert and William,
What does "closing a ticket" mean? Is it the same as providing a
resolution such as "fixed", "wontfix", "duplicate"? Or is closing the
ticket something that comes *after* providing a resolution?
If "providing resolution" and "closing" is the same, then I recently
closed a t
On Mon, Jul 12, 2010 at 10:47 AM, David Kirkby wrote:
> On 12 July 2010 09:05, William Stein wrote:
>
>> http://trac.sagemath.org/sage_notebook
>>
>> is a trac just for the notebook.
>
> It's a broken link for me.
It was a hypothetical link for everyone.
>
> Dave
>
--
Robert L. Miller
http
> So you and William are interpreting this differently.
Dave,
I think you'll find that William and I have the same opinion about
closing tickets -- you're unfortunately trying to absolutely
generalize what I'm saying. You haven't caused any trouble by closing
tickets, but it is very easy for many
On 12 July 2010 09:05, William Stein wrote:
> http://trac.sagemath.org/sage_notebook
>
> is a trac just for the notebook.
It's a broken link for me.
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+unsubs
On 12 July 2010 08:58, Robert Miller wrote:
> I'd just like to remind everyone:
>
> Only the release manager should close tickets.
>
> Tim Dumol has closed #7379, even though there was a sage library patch
> there which needed to be merged. This is causing 4.5.rc0 to fail in
> much worse ways than
On Mon, Jul 12, 2010 at 1:45 AM, Niles Johnson wrote:
> Hello all,
>
> I noticed some varying definitions of random_element for ZZ, QQ, and
> RR (and probably other rings). This causes misleading documentation
> (whch doctests don't catch, because the output is random!) and, for
> power series ri
> This would be a good reason for us to setup a separate trac server for
> the notebook.
I was thinking the same exact thing!
+1
--
Robert L. Miller
http://www.rlmiller.org/
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
On Mon, Jul 12, 2010 at 10:01 AM, Tim Joseph Dumol wrote:
> I'm copying my reply to the Sage 4.5.rc0 thread:
>
> Sorry! I was last informed that I could close notebook tickets that
> are merged in a SageNB release.
This would be a good reason for us to setup a separate trac server for
the noteboo
I'm copying my reply to the Sage 4.5.rc0 thread:
Sorry! I was last informed that I could close notebook tickets that
are merged in a SageNB release. Since you closed #9430 (SageNB 0.8.1)
and said that it was merged in 4.5.rc0, I assumed that the Sage
library patch at #7379 was merged as well, sinc
I'd just like to remind everyone:
Only the release manager should close tickets.
Tim Dumol has closed #7379, even though there was a sage library patch
there which needed to be merged. This is causing 4.5.rc0 to fail in
much worse ways than it should.
If you close tickets yourself you may be pub
34 matches
Mail list logo
