So it's a Pari bug. I see. I guess I was misled by the fact that the
"trace" command only reports calls to Python functions. Thanks for
clearing that up.
David
On 10 March 2010 18:53, Robert Bradshaw wrote:
> On Mar 10, 2010, at 10:36 AM, daveloeffler wrote:
>
>> PS: I've realised that one can t
On Wednesday, 14 March 2012 03:37:27 UTC, William stein wrote:
>
> Quick update:
>
>* http://aleph.sagemath.org is up now, as Jason mentioned.
>
>* Absolutely *none* of the external disks attached to any of the
> machines have appeared, so I can only guess something weird happened
> with a
On Wednesday, 14 March 2012 08:38:57 UTC, David Loeffler wrote:
> It looks like the patchbot server, at patchbot.sagemath.org, is still
> down.
>
> David
>
... and now it's back up again. Thanks!
--
To post to this group, send an email to sage-devel@googlegroups.com
To u
The trac server, which has been up all day, now seems to have gone back
down again.
David
--
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:/
On Wednesday, 14 March 2012 18:33:49 UTC, William stein wrote:
>
> On Wed, Mar 14, 2012 at 11:22 AM, William Stein wrote:
> > Hi,
> >
> > A circuit breaker was blown by yet another power issue. Fortunately,
> > the sysadmin strong some temporary power, and at least most services
> > are restar
Hi folks,
I just hit a rather evil linear algebra bug, which results in an instant
segfault:
sage: A = identity_matrix(ZZ, 2, sparse=True)
sage: B = identity_matrix(ZZ, 2, sparse=True)
sage: A.solve_left(B)
/storage/masiao/sage-5.0.beta8/spkg/bin/sage: line 308: 7843 Segmentation
fault sage-
Is there any progress on getting the patchbot links working again? Now that
we have a ticket to make the patchbot code generally available, there are
more copies of the patchbot running (I have one going), so the feedback is
more useful than ever before and it's a shame that it's hidden from sig
This looks great -- for ages I've been ignoring the built-in trac reports
and using Custom Query because the built-in reports were no use, but these
look much more sensible.
One request: can we have a query for "Tickets I authored (including
closed)", and similarly "Tickets reviewed by me"? (F
On Thursday, 22 March 2012 21:37:19 UTC, fhivert wrote:
>
> Hi there,
>
> Sage documentation still has a lot of dangling links. To check if there are
> some please use the recently added option --warn-links as in:
>
> sage --docbuild --warn-links reference html
>
> Beware that it trigger
On Saturday, 24 March 2012 13:33:59 UTC, Nicolas M. Thiéry wrote:
>
> On Sat, Mar 24, 2012 at 04:35:42AM -0700, David Loeffler wrote:
> >I tried to use this, but ran into the following stupid glitch.
Yeah, those recompilations are a pain. In such a situation, one would
> wa
On Tuesday, 27 March 2012 17:03:12 UTC+1, Dima Pasechnik wrote:
>
> On 2012-03-27, leif wrote:
> > On 27 Mrz., 17:29, leif wrote:
> >> On 27 Mrz., 15:39, Volker Braun wrote:
> >>
> >> > The current state is that we build static atlas with and without
> threads,
> >> > and the shared library wit
Dear Sage devs,
Could I ask if any of you would have time to look at a tiny patch for a bug
in Sage's polynomial code?
This came up as a side-effect of work on Eisenstein series in the modular
forms code at ticket #12724. I wrote a patch which did have a positive
review, but it subsequently tu
Just to pick up on a comment from William's message earlier
On 13 May 2012 12:46, William Stein wrote:
>
> It might be useful to work with floating point approximations to the
> algebraic numbers and ask for the minpoly of any particular one later.
This is exactly what is done by Sage's (IMHO ex
The grey circle is because the patches now on the ticket aren't the
same ones that patchbot ran its tests with (note the word "mismatch"
in red on the patchbot page).
David
On 15 May 2012 10:33, Keshav Kini wrote:
>
> Hi,
>
> I've been playing around with the installable patchbot code Robert put
Hi folks,
I just looked again, after a longish absence, at the Patchbot page at
http://patchbot.sagemath.org. I was very puzzled by what I saw: the table
of tickets had somehow been transformed into a vertical column consisting
of coloured blobs and small nonnegative integers, without any ticke
> On 4 July 2012 03:05, Maarten Derickx wrote:
>> Dear All,
>>
>> Today I was trying to compute some stuff using modular symbols. And I found
>> the following slightly worrying:
Yup, this is definitely a bug. The "old submodule" it calculates isn't
Hecke-invariant:
sage: M.hecke_matrix(17).restr
On 25 July 2012 00:30, Justin C. Walker wrote:
> While looking through Stein's "Three Lectures" paper, I tried the examples
> in \S 2.1.1. In particular, the last item, computing the order of the cubic
> field's Galois group (72) seems to be straightforward when looking at the
> paper. When I tr
On 25 July 2012 10:30, Javier López Peña wrote:
> There is a (sort of new) fast probabilistic algorithm for computing Galois
> groups, due to Nikolai Durov:
Which sense of "computing" are we using here? (Cf. my previous email
in this thread and Nils' response.)
Regards, David
--
--
To post to
I just hit this bug in the wild while doing some modular forms computations:
masiao@fermat:~$ sage
--
| Sage Version 5.3, Release Date: 2012-09-08 |
| Type "notebook()" for the browser-based notebook interf
On 4 October 2012 00:57, Maarten Derickx wrote:
> The reason is that q_expansion_basis returns power series and not modular
> forms:
Yes, I know, but in practice one often wants to know if a given power
series is the q-expansion of an element of the space, and it seems
strange to me that you can
I suspect that what John wants is the sum of V and W as subspaces of a
common ambient space (not the direct sum embedded in the direct sum of
two copies of the ambient space, as Francis suggests). This can be
obtained (very quickly) by doing
sage: time V + W
Vector space of degree 100 and dimensio
That's very strange! The time-critical part of that computation is almost
entirely in doing linear algebra with the coefficients of power series --
it bypasses most of the modular symbols code, which would be very
inefficient in this example since the level is small and the weight large
-- and oddl
On 9 January 2013 17:34, P Purkayastha wrote:
> On 01/10/2013 12:50 AM, Jeroen Demeyer wrote:
>
>> On 2013-01-09 17:34, Volker Braun wrote:
>>
>>> Also, ccache is awesome.
>>>
>> Absolutely. Now we only need sphinx-cache, THAT would speed up building
>> Sage!
>>
>
> I don't want to go offtopic h
The following curious bug came up during work on ticket #12233. For some
reason, if one creates a 2x2 integer matrix directly using the constructor
then it is possible to tell it to be immutable; but if one creates one via
arithmetic operations then calling "set_immutable" on it fails. Here's an
ex
-1 -- sorry. If we must have a shorthand for log to base 2, isn't "lb" the
canonical one?
Regards, David
On 10 January 2013 09:45, Nathann Cohen wrote:
> Hello everybody !
>
> I understand very well that asking questions like that can easily get me
> killed by a crowd of angry mathematicia
On 11 January 2013 09:29, Johhannes wrote:
>
>
> Am Freitag, 11. Januar 2013 00:53:08 UTC+1 schrieb Nils Bruin:
>
>>
>>
>> It could be more appropriate to fix this by making 2x2 matrices always
>> immutable (then the methods accessing that can be special-cases on the
>> class) or by lying and jus
> I think the reason for subclassing in this case is code-reuse. But that's
in itself a dangerous thing to do if we change the class' internal >
behavior by this much. People changing the code for Matrix_dense shouldn't
need to deal with issues in a non-conforming subclass --
> but they will have t
n existing
code).
David
On 11 January 2013 13:14, Timo Kluck wrote:
> Op vrijdag 11 januari 2013 13:41:42 UTC+1 schreef David Loeffler het
> volgende:
>>
>>
>> > I think the reason for subclassing in this case is code-reuse. But
>> that's in itself a danger
The bug also occurs on Sage 5.7, and a quick-and-dirty bisection
script shows that n = 46341 does work and n = 46342 does not. Since
46341 is almost exactly the square root of 2^{31}, and the relevant
bits of code seem to use C int variables rather than Sage integers
(presumably for speed reasons),
On 5 March 2013 06:54, Peng Tian wrote:
> Dear David,
> You are right. I tried to change the data type of the code in sage, which is
> "int" type in the source code of SAGE and now I'm using "long int" instead.
> The previous error is gone and everything is working well now.
>
> Thanks a lot!
>
>
On 26 March 2013 12:37, leif wrote:
> Volker Braun wrote:
>>
>> Is it just me? I get UnicodeWarning printed during doctests on many
>> files. Apparently they don't cause test failures, though they might mask
>> failing doctests since the comparison in question is always false:
>
>
> I thought this
We should have a clear policy on this, because it's been a contentious
issue in the past. I remember this came up once with regard to a patch
I had refereed, which changed an error message in finite fields and
thus broke the doctests in sage/tests/french_book/. The original fix
was just to change t
I would argue that P.root_field() should return a p-adic field here, not a
polynomial quotient ring. This would be consistent with the behaviour of
root_field for polynomials over QQ and number fields; generally, when we
have a choice of several different Sage representations of the same
mathem
Hi folks,
I'm at SD51 in Leiden this week, and it would be nice if we had a working
sage patchbot to test the patches we're writing...
At the moment there seems to be something rather odd going on with the
patchbot. I have set a patchbot worker process running on one of our
Warwick machines, b
rity of them, it
claims the ticket status is "unknown".
David
On Thursday, July 25, 2013 12:28:26 AM UTC+2, David Loeffler wrote:
>
> Hi folks,
>
> I'm at SD51 in Leiden this week, and it would be nice if we had a working
> sage patchbot to test the patches we're
so I don't have to parse the html). It'll take a
> while to actually update all the tickets in question.
>
> On Thu, Jul 25, 2013 at 2:32 AM, David Loeffler
> wrote:
>> Some further data: the problem is definitely with the patchbot server
>> process running at p
On Friday, July 26, 2013 7:54:41 PM UTC+1, Robert Bradshaw wrote:
>
> On Fri, Jul 26, 2013 at 3:19 AM, David Loeffler
> > wrote:
> > Hi Robert,
> >
> > That's excellent -- thanks! One question: there are some tickets (e.g.
> > #14366) where it is no
Hi John,
Are you maybe using Sage inside a screen session? Apparently screen
doesn't play nicely with UTF-8 characters, unless you invoke it with
"screen -U".
David
On 20 August 2013 14:24, Volker Braun wrote:
> You need a UTF-8 capable terminal (independently of Sage it would be a good
> time
There is a second problem, also, with the use of "verbose" in Cython
code in the sage library. When "verbose" is called, the code for the
verbosity mechanism decides whether to print the message based on the
name of the module containing the calling function. Unfortunately this
introspection mechan
It's happened a few times that people have put tests in the sage/tests
directory which explicitly require that certain inputs return
NotImplementedError, or something similar. Surely we shouldn't have to
go through the rigmarole of contacting the original author and waiting
a year in order to add a
I'm surprised at the apparent consensus that the only solution is to
re-implement "verbose" by some totally different method. I came across this
issue before and I found a perfectly acceptable fix, which I didn't bother
to make a ticket for because I didn't know if anyone else cared about this
issu
I have also raised some objections on the ticket, which relate less to the
content of the ticket than to the tone of the discussion (both on the
ticket and on this thread). It is one thing to propose a change to a file
name; it is another thing to mock a fellow Sage contributor or to accuse
the
(The joke doesn't actually work in British English, because we'd always say
"X is really lazy" rather than "X is real lazy".)
David
On 23 January 2016 at 17:03, Dima Pasechnik wrote:
>
>
> On Saturday, 23 January 2016 14:47:26 UTC, David Loeffler wrote:
&
On 6 February 2016 at 22:48, Volker Braun wrote:
> So as long as the elements are sortable a set is just as good as a list
> for doctests purposes.
Isn't that the whole point of this discussion: that number field elements
are presently *not* sortable, in any consistent and reliable way?
David
I'd like to request opinions on whether we should get rid of the "Trusted
Authors" check in the Sage patchbot.
At present, the patchbot won't test a ticket unless all of the names in the
Trac "Authors" field have had at least one ticket previously merged.
Presumably the intention of this is to pre
The upgrade to 8.2.beta1 seems to have broken the patchbot -- several
patchbots ("arando", "quasar" and "sage4") are now reporting failures, all
to do with downloading a new version of the package "notedown". Below is
the tail end of a sample report.
Is there any way we can make the patchbot recog
This is a bug in PARI, rather than in Sage, apparently:
GP/PARI CALCULATOR Version 2.9.4 (released)
amd64 running linux (x86-64/GMP-6.1.0 kernel) 64-bit version
[...]
? nffactor(y^8 - y^6 + y^4 - y^2 + 1, x^4 + 1) \\ works
%1 =
[x^2 + Mod(-y^5, y^8 - y^6 + y^4 - y^
>
> Hence no patchbot can test any ticket, otherwise they will report an error
> on each ticket due to that unrelated failing doctest.
This is not quite true. The correct statement is that no patchbot can
*start* testing tickets. When the patchbot is started, it tests whether the
latest Sage beta
On 16 March 2018 at 18:58, Jeroen Demeyer wrote:
> On 2018-03-16 12:40, David Loeffler wrote:
>
>> IMHO, the patchbot should be reconfigured so that it re-tests ticket 0
>> after every upgrade, and if that test fails, the patchbot should stop
>>
>
> Absolutely
Sounds reasonable to me. Can you open a trac ticket for this?
On 28 March 2018 at 18:01, Nicolás Sirolli wrote:
> The Gauss sum for the Dirichlet character modulo 1 is equal to 1, but:
>
> sage: G = DirichletGroup(1)
> sage: chi = G.list()[0]
> sage: chi.gauss_sum()
> 0
>
> The output is zero be
On 13 April 2018 at 12:25, Sanketh wrote:
> This is probably obvious but why is type='gap' not standard for Galois
> groups?
>
Because Pari is *vastly* faster. E.g. see this example, where Pari beats
Gap by a factor of 100:
sage: K. = NumberField(x^5 - x - 1)
sage: time _=K.galois_group(type='p
On Wednesday, 2 May 2018 20:03:24 UTC+2, Erik Bray wrote:
> Indeed--at some point I plan to start running pyflakes over Sage.
On 6 May 2018 at 17:07, Maarten Derickx wrote:
> A big +1 on adding a "plain old rule-based lint" like pyflakes to the
> testsuite.
>
Inspired by this I ran pyflakes o
On 11 May 2018 at 17:17, John Cremona wrote:
>
>
> The patchbot David Loeffler and I run in Warwick is on a machine which has
> Magma on it.
>
> John
>
I'd be grateful if someone could explain how to configure the patchbot to
run the Magma optional doctests -- I
> In summary, if we implement subgroups in such a way that testing equality
is not implemented then it is very misleading to return False every time.
I've run into this issue before (that two subgroups of the same ambient
matrix group can compare as unequal, despite having the same elements). See
On 31 May 2018 at 11:07, Erik Bray wrote:
>
> "mathematical equality" is also a red herring being that there are
> many possible definitions thereof. Are we talking equality up to
> isomorphism? Etc...
In the example posted by Chris Wuthrich, all the objects invoved were, by
construction, subg
55 matches
Mail list logo