Thanks !
Eric.
--
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-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegro
On Sunday, April 17, 2016 at 9:05:46 PM UTC+2, Volker Braun wrote:
>
> It seems that the assumption (wrongly) thinks that x is integer:
>
http://trac.sagemath.org/ticket/20456
Fixed in newest Pynac.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group
It seems that the assumption (wrongly) thinks that x is integer:
sage: assume(x>0)
sage: sin(pi*x)
0
sage: cos(pi*x)
(-1)^x
On Sunday, April 17, 2016 at 5:58:07 PM UTC+2, Eric Gourgoulhon wrote:
>
> Hi,
>
> In Sage 7.2.beta4:
>
> sage: assume(x>0)
> sage: sin(pi*x)
> 0
>
> As far as I can tell,
> > > 1) Expose as much Maxima functionality as possible (one example is
> > > substitution of other things besides symbols).
>
> We've definitely laid the foundations for that step very very well.
Yes, nice work.
> > > 2) It's important to allow users to create their own functions and the
> > >
On Nov 15, 2007 9:15 AM, mabshoff
<[EMAIL PROTECTED]> wrote:
> > 1) Expose as much Maxima functionality as possible (one example is
> > substitution of other things besides symbols).
We've definitely laid the foundations for that step very very well.
> > 2) It's important to allow users to creat
On Nov 16, 2007 9:50 AM, Fabio Tonti <[EMAIL PROTECTED]> wrote:
> So basically, on the long run, you would like to use SymPy together with
> everything rewritten in Cython? Did I get it correctly?
Not necessarily. In the long run I want to have a very simple but fast
calculus engine, which people
So basically, on the long run, you would like to use SymPy together with
everything rewritten in Cython? Did I get it* correctly?*
On Nov 15, 2007 5:39 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I would like to discuss how to improve calculus in SAGE.
>
> I know, that currently, mos
On Nov 15, 5:39 pm, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to discuss how to improve calculus in SAGE.
>
> I know, that currently, most of the developers need other things more
> urgently, but I think calculus will be the most frequently used part
> in SAGE. For exampl
William wrote:
> Sage is free software produced mostly by volunteer work.
> There is currently not a single person who is paid fulltime
> to work on Sage. The current goal with Sage is not to maximize
> profit, and as such, the phrase "target market" is likely have a
> different meaning for Sag
On 9/18/07, Ted Kosan <[EMAIL PROTECTED]> wrote:
>
> > This is a basic mathematics/CS divide. Mathematicians will expect
> > their vectors of length n to have indices 1..n and similarly for
> > matrices and so on. The packages pari and magma use that convention
> > accordinly, since they are writ
On 9/18/07, Peter Doyle <> wrote:
>
> Hi William,
>
> > When you click download, what happens is that you save the file
> > to your local disk, and only after that happens it happens to
> > be opened by a pdf (or dvi or ps) reader on your computer. Three
> > separate things happen.
> >
>
> Actuall
On Sep 18, 9:04 am, Nick Alexander <[EMAIL PROTECTED]> wrote:
> > True. I've been looking forward to somebody rewriting the preparse
> > (...)
> > function for a long time. Much to my surprise nobody has. I don't
> > think
> > anybody has even tried, though people have suggested they would try
John wrote:
> This is a basic mathematics/CS divide. Mathematicians will expect
> their vectors of length n to have indices 1..n and similarly for
> matrices and so on. The packages pari and magma use that convention
> accordinly, since they are written for mathematicians to be as close
> to ma
> True. I've been looking forward to somebody rewriting the preparse
> (...)
> function for a long time. Much to my surprise nobody has. I don't
> think
> anybody has even tried, though people have suggested they would try
> on a few occasions.
I did! In the end, I never was able to parse
On 9/18/07, Joel B. Mohler <[EMAIL PROTECTED]> wrote:
>
> I don't have a strong opinion about the original proposition ... although
> I
> have spent the last week being thoroughly vexed by python being zero-based
> when all the things I would write on paper about math would index things
> one-based
> I vote against it!
>
> (a) because I usually vote against preparser changes :-)
> (b) it means SAGE is slowly getting its own language and
> (c) it breaks conventions, i.e. it adds confusion IMHO.
> (d) It might be because I used to be CS major but I think it is okay just
> educate users about t
On Sep 17, 2007, at 11:55 PM, William Stein wrote:
> And, if anybody out there thinks adding the above to the preparser
> would make you positively cringe in disgust, please speak up!
> (It doesn't mean we won't add it anyways...)
Positively cringe in disgust.
-1
david
--~--~-~--~--
[I'm not sure why this thread is atll called "Calculus"!]
This is a basic mathematics/CS divide. Mathematicians will expect
their vectors of length n to have indices 1..n and similarly for
matrices and so on. The packages pari and magma use that convention
accordinly, since they are written for
On Tuesday 18 September 2007 00:32, Nick Alexander wrote:
> > Robert, Since you do so much work on Cython, maybe you could think
> > about the formal specification of the Python language and see whether
> > ..
> > not appearing in a string is ever valid Python. I.e., could we add
> > [e
On 9/17/07, William Stein <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> > > It sounds from what you write though, that it is best to just stick
> > > with the "upload" / "download" terminology, since it is *very* clear
> > > in which direction the file goes
On Sep 17, 10:55 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> And, if anybody out there thinks adding the above to the preparser
> would make you positively cringe in disgust, please speak up!
> (It doesn't mean we won't add it anyways...)
If you ask me, my opinion would be not to change it.
On Sep 18, 2007, at 12:50 AM, Martin Albrecht wrote:
>>> I wonder if there would be some consistent way to make 1..4 stand
>>> for
>>> an iterator, and [1..4] a list. Hmm: then since we'd want
>>> [2,3,5..9]
>>> to be a list, we'd want 2,3,5..9 to be an iterator, whereas
>>> (2,3,5..9)
>
> > I wonder if there would be some consistent way to make 1..4 stand for
> > an iterator, and [1..4] a list. Hmm: then since we'd want [2,3,5..9]
> > to be a list, we'd want 2,3,5..9 to be an iterator, whereas (2,3,5..9)
> > would presumably be a tuple, which seems problematic. Is there a
> >
Sorry to double-post, but what convention are you referring to that
we are breaking?
On Sep 17, 2007, at 9:39 PM, Mike Hansen wrote:
> Yeah, I'm not sure if the benefits would be worth breaking such a
> strong Python convention.I'd rather have consistency since it
> appears so often in oth
There is the (obscure) Ellipsis object that, only in the context of a
multi-dimensional slice list, is represented by '...' (exactly three
dots). Exactly two subsequent dots is illegal.
I don't think there is a suitable binary operation to hijack, however
I think
'[' expr1 [,]..[,] expr2 '
Yeah, I'm not sure if the benefits would be worth breaking such a
strong Python convention.I'd rather have consistency since it
appears so often in other places.
I'd vote against.
--Mike
On 9/17/07, Nick Alexander <[EMAIL PROTECTED]> wrote:
>
> > Robert, Since you do so much work on Cython,
On 9/17/07, Nick Alexander <[EMAIL PROTECTED]> wrote:
>
>
> > Robert, Since you do so much work on Cython, maybe you could think
> > about the formal specification of the Python language and see whether
> > ..
> > not appearing in a string is ever valid Python. I.e., could we add
> > [ex
> Robert, Since you do so much work on Cython, maybe you could think
> about the formal specification of the Python language and see whether
> ..
> not appearing in a string is ever valid Python. I.e., could we add
> [expr1 .. expr2]
> to the language without running into problems?
Muc
On 9/17/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> > It sounds from what you write though, that it is best to just stick
> > with the "upload" / "download" terminology, since it is *very* clear
> > in which direction the file goes in each case. Upload means "goes
> > to the server (SAGE no
On Sep 17, 2007, at 7:21 PM, William Stein wrote:
> On 9/17/07, Peter Doyle <[EMAIL PROTECTED]> wrote:
> On 9/17/07, William Stein <[EMAIL PROTECTED]> wrote:
> > On 9/17/07, Peter G. Doyle <[EMAIL PROTECTED]> wrote:
>
> > > -- It's still far from clear to me what `downloading' and
> `uploadin
On 9/17/07, Peter Doyle <[EMAIL PROTECTED]> wrote:
>
> On 9/17/07, William Stein <[EMAIL PROTECTED]> wrote:
> > On 9/17/07, Peter G. Doyle <[EMAIL PROTECTED]> wrote:
>
> > > -- It's still far from clear to me what `downloading' and `uploading'
> are
> > > supposed to mean.
> >
> >
> > It's suppose
- Original Message -
From: William Stein
> One possibly nasty possibility would be to allow Magma-like notation:
> sage: [1..4]
> [1, 2, 3, 4]
>
> How does one specify an integer range in Maple, Mathematica, Maxima?
In Maple it is similar to Magma, $1..4 produces 1,2,3,4. Also, .. is u
On 9/17/07, William Stein <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Peter G. Doyle <[EMAIL PROTECTED]> wrote:
> > I have recently discovered SAGE, which I think is really quite amazing.
> >
> > I am contemplating introducing the students in our honors calculus course
> > here at Dartmouth to SAGE.
On 9/17/07, Peter G. Doyle <[EMAIL PROTECTED]> wrote:
>
> I have recently discovered SAGE, which I think is really quite amazing.
>
> I am contemplating introducing the students in our honors calculus course
> here at Dartmouth to SAGE. I'm a bit leery about this, since I'm new to
> SAGE
> myself.
> "Mathematica gives the standard result for this integral, implicitly
> assuming that n is not equal to -1."
> Integrate[x^n, x]
>
> the result is x^(1+n)/(1+n)
>
> (this even happens when you give the option GenerateConditions->True)
>
> It would be much better to return the solution and its ass
On Sep 12, 2007, at 9:52 PM, William Stein wrote:
> Personally, I think you're applying some of the very structured
> coercion
> model thinking in this situation, which is I think the wrong approach
> for symbol pushing and symbolic calculus.
I think you're right...
> Right now one gets the f
ack, first first paragraph has the sentences out of order - an example
of giving a "useful result with an implicit assumption" is:
http://reference.wolfram.com/mathematica/tutorial/IndefiniteIntegrals.html
"Mathematica gives the standard result for this integral, implicitly
assuming that n is not
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
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 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 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 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
> 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 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->
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 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
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(
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
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:
> >> 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: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:
> 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:
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: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 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 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, 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 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
58 matches
Mail list logo
