Inert Integrals and Derivatives?
Tim Lahey
Maple has a really useful feature of inert integrals
and derivatives. Basically, the integrals and derivatives
show up in the equations, but aren't evaluated until
a command to evaluate them is explicitly given. So,
you can delay the evaluation until after you've processed
the expression to the point where it can be evaluated.
This feature comes in very handy during complicated
derivations because you can see which terms are integrals
or derivatives and manipulate them along side
non-integrals/derivatives.
Is there a way to do this in Sage?
Thanks,
Tim.
Burcin Erocal
This is not supported in Sage at the moment, but it is definitely
planned. It should be fairly simple to implement this using the new
symbolic function interface from ginac, which allows one to specify
custom simplify/automatic evaluation functions.
I am not familiar with the maple syntax. Can you give some examples of
how to use these features so I can play with them without having to dig
through documentation?
Thanks.
Burcin
David Joyner
I agree this would be a very useful feature. Basically, something like
(1)
sage: integral(x,x,0,1)
1/2
sage: Integral(x,x,0,1)
\int_0^1 x\, dx
(not the upper case I), or maybe
(2)
sage: A = Integral(x,x,0,1)
sage. latex(A)
\int_0^1 x\, dx
sage: A
Integral(x,x,0,1)
>
>
> Thanks.
>
> Burcin
>
> >
>
William Stein
I'm not enthuisiastic about using
Foo and foo to denote different commands. If we have
two cases of the exact same word in Sage, then they should
be aliased. Isn't (2) below identical to (1) above?
Or did you not mean to distinguish case above?
>
> (2)
> sage: A = Integral(x,x,0,1)
> sage. latex(A)
> \int_0^1 x\, dx
> sage: A
> Integral(x,x,0,1)
>
>>
>>
>> Thanks.
>>
>> Burcin
>>
>> >
>>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
David Joyner
Okay. I just tried to answer Burcin's question of what Maple does,
using Sage as an analogy.
> two cases of the exact same word in Sage, then they should
> be aliased. Isn't (2) below identical to (1) above?
> Or did you not mean to distinguish case above?
I think you are right. I wasn't thinking that at the time but
now I can't see a way to implement (1) and (2) differently.
Tim Lahey
It's what Maple does. In Maple, Int() is used to indicate an
inert integral, while int() is used to indicate an integral which
is evaluated at that time.
>>
>> (2)
>> sage: A = Integral(x,x,0,1)
>> sage. latex(A)
>> \int_0^1 x\, dx
>> sage: A
>> Integral(x,x,0,1)
>>
I don't really care which syntax is used, as long as there is a
consistent way of doing this.
Cheers,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
Robert Bradshaw
I like the concept, though I'm also -1 on the capital/lowercase
syntax. Perhaps integral could take an extra argument, so one would have
sage: integral(x,x,0,1)
1/2
sage: Integral(x,x,0,1, evaluate=False)
\int_0^1 x\, dx
Or maybe a new function formal_integral?
- Robert
David Joyner
<robe...@math.washington.edu> wrote:
>
...
> I like the concept, though I'm also -1 on the capital/lowercase
> syntax. Perhaps integral could take an extra argument, so one would have
>
> sage: integral(x,x,0,1)
> 1/2
> sage: Integral(x,x,0,1, evaluate=False)
> \int_0^1 x\, dx
I like this! (I assume you meant integral, not Integral?)
But could you implement it in such a way that
sage: A = integral(x,x,0,1, evaluate=False)
sage: eval(A)
1/2
sage: latex(A)
\int_0^1 x\, dx
works?
Jason Merrill
unevaluated until it is wrapped with an Evaluate[]. The nice thing
about this syntax is that it works for any kind of expression (not
just integrals).
JM
Tim Lahey
On Aug 29, 2008, at 8:17 AM, David Joyner wrote:
>
> I like this! (I assume you meant integral, not Integral?)
> But could you implement it in such a way that
>
> sage: A = integral(x,x,0,1, evaluate=False)
> sage: eval(A)
> 1/2
> sage: latex(A)
> \int_0^1 x\, dx
>
+1
I like this approach and is relatively consistent with Maple's
because it still allows you to evaluate the integral in a
straightforward manner. It also helps indicate to the
user that "evaluate" is just a property of the integral and
makes it easy to see that eval will change that state.
Whether this is done for more than differentiation and
integration, I'm not that concerned about, but it can
be implemented in a similar manner if we have a state
variable.
Jason Grout
So maybe we could have something like a FormalExpression class which
does the same thing (has an argument that it doesn't evaluate).
Jason
Robert Bradshaw
Not sure how one would do this in Python though... (Maybe via preparsing
somehow, it would still be pretty hard...)
Ondrej Certik
SymPy has this for a long time already and so far noone seems to have
complained:
In [3]: integrate(sin(x), (x, 0, pi))
Out[3]: 2
In [4]: Integral(sin(x), (x, 0, pi))
Out[4]:
π
⌠
⎮ sin(x) dx
⌡
0
In [5]: print Integral(sin(x), (x, 0, pi))
Integral(sin(x), (x, 0, pi))
In [6]: Integral(sin(x), (x, 0, pi)).doit()
Out[6]: 2
Btw, as usual, I would learn from what Mathematica is doing, because
the Hold(...) stuff seams really simple to me. So maybe the evaluate
keyword should be used in Python. We use the "evaluate" keyword
inconsistently in sympy so far.
As to lowercase/uppercase, we just follow python conventions, so
Integral is a class, while integrate is a function.
Ondrej
Ondrej Certik
> the Hold(...) stuff seams really simple to me. So maybe the evaluate
> keyword should be used in Python. We use the "evaluate" keyword
> inconsistently in sympy so far.
Here is Mathematica's documentation for Hold:
http://reference.wolfram.com/mathematica/ref/Hold.html
In [1]: Hold[Evaluate[1 + 1], 2 + 2]
Out[1]: Hold[2, 2+2]
so this could be translated to Python along these lines:
In [1]: [1+1, Hold(2+2)]
Out[1] [2, 2+2]
Where Hold function would just set some (global?) parameter for the
__add__ function not to evaluate the stuff. I don't like this option
much though. Another option:
In [2]: [1+1, Add(2, 2, evaluate=False)]
Out[2]: [2, 2 + 2]
In fact, I executed [2] in SymPy...
But honestly, Mathematica's way Hold[2+2] is simpler than Add(2, 2,
evaluate=False).
So, opinions on this? I don't like preparsing.
Ondrej
Robert Dodier
> Not sure how one would do this in Python though... (Maybe via
> preparsing somehow, it would still be pretty hard...)
nobody here is aware that selective evaluation is trivial in Lisp,
and Maxima. In both cases a single quote marks stuff that
isn't evaluated. Maxima further marks a distinction between
so-called noun and verb operators; nouns are formal expressions
and verbs are callable functions. E.g. integrate(...) is a function
call
and 'integrate(...) is a formal expression. I've omitted some details.
This kind of stuff yanks my chain in a bad way, unfortunately.
I gather it is more interesting to reinvent the wheel than learn
how to use existing, unfamiliar wheel technology. What makes
it worse is that there is talk of copying Maple and Mathematica
notation, which both have all sorts of warts. Blechh.
Oh gods, help me! I seem to be turning into RJF. Probably I
should just butt out of this. It will make no difference to you
and I will be happier in my ignorance.
FWIW
Robert "curmudgeon-in-training" Dodier
Ondrej Certik
> I gather it is more interesting to reinvent the wheel than learn
> how to use existing, unfamiliar wheel technology. What makes
> it worse is that there is talk of copying Maple and Mathematica
> notation, which both have all sorts of warts. Blechh.
>
> Oh gods, help me! I seem to be turning into RJF. Probably I
> should just butt out of this. It will make no difference to you
> and I will be happier in my ignorance.
No, please keep posting and telling us. I am well aware of noun and
verbs, because people have requested this from sympy as well. I just
don't know how to do this in Python. Mathematica seems to be more
Python compatible than lisp.
Which warts has Mathematica? Could you be more explicit?
Thanks,
Ondrej
Tim Lahey
On Aug 30, 2008, at 7:46 PM, Robert Dodier wrote:
>
> This kind of stuff yanks my chain in a bad way, unfortunately.
> I gather it is more interesting to reinvent the wheel than learn
> how to use existing, unfamiliar wheel technology. What makes
> it worse is that there is talk of copying Maple and Mathematica
> notation, which both have all sorts of warts. Blechh.
I only brought up Maple because that was what I'm familiar with,
which isn't surprising since I come from the university where
Maple was originally developed. That said, the discussion has
moved to the discussion of the specific features rather than
the notation.
I'd considering using Maxima directly if I only needed a CAS,
but Sage provides me with Scipy as well.
Jason Merrill
> From the direction this discussion has taken I'm guessing that
> nobody here is aware that selective evaluation is trivial in Lisp,
> and Maxima. In both cases a single quote marks stuff that
> isn't evaluated. Maxima further marks a distinction between
> so-called noun and verb operators; nouns are formal expressions
> and verbs are callable functions. E.g. integrate(...) is a function
> call
> and 'integrate(...) is a formal expression. I've omitted some details.
this sits squarely in Lisp's problem domain, and not so much in
Python's. Some would argue that everything sits squarely in Lisp's
problem domain, right? But Sage is Python, so what should we do?
> This kind of stuff yanks my chain in a bad way, unfortunately.
> I gather it is more interesting to reinvent the wheel than learn
> how to use existing, unfamiliar wheel technology. What makes
> it worse is that there is talk of copying Maple and Mathematica
> notation, which both have all sorts of warts. Blechh.
has plenty of warts. Nonetheless, it's what I know well, and I'll
continue pointing out where I think it is better than proposed
alternatives. I also accept that it's sometimes worse than things I
don't know about.
> Oh gods, help me! I seem to be turning into RJF. Probably I
> should just butt out of this. It will make no difference to you
> and I will be happier in my ignorance.
expert in an area where most others on this list are deficient.
You've got some kick ass wheels. It's just, well, we've got the
beginnings of this whole car, and how do we fit those wheels on
there? Even if Sage decides to come up with its own wheels, there's
no doubt that Lisp/Maxima's wheels are worth learning from.
JM
David Philp
Robert Bradshaw wrote:On Fri, 29 Aug 2008, Jason Grout wrote:Jason Merrill wrote:The Mathematica syntax is Hold[Integral[x,{x,0,1}]]. This remainsunevaluated until it is wrapped with an Evaluate[]. The nice thingabout this syntax is that it works for any kind of expression (notjust integrals).So maybe we could have something like a FormalExpression classwhichdoes the same thing (has an argument that it doesn't evaluate).Not sure how one would do this in Python though... (Maybe viapreparsing somehow, it would still be pretty hard...)
From the direction this discussion has taken I'm guessing that
nobody here is aware that selective evaluation is trivial in Lisp,
and Maxima.
This kind of stuff yanks my chain in a bad way, unfortunately.
I gather it is more interesting to reinvent the wheel than learn
how to use existing, unfamiliar wheel technology.
What makes
it worse is that there is talk of copying Maple and Mathematica
notation, which both have all sorts of warts. Blechh.
David J Philp
Postdoctoral Fellow
National Centre for Epidemiology and Population Health
Building 62, cnr Mills Rd & Eggleston Rd
The Australian National University
Canberra ACT 0200 Australia
T: +61 2 6125 8260
F: +61 2 6125 0740
M: 0423 535 397
W: http://nceph.anu.edu.au/
CRICOS Provider #00120C
Robert Bradshaw
> Robert Bradshaw wrote:
>> On Fri, 29 Aug 2008, Jason Grout wrote:
>>> Jason Merrill wrote:
>
>>>> The Mathematica syntax is Hold[Integral[x,{x,0,1}]]. This remains
>>>> unevaluated until it is wrapped with an Evaluate[]. The nice thing
>>>> about this syntax is that it works for any kind of expression (not
>>>> just integrals).
>
>>> So maybe we could have something like a FormalExpression class
>>> whichdoes the same thing (has an argument that it doesn't evaluate).
>
>> Not sure how one would do this in Python though... (Maybe via
>> preparsing somehow, it would still be pretty hard...)
>
> From the direction this discussion has taken I'm guessing that
> nobody here is aware that selective evaluation is trivial in Lisp,
> and Maxima. In both cases a single quote marks stuff that
> isn't evaluated.
I actually did know that lisp has this feature. The real question is
how to expose such a feature in a natural way in the Sage (Python)
environment. Using Python has worked out very nice both for the UI
and core library--I don't see this changing anytime soon. And as
beautiful lisp is as a language, it seems even Maxima decided that it
wasn't suited for the front end of a CAS.
> Maxima further marks a distinction between
> so-called noun and verb operators; nouns are formal expressions
> and verbs are callable functions. E.g. integrate(...) is a function
> call and 'integrate(...) is a formal expression. I've omitted some
> details.
This is another good idea to consider, though there are some
drawbacks--it makes tab completion less convenient and in OO
programing the verb/noun distinction is often used to denote mutating/
return new object (though most of our objects are immutable).
This would be much easier to implement (in Python) than a generic
FormalExpression(2+2) that doesn't actually perform the addition.
Though slightly off topic, this is (IMHO) a much more interesting
question to think about. Python executes function arguments before
calling the function, which presents some difficulties. One thing we
could do is preparse this to FormalExpression("2+2") and use the
parser at http://hg.sagemath.org/sage-main/file/69d774a64568/sage/
misc/parser.pyx to get an expression tree. It would only handle a
subset of the Python language, but that's probably sufficient for
nearly all use cases and could be clearly documented. An
evaluate=False option for some things would give a non-preparsed way
of accessing this in some special cases.
> This kind of stuff yanks my chain in a bad way, unfortunately.
> I gather it is more interesting to reinvent the wheel than learn
> how to use existing, unfamiliar wheel technology.
To extend the analogy further, I think a significant portion of the
issue is that the wheel does not have the right hookups for the car,
and the amount of duct tape and hacks to get them working together
has become burdensome and inefficient. Also, Sage is not against
reinventing the wheel if nothing else out there meets our needs. That
being said, I think Maxima will remain a part of Sage for some time
to come, it just won't get fired up every time someone wants to
compute (sqrt(x)+1)^2.
> What makes
> it worse is that there is talk of copying Maple and Mathematica
> notation, which both have all sorts of warts. Blechh.
It's good to see how others do it for inspiration, but blindly
copying is bad. When warts are pointed out, hopefully we can come up
with something better.
> Oh gods, help me! I seem to be turning into RJF. Probably I
> should just butt out of this. It will make no difference to you
> and I will be happier in my ignorance.
No, your input is actually useful, and I don't have to put on a flame
suit every time I see your name. Please continue.
- Robert
> Robert "curmudgeon-in-training" Dodier
:)
Robert Dodier
> On Aug 30, 2008, at 4:46 PM, Robert Dodier wrote:
> > From the direction this discussion has taken I'm guessing that
> > nobody here is aware that selective evaluation is trivial in Lisp,
> > and Maxima. In both cases a single quote marks stuff that
> > isn't evaluated.
> I actually did know that lisp has this feature. The real question is
> how to expose such a feature in a natural way in the Sage (Python)
> environment.
the realm of possibility to develop a superset of Python which has a
modified evaluation policy. Existing programs would act the same
in this hypothetical language, but there could be new constructs
(quoting and evaluating, unevaluated and partially-evaluated
expressions, maybe more) which extend the language.
> Using Python has worked out very nice both for the UI
> and core library--I don't see this changing anytime soon.
it is a much stronger programming language than the existing
Maxima language. There is an implementation of Python in
Lisp, namely CLPython. I have toyed with the idea of using
CLPython as the UI language for Maxima.
> And as beautiful lisp is as a language, it seems even Maxima
> decided that it wasn't suited for the front end of a CAS.
That's much more important than parenthesis or the lack of them.
All the best
Robert Dodier
Ondrej Certik
Ok. I would be really interested what things you don't like on
Mathematica. It seems to me it is also quite lisp like, no?
So what things do they have wrong? So that we can learn from it.
Ondrej
Robert Dodier
> So what things do they have wrong? So that we can learn from it.
* BumpyCaseIsHardToRead
* square brackets for function arguments
* two square brackets for subscripts
* squiggly braces for lists
* sets and matrices not distinguished from lists
* lack of syntax in programming constructs
There's really nothing to recommend any of this.
FWIW
Robert Dodier
Robert Bradshaw
I'm with you on those! The folks at Mathematica have a lot of good
ideas, but I certainly don't see us wanting anything from this list.
- Robert
David Philp
On 02/09/2008, at 6:22, Robert Dodier <robert...@gmail.com> wrote:
> * sets and matrices not distinguished from lists
This is a serious defect in mathematica. It has led to me making
mistakes.
Most of your other objections were matters of taste. (I agree with
most of them but they are mostly things that sage will obviously avoid
so they aren't very instructive.)
I think the most useful thing for this discussion is to concentrate on
the things the 'big four' get right, that sage lacks.
> * lack of syntax in programming constructs
What does this mean?
D
Ondrej Certik
Ah, this, but all of those are fixed by Python. I thought you mean
some design principle. Yes, those are things why I wrote in some other
thread that programming in mathematica is not fun (for me), but the
design of mathematica (at least what I understood so far), I must say,
is fun for me and I want to have it, just in Python.
Ondrej
Robert Dodier
While[a, b] instead of "while a do b" or "while (a) b" or something
like that
Switch[a, x, xx, y, yy, ...] instead of "switch (a) case x : xx, case
y : yy, ..." or something like that
The point in each case is that it helps the reader see the structure
of the
code to separate the arguments by keywords or other syntax elements.
best
Robert Dodier