I'm getting an error trying to clone from a fresh 2.4.1.1
robert-bradshaws-computer:~/sage/current/devel robert$ sage -clone
spring
Now cloning the current SAGE library branch...
hg clone sage sage-spring
abort: No such file or directory: sage-spring/.hg/store/data/sage/
schemes/elliptic__cur
I have repeatedly read on this list that sage has now optimized
routines for
linear algebra mod p. Does this extend to linear algebra mod m with m
not prime?
I am mainly thinking about solving a system of linear equations (with
presumably
a unique solution).
I know that one can reduce this prob
On 3/28/07, Michel <[EMAIL PROTECTED]> wrote:
> I have repeatedly read on this list that sage has now optimized
> routines for
> linear algebra mod p. Does this extend to linear algebra mod m with m
> not prime?
>
> I am mainly thinking about solving a system of linear equations (with
> presumabl
On 3/28/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
> > I've released sage-2.4.1. It has:
> >
> >* d roe: massively updated p-adics code
> >* r bradshaw: much misc code; Coleman integration
> >* misc bug fixes
>
> What about my number field pyrexification?
> Joel
I forgot to mentio
On Mar 28, 2007, at 2:33 AM, Robert Bradshaw wrote:
>
> I'm getting an error trying to clone from a fresh 2.4.1.1
>
> robert-bradshaws-computer:~/sage/current/devel robert$ sage -clone
> spring
> Now cloning the current SAGE library branch...
> hg clone sage sage-spring
> abort: No such file or
On Mar 28, 4:18 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 3/28/07, Michel <[EMAIL PROTECTED]> wrote:
>
> > I have repeatedly read on this list that sage has now optimized
> > routines for
> > linear algebra mod p. Does this extend to linear algebra mod m with m
> > not prime?
>
> > I
On 3/28/07, Yi Qiang <[EMAIL PROTECTED]> wrote:
> > I'm getting an error trying to clone from a fresh 2.4.1.1
> >
> > robert-bradshaws-computer:~/sage/current/devel robert$ sage -clone
> > spring
> > Now cloning the current SAGE library branch...
> > hg clone sage sage-spring
> > abort: No such f
On Mar 28, 12:53 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> Thank you. This is exactly the kind of information I was looking for.
> I knew about the range of values limitation, but was only vaguely
> aware of the rest. The situation I'm thinking of is the default
> implicit ring (e.g. when o
On Mar 28, 2007, at 10:27 , cwitty wrote:
> On Mar 28, 12:53 am, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> Thank you. This is exactly the kind of information I was looking for.
>> I knew about the range of values limitation, but was only vaguely
>> aware of the rest. The situation I'm think
Actually, what I get after a sage -upgrade didn't include the patch. Did
my -upgrade go south? There should not be a number_field_element.py and
there should be a number_field_element.pyx in the sage/rings/number_field
directory.
--
Joel
On Wednesday 28 March 2007 10:30, William Stein wrote
When I looked carefully at my sage -upgrade output, I noticed a hg
"rollback" caused by the error indicated in my previous email. This
is why I didn't get any of the patches without moving sage-main
first. Perhaps the hg repository in the sage-2.4.1.1 is corrupted?
- Robert
On Mar 28, 2007
On Mar 28, 2007, at 10:27 AM, cwitty wrote:
> In the following carefully chosen example, we see a case where a
> native double result (or a result using RDF) has only 4 correct digits
> (about 12 bits). (This example is from John Harrison's paper, _Formal
> verification of floating point trigono
Actually I think the easiest way to fix this, at least for me, was to
do sage -upgrade, have mercurial roll back the merge and then simply do:
sage: hg_sage.pull()
This will get you up to the latest version.
On Mar 28, 2007, at 12:27 PM, Robert Bradshaw wrote:
>
> When I looked carefully at
-- Forwarded message --
From: Nicolas M. Thiery <[EMAIL PROTECTED]>
Date: Mar 28, 2007 1:10 PM
Subject: Re: Combinatorics in SAGE
To: [EMAIL PROTECTED]
Dear Mike,
My post (two weeks ago) to sage-devel was rejected. Could you please
forward it on my behalf?
Thanks in adv
Hello Nicolas,
> How much "man-year" do you expect to put on this project? I mean, it
> took us 6 years to develop MuPAD-Combinat. But of course, reusing past
> experience, one can hope to go quite faster.
I've been relatively busy with school stuff since graduation will be
here before I know it
On Mar 28, 12:39 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Mar 28, 2007, at 10:27 AM, cwitty wrote:
> > In the following carefully chosen example, we see a case where a
> > native double result (or a result using RDF) has only 4 correct digits
> > (about 12 bits). (This example is from
On Mar 28, 2007, at 2:23 PM, cwitty wrote:
>
> On Mar 28, 12:39 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> On Mar 28, 2007, at 10:27 AM, cwitty wrote:
>>> In the following carefully chosen example, we see a case where a
>>> native double result (or a result using RDF) has only 4 correct
On 3/28/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> > If we decide that we value portability but not necessarily precision,
> > we could use RDF but avoid using C library implementations of the
> > mathematical functions. (Currently, RDF uses the C library for tan(),
> > acos(), asin(), atan
I ran lots of benchmarks before starting this post, I should have
included them. Here they are some typical ones:
%pyrex
def foo(R, a, b, c, n):
cdef int i
a = R(a); b = R(b); c = R(c)
for i from 0 <= i < n:
z = a.sin().sin()
sage: time foo(RR, 3, 4.5, 200, 10^5)
CPU ti
Optimized RDF element allocation "a bit", new benchmarks:
%pyrex
def foo(R, a, b, c, n):
cdef int i
a = R(a); b = R(b); c = R(c)
for i from 0 <= i < n:
z = a*b + b*c + c*a
sage: time foo(RR, 3, 4.5, 200, N)
CPU time: 0.32 s, Wall time: 0.33 s
sage: time foo(RDF, 3, 4.5,
Hi,
Continuing the MuPAD thread from a few months ago, I just
wanted to mention that I just wrote a SAGE <--> MuPAD interface,
which will be in SAGE-2.4.2 (to be released probably Friday).
If you have MuPAD and want to try the interface (on Linux at least),
install or upgrade to the current vers
21 matches
Mail list logo