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 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:
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
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, 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 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
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 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
> "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
24 matches
Mail list logo
