It's worth running the sage testsuite on linux with "export
MALLOC_CHECK_=3" (on OSX, look up gmalloc for similar testing). It
makes malloc a little less tolerant of misuse. It found a problem in
graph_generators.py. See
http://trac.sagemath.org/sage_trac/ticket/13719
--
You received this messag
On Nov 16, 10:57 pm, Simon King wrote:
> I think it should be on a Sage trac ticket even if it should be the case
> that ultimately it is an upstream bug.
I don't think it's upstream. I think it's a bad interaction between
how we (fail to) properly refcount singular objects and how it is
expected
On 2012-11-16 19:35, Nils Bruin wrote:
> On Nov 15, 11:59 pm, Jeroen Demeyer wrote:
>> Could you try again with sage-5.5.beta1?
>
> Same behaviour. Was there a reason to expect differently?
After adding every single ticket, there is reason to expect differently.
This stuff is *so sensitive* to ch
On 2012-11-16, Julien Puydt wrote:
> Le 16/11/2012 16:53, mmarco a écrit :
>> I run sage on my tablet (asus transformer prime) precisely in that
>> way: over a ubuntu chroot. I have an old version installed though. I
>> have an ubuntu 10 chroot, where i compiled sage 4.8 (it was a pain:
>> over a
Le 17/11/2012 10:13, Dima Pasechnik a écrit :
IMHO Samsung's new ARM Chromebook is what you might want; unfortunately
the internal SSD is small, only 16GB (like on AC100), but 1.7GHz
dual-core Cortex A15. (and 12"(?) screen)
http://www.chromium.org/chromium-os/developer-information-for-chrome-o
It was a TF 201
Oh, and btw, i think the real bottleneck with it was not the
processor, but the disk access. The processor is not bad (but again,
it can overheat), but the access to the internal sd disk is too slow.
Definitely, not a machine designed with this purpose in mind. And i
guess that pr
Le 17/11/2012 12:03, mmarco a écrit :
It was a TF 201
Oh, and btw, i think the real bottleneck with it was not the
processor, but the disk access. The processor is not bad (but again,
it can overheat), but the access to the internal sd disk is too slow.
Definitely, not a machine designed with t
On 2012-11-17, Julien Puydt wrote:
>
> The internal storage is small, but since it's possible to stick a big SD
> in, that could fly (I need about 5Go for a system, 7Go for sage [did I
> mention it's too much?] and 20Go [mostly] static storage).
>
> Now I'll only
> (1) make sure it can run ubunt
On Nov 17, 1:01 am, Jeroen Demeyer wrote:
> On 2012-11-16 19:35, Nils Bruin wrote:> On Nov 15, 11:59 pm, Jeroen Demeyer
> wrote:
> After adding every single ticket, there is reason to expect differently.
> This stuff is *so sensitive* to changes, even changes which look
> completely unrelated.
T
Le 17/11/2012 08:55, Jan Groenewald a écrit :
Hi
The PPA can now be used to install on Ubuntu 12.10.
Yes,
This is ok!
Thanks!
t.d.
Sulliwane, you can revert your 12.10 system back to the way
it should be with this command (all on one line):
sudo sed -ie 's/precise/quantal/g' /etc/apt/sources.
David Roe writes:
> Maxima will use ascii-art to print expressions (http://
> www.sagemath.org/doc/reference/sage/interfaces/maxima.html), but it
> will just leave sqrt as sqrt. I don't know a way to get an ascii art
> representation for sqrt.
> David
Sympy does this::
sage: from sympy impo
Volker Braun writes:
> Incidentally, about the legacy code for loading old notebooks: here
> is one lesson to be learned about long-term support of data files.
> The only sane way to handle this imho is:
>
> * The current code can read/write the current data format
> * Whenever you upgrade from fo
On Nov 17, 2012, at 8:01 PM, Nils Bruin wrote:
> On Nov 17, 1:01 am, Jeroen Demeyer wrote:
>> On 2012-11-16 19:35, Nils Bruin wrote:> On Nov 15, 11:59 pm, Jeroen Demeyer
>> wrote:
>> After adding every single ticket, there is reason to expect differently.
>> This stuff is *so sensitive* to cha
On Nov 17, 12:20 pm, Ivan Andrus wrote:
> At one point I had the goal of creating a suppressions file so that the
> doctests passed "cleanly". I'm sure some of the suppressions were actual
> problems, but it would at least allow you to find new problems. I still have
> the scripts that I use
On Nov 17, 2012, at 9:56 PM, Nils Bruin wrote:
> On Nov 17, 12:20 pm, Ivan Andrus wrote:
>
>> At one point I had the goal of creating a suppressions file so that the
>> doctests passed "cleanly". I'm sure some of the suppressions were actual
>> problems, but it would at least allow you to f
2012/11/17 Keshav Kini
> Sympy does this::
>
> sage: from sympy import sympify, pprint
> sage: pprint(sympify(sqrt(3)))
>
I just tried also with a more "fancy" example:
pprint(sympify(sqrt(3)*1/(2^e)))
That's great. :D
--
*Andrea Lazzarotto* - http://andrealazzarotto.com*
*
--
You r
I just opened,
http://trac.sagemath.org/sage_trac/ticket/13720
intending to submit a patch a few minutes later, but I've hit a problem.
The current examples feature,
sage: legendre_P(3, GF(11)(5))
8
which works due to a quirk in Maxima's string representation of the
polynomial:
sage: m
How about doing
sage: f = legendre_P(3, GF(11)['x'].gen()); f
8*x^3 + 4*x
sage: parent(f)
Univariate Polynomial Ring in x over Finite Field of size 11
sage: f(5)
8
However, the implementation (manipulating strings) is pretty horrid.
On Sat, Nov 17, 2012 at 8:08 PM, Michael Orlitzky wrote:
>
On Nov 17, 9:28 pm, Robert Bradshaw
wrote:
> How about doing
>
> sage: f = legendre_P(3, GF(11)['x'].gen()); f
> 8*x^3 + 4*x
> sage: parent(f)
> Univariate Polynomial Ring in x over Finite Field of size 11
> sage: f(5)
> 8
>
> However, the implementation (manipulating strings) is pretty horrid.
On 2012-11-18, Michael Orlitzky wrote:
> I just opened,
>
> http://trac.sagemath.org/sage_trac/ticket/13720
>
> intending to submit a patch a few minutes later, but I've hit a problem.
> The current examples feature,
>
> sage: legendre_P(3, GF(11)(5))
> 8
>
> which works due to a quirk in Ma
I don't think Sage currently supports localizations, though it would make a
nice project for a student
David
On Sun, Nov 18, 2012 at 12:10 AM, Dima Pasechnik wrote:
> On 2012-11-18, Michael Orlitzky wrote:
> > I just opened,
> >
> > http://trac.sagemath.org/sage_trac/ticket/13720
> >
> >
On 11/18/2012 01:31 AM, Nils Bruin wrote:
>
> That can be cleaned up quite a bit if this were rewritten to use
> maxima_lib. In that case the multiplications would probably be actual
> sage multiplications too, so would likely lead to the same errors as
> in Sage, though.
>
> The issue really is
On Nov 16, 7:05 pm, Nils Bruin wrote:
> ./sage -t --gdb devel/sage/sage/libs/singular/function.pyx
Interestingly, when running this with ElectricFence using
$ export LD_PRELOAD=libefence.so
$ export EF_ALLOW_MALLOC_0=1 #apparently sage/python does a
malloc(0) somewhere
$ echo 512000 | sudo t
23 matches
Mail list logo
