They don't supply a Fortran compiler, which we need. Also as of Xcode 5
they no longer supply gcc (the gcc in PATH is actually clang) and some
packages we include depend explicitly on having gcc as our c compiler.
If anything we need our own compiler now more than before, and this
situation doesn'
On Sat, Jul 20, 2013 at 6:00 AM, Pippijn van Steenhoven
wrote:
> Hello Aldor, FriCAS, and Sage users,
>
> as some of you might have noticed, Aldor has been made Free Software by
> Aldor.org. This has had several implications, one of which is that we now
> have a github repository:
> https://gith
Just wondering... has Apple's compiler by any chance improved enough so we
can stop building our own GCC?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-dev
Hi,
I'm wondering if anyone could make a tutorial about benchmarking Sage
methods. I am personally not much of a speed fanatic, but when I am
refactoring other people's code I'm trying to make sure it doesn't
slow down as the result and this does require me to run timings. I'm
aware of the basics
On Fri, Nov 22, 2013 at 7:39 PM, William Stein wrote:
> Maybe we could have a criterion to decide what "obscure" is and some
> examples?
Well, there are also other measurements you can take and mix together.
e.g. how broadly the given constructor is developed, I mean, how many
features are implem
On Fri, Nov 22, 2013 at 10:23 AM, Volker Braun wrote:
> There is some value to have often-used things in the global namespace; Sage
> integers should always be ZZ and not just rings.Integers.
+1
This was in particular one of the things I changed from the design of
Magma, where you *have* to type
There is some value to have often-used things in the global namespace; Sage
integers should always be ZZ and not just rings.Integers.
* In the future, do not add new factory functions to the global namespace
if there is a better place
* Remove obscure constructors from globals at some later tim
+1 to removing them from the main namespace (with appropriate deprecation
period).
When we designed the matroid code, keeping the namespace clean was an
important goal for me. So we only have "Matroid" and "matroids" in there,
and I expect it'll stay that way.
I can see no reason to have indiv
What happened with the plan of buying some arm machine to work as a
buildbot?
My experience trying to compile sage on arm machines has been painful. It
took two weeks to compile it in my android tablet (under an ubuntu chroot),
and it overheated so much that the device got damaged.
Anyways, on
On 22 November 2013 15:52, William Stein wrote:
> On Fri, Nov 22, 2013 at 7:50 AM, John Cremona wrote:
>> @William: that looks like the correct diagnosis. The return value is
>> a list of elliptic curve points, and was failing except on the exmpty
>> list. I got around it by returning the bare
On Friday, November 22, 2013 7:52:12 AM UTC-8, William wrote:
> Is the pickling issue a bug in Sage?
>
I'd say so. It's a subtle one:
loads(dumps(cremona_curves(37).next().gens(descent_second_limit=10)))
tends to work but loading the saved pickle from a file does not. Executing
V=loads(dumps(
I really like these collections of similar constructors. Having more of
them would make Sage - as you said - much more discoverable. Is there a
plots.* ? For example, list_plot is never seen, if you do plot[tab].
On Friday, November 22, 2013 2:21:32 PM UTC+1, John Cremona wrote:
>
> Backwards co
On Fri, Nov 22, 2013 at 7:50 AM, John Cremona wrote:
> @William: that looks like the correct diagnosis. The return value is
> a list of elliptic curve points, and was failing except on the exmpty
> list. I got around it by returning the bare coordinates as [P.xy()
> for P in E.gens()]
>
> @Jero
@William: that looks like the correct diagnosis. The return value is
a list of elliptic curve points, and was failing except on the exmpty
list. I got around it by returning the bare coordinates as [P.xy()
for P in E.gens()]
@Jeroen: I was about to say "I didn't know about alarm()" untl I saw
t
On 2013-11-22 16:22, John Cremona wrote:
I am trying to use the @fork decorator as described here:
http://www.sagemath.org/doc/reference/parallel/sage/parallel/decorate.html
in order to force a function not to take more run time than some
maximum.
Given that #13311 is fixed (and merged in sage-5.
On Fri, 22 Nov 2013 03:59:01 -0800
Paul Lutus wrote:
> On 11/22/2013 03:08 AM, Erik Massop wrote:
> > On Thu, 21 Nov 2013 16:28:52 -0800 (PST)
> > lutusp wrote:
> >
> >> On Thursday, November 21, 2013 1:23:14 PM UTC-8, lutusp wrote:
> >>> matime: Assertion `fscanf(fp, "%lf", &mflop[i])' failed.
Begin forwarded message:
Date: Fri, 22 Nov 2013 03:59:01 -0800
From: Paul Lutus
To: Erik Massop
Subject: Re: [sage-devel] Re: Sage 5.12 fails to build Atlas, 64-bit
SuSE 13.1
On 11/22/2013 03:08 AM, Erik Massop wrote:
> On Thu, 21 Nov 2013 16:28:52 -0800 (PST)
> lutusp wrote:
>
>> On Thurs
On Fri, Nov 22, 2013 at 7:22 AM, John Cremona wrote:
> I am trying to use the @fork decorator as described here:
> http://www.sagemath.org/doc/reference/parallel/sage/parallel/decorate.html
> in order to force a function not to take more run time than some
> maximum. The examples on that page all
I am trying to use the @fork decorator as described here:
http://www.sagemath.org/doc/reference/parallel/sage/parallel/decorate.html
in order to force a function not to take more run time than some
maximum. The examples on that page all work but this does not. Why
not?
sage: @fork(timeout=10, ve
On 11/22/2013 09:34 PM, John Cremona wrote:
On 22 November 2013 13:31, Nathann Cohen wrote:
Hellooo !!
Backwards compatibility issues?
Well, we can deprecate stuff for a start. And the message could say "What
you are looking for moved to a different place ! It's larger, there is a lot
o
>
>
> > > On the subject of the time taken to compile R: R itself compiles
> in
> > > parallel relatively
> > > fast.
> > Really? I find that, when building sufficiently in parallel, R is
> > actually the *second slowest* package of all packages to compile,
> after
>
On 2013-11-22 14:58, Jean-Pierre Flori wrote:
On Friday, November 22, 2013 2:27:28 PM UTC+1, Jeroen Demeyer wrote:
On 2013-11-22 10:15, Fran�ois wrote:
> On the subject of the time taken to compile R: R itself compiles in
> parallel relatively
> fast.
Really? I find th
On Friday, November 22, 2013 2:27:28 PM UTC+1, Jeroen Demeyer wrote:
>
> On 2013-11-22 10:15, Fran�ois wrote:
> > On the subject of the time taken to compile R: R itself compiles in
> > parallel relatively
> > fast.
> Really? I find that, when building sufficiently in parallel, R is
> actu
On 22 November 2013 13:31, Nathann Cohen wrote:
> Hellooo !!
>
>> Backwards compatibility issues?
>
> Well, we can deprecate stuff for a start. And the message could say "What
> you are looking for moved to a different place ! It's larger, there is a lot
> of light and a comfy couch. Come join
Hellooo !!
> Backwards compatibility issues?
Well, we can deprecate stuff for a start. And the message could say "What
you are looking for moved to a different place ! It's larger, there is a
lot of light and a comfy couch. Come join us !"
> I have a lot of code where I would
> not want to c
On 2013-11-22 10:15, François wrote:
On the subject of the time taken to compile R: R itself compiles in
parallel relatively
fast.
Really? I find that, when building sufficiently in parallel, R is
actually the *second slowest* package of all packages to compile, after
ATLAS.
--
You received t
Recent blog on this kind of issue:
http://www.r-bloggers.com/the-homogenization-of-scientific-computing-or-why-python-is-steadily-eating-other-languages-lunch/
On 22 November 2013 14:16, Javier López Peña wrote:
> On Thursday, November 21, 2013 1:50:07 PM UTC, Volker Braun wrote:
>>
>> ... but
Backwards compatibility issues? I have a lot of code where I would
not want to change every NumberField(...) to fields.NumberField(...)
and similarly with QuadraticField() and CyclotomicField(). Is this
just a question of scale, i.e. those are almost all the special field
constructors while there
Hellooo everybody !
I just created ticket that adds a new codes. object to Sage gathering
all codes that Sage can build, the same way that we already have such
objects for groups/graphs/designs/matroids and perhaps others.
Basu wondered if it made sense to keep all constructors in the global
On Thursday, November 21, 2013 1:50:07 PM UTC, Volker Braun wrote:
>
> ... but there is very little that we currently can do to replace R
> functionality. Having said that, there is a serious lack of statistics in
> Sage.
>
In my personal experience the pandas package [1] is capable of doing mos
On Thu, 21 Nov 2013 16:28:52 -0800 (PST)
lutusp wrote:
> On Thursday, November 21, 2013 1:23:14 PM UTC-8, lutusp wrote:
> > matime: Assertion `fscanf(fp, "%lf", &mflop[i])' failed.
...
> Addendum: Sage version 5.11 successfully compiled on the same machine with
> no changes.
This looks like th
On Friday, November 22, 2013 10:48:26 AM UTC+1, Jean-Pierre Flori wrote:
> A few random remarks:
> * I directly built it on the raspberry pi (I don't think Sage own build
> system is flexible enough to cross compile as lmonade could do).
> * it took something like 5 days.
> * there were no real
I've put a binary for raspberry pi at
http://boxen.math.washington.edu/home/jpflori/dist at some point.
It's was for 5.10.
A few random remarks:
* I directly built it on the raspberry pi (I don't think Sage own build
system is flexible enough to cross compile as lmonade could do).
* it took some
On Friday, November 22, 2013 3:47:16 PM UTC+13, William wrote:
>
> On Thu, Nov 21, 2013 at 6:40 PM, kcrisman >
> wrote:
> >
> >
> > On Thursday, November 21, 2013 3:08:44 PM UTC-5, François wrote:
> >>
> >> On Thu, 21 Nov 2013 09:54:10 Jason Grout wrote:
> >> > On 11/21/13 9:35 AM, kcrisma
34 matches
Mail list logo
