Riemann sums , trapezoid mode

[Gagan Sekhon]

Currently, both riemann_sum and riemann_sum_integral_approximation
does not support trapezoid mode. But instead there are separate
function which computes these for trapezoid mode .

I am added this mode to both riemann_sum and
riemann_sum_integral_approximation and wanted to take a vote on how
many people think trapezoid function should stay, should be deprecated
or completely deleted

Gagan

[Geoff Ehrman]

+1 for deprecate.

--
To post to this group, send an email to sage-...@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[Jason Grout]

At first, my vote was to deprecate, then delete the function. However,
I think some people might argue that a trapezoid function was not a
riemann sum since it is not of the form (width)*(f(point)) like the
left, right, and midpoint sums. So maybe a new function that absorbs
all of these called approximate_integral or something is in order?

Jason

[mhampton]

It is a Riemann sum with a non-constant width. The usual definition
allows that as long as the widths of each interval have a limit of
zero.

-Marshall

[Francois Maltey]

Hello,
(and copy to Sage-edu)

>>> Currently, both riemann_sum and riemann_sum_integral_approximation
>>> does not support trapezoid mode. But instead there are separate
>>> function which computes these for trapezoid mode .
>>>
>>> I am added this mode to both riemann_sum and
>>> riemann_sum_integral_approximation and wanted to take a vote on how
>>> many people think trapezoid function should stay, should be deprecated

>>> or completely deleted.
>>>
I prefer very few functions with an optional parameter.

In this case, I vote for an only one (if possible) function
numerical_integral with a new option in
the parameter algorithm (or method)

algorithm="Riemann", algorithm="trapezoid" or algorithm="Simpson",
algorithm="GaussLegendre"...

I don't find any riemann_sum_integral_approximation nor rieman_sum
functions in my 4.6 Sage.

F.

[kcrisman]

These are very old methods that David Joyner put in Sage when there
was virtually nothing for calculus - particularly pedagogical examples
- in Sage. I believe they only work with the Piecewise class, and
return Piecewise functions (which can't do much). In
sage.functions.piecewise.py :

- David Joyner (2006-09): added __eq__, extend_by_zero_to, unextend,
convolution, trapezoid, trapezoid_integral_approximation,
riemann_sum, riemann_sum_integral_approximation, tangent_line fixed
bugs in __mul__, __add__

You'll also notice that the examples in the doctest use polynomial
rings - because the "symbolic ring" didn't yet exist at that point.
Incidentally, this isn't a slam on the Piecewise stuff - it's just
recognition that massive work by people to get Maxima and Pynac/Ginac
into Sage properly has vastly improved its capabilities.

So my opinion is that we should leave those alone for now. The
Piecewise class needs a massive rewrite, because we really need good
piecewise support; unfortunately those who have the expertise don't
have the motivation and time, and those who have the motivation and
time don't have the expertise to do so. This would be a great project
for someone wanting to make a lasting impact - giving

That doesn't mean we shouldn't have some good pedagogically motivated
RS methods for any old functions, but that would be a somewhat bigger
job (though certainly tractable for a single ticket). Probably
http://wiki.sagemath.org/interact/calculus#Numericalintegralswithvariousrules
would be good inspiration for that.

@Marshall - I suppose you could write an equivalent RS for trapezoid,
yes, but I haven't ever seen a treatment which talks about it that
way. Simpson is the same, in my view.

- kcrisman

[Dima Pasechnik]

On Jan 12, 2:09 pm, mhampton <hampto...@gmail.com> wrote:
> It is a Riemann sum with a non-constant width.  

trapezoid rule is what you get if you take the average of the left-
point and the right-point ones.
(for an obvious geometric reason)

I don't see why width is relevant here.

[Robert Bradshaw]

On Mon, Jan 24, 2011 at 10:58 PM, Dima Pasechnik <dim...@gmail.com> wrote:
>
>
> On Jan 12, 2:09 pm, mhampton <hampto...@gmail.com> wrote:
>> It is a Riemann sum with a non-constant width.
> trapezoid rule is what you get if you take  the average of the left-
> point and the right-point ones.
> (for an obvious geometric reason)
>
> I don't see why width is relevant here.

A Riemann sum is a sum of areas of rectangles (equivalently, a
weighted sum of evaluations). The trapezoid rule is equivalent to
taking rectangles of half the width, alternating taking the left and
right endpoints as the heights. (Or, again equivalently, letting all
the "middle" rectangles be twice the width of the two side ones.)

>> The usual definition
>> allows that as long as the widths of each interval have a limit of
>> zero.
>>
>> -Marshall
>>
>> On Jan 11, 9:51 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>>
>>
>>
>> > On 1/11/11 6:06 PM,GaganSekhon wrote:
>>
>> > > Currently, both riemann_sum and riemann_sum_integral_approximation
>> > > does not support trapezoid mode. But instead there are separate
>> > > function which computes these for trapezoid mode .
>>
>> > > I am added this mode to both riemann_sum and
>> > > riemann_sum_integral_approximation and wanted to take a vote on how
>> > > many people think trapezoid function should stay, should be deprecated
>> > > or completely deleted
>>
>> > At first, my vote was to deprecate, then delete the function.  However,
>> > I think some people might argue that a trapezoid function was not a
>> > riemann sum since it is not of the form (width)*(f(point)) like the
>> > left, right, and midpoint sums.  So maybe a new function that absorbs
>> > all of these called approximate_integral or something is in order?
>>
>> > Jason
>