[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #57603] quadv gives wrong results integrating

From: Rik
Subject: [Octave-bug-tracker] [bug #57603] quadv gives wrong results integrating sin^2 or cos^2 on multiple of 8 periods
Date: Thu, 16 Jan 2020 10:57:13 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

Update of bug #57603 (project octave):

                Severity:           4 - Important => 3 - Normal             
                  Status:               Confirmed => In Progress            
             Assigned to:                    None => rik5                   


Follow-up Comment #6:

I took a look at this yesterday and discovered quite a few things that were
undesirable about the implementation.

1) The algorithm always begins by bisecting the interval, which can cause
problems if the integrand is periodic.  I also came up with the same idea as
Olivier in comment #5, that is, Octave should divide the initial integral in
to two unequal regions.  Ideally, the division should be an irrational number
so that no set of integer factors N/D can ever be periodic.  At this point, I
ran some experiments and it appears that Matlab divides the initial integral
in to three separate regions.  The left and right regions are approximately
27% of the absicssa distance (b - a), and the middle region is 46% of (b - a).
 I'm not sure why trisection would be particularly better than bisection, but
it is also easy to implement.

2) The Octave algorithm is not using Richardson extrapolation which makes each
integral interval just a bit more accurate.  For this integral

quadv(@(t)sin(t).^2,0,2.5*pi, 1e-6, true)

The current method requires 217 function evaluations versus just 61 if
extrapolation is used.  That is a tremendous difference and needs to be coded
in to Octave.

3) The algorithm is not correctly working to implement the user's requested

We want to bound Q to +/- tol, and we calculate Q by dividing the region in
two and then calculating q1 and q2 where Q = q1 + q2.  In order to preserve
the user's request, the tolerance needs to halve at each interval.  Then

Q = (q1 +/- tol/2) + (q2 +/- tol/2) = q1 + q2 +/- tol.

4) The tracing output display could be better aligned.

I've made some progress on this already so I've assigned the bug to myself.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]