octave-bug-tracker
[Top][All Lists]
Advanced

[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
tolerance.

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:

  <https://savannah.gnu.org/bugs/?57603>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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