bugGNU Octave - Bugs: bug #52074, Missing integration functions...

 
 

bug #52074: Missing integration functions integral2, integral3

Submitted by:  Nicholas Jankowski <nrjank>
Submitted on:  Wed 20 Sep 2017 05:48:16 PM UTC  
 
Category: Octave FunctionSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Feature Request
Status: FixedAssigned to: None
Originator Name: Nicholas R. JankowskiOpen/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 16 Oct 2017 07:10:08 PM UTC, comment #29:

I reviewed and checked in the changes here http://hg.savannah.gnu.org/hgweb/octave/rev/2e64bed0bb3a.

For starters, the files were encoded with DOS line feeds so I had to change that. Also, tabs were occasionally used which expanded oddly on my computer so I replaced all tabs with spaces per Octave coding convention. For some reason, the Copyright statement at the beginning of the file was also not the verbatim text that we use so I replaced that as well.

I also did some more useful improvements. I added some examples showing how to use the quadrature routines with constants and with function handles as limits. I also made the input validation stricter. It was previously only checking for scalar limits of integration, but really it needs to be a real number, not a scalar cell array for example. I also expanded the BIST tests significantly to verify every call to error() or warning() in the code.

Marking bug as fixed and closing report.

Rik <rik5>
Project Administrator
Mon 16 Oct 2017 10:01:20 AM UTC, comment #28:

@nrjank
I actually prefer the G7K15 rule as it allows the edge singularity weakening transforms to be included by default. If we used a G3K7 rule, the order of the rule would be reduced by 1 due to the transform with a G3 rule only capable of accurately relatively low order polynominals, or alternatively many more fucntion calls would be needed. The G3K7 rule will only be better for relatively simple integrands.

David

David Bateman <dbateman>
Project Member
Sat 14 Oct 2017 10:52:01 PM UTC, comment #27:

last thing, really.

For David and any others who have to wait on a new version of the Windows build to use these functions because they call the updated quadcc, below is a quadcc.m wrapper that you can put in the working folder to 'fake' having a version that passes both abstol and reltol. obviously it will not follow the expected tolerance behavior, but otherwise things will run.

Nicholas Jankowski <nrjank>
Sat 14 Oct 2017 10:43:36 PM UTC, comment #26:

whoops. whitespace in the commit message is always messy and I forgot to clean up. Tidied version here.

(file #42154)

Nicholas Jankowski <nrjank>
Sat 14 Oct 2017 10:41:18 PM UTC, comment #25:

ok. i think we have it. made some very minor edits. they pass all tests on my machine, but maybe could use a few more. mostly whitespace-type edits. made the multi-line is-single checks a single command so it would shortcut if any early ones hit. This is some good work David.

Note I also took a few minutes looking for a G3K7 quadrature set, but didn't find any. found one non-free generating function but nothing to verify it against. I think sticking with G7K15 like quadgk is fine unless anyone else objects. Also, i saw your default max iterations was 5000. mathwork's public doc shows they use 2000. I don't think that's really a compatibility concern, so left it at 5000. easy change if anyone else thinks otherwise.

(file #42150, file #42151, file #42152, file #42153)

Nicholas Jankowski <nrjank>
Thu 12 Oct 2017 06:14:36 PM UTC, comment #24:

Sorry I've been away from this with real life. I'll let Nicholas complete his review and then add these functions to the Octave Mercurial repository this weekend.

Rik <rik5>
Project Administrator
Thu 12 Oct 2017 09:52:29 AM UTC, comment #23:

Note that quad2d requires finite boundaries, which seems to be what matlab also requires. I didn't update the help text of quad2d when copying it from integral2 for this or add a test to ensure finite boundaries in the code. We could use a change of variable like

to allow quad2d to be used on infinite boundaries, but there are at least 9 different possible sub cases to treat of different combiminations of infinite boundaries. I suggest leaving quad2d as only functional with finite boundaries, adding a test to quad2d to ensure this, and leaving integral2 to force the use of the iterated method for infinite boundaries. If a user really wants to use quad2d with infinite boundaries they can deal with the variable subsitution themselves.

D.

David Bateman <dbateman>
Project Member
Tue 10 Oct 2017 11:44:03 PM UTC, comment #22:

Wow, great work Dave. I'll try to work up a patch and verify tests in the next day or so.

Nicholas Jankowski <nrjank>
Tue 10 Oct 2017 03:49:40 PM UTC, comment #21:

Grrr, I found another minor error in quad2d and updated it and fixed the issue in comment #20. Uploaded in the attached zip file

D.

(file #42114)

David Bateman <dbateman>
Project Member
Tue 10 Oct 2017 03:37:19 PM UTC, comment #20:

BTW the integral2 and integral3 functions I uploaded have the calls to quadcc that allow absolute and relative tolerances commented out and replaced with a call that allows only one of these. So before uploading to octave this should be fixed

D.

David Bateman <dbateman>
Project Member
Tue 10 Oct 2017 03:20:16 PM UTC, comment #19:

Nicolas,

As discussed offline, it would be good to have an implementation of quad2d. In fact the tiled code integral2 is the code needed for the quad2d function. So it would be a good idea to split this code out into a seperate quad2d function. With the attached files I've done this and made a couple of other changes

  • Added the edge singularity weakening transforms to the quad2d and make it the default, as is the case for matlabs quad2d function. Though Shampine's TwoD function by default didn't use these transforms. As we're using a higher order Gauss-Kronrod rule than Shampine, the order reduction of the rule imposed by the transform will cost little in terms of iterations, so its better to leave it on as the default
  • Added the 'FailurePlot' option. This option is also present in the matlab version and allows the areas that need refinement in unconverged quadratures to be plotted.
  • Increased the local tolerance needed for each region. I was off by 4 in my original code as I forgot to divide the local tolerance after splitting the zone under consideration into 4 zones. Also Shampine suggests that the local tolerance should be lower than the global tolerance to avoid problems. He suggested a factor of 8. So I've effectivement increased the local tolerance by a factor of 32.
  • removed the test for "vecorized" equals true, as it doesn't create an error, but rather bizarre results due to the matrix-matrix product used in the kernel of the integral
  • Added the integral3 function as a quadcc over the equivalent of an integral2 function call.

The functions quad2d, integral2 and integral3 are attached.

(file #42111, file #42112, file #42113)

David Bateman <dbateman>
Project Member
Sun 08 Oct 2017 05:46:03 AM UTC, comment #18:

Ok, this is pretty good I think. I've done a bit of editing on your version to make the few changes/bug fixes match the Comment #16 version. So now we have a functioning integral2 that I believe is fully compatible.

I think the next steps we had discussed outside of the bug report would be to do a similar update to integral3. enable functional limits for both the 2nd and 3rd dimension, and implement the Method option so it could basically call the new integral2("tiled") method, eliminating the triplequad dependence just like we had to do with dblquad.

Another idea is to just pull the "tiled_integral2" subfunction out and name as quad2d, modifying as needed to enable that currently missing function.

integral2 function attached with patch to update it to it's current form.

(file #42086, file #42087)

Nicholas Jankowski <nrjank>
Fri 29 Sep 2017 10:13:11 PM UTC, comment #17:

Nicholas,

As discussed offline, I've taken a couple of hours to completely rewrite the tiled code from scratch rather than cpnvert it from the R code. It was relatively straight forward to do so, as the core of the Shampine paper is just a tensor product of a Guass-Kronrod rule.

There are a number of differences from the original R code

  • I haven't included edge singularity weakening transforms
  • I couldn't find a public source of the abcissa et weights of the G3,K7 Guass-Kronrod rule proposed by Shampine, so I've instead used a G7,G15 rule
  • Because I used a much much precise rule, I chose not to calculate 4 integrands at once as Shampine suggests, but one at a time. This makes the code clearer to me
  • I used a struct array to store the active list of tiles to treat including the sub integrands and errors
  • I based the acceptance tests on what is used in quadgk

However, I didn't refer to your latest proposed code and so my code probably needs to be gone over again. Hopefully, this resolves the issues with my originally proposed tiled code as ported from R.

David

(file #42009)

David Bateman <dbateman>
Project Member
Fri 29 Sep 2017 01:37:13 PM UTC, comment #16:

I've attached a trimmed version of integral2. It leaves in the functional y limits and I chose to document the 'vectorized' option but it trims out the tiled functionality for now until some implementation issues are taken care of. Additionally, there were a few minor errors this corrects (the issingular calculation, a missing bracket, etc.) a few appearance/style cleanups and docstring as well. I used a quadcc wrapper so i could test the function without having the new quadcc, but someone should verify these tests before approving the patch. (both patch and function attached.)

(file #41980, file #41981)

Nicholas Jankowski <nrjank>
Thu 28 Sep 2017 07:16:21 PM UTC, comment #15:

The iterated method is essential dblquad, so what you did isn’t quick and dirty. Just incomplete.

Another issue is that the iterated method should handle infinite boundaries and I don’t believe that this was tested

D.

David Bateman <dbateman>
Project Member
Thu 28 Sep 2017 06:54:32 PM UTC, comment #14:

masking was only thought of as an option because we were just implementing a 'quick' wrapper to satisfy compatibility. It was always my opinion that an efficient integrator would require avoiding dblquad and triplequad and re-coding the integral function directly. I expect that will still be required to get a fully compatible version of integral if you want to take a look at that. (bug #42037)

If your integral2 is all m-code I can give it a once over.

Nicholas Jankowski <nrjank>
Thu 28 Sep 2017 06:53:23 PM UTC, comment #13:

@David: Thanks for this work. I also eyed up changing the order of integration in dblquad, but I had other non-Octave priorities so I just left it alone. I think I'll have some time this weekend to review.

Rik <rik5>
Project Administrator
Thu 28 Sep 2017 06:41:35 PM UTC, comment #12:

Why mask at all ? You just need to invert the order of the integration in dblquad and adapt the inner integrand to take into account the parametric y boundaries, which is pretty easy. Basically as integral2 deals with the argument checking, a couple of lines imported from dblquad is enough for this.

As for the 'tiled' version of the code, the Matlab version of this code uses the TwoD function developed by Shampine and available at

http://faculty.smu.edu/shampine/current.html

The license of Shampine is not clear though the code contains a clear copyright line. So read the article but not the code!!!

However, the R developers have reimplemented the intaregal2 and integral3 functions based on Shampine's work in the "pracma" package available at

https://cran.r-project.org/web/packages/pracma/index.html

under a GPLv3 license. Converting the R code to Octave seems relatively trivial, so see the attached function that I converted. It does the following

  • Adds the parametric 'integrated' y boundaries
  • Ports the R code to Octave
  • Tries to auto detect the edge singularities in the 'tiled' method and restarts the integration with singularity weakening transforms
  • Adds the possibility to use unvectorized functions by wrapping them in array fun

As an example of the performance of the new method

This seems to me to be better version of integral2 and certainly more complete. Though as I've done very little Octave coding for a number of years, having someone read over the code and test it is probably a good idea. I also took very little care with the Octave coding guidelines, so Rik go ahead and rip my code apart ;-)

I also don't have a mercurial copy of Octave on my machine, so someone else will have to work this up as a changeset.

D.

(file #41949)

David Bateman <dbateman>
Project Member
Tue 26 Sep 2017 04:33:40 PM UTC, comment #11:

both this and the integral bug both had 'FIXME's left to try to achieve full compatibility. we closed that other bug report, but up to you if you think that's worth leaving this one open.

Masking is definitely not the best way to do this, but I was thinking it's the fastest way to get a compatible implementation in place.

any other option I think would have to avoid being a wrapper to dblquad and recode a better 2D integrator. that should let you just modify the limits of integration in one dimension according to an input function, rather than integrating over a lot of deadspace.

Nicholas Jankowski <nrjank>
Tue 26 Sep 2017 03:49:14 PM UTC, comment #10:

I reviewed the patches, made some changes, and checked it all in here (http://hg.savannah.gnu.org/hgweb/octave/rev/c723faa56ab4).

We can close this report now, or leave it open for other issues on integral2 and integral3.

One remaining issue is the fact that integral2,3 can accept function handles for the limits of integration. I'm not sure this is the optimal solution in terms of computational efficiency, but one solution would be to apply a masking function to the integrand itself. As an example, see the help documentation for integral2 (http://www.mathworks.com/help/matlab/ref/integral2.html).

There they perform a double integral of

over the region 0 <= x <= 1, 0 <= y <= 1 - x.

The answer they get for this integral is 0.2854.

If I do the same thing in Octave, which integrates over the rectangular region, I obviously get a larger answer.

But now let me define a masking function fmask which is 0 outside of the area of integration, and one inside.

The masking function is implicitly vectorized so if x is a series of points, fmask will be a series of mask values.

The new integrand with mask applied is

The dot operator is used so I am always multiplying by either 0 or 1.

Finally,

This might be a quick way to add support for limits which are function handles. Although, my guess is we would still like to find a way to just integrate over the relevant area beause using the masking function is about 6X slower than integrating over the rectangular region. Although, it is only 4X slower if I incorporate the fmask definition directly into the definition of a new function. That suggests that Octave's composition of functions is slow.

To be a completely generalizable, the mask function probably needs to be

Anyways, this is just an idea.

Rik <rik5>
Project Administrator
Sat 23 Sep 2017 10:18:04 PM UTC, comment #9:

i haven't seen any particular criticism of the approach yet.

in the meantime i worked up a version of the patch that implements integral2 and 3 calling a modified quadcc, assuming the planned calling form will be:

quadcc(f,a,b,[abstol reltol])

So this will need to be applied after that patch. this also updates docstrings in other m-file quad functions. (will still need to update @seealso in quad and quadcc)

at the moment since I'm not set up here to compile from source I can't run tests against a modified quadcc, so the tests might need to be adjusted.

(file #41884)

Nicholas Jankowski <nrjank>
Fri 22 Sep 2017 05:35:52 PM UTC, comment #8:

The patch for quadcc wasn't hard at all. I've written something to the Octave Maintainer's list to gather opinions about making a non-backwards compatible change to the quadcc interface. See http://octave.1599824.n4.nabble.com/Implementing-AbsTol-for-quadcc-td4684992.html.

Rik <rik5>
Project Administrator
Fri 22 Sep 2017 02:44:51 AM UTC, comment #7:

Well, MATLAB has no quadcc implementation, so there's no compatibility concern in changing it, just a backwards compatibility concern if we break anything else that used it. Looking at a few other implementations most seem to mention a relative tolerance value, so maybe that was in the original algorithm.

Don't have it in front if me right now but does dblquad do a scalar check on tol? If not, then what you say could work. Abs and rel tols get passed through dblquad as a 2 elem vector down to quadcc, and no need for quadgk calls at all.

It may be worth considering having quadcc deviate from the others and still have reltol first. That would maintain backward compatibility, and I guess the source code intent. Also, I looked at matlabs dblquad doc and it just says tolerance, not rel or abs. So, dblquad behavior would also just be a backward compatibility preference. Don't know how concerning those are.

I did code up a version that works as per comment #5, but didn't work up a patch yet. Will wait and see what you find with quadcc.

Nicholas Jankowski <nrjank>
Fri 22 Sep 2017 12:21:28 AM UTC, comment #6:

Let me see if I can modify quadcc to take an abstol parameter. I looked very briefly and it looked feasible. If it is, I would like to follow the example of quad which is documented as

First, I think quadcc should default, like all the other quad routines, to use AbsTol if only a single tolerance value is given. By accepting a vector quadcc can check for a scalar TOL and set AbsTol or a 2-element vector and set AbsTol and RelTol. We can keep the sensible default of 1e-6 for RelTol if it is left unspecified.

Rik <rik5>
Project Administrator
Thu 21 Sep 2017 08:23:03 PM UTC, comment #5:

ahhh right. I see that. well, that throws out most of the previous convoluted tolerance stuff.

from quadcc's help, it seems you're right (it's not an m-file, so I didn't peek inside to make sure the help text is right):

I guess I was misled by the statement in dblquad:

Looking at dblquad code it seems to just pass tol straight to the called integrator. So if left unspecified that will be quadcc and it will be a relative tolerance. if specified as quadgk, quadl, or quadv, it will be passed as an absolute tolerance, so quadcc is unique in that regard. quadgk also assumes a default reltol, so even when dblquad is called for quadgk with an abstol, a reltol that can't be modified is being checked as well. Quadgk is the only one that does a composite convergence check, using rel and abs to satisfy

assuming it follows matlab's convention.

my guess is matlab just wrote an array-valued version of quadgk, called it 'integral', and are basing integral2 and 3 on it. I'm beginning to see why.

OK.. so now what. the point of the wrappers is to provide a compatible script. integral2 and 3 are supposed to be able to take both (simultaneously) abstol and reltol. the only integrator that takes both is quadgk, but dbl/triplequad doesn't give us access to both.

1 - seems we should edit the help text on dblquad to clarify that the specified tolerance is not necessarily an absolute tolerance, and other tolerances may be at work under the hood depending on integrator called.

2 - I can rewrite int2 and 3 so that it will take either an abstol OR a reltol. if it's a reltol, we call quadcc. if it's an abstol, we call quadgk and need to also note that a default reltol is being applied as well. at least quadgk should autoadjust that for double/single.

I'd say that's about as good as a wrapper will get until someone puts together a better 1d integral, or forgets dblquad and just implements a 2d integrator calling quadgk directly. maybe that would have been faster.

Nicholas Jankowski <nrjank>
Thu 21 Sep 2017 06:16:07 PM UTC, comment #4:

That was fast work. I had a question though, quadcc was not favored because it supposedly doesn't implement reltol, but according to the help text quadcc implements reltol, but not abstol.

In general, unless the integrand is very small, the relative tolerance of

becomes the stopping criteria. Thus, it might not be that disadvantageous to ues quadcc.

Rik <rik5>
Project Administrator
Thu 21 Sep 2017 05:46:51 PM UTC, comment #3:

ok, attached are draft implementations of integral2 and integral3 and a patch that adds them both plus modifies the other associated supporting files.

this basically puts in place the thoughts I listed comment #2, and it's at least a functional compatibility fix. by no means is it optimal.

It calls quadgk by default, and allows turning off reltol. calling quadgk instead of quadcc does impact integration accuracy. it's going to result in a lot of integration accuracy warnings. I made the BISTs and limits specifically to avoid those warnings. It wouldn't be difficult to throw out the RelTol = off hack if we'd rather stick with quadcc and only abstol.

integral3 is nearly identical to integral2, with the same implementation issues.

(file #41856, file #41857, file #41858)

Nicholas Jankowski <nrjank>
Thu 21 Sep 2017 03:09:18 PM UTC, comment #2:

the wrapper could call quadgk instead of the default quadcc. while we couldn't pass a desired reltol to it, quadgk would by default attempt to satisfy the default reltol (1e-6 or 1e-4 for single) in addition to any specified abstol (or the default if unspecified 1e-10, 1e-5 for single)

for compatibility: integral2 normally would impose a default of both abstol and reltol. if i do that, there is no way for the user to override or change the reltol.

perhaps I have it call quadgk by default, so that it imposes the correct default tolerances. abstol can be adjusted as normal. if reltol is called, i warn that it cannot be adjusted. but I can offer a reltol="off" option, and I would switch the integrator back over to quadcc. that's about the most control I can give without rewriting dblquad.

Nicholas Jankowski <nrjank>
Thu 21 Sep 2017 03:00:47 PM UTC, comment #1:

I started a wrapper to dblquad similar to that done for integral. I'm now recalling what issues popped up last time I looked at this.

In order to have full compatibility:
1 - integral2 needs y-limits to be able to be functions of x. dblquad can only handle scalar limits (rectangular integration region.) it may be able to do a mask function overlay to 'zero out' certain regions for non-rectangular domains, but that seems pretty inefficient (matlab agrees in it's public help for integral2). but it may be a decent initial compatibility hack. (ylim as a function is not available in matlab's dblquad either, so it's not a dblquad incompatibility)

2 - integral2 takes a 'method' parameter that lets you select between 'tiled' (or patch integration a la quad2d, not yet implemented in Octave) and 'iterated' (what it seems dblquad currently does). if a quad2d gets implemented could probably have the wrapper call quad2d or dblquad as specified. for now, can't do it.

3 - only other parameters are reltol and abstol. the problem is that dblquad only takes abstol. it will pass parameters to the integrating function, but it will only pass the limits and abstol to the underlying integrator. So even though I could have it use quadgk which can take a reltol, I don't have any way of pass the reltol value to it. So, another parameter that can't be used if integral2 is a simple wrapper.

a minimal, not fully compatible wrapper should be trivial. issue 2 should be trivial once a quad2d appears. issue 1 should be able to be satisfied with a masking hack. issue 3... no idea without fully reimplementing a 2-d integration routine. (I think all the integral, integral2, integral3 functions will need that to get full compatibility.)

will try for a minimal integral2 wrapper this weekend.

Nicholas Jankowski <nrjank>
Wed 20 Sep 2017 05:48:16 PM UTC, original submission:

matlab has 2 and 3d versions of the integral function. a limited implementation of integral was recently implemented as a wrapper to quadgk and quadv in Bug #42037. Suspect a similar strategy might work for integral2. opening a 'wishlist' missing function bug as a placeholder for any work on these functions.

Nicholas Jankowski <nrjank>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #42154:  add_quad2d_update_integral2and3_v2.diff added by nrjank (64KiB - application/octet-stream - cleaned up commit message)
file #42150:  add_quad2d_update_integral2and3.diff added by nrjank (64KiB - application/octet-stream - quad2d and updated integral2 and 3 to use it and avoid dbl&triplequad. plus patch for all based on recent tip)
file #42151:  integral2.m added by nrjank (11KiB - text/plain - quad2d and updated integral2 and 3 to use it and avoid dbl&triplequad. plus patch for all based on recent tip)
file #42152:  quad2d.m added by nrjank (16KiB - text/plain - quad2d and updated integral2 and 3 to use it and avoid dbl&triplequad. plus patch for all based on recent tip)
file #42153:  integral3.m added by nrjank (11KiB - text/plain - quad2d and updated integral2 and 3 to use it and avoid dbl&triplequad. plus patch for all based on recent tip)
file #42114:  quad2d.zip added by dbateman (12KiB - application/x-zip-compressed)
file #42111:  quad2d.m added by dbateman (15KiB - application/octet-stream)
file #42112:  integral2.m added by dbateman (11KiB - application/octet-stream)
file #42113:  integral3.m added by dbateman (11KiB - application/octet-stream)
file #42086:  integral2.m added by nrjank (16KiB - text/plain - integral2 with funct. limits and david's tiled implementation)
file #42087:  update_integral2_limitsAndTiled.diff added by nrjank (26KiB - application/octet-stream - integral2 with funct. limits and david's tiled implementation)
file #42009:  integral2.m added by dbateman (16KiB - application/octet-stream)
file #41980:  integral2_func_limits.diff added by nrjank (21KiB - application/octet-stream - integral2 using func. limits, but not tiled yet.)
file #41981:  integral2.m added by nrjank (12KiB - text/plain - integral2 using func. limits, but not tiled yet.)
file #41949:  integral2.m added by dbateman (19KiB - application/octet-stream)
file #41884:  add_integral2and3_v2.diff added by nrjank (26KiB - application/octet-stream - patch for integral2 and 3 planning for modified quadcc)
file #41856:  add_integral2and3_v1.diff added by nrjank (19KiB - application/octet-stream)
file #41857:  integral2.m added by nrjank (8KiB - text/plain)
file #41858:  integral3.m added by nrjank (8KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dbateman (Updated the item)
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by nrjank (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 24 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 16 Oct 2017 07:10:08 PM UTCrik5StatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Sat 14 Oct 2017 10:43:36 PM UTCnrjankAttached File-=>Added add_quad2d_update_integral2and3_v2.diff, #42154
    Sat 14 Oct 2017 10:41:18 PM UTCnrjankAttached File-=>Added add_quad2d_update_integral2and3.diff, #42150
      Attached File-=>Added integral2.m, #42151
      Attached File-=>Added quad2d.m, #42152
      Attached File-=>Added integral3.m, #42153
    Tue 10 Oct 2017 03:49:40 PM UTCdbatemanAttached File-=>Added quad2d.zip, #42114
    Tue 10 Oct 2017 03:20:16 PM UTCdbatemanAttached File-=>Added quad2d.m, #42111
      Attached File-=>Added integral2.m, #42112
      Attached File-=>Added integral3.m, #42113
    Sun 08 Oct 2017 05:46:03 AM UTCnrjankAttached File-=>Added integral2.m, #42086
      Attached File-=>Added update_integral2_limitsAndTiled.diff, #42087
    Fri 29 Sep 2017 10:13:11 PM UTCdbatemanAttached File-=>Added integral2.m, #42009
    Fri 29 Sep 2017 01:37:13 PM UTCnrjankAttached File-=>Added integral2_func_limits.diff, #41980
      Attached File-=>Added integral2.m, #41981
    Thu 28 Sep 2017 06:41:34 PM UTCdbatemanAttached File-=>Added integral2.m, #41949
    Sat 23 Sep 2017 10:18:04 PM UTCnrjankAttached File-=>Added add_integral2and3_v2.diff, #41884
    Fri 22 Sep 2017 05:35:52 PM UTCrik5StatusConfirmed=>In Progress
    Thu 21 Sep 2017 05:46:51 PM UTCnrjankAttached File-=>Added add_integral2and3_v1.diff, #41856
      Attached File-=>Added integral2.m, #41857
      Attached File-=>Added integral3.m, #41858
    Thu 21 Sep 2017 12:28:32 AM UTCrik5Severity3 - Normal=>1 - Wish
      StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1