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
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,
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
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
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 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
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
-- 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
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
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
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
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
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
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 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, 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 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 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 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
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
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
21 matches
Mail list logo