Hi,
I have a few design questions that I would like to discuss and they
are relevant to both SymPy and SAGE, so I am posting to both
mailinglists.
We are currently redesigning the class hierarchy in SymPy so that:
1)
Add(sin, cos)
and
Add(sin(1),cos(1))
are valid constructions. Here (Ad
Hi there,
consider the the ring
R = F_2[x1,...,xn] / .
Right now, if one constructs such a thing in SAGE one will get a QuotientRing
and QuotientRingElements. These are somewhat generic in the sense that they
serve e.g. univariate and multivariate polynomial rings.
Essentially, I want to
Hi,
Consider the following:
sage: x,y=ZZ['x,y'].gens()
sage: f=(x+1)*(y+1)*(1-x*y)
sage: f.factor()
...
: no conversion to a Singular ring defined
It certainly seems to me that this should coerce just fine to a Singular ring.
Is this a bug?
--
Joel
--~--~-~--~~~-
On Wednesday 12 September 2007, Joel B. Mohler wrote:
> Hi,
>
> Consider the following:
>
> sage: x,y=ZZ['x,y'].gens()
> sage: f=(x+1)*(y+1)*(1-x*y)
> sage: f.factor()
> ...
> : no conversion to a Singular ring defined
>
> It certainly seems to me that this should coerce just fine to a Singular
>
On 9/12/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
>
> On Wednesday 12 September 2007, Joel B. Mohler wrote:
> > Hi,
> >
> > Consider the following:
> >
> > sage: x,y=ZZ['x,y'].gens()
> > sage: f=(x+1)*(y+1)*(1-x*y)
> > sage: f.factor()
> > ...
> > : no conversion to a Singular ring defined
>
FYI - the following have recently
been released:
gmp-4.2.2
mpfr-2.3.0
ecm-6.1.3
Kate
--
Kate Minola
University of Maryland, College Park
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group,
Kate Minola wrote:
> FYI - the following have recently
> been released:
>
> gmp-4.2.2
> mpfr-2.3.0
> ecm-6.1.3
>
> Kate
Hello Kate,
#541, #542 and #642 in sagetrac respectively. I have to admit that I
added #642 only two hours ago. I expect that I will spend some time on
those tickets du
On Sep 12, 2007, at 6:23 AM, Ondrej Certik wrote:
> Hi,
>
> I have a few design questions that I would like to discuss and they
> are relevant to both SymPy and SAGE, so I am posting to both
> mailinglists.
>
> We are currently redesigning the class hierarchy in SymPy so that:
>
> 1)
>
> Add(si
On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> > I have a few design questions that I would like to discuss and they
> > are relevant to both SymPy and SAGE, so I am posting to both
> > mailinglists.
Thanks. I want to preface my comments below by remarking that the
design constraints
On Sep 12, 2007, at 1:06 PM, William Stein wrote:
> On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>>> I have a few design questions that I would like to discuss and they
>>> are relevant to both SymPy and SAGE, so I am posting to both
>>> mailinglists.
>
> Thanks. I want to preface my
On 9/12/07, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
> Kate Minola wrote:
> > FYI - the following have recently
> > been released:
> >
> > gmp-4.2.2
> > mpfr-2.3.0
> > ecm-6.1.3
> >
> > Kate
>
> Hello Kate,
>
> #541, #542 and #642 in sagetrac respectively. I have to admit that I
> added #642
On Sep 12, 10:37 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 9/12/07, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Kate Minola wrote:
> > > FYI - the following have recently
> > > been released:
>
> > > gmp-4.2.2
> > > mpfr-2.3.0
> > > ecm-6.1.3
>
> > > Kate
>
> > Hello Kate,
On Sep 12, 2007, at 4:37 PM, William Stein wrote:
> Yep. However, one thing I want to add is that my understanding
> is that the GPL-only patches that make xgcd/gcd *vastly* faster
> for large numbers might only work with gmp-4.2.1, at least
> without a lot more work to port it, and if so we sh
I'm currently testing several of the major GMP patches with gmp-4.2.2.
Should have some results by this weekend.
On 9/12/07, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> On Sep 12, 10:37 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > On 9/12/07, mabshoff <[EMAIL PROTECTED]> wrote:
> >
> >
> >
On Sep 12, 1:30 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Sep 12, 2007, at 1:06 PM, William Stein wrote:
> >>> I have a few design questions that I would like to discuss and they
> >>> are relevant to both SymPy and SAGE, so I am posting to both
> >>> mailinglists.
>
> > Thanks. I wa
On Sep 12, 2007, at 2:00 PM, cwitty wrote:
> On Sep 12, 1:30 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> On Sep 12, 2007, at 1:06 PM, William Stein wrote:
> I have a few design questions that I would like to discuss and
> they
> are relevant to both SymPy and SAGE, so I am p
On 9/12/07, cwitty <[EMAIL PROTECTED]> wrote:
> > Seehttp://www.sagemath.org:9002/sage_trac/ticket/644
>
> Is this really a good thing? It seems like it might get a little
> confusing, especially when you get into some more complicated cases.
>
> Assume that sin and cos are 1-argument functions,
On Sep 12, 2007, at 2:14 PM, William Stein wrote:
> On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
>> That's assuming we go beyond 1-argument functions, which may or may
>> not be a good idea (and is certainly less common).
>>
>> Also, I would propose
>>
>> sage: x, y = var('x y')
>> sa
On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> >> BTW, I think this is a bug:
> >>
> >> sage: f = x+y
> >> sage: f
> >> y + x
> >> sage: f(4)
> >> y + 4
> >>
> >
> > That's not a bug, that's *exactly* how we designed things
> > to work. Calling when the inputs are explicit is done with
On Sep 12, 2007, at 2:24 PM, William Stein wrote:
> On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
BTW, I think this is a bug:
sage: f = x+y
sage: f
y + x
sage: f(4)
y + 4
>>>
>>> That's not a bug, that's *exactly* how we designed things
>>> to work
On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> That's assuming we go beyond 1-argument functions, which may or may
> not be a good idea (and is certainly less common).
>
> Also, I would propose
>
> sage: x, y = var('x y')
> sage: f(x) = x^2 + 1
> sage: f + sin
> x^2 + 1 + sin(x)
> sage:
Forwarding Pearu's answer on this, since it was posted to sympy list only.
-- Forwarded message --
From: Pearu Peterson <[EMAIL PROTECTED]>
Date: Sep 12, 2007 7:02 PM
Subject: Re: calculus in SAGE/SymPy
To: sympy <[EMAIL PROTECTED]>
On Sep 12, 1:23 pm, "Ondrej Certik" <[EMAIL P
Where are the algorithms behind these impressive speed-ups documented
-- or is it done by clever implementation? Either way they should be
published for posterity, or at least documented !
John
On 9/12/07, William Stein <[EMAIL PROTECTED]> wrote:
>
> On 9/12/07, mabshoff <[EMAIL PROTECTED]> wr
On Sep 12, 2007, at 5:48 PM, John Cremona wrote:
> Where are the algorithms behind these impressive speed-ups documented
> -- or is it done by clever implementation? Either way they should be
> published for posterity, or at least documented !
The code was taken from the first section of
htt
Hmm, there seems to be many assumptions that I would like it be clarified.
Specifically where do all these objects live in.
For example, sin is a function from K->K.
same as cos. If that's the case, then sin+cos makes perfect sense.
Can we make the same assumtion for x? Is it safe to assume x is a
Hello all,
So I took the plunge and started trying to write optimized code in
Cython for my enumeration problem. The code can be found at
http://www.cems.uvm.edu/~voight/tr_data.spyx
http://www.cems.uvm.edu/~voight/totallyreal.py
and for the experts out there, I'd appreciate any feedback you
some partial answers to a subset of those questions:
On Sep 12, 2007, at 7:26 PM, John Voight wrote:
> (1) At a certain moment in the algorithm, I need to test if a
> polynomial with integer coefficients is squarefree (using exact
> arithmetic). Is it acceptable practice to do this in a brutal
Hi,
Just to add my 2 bits, I think we should aim for something like the
following:
sage: x = var('x')
sage: X = x.domain()
sage: X
Affine line over the Real Field
sage: X.identity()
x
sage: f = sin(x)
sage: X == f.domain()
True
sage: f = sin(domain=X,codomain=X)
sage: y = var('y')
sage: g = sin(
On 9/12/07, John Voight <[EMAIL PROTECTED]> wrote:
> So I took the plunge and started trying to write optimized code in
> Cython for my enumeration problem. The code can be found at
> http://www.cems.uvm.edu/~voight/tr_data.spyx
> http://www.cems.uvm.edu/~voight/totallyreal.py
> and for the e
On 9/12/07, Soroosh Yazdani <[EMAIL PROTECTED]> wrote:
> Hmm, there seems to be many assumptions that I would like it be clarified.
> Specifically where do all these objects live in.
> For example, sin is a function from K->K.
> same as cos.
What is K? sin is symbolic so the input is anything sy
On 9/12/07, David Kohel <[EMAIL PROTECTED]> wrote:
> Just to add my 2 bits, I think we should aim for something like the
> following:
>
> sage: x = var('x')
> sage: X = x.domain()
> sage: X
> Affine line over the Real Field
> sage: X.identity()
> x
> sage: f = sin(x)
> sage: X == f.domain()
> True
On Wed, Sep 12, 2007 at 05:19:57PM -0700, William Stein wrote:
>
> On 9/12/07, Soroosh Yazdani <[EMAIL PROTECTED]> wrote:
> > Hmm, there seems to be many assumptions that I would like it be clarified.
> > Specifically where do all these objects live in.
> > For example, sin is a function from K->
> I remember reading a long thread on axiom-devel that was a discussion
> between Ondrej Certik and the axiom developers. It ended rather
> abruptly when one of them wrote that they were not interested at all in
> "formal symbol manipulation" and Ondrej replied that possibly non-rigorous
> forma
On 9/12/07, William Stein <[EMAIL PROTECTED]> wrote:
> ...
> I remember reading a long thread on axiom-devel that was a discussion
> between Ondrej Certik and the axiom developers. It ended rather
> abruptly when one of them wrote that they were not interested at all in
> "formal symbol manipulat
On Sep 12, 2007, at 7:17 PM, Ondrej Certik wrote:
>> sage: sin.is_zero()
>> False
>
> What should this particular line do? I don't understand the doctest
> for is_zero either:
>
> "
> Return True if self equals self.parent()(0). The default
> implementation is to fall back to 'not sel
On Sep 12, 2007, at 5:19 PM, William Stein wrote:
> On 9/12/07, Soroosh Yazdani <[EMAIL PROTECTED]> wrote:
>> BTW, I don't think this is a good idea:
sage: x, y=vars('x y')
sage: y + sin
y + sin(y)
sage: x + sin
x + sin(x)
>
> That's definitely not how SAGE works now, and
On 9/12/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> Letting x + sin == x + sin(x) was my way of justifying (x + sin)(5)
> == 5 + sin(5). I was thinking "sin" was a function of exactly one
> variable, it just doesn't know/have a name for that variable yet.
Personally, I think you're applying
On 9/12/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
> consider the the ring
>
> R = F_2[x1,...,xn] / .
>
> Right now, if one constructs such a thing in SAGE one will get a QuotientRing
> and QuotientRingElements. These are somewhat generic in the sense that they
> serve e.g. univariate and mu
On the other hand, sometimes Mathematica makes assumptions "in order
to return useful results" that are sometimes wrong and then people
complain about it on the mailing list. It is probably much easier to
ask the user to declare something as real than it is to ask the user
to figure out that the s
39 matches
Mail list logo
