[sage-devel] Re: calculus in SAGE/SymPy
> "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 assumption. (or > even better, all possible solutions, or some sort of message that not > all solutions could be found) I agree with this - it should return a set of conditions that need to be true in order for the solution to be correct or return all solutions together with their conditions. There could be some some keyword parameter controlling this behavior. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 following, which is very lame (if you > agree, please add this to the trac ticket): > > sage: f(x) = x^2 > sage: f + sin > x |--> sin + x^2 > sage: f(10) > 100 Done. >> What should >> sin.variables() return? > > What it does now: > > sage: sin.variables() > () > >> I think it should be a tuple with one >> element, as it takes one argument... >> Or something special? > > It has no variables right now, so why should it return any? It's > an unevaluate function. It is an unevaluated function *in one input*. If I type sage: f(x) = x^3-x now f is an unevaluated function as well, right? (or is it a function evaluated at x? If so, can I get the unevaluated version?) - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 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 assumption. (or
even better, all possible solutions, or some sort of message that not
all solutions could be found)
On Sep 13, 12:48 am, Chris Chiasson <[EMAIL PROTECTED]> wrote:
> 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 software made an incorrect assumption. (I am
> specifically thinking of integration.)
>
> Anyway, about the (sin+cos)(1) giving sin(1)+cos(1):
> In Mathematica, this is implemented by a generalized function called
> Through (that operates on expression trees). It isn't automatic like
> people are suggesting here. Also, other operations are possible, such
> as threading, distribution, outer and inner products, etc (not all of
> which make sense here). It seems like people are thinking of a direct
> mapping between syntax and the operations that are performed. Should
> there be some level of generalized expression handling that allows
> manipulation of expressions, or should everything be hard-coded for
> each class?
>
> On Sep 12, 8:17 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > 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
> > > sage: f = sin(domain=X,codomain=X)
> > ...
> > > Note that the default domain could be a Complex Field rather than a
> > > Real Field.
> > > In order to allow domains which are, say, the positive real numbers, I
> > > don't see
> > > how to get around the need for a class for such domains (i.e.
> > > RealField() does
> > > not do the job).
> > [...]
> > > However it also introduces some headaches, like when (or on what
> > > domain) is the
> > > composition sqrt(x) defined, and how to specify the domain of an
> > > inverse function:
> > >[...]
> > > With this approach, one has to make a design decision whether a
> > > function must be
> > > defined everywhere on a domain, whether it can have isolated poles,
> > > and if the ...
> > [...]
> > > This would provide some
> > > mathematical rigor without killing usability.
>
> > The entire point of the SAGE symbolic calculus package is to not
> > do what you're suggesting above. It is meant for pure symbol
> > manipulation and calculus, even if this might not be completely
> > rigorous. It's a completely different kind of thinking than what
> > goes into Magma or even advanced rigorous mathematics.
> > And for certain types of problems (the vast majority of the ones
> > undergrad non-math majors encounter), this non-rigorous
> > symbol manipulation is by far the easiest thing to use. There is
> > a genuine reason why Maple and Mathematica have millions of users,
> > and more formal rigorous systems (e.g., Axiom) have far less, even
> > though they to some extent address the same problems.
>
> > My goal for for SAGE is to provide a viable open source alternative to
> > Maple, Mathematica, Matlab, and Magma. To do this it's critical that
> > there
> > be a part of SAGE that can truly be as usable for non-mathematicians
> > as Maple. We're far from there yet, but I think the current calculus
> > package
> > is a step in the right direction, and what you're suggesting isn't.
>
> > I think that something like you're suggesting definitely has a place for
> > people with much more mathematical maturating that "undergrad science
> > majors". But I think the two must be complementary, not that one replaces
> > the other.
>
> > 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
> > formal symbol manipulation was *precisely* what he is interested in.
> > There is certainly a very important place for this sort of computation.
>
> > William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, vis
[sage-devel] Re: calculus in SAGE/SymPy
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 software made an incorrect assumption. (I am
specifically thinking of integration.)
Anyway, about the (sin+cos)(1) giving sin(1)+cos(1):
In Mathematica, this is implemented by a generalized function called
Through (that operates on expression trees). It isn't automatic like
people are suggesting here. Also, other operations are possible, such
as threading, distribution, outer and inner products, etc (not all of
which make sense here). It seems like people are thinking of a direct
mapping between syntax and the operations that are performed. Should
there be some level of generalized expression handling that allows
manipulation of expressions, or should everything be hard-coded for
each class?
On Sep 12, 8:17 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> 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
> > sage: f = sin(domain=X,codomain=X)
> ...
> > Note that the default domain could be a Complex Field rather than a
> > Real Field.
> > In order to allow domains which are, say, the positive real numbers, I
> > don't see
> > how to get around the need for a class for such domains (i.e.
> > RealField() does
> > not do the job).
> [...]
> > However it also introduces some headaches, like when (or on what
> > domain) is the
> > composition sqrt(x) defined, and how to specify the domain of an
> > inverse function:
> >[...]
> > With this approach, one has to make a design decision whether a
> > function must be
> > defined everywhere on a domain, whether it can have isolated poles,
> > and if the ...
> [...]
> > This would provide some
> > mathematical rigor without killing usability.
>
> The entire point of the SAGE symbolic calculus package is to not
> do what you're suggesting above. It is meant for pure symbol
> manipulation and calculus, even if this might not be completely
> rigorous. It's a completely different kind of thinking than what
> goes into Magma or even advanced rigorous mathematics.
> And for certain types of problems (the vast majority of the ones
> undergrad non-math majors encounter), this non-rigorous
> symbol manipulation is by far the easiest thing to use. There is
> a genuine reason why Maple and Mathematica have millions of users,
> and more formal rigorous systems (e.g., Axiom) have far less, even
> though they to some extent address the same problems.
>
> My goal for for SAGE is to provide a viable open source alternative to
> Maple, Mathematica, Matlab, and Magma. To do this it's critical that
> there
> be a part of SAGE that can truly be as usable for non-mathematicians
> as Maple. We're far from there yet, but I think the current calculus package
> is a step in the right direction, and what you're suggesting isn't.
>
> I think that something like you're suggesting definitely has a place for
> people with much more mathematical maturating that "undergrad science
> majors". But I think the two must be complementary, not that one replaces
> the other.
>
> 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
> formal symbol manipulation was *precisely* what he is interested in.
> There is certainly a very important place for this sort of computation.
>
> William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 some of the very structured coercion model thinking in this situation, which is I think the wrong approach for symbol pushing and symbolic calculus. > Perhaps this was a bad idea, but then it is unclear what (x+sin) is. > For callable symbolic expressions I think it may be a bit clearer. Currently it is the formal sum of a symbolic variable and an unevaluated function. This is meaningful in the world of symbolic manipulation. > sage: f(x) = x^2 > sage: f + sin > x^2 + sin(x) # because f.parent()(sin) = sin(x) ?? That's very reasonable and should be fixed: sage: f(x) = x^2 sage: f + sin x |--> sin(x) + x^2 Right now one gets the following, which is very lame (if you agree, please add this to the trac ticket): sage: f(x) = x^2 sage: f + sin x |--> sin + x^2 sage: f(10) 100 > Also, what should (x+y+sin)(5) be? An error? 5+y+sin? If ( x + sin)(5) is 5 + sin(5), then the above should be 5 + y + sin(5). The expression x + y + sin is evaluated at 1 input, so since the variables are (x,y), this is turned into (x+y+sin)(x=5). Next, this is evaluated term by term and the result is added. x(x=5) is 5 y(x=5) is y sin (x=5) is sin(5), *if* we have the rule that calling an unevaluated function with a named variable evaluates the unevaluated function at the value of that variable. > What should > sin.variables() return? What it does now: sage: sin.variables() () > I think it should be a tuple with one > element, as it takes one argument... > Or something special? It has no variables right now, so why should it return any? It's an unevaluate function. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 now how
> it should work.This is what currently happens:
>
> sage: x,y = var('x y')
> sage: y + sin
> sin + y
> sage: x + sin
> sin + x
> sage: (x + sin)(5) # this is bad -- it's the trac ticket robert
> opened
> sin + 5 # should be sin(5) + 5.
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.
Perhaps this was a bad idea, but then it is unclear what (x+sin) is.
For callable symbolic expressions I think it may be a bit clearer.
sage: f(x) = x^2
sage: f + sin
x^2 + sin(x) # because f.parent()(sin) = sin(x) ??
Also, what should (x+y+sin)(5) be? An error? 5+y+sin? What should
sin.variables() return? I think it should be a tuple with one
element, as it takes one argument... Or something special?
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 self.__nonzero__'. > " Would it be better to say "Return True if self is the zero element in its parent." Here 'sin' is not the zero expression, so we return False. However, sage: (sin - sin).is_zero() # this is equal to the zero expression True (Of course, depending on the limitations of the underlying symbolic engine, it may give false negatives.) > I understand this though: > > sage: sin(0).is_zero() > True > sage: sin(1).is_zero() > False > > >> I don't see the latter ever getting used, or even being exposed. It >> seems as unnatural as >> >> sage: import types >> sage: types.IntType(4) # instead of using int(4) > > Well, I can see a difference: > > sage: type(sin) > > sage: type(4) > type(4) > > > so basically the "type" says what is the class of that instance. So 4 > is an instance of int or Integer in SAGE and thus should be > instantiated using int(4), or just using a syntactic sugar: 4. On the > other hand sin is an instance of Function_sin, but it shouldn't be > instantiated by Function_sin(). It seems to me like some kind of > magic, that I type "sin" and some instance of a class that I am not > supposed to import is returned. Note that we do the same in sympy > currently. I think of it as pre-populating the namespace with common and useful classes, functions, and objects, among them is a well named instance of Function_sin. Whether or not that is magical is a matter of opinion, but I think it obeys the principle of least surprise for the end user. > Nevertheless, it's not a big deal anyway. I just wanted to know your > opinions about this. Thanks a lot for all the ideas you wrote. > > Ondrej Thank you for posting your questions here, I think it's generated a good discussion. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 manipulation" and Ondrej replied that possibly non-rigorous > formal symbol manipulation was *precisely* what he is interested in. > There is certainly a very important place for this sort of computation. > There is perhaps a formal distinction to be made between algebra and calculus, where one views algebra as studing mathematical objects and their relationships, while calculus is devoted to formal manipulations of expressions with much less emphasis on the objects which they may or may not represent. Of course one of the types of mathematical object worthy of study are just such expressions. From my point of view this was/is the primary purpose of programming languages such as Lisp, e.g. S-expressions. Axiom is written in Lisp so there is very definitely an interest in formal symbol manipulation of this type, but it's primary purpose is to describe very much more general algebraic objects. I recall Ondrej's posts to axiom-developer. I am not sure exactly what conversation you have in mind but my recollection is somewhat different. I think the point (on the Axiom side) was that in principle it should not be necessary to sacrifice mathematical rigor in the design of packages for formal symbol manipulation. Doing so risks perpetuating the confusing array of ad hoc manipulations that are the basis of programs like Maxima, Maple, and Mathematica today. From this point of view, having yet another system for doing this in Python does not seem like much of an advantage - at best it is a matter of convenience for people who for whatever reason already program in Python. But I think the connection between symbolic and algebraic modes of computation is a rather deep one that even as a research subject has not been fully explored yet. I think it is worth trying to understand how Axiom attempted to implement a fairly general "Expression" domain by first formally defining polynomials, then rational functions and extending them with transcendental operators etc., all in a mathematically rigorous manner. This is a way of being as formal and as flexible as possible in a mathematically defensible manner. The emphasis is on the deep semantics of the underlying algebraic operations, rather than focusing only on the surface-level syntactic manipulations. The Expression domain in Axiom is where most of the "calculus" (integration, differentiation, limits, etc.) takes place but it is built up step my step in a rigorous manner from simpler algebraic objects. On the critical side however, one might consider how the Axiom "Expression" domain fails to be sufficiently general for some important purposes. In these cases even the Axiom algorithms sometimes resort to rather shallow heuristics and simple pattern matching. Over the long history of projects like Axiom this subject has been debated in many different ways. (For example you could check the axiom-developer email archives for references to recent papers by Stephen Watt on this subject.) I think it would be a great pity if we do not find some way to build on this work rather than walking over the same ground again and again just wearing slightly different clothes. So I am very grateful to Ondrej to having taken some time to look at Axiom and to discuss these ideas. And I think that it is a good thing that the subject comes up again here in Sage since Sage does make some effort to implement other formal (algebraic) mathematical structures in a rigorous manner. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
> 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 > formal symbol manipulation was *precisely* what he is interested in. > There is certainly a very important place for this sort of computation. There is just a huge difference between how pure mathematicians and physicists and engineers are accessing the mathematics. The most prominent example being distributions, mathematicians usually love the notation instead of writing integral(delta(0)*phi(x), x), which is more natural, it has the same rigor and you can manipulate with it more easily. It's not just "undergraduate science majors", IMHO it's all engineers and all physicists as well. I think everyone except mathematicians. :)) Just joking. It should be done in a way, so that if you type "sqrt(x)", or whatever, it will just do what I would expect it to do. And of course you can specify more mathematical rigor, if you want (like domains, etc.) if needed. As to y+sin I don't see any reasonable meaning to it, so it should rise an exception in my opinion. > I think sin should be an instance rather than a class, and it would > have a reasonable __call__ method. This would have the side effect of > being consistent with Python conventions, and would be more > consistent with the user's idea that "sin" is a function. One can > also then do things like This is what we do in SymPy at the moment. See below why I don't like it. > 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 self.__nonzero__'. " I understand this though: sage: sin(0).is_zero() True sage: sin(1).is_zero() False > I don't see the latter ever getting used, or even being exposed. It > seems as unnatural as > > sage: import types > sage: types.IntType(4) # instead of using int(4) Well, I can see a difference: sage: type(sin) sage: type(4) >>> type(4) so basically the "type" says what is the class of that instance. So 4 is an instance of int or Integer in SAGE and thus should be instantiated using int(4), or just using a syntactic sugar: 4. On the other hand sin is an instance of Function_sin, but it shouldn't be instantiated by Function_sin(). It seems to me like some kind of magic, that I type "sin" and some instance of a class that I am not supposed to import is returned. Note that we do the same in sympy currently. Nevertheless, it's not a big deal anyway. I just wanted to know your opinions about this. Thanks a lot for all the ideas you wrote. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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->K.
> > same as cos.
>
> What is K? sin is symbolic so the input is anything symbolic. It's formal.
I specifically called it K, because I didn't want to say reals or complex.
Can I claim K is the ring of symbolic expressions? I still like to think
of sin as a function from symbols to symbols, since that's how I'm resolving
the expression (sin+cos)(1).
>
> > 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 also
> > a function from K->K?
>
> x is a symbolic variable. It also has a call method.Actually,
> i don't know what you mean by x in the questions above.
sorry. Most of the rest of the questions I have were derived from
Robert's proposal:
sage: x, y = var('x y')
sage: f(x) = x^2 + 1
sage: f + sin
x^2 + 1 + sin(x)
sage: y + sin
y + sin(y)
I understand that x is a symbolic variable, but I am confused that a command
like x(5) makes sense. Again my way of resolving it was to think of x as
a function from ring of symbolic expressions to ring of symbolic expressions.
>
> > Can we assume sin(x)=sin?
>
> No, and they aren't equal. That doesn't make sense. One is
> an unevaluated function, and the other is evaluated at the point
> x. The data types are totally different.
Here's what sage does right now:
sage: sin(x)(5)
sin(5)
I think this is fine, but again, this was why I asked that question.
However, on the way home I concluded that they are not equal, but when
simplified they are equal.
> sage: x,y = var('x y')
> sage: y + sin
> sin + y
> sage: x + sin
> sin + x
> sage: (x + sin)(5) # this is bad -- it's the trac ticket robert opened
> sin + 5 # should be sin(5) + 5.
Ok, these examples are all consistent in some ways. What should sage
return for (y+sin)(5)? If I read Robert's proposal correctly, it should
return 5+sin(5), however I think that's wrong. If we follow that then we
don't necessarily have f(5)+g(5)=(f+g)(5), and I think it can be a source
of much confusion.
Soroosh
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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
> sage: f = sin(domain=X,codomain=X)
...
> Note that the default domain could be a Complex Field rather than a
> Real Field.
> In order to allow domains which are, say, the positive real numbers, I
> don't see
> how to get around the need for a class for such domains (i.e.
> RealField() does
> not do the job).
[...]
> However it also introduces some headaches, like when (or on what
> domain) is the
> composition sqrt(x) defined, and how to specify the domain of an
> inverse function:
>[...]
> With this approach, one has to make a design decision whether a
> function must be
> defined everywhere on a domain, whether it can have isolated poles,
> and if the ...
[...]
> This would provide some
> mathematical rigor without killing usability.
The entire point of the SAGE symbolic calculus package is to not
do what you're suggesting above. It is meant for pure symbol
manipulation and calculus, even if this might not be completely
rigorous. It's a completely different kind of thinking than what
goes into Magma or even advanced rigorous mathematics.
And for certain types of problems (the vast majority of the ones
undergrad non-math majors encounter), this non-rigorous
symbol manipulation is by far the easiest thing to use. There is
a genuine reason why Maple and Mathematica have millions of users,
and more formal rigorous systems (e.g., Axiom) have far less, even
though they to some extent address the same problems.
My goal for for SAGE is to provide a viable open source alternative to
Maple, Mathematica, Matlab, and Magma. To do this it's critical that
there
be a part of SAGE that can truly be as usable for non-mathematicians
as Maple. We're far from there yet, but I think the current calculus package
is a step in the right direction, and what you're suggesting isn't.
I think that something like you're suggesting definitely has a place for
people with much more mathematical maturating that "undergrad science
majors". But I think the two must be complementary, not that one replaces
the other.
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
formal symbol manipulation was *precisely* what he is interested in.
There is certainly a very important place for this sort of computation.
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 symbolic. It's formal.
> 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 also
> a function from K->K?
x is a symbolic variable. It also has a call method.Actually,
i don't know what you mean by x in the questions above.
> Can we assume sin(x)=sin?
No, and they aren't equal. That doesn't make sense. One is
an unevaluated function, and the other is evaluated at the point
x. The data types are totally different.
> 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 now how
it should work.This is what currently happens:
sage: x,y = var('x y')
sage: y + sin
sin + y
sage: x + sin
sin + x
sage: (x + sin)(5) # this is bad -- it's the trac ticket robert opened
sin + 5 # should be sin(5) + 5.
> If I understand the logic of everything, y is an element of functions
> from K^2 -> K, while sin is a function from K->K.
No, that's not right. There is absolutely no mathematical
difference between x and y at all. They are both formal indeterminates.
Thanks for your questions and comments.
> Soroosh
>
> On Wed, Sep 12, 2007 at 02:29:26PM -0700, Robert Bradshaw wrote:
> > 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. Calling when the inputs are explicit is done with
> > >>> the variables in dictionary order.
> > >>
> > >> I'll take that back, I didn't know dictionary order was explicitly
> > >> used, and I'm OK with that as there is no ambiguity. Is there any
> > >> reason f(2,3) does not work?
> > >>
> > >
> > > I can't think of any, so *that* must be a bug. Could you open
> > > a trac ticket for it?
> > >
> > > William
> >
> > Done. http://www.sagemath.org:9002/sage_trac/ticket/645
> >
> >
> >
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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(y)
sage: f.domain() == g.domain()
False
sage: f == g
False
sage: h = sin(domain=X,codomain=Y)
sage: f == h
False
Note that the default domain could be a Complex Field rather than a
Real Field.
In order to allow domains which are, say, the positive real numbers, I
don't see
how to get around the need for a class for such domains (i.e.
RealField() does
not do the job).
Note also that this provides a means of resolving sqrt(x)^2 and
similar expressions.
However it also introduces some headaches, like when (or on what
domain) is the
composition sqrt(x) defined, and how to specify the domain of an
inverse function:
sage: sin_inv = sin.inverse() # well-defined on some default subspace
of the codomain?
sage: sin_inv.domain()
???
With this approach, one has to make a design decision whether a
function must be
defined everywhere on a domain, whether it can have isolated poles,
and if the
domain and codomain contains a +oo and/or -oo. Personally, I think
isolated poles
(or codimension >= 1 poles) should be allowed, but sqrt(x) should
require x.domain()
to be contained in the positive reals (or a complex domain and some
choice of branch).
Thus sqrt(exp(x)) would be valid but not x = var('x'); sqrt(x). This
would provide some
mathematical rigor without killing usability.
--David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 also
a function from K->K? Can we assume sin(x)=sin?
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)
If I understand the logic of everything, y is an element of functions
from K^2 -> K, while sin is a function from K->K.
Soroosh
On Wed, Sep 12, 2007 at 02:29:26PM -0700, Robert Bradshaw wrote:
> 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. Calling when the inputs are explicit is done with
> >>> the variables in dictionary order.
> >>
> >> I'll take that back, I didn't know dictionary order was explicitly
> >> used, and I'm OK with that as there is no ambiguity. Is there any
> >> reason f(2,3) does not work?
> >>
> >
> > I can't think of any, so *that* must be a bug. Could you open
> > a trac ticket for it?
> >
> > William
>
> Done. http://www.sagemath.org:9002/sage_trac/ticket/645
>
>
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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. Calling when the inputs are explicit is done with >>> the variables in dictionary order. >> >> I'll take that back, I didn't know dictionary order was explicitly >> used, and I'm OK with that as there is no ambiguity. Is there any >> reason f(2,3) does not work? >> > > I can't think of any, so *that* must be a bug. Could you open > a trac ticket for it? > > William Done. http://www.sagemath.org:9002/sage_trac/ticket/645 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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
> > the variables in dictionary order.
>
> I'll take that back, I didn't know dictionary order was explicitly
> used, and I'm OK with that as there is no ambiguity. Is there any
> reason f(2,3) does not work?
>
I can't think of any, so *that* must be a bug. Could you open
a trac ticket for it?
William
> >
> > sage: var('x,y')
> > (x, y)
> > sage: f = x+y
> > sage: f(4)
> > y + 4
> > sage: f(4)(7)
> > 11
> >
> > If you have a good argument for changing this (and are willing
> > to the do work), I am certainly interested in it.
> >
> > William
> >
> >
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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')
>> sage: f(x) = x^2 + 1
>> sage: f + sin
>> x^2 + 1 + sin(x)
>> sage: y + sin
>> y + sin(y)
>>
>> 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
> the variables in dictionary order.
I'll take that back, I didn't know dictionary order was explicitly
used, and I'm OK with that as there is no ambiguity. Is there any
reason f(2,3) does not work?
>
> sage: var('x,y')
> (x, y)
> sage: f = x+y
> sage: f(4)
> y + 4
> sage: f(4)(7)
> 11
>
> If you have a good argument for changing this (and are willing
> to the do work), I am certainly interested in it.
>
> William
>
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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: y + sin
> y + sin(y)
>
> 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
the variables in dictionary order.
sage: var('x,y')
(x, y)
sage: f = x+y
sage: f(4)
y + 4
sage: f(4)(7)
11
If you have a good argument for changing this (and are willing
to the do work), I am certainly interested in it.
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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, and pow and atan2 > are 2-argument functions. What do the following mean? I'll bite: > (sin+cos)(1) sin(1) + cos(1) > (sin+1)(1) sin(1) + 1 > (pow+atan2)(1, 2) 1^2 + atan2(1,2) > (sin+cos)(1, 2) Error message. > (pow+atan2)(1) Error message. > (pow+sin)(1) Error message > (pow+sin)(1, 2) Error message. > (pow+sin+1)(1) Error message. Basically in each case distribute the call to the operands, and then add the result. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 posting to both
> mailinglists.
>>
>>> Thanks. I want to preface my comments below by remarking that the
>>> design constraints in SAGE and SymPy are different so the best
>>> answers
>>> in each case may be different.
>>
> 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 (Add(sin, cos))(1) will produce
> Add(sin(1), cos(1)). So that we can use both applied (sin(x)) and
> unapplied (sin) functions.
>>
>>> In SAGE the following happens. Maybe this is a design mistake in
>>> SAGE:
>>
>>> sage: f = sin + cos; f
>>> sin + cos
>>> sage: f(1)
>>> sin + cos # design mistake? should it be sin(1) + cos(1)?
>>> sage: sin(1)
>>> sin(1)
>>
>>> It definitely seems wrong from one point of view. What's happening
>>> above is that f(1) does substitution on the variables in f, of which
>>> there are none. In contrast sin(1) evaluates the function sin at 1.
>>
>>> If somebody agrees that the above should be considered a bug
>>> in SAGE, it should be added to trac.
>>
>> Seehttp://www.sagemath.org:9002/sage_trac/ticket/644
>
> Is this really a good thing?
I think so, but I welcome lots of discussion before it gets implemented.
> 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, and pow and atan2
> are 2-argument functions. What do the following mean?
>
> (sin+cos)(1)
sin(1) + cos(1)
> (sin+1)(1)
sin(1) + 1
> (pow+atan2)(1, 2)
1 + atan(1,2)
> (sin+cos)(1, 2)
error, wrong number of args
> (pow+atan2)(1)
error, wrong number of args
> (pow+sin)(1)
> (pow+sin)(1, 2)
> (pow+sin+1)(1)
Coercion error, no common parent for '+' (CallableSR in 2 unnamed
vars, CallableSR in 1 unnamed var) # due to ambiguity of where the
1st var goes
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: y + sin
y + sin(y)
BTW, I think this is a bug:
sage: f = x+y
sage: f
y + x
sage: f(4)
y + 4
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 want to preface my comments below by remarking that the > > design constraints in SAGE and SymPy are different so the best answers > > in each case may be different. > > >>> 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 (Add(sin, cos))(1) will produce > >>> Add(sin(1), cos(1)). So that we can use both applied (sin(x)) and > >>> unapplied (sin) functions. > > > In SAGE the following happens. Maybe this is a design mistake in > > SAGE: > > > sage: f = sin + cos; f > > sin + cos > > sage: f(1) > > sin + cos # design mistake? should it be sin(1) + cos(1)? > > sage: sin(1) > > sin(1) > > > It definitely seems wrong from one point of view. What's happening > > above is that f(1) does substitution on the variables in f, of which > > there are none. In contrast sin(1) evaluates the function sin at 1. > > > If somebody agrees that the above should be considered a bug > > in SAGE, it should be added to trac. > > 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, and pow and atan2 are 2-argument functions. What do the following mean? (sin+cos)(1) (sin+1)(1) (pow+atan2)(1, 2) (sin+cos)(1, 2) (pow+atan2)(1) (pow+sin)(1) (pow+sin)(1, 2) (pow+sin+1)(1) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 comments below by remarking that the > design constraints in SAGE and SymPy are different so the best answers > in each case may be different. > >>> 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 (Add(sin, cos))(1) will produce >>> Add(sin(1), cos(1)). So that we can use both applied (sin(x)) and >>> unapplied (sin) functions. > > In SAGE the following happens. Maybe this is a design mistake in > SAGE: > > sage: f = sin + cos; f > sin + cos > sage: f(1) > sin + cos # design mistake? should it be sin(1) + cos(1)? > sage: sin(1) > sin(1) > > It definitely seems wrong from one point of view. What's happening > above is that f(1) does substitution on the variables in f, of which > there are none. In contrast sin(1) evaluates the function sin at 1. > > If somebody agrees that the above should be considered a bug > in SAGE, it should be added to trac. See http://www.sagemath.org:9002/sage_trac/ticket/644 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
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 in SAGE and SymPy are different so the best answers in each case may be different. > > 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 (Add(sin, cos))(1) will produce > > Add(sin(1), cos(1)). So that we can use both applied (sin(x)) and > > unapplied (sin) functions. In SAGE the following happens. Maybe this is a design mistake in SAGE: sage: f = sin + cos; f sin + cos sage: f(1) sin + cos # design mistake? should it be sin(1) + cos(1)? sage: sin(1) sin(1) It definitely seems wrong from one point of view. What's happening above is that f(1) does substitution on the variables in f, of which there are none. In contrast sin(1) evaluates the function sin at 1. If somebody agrees that the above should be considered a bug in SAGE, it should be added to trac. > > 2) we have the least amount of classes in there > > > > For details, see: > > > > http://code.google.com/p/sympy/issues/detail?id=329 > > > > However, there are some longterm questions: > > > > 1) when you type sin(x), it's an instance of the class "sin". Now, all > > classes in Python should be CamelCase, so we should rather use > > "Sin(x)". Currently, SymPy/SAGE/Maple uses "sin(x)", while Mathematica > > uses "Sin[x]". > > > > What is your opinion about this? See also: > > > > http://code.google.com/p/sympy/issues/detail?id=329#c11 > > > > I'd very much like to obey Python conventions, because this is what > > people expect when seeing the code for the first time. Of course we > > can do something like > > > > sin=Sin > > > > so that people can use both. But I am against it, since there should > > be just one way of doing things. And especially, there should be just > > one way how things are done both inside and outside SymPy, i.e. there > > shouldn't be one way how to create functions in SymPy core and another > > way how users will create functions. > > > > So for the time being, we use lower case name of some classes in > > SymPy, like "sin", "cos", so that we don't break the current code. > > I think sin should be an instance rather than a class, and it would > have a reasonable __call__ method. This would have the side effect of > being consistent with Python conventions, and would be more > consistent with the user's idea that "sin" is a function. One can > also then do things like > > sage: sin.is_zero() > False > I, of course, agree 100% with Robert's response, since it is exactly what we do in SAGE. > > 2) I was looking at how this is done in SAGE.calculus: > > > > There is: > > > > class Function_sin(PrimitiveFunction): > > > > > > sin = Function_sin() > > _syms['sin'] = sin > > > > example: > > > > sage: from sage.calculus.calculus import Function_sin > > sage: sin(x) > > sin(x) > > sage: Function_sin()(x) > > sin(x) > > sage: type(sin) > > > > sage: type(sin(x)) > > > > > > > > So first there are two ways how to create a sin(x): "sin(x)", or > > "Function_sin()(x)" > > I don't see the latter ever getting used, or even being exposed. It > seems as unnatural as > > sage: import types > sage: types.IntType(4) # instead of using int(4) One should never explicitly import stuff from calculus.py unless you have a very very good reason to do so. Doing Function_sin() is thus very much frowned on.In fact, it would probably be good to overload the __new__ method in Function_sin, so that Function_sin() is sin is True. > > and second everything is an instance of > > SymbolicComposition. Currently in SymPy it's very similar, there is > > Sin and ApplySin, Cos and ApplyCos (in sage you just use > > SymbolicComposition for all those ApplySin, ApplyCos,...). In SymPy, > > it's a mess and we are changing that. > > > > How do you test, if "e" is of type sin? > > > > In SymPy, we would like to do this: > > > > e = sin(x) > > print isinstance(e, sin) > > > > (currently on needs to do isinstance(e, ApplySin), but this is going > > to be changed) > > for the unnapplies, one would do e == sin, for the applied one would > have to do > > isinstance(e, SymbolicComposition) and e._operands[0] == sin > > (this should probably be fixed by adding methods to SymbolicComposition) Agreed. We'll do this when somebody actually requests it for a real application. > > In SymPy, we are just going to try a very simple approach and see how > > it goes, see the 329 issue above for details. > > > > 2) What is your position on this: > > > > sage: (sin(x)).taylor(x, 0, 5) > > x - x^3/6 + x^5/120 > > sage: taylor(sin(x), x, 0, 5) > > x - x^3/6 + x^5/120 > > > > shouldn't there be just one way how to do series e
[sage-devel] Re: calculus in SAGE/SymPy
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(sin, cos) > > and > > Add(sin(1),cos(1)) > > are valid constructions. Here (Add(sin, cos))(1) will produce > Add(sin(1), cos(1)). So that we can use both applied (sin(x)) and > unapplied (sin) functions. > > 2) we have the least amount of classes in there > > For details, see: > > http://code.google.com/p/sympy/issues/detail?id=329 > > However, there are some longterm questions: > > 1) when you type sin(x), it's an instance of the class "sin". Now, all > classes in Python should be CamelCase, so we should rather use > "Sin(x)". Currently, SymPy/SAGE/Maple uses "sin(x)", while Mathematica > uses "Sin[x]". > > What is your opinion about this? See also: > > http://code.google.com/p/sympy/issues/detail?id=329#c11 > > I'd very much like to obey Python conventions, because this is what > people expect when seeing the code for the first time. Of course we > can do something like > > sin=Sin > > so that people can use both. But I am against it, since there should > be just one way of doing things. And especially, there should be just > one way how things are done both inside and outside SymPy, i.e. there > shouldn't be one way how to create functions in SymPy core and another > way how users will create functions. > > So for the time being, we use lower case name of some classes in > SymPy, like "sin", "cos", so that we don't break the current code. I think sin should be an instance rather than a class, and it would have a reasonable __call__ method. This would have the side effect of being consistent with Python conventions, and would be more consistent with the user's idea that "sin" is a function. One can also then do things like sage: sin.is_zero() False > 2) I was looking at how this is done in SAGE.calculus: > > There is: > > class Function_sin(PrimitiveFunction): > > > sin = Function_sin() > _syms['sin'] = sin > > example: > > sage: from sage.calculus.calculus import Function_sin > sage: sin(x) > sin(x) > sage: Function_sin()(x) > sin(x) > sage: type(sin) > > sage: type(sin(x)) > > > > So first there are two ways how to create a sin(x): "sin(x)", or > "Function_sin()(x)" I don't see the latter ever getting used, or even being exposed. It seems as unnatural as sage: import types sage: types.IntType(4) # instead of using int(4) > and second everything is an instance of > SymbolicComposition. Currently in SymPy it's very similar, there is > Sin and ApplySin, Cos and ApplyCos (in sage you just use > SymbolicComposition for all those ApplySin, ApplyCos,...). In SymPy, > it's a mess and we are changing that. > > How do you test, if "e" is of type sin? > > In SymPy, we would like to do this: > > e = sin(x) > print isinstance(e, sin) > > (currently on needs to do isinstance(e, ApplySin), but this is going > to be changed) for the unnapplies, one would do e == sin, for the applied one would have to do isinstance(e, SymbolicComposition) and e._operands[0] == sin (this should probably be fixed by adding methods to SymbolicComposition) > In SymPy, we are just going to try a very simple approach and see how > it goes, see the 329 issue above for details. > > 2) What is your position on this: > > sage: (sin(x)).taylor(x, 0, 5) > x - x^3/6 + x^5/120 > sage: taylor(sin(x), x, 0, 5) > x - x^3/6 + x^5/120 > > shouldn't there be just one way how to do series expansion? In SymPy > we also have those 2 ways - but it's kind of inconsistent, we have it > for some methods, but not all. My own opinion is more in favor of > removing all those module level functions (like taylor, expand), if > there is a corresponding method. But there are other opinions as well. Usually we go for the former, so as not to clutter the namespace and to avoid big if-then lists. Occasionally, though, we provided a global function like def foo(x): try: return x.foo() except AttributeError: # generic code or raise a value error - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
