Explicit variable of integration

[Golam Mortuza Hossain]

Hi,

I am preparing patches that will resolve

http://trac.sagemath.org/sage_trac/ticket/6465

and will also move symbolic integration as a sub-class
of SFunction into new symbolics.

Currently, Sage allows omitting variable of integration for convenience.
However, this convenience comes at a hefty price by making Sage
syntax highly inconsistent. On top of this, it mask genuine typing error
as a valid input.

For example: "integrate(f(x), x, a, )" is treated as "integrate(f(x), x, x, a)"
where user may have wanted to type "integrate(f(x), x, a, b)" but
missed the "b".

Given we are moving to a new settings, I am proposing that we make
integration syntax bit stricter and consistent now. In particular, we allow only
following inputs as valid

(1) integrate( f(x), x)
(2) integrate( f(x), (x,a,b) )
(3) integrate( f(x), x, a, b)

Cheers,
Golam

[William Stein]

I strongly agree.

William

[Nick Alexander]

>> (2) integrate( f(x), (x,a,b) )
>> (3) integrate( f(x), x, a, b)

Let's just choose one. I'm torn, but prefer (3) with a and b optional
variables.

Nick

[Ondrej Certik]

I am for 2), it's consistent with mathematica, e.g. if you have
multiple integration.

Btw sympy also supports all 1), 2) and 3).

Ondrej

[William Stein]

On Tue, Aug 18, 2009 at 11:00 AM, Nick Alexander<ncale...@gmail.com> wrote:
>

Hmm. If I had to choose one of these:

> (1) integrate( f(x), x)

> (2) integrate( f(x), (x,a,b) )
> (3) integrate( f(x), x, a, b)

I would choose only (2) or (1) and get rid of (3)! Why? Simply
because that is far more consistent with plotting (which in turn was
meant to be consistent with Mathematica). I suspect 3 is more like
Maple.

So I prefer (1) and (2).

William

[Golam Mortuza Hossain]

Hi,

Personally, I too prefer (1) and (2) but we need to keep (3) (at least
behind the scene as maxima would return in this form and we may need
to re-use it)

Cheers,
Golam

[Jason Grout]

+1

actually, +however many points I can influence and vote! I've been
wanting this for a very long time.

If we further simplified, then +1 to keeping (1) and (2) and making (3)
at least not encouraged, if not outright dropped or deprecated. The
examples ought to be changed to not use (3) in the very least, I think.

Jason

[Bill Page]

Actually both Maple and Axiom use something called a SegmentBinding. E.g.

(1) -> x=a..b

(1) x= a..b
Type: SegmentBinding(Symbol)

In Axiom the operator .. is sugar for ' segment(a,b)' that returns
something of type 'Segment' and in this case '=' constructs a
'SegmentBinding' from a 'Symbol' and a 'Segment'. The 'segment'
operator is rather like 'range' in Python except it can form symbolic
expressions. A 'SegmentBinding' is rather like '(x,a,b)' except not
quite so raw.

So normally one would write for example:

(2) -> integrate(sin(x),x=a..b)

(2) - cos(b) + cos(a)
Type: Union(f1: OrderedCompletion(Expression(Integer)),...)

Why doesn't Sage support something like this?

Regards,
Bill Page.

[Nick Alexander]

>> (1) integrate( f(x), x)
>> (2) integrate( f(x), (x,a,b) )
>> (3) integrate( f(x), x, a, b)
>

> So I prefer (1) and (2).

Fine by me -- +1 to (1) and (2).

Nick

[Robert Bradshaw]

Same here. I'm not opposed to option (3), but if we're going to cut it
down that'd be the one to go (and certainly the current code is too
lenient and inconsistant).

- Robert

[Fredrik Johansson]

I suggest getting rid of (3) if only to support the following syntax
for multiple integrals without ambiguity:

integrate(f(x,y,z), (x,a,b), (y,c,d), (z,e,f))

Fredrik

[Jason Grout]

Technically, that's unambiguous now, as it's easy to tell the difference
between a tuple (x, a, b) and a number or symbolic variable.

However, I think you're right that it is confusing to students to have
the above notation and (3).

Jason

[Ondrej Certik]

Yeah, in sympy we use 1) to 3) for couple years now and as far as I
know, we never had any complains about it. People coming from Maple
use 3), people coming from mathematica use 1 or 2, so everybody is
happy.

Ondrej

[Fredrik Johansson]

It's ambiguous if you want to support indefinite integrations as well.
Is integrate(expr, x, y, z) a triple integral with respect to x, y, z,
or an integral with respect to x ranging from y to z?

It's also ambiguous to the reader in code where the tuples are passed
as variables rather than written out as literals at the point of the
call.

Fredrik

[rjf]

Let's see, in sage then you have the following syntax.
(x,y) means a list
f(x,y) means a function application
(x+y) means grouping for arithmetic.
RationalField(x) means, uh, sortof "in indeterminate..."
Integer(4) means, uh, set the type? force a coercion?

Are there any other distinct uses of ()?

Mathematica uses
{} for lists
[] for function arguments (in SMP these were called projections)
() for grouping

Maxima uses
(a,b,c) as meaning something like begin a; b; c end
[] for lists and array subscripting
() for grouping and function calls.

So it seems that you have a choice.


However, the Sage choice is kind of confusing.
x //a variable
(x ) // a list of one item or a group consisting of x alone, hence x.
((x)) // a list of one item, grouped alone. Or a list of a list of
one item. Or just x.

That is, if (a+1,a+2) is a list of 2 items, is (a+1) not a list of
one item?

I'm sure there is a simple explanation.

[Ondrej Certik]

yeah, (x) is the same as x, use (x, ) to have a tuple of one element "x".

Ondrej

[Robert Bradshaw]

On Aug 18, 2009, at 9:56 PM, rjf wrote:

> Let's see, in sage then you have the following syntax.
> (x,y) means a list

Technically, a tuple (immutable, where as lists (using [] like
maxima) are mutable).

> f(x,y) means a function application

That's pretty standard in mathematics and programming.

> (x+y) means grouping for arithmetic.

Same here.

> RationalField(x) means, uh, sortof "in indeterminate..."
> Integer(4) means, uh, set the type? force a coercion?

These are function calls, just like f(x,y) above. (In Python, class
constructors are just function calls.)

> Are there any other distinct uses of ()?

Smilies :). Oh, you meant in Sage. Not that I can think of.

- Robert

[Alex Ghitza]

On Wed, Aug 19, 2009 at 2:56 PM, rjf<fat...@gmail.com> wrote:
>
> Let's see, in sage then you have the following syntax.
> (x,y)   means a list

Not at all. (x, y) is a tuple. [x, y] is a list.

> f(x,y)  means a function application
> (x+y) means grouping for arithmetic.
> RationalField(x)  means, uh, sortof  "in indeterminate..."
> Integer(4)  means, uh, set the type? force a coercion?
>
> Are there any other distinct uses of ()?
>
>

> However, the Sage choice is kind of confusing.
> x  //a variable
> (x )  // a list of one item or a group consisting of x alone, hence x.
> ((x))  // a list of one item, grouped alone.  Or a list of a list of
> one item.  Or just x.
>
> That is, if (a+1,a+2)  is a list of 2 items, is (a+1) not a list of
> one item?
>
> I'm sure there is a simple explanation.

Yes, the explanation is that you're mixing up ()'s and []'s. You
*could* actually try out the above in Sage to see whether you're right
or not, instead of making it up:

sage: a = 1; a
1
sage: type(a)
<type 'sage.rings.integer.Integer'>
sage: a = (1); a
1
sage: type(a)
<type 'sage.rings.integer.Integer'>
sage: a = ((1)); a
1
sage: type(a)
<type 'sage.rings.integer.Integer'>
sage: a = (((((((1))))))); a
1

So in the absence of a function in front of (), and in the absence of
commas inside (), it's what you call "grouping for arithmetic".

Now for lists:

sage: a = [1]; a
[1]
sage: type(a)
<type 'list'>
sage: a[0]
1
sage: type(a[0])
<type 'sage.rings.integer.Integer'>
sage: a = [[1]]; a
[[1]]
sage: type(a)
<type 'list'>
sage: a[0]
[1]
sage: type(a[0])
<type 'list'>
sage: a[0][0]
1
sage: type(a[0][0])
<type 'sage.rings.integer.Integer'>

These seem unambiguous to me. If you're after the tuple with one
element 1, a = (1,) does the trick, as Ondrej pointed out.


Best,
Alex




> >
>

























--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/

[Golam Mortuza Hossain]

Hi,

On Tue, Aug 18, 2009 at 8:02 PM, Jason Grout<jason...@creativetrax.com> wrote:
>
> Fredrik Johansson wrote:

>>> Given we are moving to a new settings, I am proposing that we make
>>> integration syntax bit stricter and consistent now. In particular, we allow only
>>> following inputs as valid
>>>
>>> (1) integrate( f(x), x)
>>> (2) integrate( f(x), (x,a,b) )
>>> (3) integrate( f(x), x, a, b)
>>
>> I suggest getting rid of (3) if only to support the following syntax
>> for multiple integrals without ambiguity:
>>
>> integrate(f(x,y,z), (x,a,b), (y,c,d), (z,e,f))
>>
>
> Technically, that's unambiguous now, as it's easy to tell the difference
> between a tuple (x, a, b) and a number or symbolic variable.
>
> However, I think you're right that it is confusing to students to have
> the above notation and (3).

I agree that if we want to support multiple integrals in future then
we should get rid of (3).

There are some technical issues for implementing (2) in new symbolics
directly. As it stands, tuple can't be coerce to SR of pynac.
-------
sage: x,a,b = var('x,a,b')
sage: f = function('f')
sage: f(x, (x,a,b) )
.....
TypeError: cannot coerce arguments: no canonical coercion from <type
'tuple'> to Symbolic Ring
-----

I know a quick-hack that bypasses this by using a dummy function
say
-------------
sage: symbolic_tuple = function('')

sage: xab = symbolic_tuple(x,a,b)
sage: f(x, xab)
f(x, (x, a, b))
-------------

I guess, there may be a better solution.

Burcin, do you have any comments/suggestions on this?

Thanks
Golam

[Golam Mortuza Hossain]

Hi,

> http://trac.sagemath.org/sage_trac/ticket/6465

Patches are up and reviews are welcome.

While (1) and (2) syntaxes are encouraged, (3) will
remain valid until we sort out the coersion issue
and update all doctests, tutorial etc. BTW, I did update
some of the doctests including the docstrings that you get
via "integrate?"

Cheers,
Golam

[Robert Bradshaw]

Sounds like we should throw a deprecation warning on it.

- Robert

[Jason Grout]

See also the very old tickets that requested such changes:

http://trac.sagemath.org/sage_trac/ticket/1221

http://trac.sagemath.org/sage_trac/ticket/2787

I noticed the other day that integrate(sin(x), (x, 0, pi)) seemed to
just hang. There was no error--it just hung.

Jason

[William Stein]

That is WEIRD given that maxima doesn't go interactive or anything and
works fine:

sage: maxima.eval('integrate(sin(x),x,0,%pi)')
'2'
sage: sage.calculus.calculus.maxima.eval('integrate(sin(x),x,0,%pi)')
'2'
sage: integrate(sin(x),(x,0,pi))
[hang forever]

William

[kcrisman]

I know I'm losing this one, but for what it's worth, I think that not
only should (1), (2), and (3) be supported, but that integrate(f)
should do what is obvious where the variable is unambiguous. :)

>
> > While (1) and (2) syntaxes are encouraged, (3) will
> > remain valid until we sort out the coersion issue
> > and update all doctests, tutorial etc. BTW, I did update
> > some of the doctests including the docstrings that you get
> > via "integrate?"
>
> Sounds like we should throw a deprecation warning on it.
>

Yes, this would definitely require it. There should conceivably be a
check for whether there are x, a, and b, and if a and b are both
numeric types, allowing (3) indefinitely in that case (as opposed to
integrate(f,x,a,b) where a and b are symbolic endpoints).

On the plus side, FJ is correct that it is impossible to have multiple
integration in an unambiguous way without removing (3) eventually (so
as to allow integrate(f,x,y,x) and the like). My preference would be
to require instead integrate(f,(x,),(y,),(x,)) or integrate(f,[x],[y],
[z]), but I think that those would not prove popular. In any case, it
should be very easy to get multiple integration working with those,
and certainly with integrate(f,(x,a,b),(y,c,d)) with the current
framework, as they pretty much work as expected if you next integrates
(I prototyped this a while ago but discarded it due to the tickets
Jason mentions not being resolved).

Your work on symbolics is impressive and valuable, Golam - keep it up!

- kcrisman

[Robert Bradshaw]

On Aug 25, 2009, at 5:44 PM, kcrisman wrote:

>
> I know I'm losing this one, but for what it's worth, I think that not
> only should (1), (2), and (3) be supported, but that integrate(f)
> should do what is obvious where the variable is unambiguous. :)
>

sage: var('x,y')
(x, y)
sage: f = -x-y
sage: integrate(f)
-1/2*x^2 - x*y
sage: integrate(f+x) # unambiguous?
-1/2*y^2
sage: integrate(f+y) # unambiguous?
-1/2*x^2
sage: integrate(f) + integrate(x)
-x*y
sage: integrate(f) + integrate(y)
-1/2*x^2 - x*y + 1/2*y^2

>
>>
>>> While (1) and (2) syntaxes are encouraged, (3) will
>>> remain valid until we sort out the coersion issue
>>> and update all doctests, tutorial etc. BTW, I did update
>>> some of the doctests including the docstrings that you get
>>> via "integrate?"
>>
>> Sounds like we should throw a deprecation warning on it.
>>
>
> Yes, this would definitely require it. There should conceivably be a
> check for whether there are x, a, and b, and if a and b are both
> numeric types, allowing (3) indefinitely in that case (as opposed to
> integrate(f,x,a,b) where a and b are symbolic endpoints).

I'm -1 to having a different meaning based on whether or not
something is "numeric." For example,

integrate(f, x, a, b).subs(a=1, b=2) != integrate(f, x, 1, 2)

bothers me.

> On the plus side, FJ is correct that it is impossible to have multiple
> integration in an unambiguous way without removing (3) eventually (so
> as to allow integrate(f,x,y,x) and the like). My preference would be
> to require instead integrate(f,(x,),(y,),(x,)) or integrate(f,[x],[y],
> [z]), but I think that those would not prove popular.

Yes, I think we should support this as well, at least the tuple version.

- Robert

[Golam Mortuza Hossain]

Hi,

On Tue, Aug 25, 2009 at 8:09 PM, William Stein<wst...@gmail.com> wrote:
>
> On Tue, Aug 25, 2009 at 3:44 PM, Jason Grout<jason...@creativetrax.com> wrote:
>> I noticed the other day that integrate(sin(x), (x, 0, pi)) seemed to
>> just hang.  There was no error--it just hung.
>
> That is WEIRD given that maxima doesn't go interactive or anything and
> works fine:

I guess, above format for providing limits is not supported in current
"integrate". Integrate hangs for generic "integrate(f(x), (x, a, b))".

It seems that it is treating entire "(x,a,b)" as a variable of integration!
Above issue should not be there with the posted patches.

Cheers,
Golam

[Golam Mortuza Hossain]

Hi,

On Tue, Aug 25, 2009 at 9:44 PM, kcrisman<kcri...@gmail.com> wrote:
>> > While (1) and (2) syntaxes are encouraged, (3) will
>> > remain valid until we sort out the coersion issue
>> > and update all doctests, tutorial etc. BTW, I did update
>> > some of the doctests including the docstrings that you get
>> > via "integrate?"
>>
>> Sounds like we should throw a deprecation warning on it.
>>
>
> Yes, this would definitely require it.

I agree. Personally, I would prefer to wait until we have
a proper coersion model from tuple/list to SR. So that
we can enforce it within a definite time-frame after issuing
the warning.

> Your work on symbolics is impressive and valuable, Golam - keep it up!

Thanks! Frankly, I am just trying to strengthen the tiny corner of Sage
that are needed for my own work.

Cheers,
Golam

[Robert Bradshaw]

On Wed, 26 Aug 2009, Golam Mortuza Hossain wrote:

>
> Hi,
>
> On Tue, Aug 25, 2009 at 9:44 PM, kcrisman<kcri...@gmail.com> wrote:
>>>> While (1) and (2) syntaxes are encouraged, (3) will
>>>> remain valid until we sort out the coersion issue
>>>> and update all doctests, tutorial etc. BTW, I did update
>>>> some of the doctests including the docstrings that you get
>>>> via "integrate?"
>>>
>>> Sounds like we should throw a deprecation warning on it.
>>>
>>
>> Yes, this would definitely require it.
>
> I agree. Personally, I would prefer to wait until we have
> a proper coersion model from tuple/list to SR. So that
> we can enforce it within a definite time-frame after issuing
> the warning.

I don't think coercion is the way to go about it... what does x + (2,"yo")
mean? Also, we want to only accept 1 or 3 items in this case, right?

>> Your work on symbolics is impressive and valuable, Golam - keep it up!
>
> Thanks! Frankly, I am just trying to strengthen the tiny corner of Sage
> that are needed for my own work.

And that's exactly how the strong parts of Sage got to where they are.
Thanks!

- Robert

[kcrisman]

> sage: var('x,y')
> (x, y)
> sage: f = -x-y
> sage: integrate(f)
> -1/2*x^2 - x*y
> sage: integrate(f+x) # unambiguous?
> -1/2*y^2
> sage: integrate(f+y) # unambiguous?
> -1/2*x^2
> sage: integrate(f) + integrate(x)
> -x*y
> sage: integrate(f) + integrate(y)
> -1/2*x^2 - x*y + 1/2*y^2
>

I meant single-variable. No, none of these are unambiguous.

>
>
> >>> While (1) and (2) syntaxes are encouraged, (3) will
> >>> remain valid until we sort out the coersion issue
> >>> and update all doctests, tutorial etc. BTW, I did update
> >>> some of the doctests including the docstrings that you get
> >>> via "integrate?"
>
> >> Sounds like we should throw a deprecation warning on it.
>
> > Yes, this would definitely require it. There should conceivably be a
> > check for whether there are x, a, and b, and if a and b are both
> > numeric types, allowing (3) indefinitely in that case (as opposed to
> > integrate(f,x,a,b) where a and b are symbolic endpoints).
>
> I'm -1 to having a different meaning based on whether or not
> something is "numeric." For example,
>
> integrate(f, x, a, b).subs(a=1, b=2) != integrate(f, x, 1, 2)
>
> bothers me.
>

Hmm, I didn't think about that. (Since I don't use subs much.)

[Robert Bradshaw]

On Wed, 26 Aug 2009, kcrisman wrote:

>> sage: var('x,y')
>> (x, y)
>> sage: f = -x-y
>> sage: integrate(f)
>> -1/2*x^2 - x*y
>> sage: integrate(f+x) # unambiguous?
>> -1/2*y^2
>> sage: integrate(f+y) # unambiguous?
>> -1/2*x^2
>> sage: integrate(f) + integrate(x)
>> -x*y
>> sage: integrate(f) + integrate(y)
>> -1/2*x^2 - x*y + 1/2*y^2
>>
>
> I meant single-variable. No, none of these are unambiguous.

"f+x" and "f+y" are "single-variable." (Note the definition of f.) This
has bitten me before.

- Robert