bugGNU Octave - Bugs: bug #47800, gammainc(x,a,"upper")...


bug #47800: gammainc(x,a,"upper") rounds down to zero if output is below eps

Submitted by:  None
Submitted on:  Thu Apr 28 18:02:53 2016  
Category: Octave FunctionSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Inaccurate Result
Status: Patch SubmittedAssigned to: None
Originator Name: A. M. WinklerOriginator Email: -unavailable-
Open/Closed: OpenRelease: dev
Operating System: Any

Add a New Comment (Rich MarkupRich 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 May 15 20:18:53 2017, comment #48:

Dear all, I corrected a bug in the .m file and added a description about the "scaled" option in the help. Then I remake the patch to work with the new organization of the folder (liboctave/cruft has been renamed in liboctave/external). You can find the patch attached or you can pull it from the gammainc bookmark on my repository

(file #40696)

Michele Ginesi <m_ginesi>
Fri Mar 24 14:12:48 2017, comment #47:

Dear all,
I corrected a bug in the .m file and during the sprint code at the OctConf I worked with Carne to make a good patch. I attach the new changeset

(file #40115)

Michele Ginesi <m_ginesi>
Tue Mar 7 18:05:52 2017, comment #46:

Dear all,
I re-post the patch because the old one stopped working (mercurial couldn't remove gammainc.cc since a line about the copyright was modified). Now it work with the last version (I'm on revision 23250).

(file #39928)

Michele Ginesi <m_ginesi>
Tue Feb 7 13:17:11 2017, comment #45:

Dear all,
I just saw that there is a problem with my previous files (they are missing), now I hope that is all ok.

(file #39689)

Michele Ginesi <m_ginesi>
Sun Feb 5 11:33:08 2017, comment #44:

Dear all,
I have made some minor modifications to gammainc.m and __gammainc_lentz.cc (files #39669 and #39670 )in such a way to adapt to the class of the input (as the actual gammainc do: if one between x and a is single, then the output is single as well).
Then I tried to make a patch (file #39668 ). I was able to build octave with this, but it's the first time I try to make a patch in which there is more to do than to modify a single file, so I'm not sure it is "well-made". So if everyone has some suggestion, I would like to help in making this patch definitive.

Michele Ginesi <m_ginesi>
Tue Jan 31 13:48:44 2017, comment #43:

I don't see a patch or changeset, just new files.

Changing the status to in progress.

We need a changeset with a proper commit message and tests.

John W. Eaton <jwe>
Project Administrator
Wed Jan 25 19:25:47 2017, comment #42:

Changing status to "patch reviewed"

Maintainers: please see comment #41

Avinoam Kalma <avinoam>
Project Member
Thu Nov 17 10:58:42 2016, comment #41:

What is the next step for getting this committed?

Nir Krakauer <nir_krakauer>
Sun Jul 3 09:23:59 2016, comment #40:

For me it is ready for pushing.


Marco Caliari <caliari>
Project Member
Sat Jul 2 06:14:17 2016, comment #39:

Nir and Marco, is this still "in progress", or do you want to push for it to be included in 4.2.0?

Bear in mind that review resources are particularly tight at this time.

Lachlan Andrew <lachlan>
Project Member
Thu Jun 2 12:38:10 2016, comment #38:

yes, actually __gammainc_lentz currently deals with scalar inputs, so there is only one convergence at a time to worry about

Nir Krakauer <nir_krakauer>
Thu Jun 2 07:51:54 2016, comment #37:

Excellent, Nir. I see that you do not remove converged values in __gammainc_lentz as you did for gammainc_s (jj subindex). Isn't it dangerous? For instance, with your previous file #37329, if I do

quite often I have no convergence. The problem seems to me that at a certain iteration, some values have converged, but at the next iteration their error is a bit above the tolerance and other converged, and so on. However, I cannot reproduce this behavior with your new file #37342.

Marco Caliari <caliari>
Project Member
Wed Jun 1 19:10:20 2016, comment #36:

*should be mkoctfile __gammainc_lentz.cc

Nir Krakauer <nir_krakauer>
Wed Jun 1 19:08:02 2016, comment #35:

Yes, a simple scalar C++ implementation of that loop improves the speed quite a bit.
(after mkoctfile __gammainv_lentz.cc )

(file #37341, file #37342)

Nir Krakauer <nir_krakauer>
Wed Jun 1 15:42:38 2016, comment #34:

First of all, the trick with

is missing in ngammainc_l. Now included.

Second, ngammainc_l is used for x>0, therefore always real results. What about to write an oct file just for ngammainc_l? it should not be difficult.

(file #37335)

Marco Caliari <caliari>
Project Member
Wed Jun 1 14:01:03 2016, comment #33:

Yes, unfortunately the new implementation can be very slow:

m = 5;
n = 100;
a = rand (m, n);
x = rand (m, n);
for i = 1:n
y = gammainc (x(:, i), a(:, i));
t = toc #old: 0.4 s, new: 19 s

Profiling shows that the main bottleneck is the ngammainc_l subfunction, where the while loop can run thousands of times before the tolerance is reached. I streamlined this loop a bit (attached), but it's seemingly impossible to relax the tolerance without losing accuracy (tests start to fail).

(file #37329)

Nir Krakauer <nir_krakauer>
Wed Jun 1 13:01:30 2016, comment #32:

Well done on fixing bug #40362 as well.

I'm still concerned about the loss of performance relative to the current C++/Fortran implementation. Do you think it won't be an issue, or is it worth working out which cases the built-in version can handle and calling it where possible?

Lachlan Andrew <lachlan>
Project Member
Wed Jun 1 12:53:09 2016, comment #31:

So, I'm uploading the latest version with

  • name changed to gammainc (I feel very close to the final implemetation)
  • vectorized D (thanks Nir for the idea)
  • D(a,x) changed into D(x,a) (as gammaninc(x,a))
  • updated test with smaller tolerances


(file #37328)

Marco Caliari <caliari>
Project Member
Wed Jun 1 06:30:00 2016, comment #30:

Yes, in octave 3.6.2 as well as 3.8.0 this fixes the reported problems with bug #40362. Thank you.

Tue May 31 10:04:01 2016, comment #29:

I think bug #40362 is triggered by

Current ngammainc handles without problems those arguments.
If you download file #37225:, call it gammainc.m, rename the inside function to gammainc, and put the file in your path, I think you should be able to overcome bug #40362. Can you please check that?

Marco Caliari <caliari>
Project Member
Tue May 31 07:55:33 2016, comment #28:

I did not take the time to follow the whole discussion through, but do you propose to replace the low-level computation of the inverse gamma function? If so, does this fix bug #40362?

Thu May 26 16:43:15 2016, comment #27:

Must be compiler differences, since lgamma is a C++ built-in. I suggest incorporating D into ngammainc and then seeing we can agree on the ngammainc tolerances.

Nir Krakauer <nir_krakauer>
Tue May 24 18:35:55 2016, comment #26:

ans = 40026bb1bbb55516
ans = 402e357590954d16
ans = 3fc0039b0be96db2

So, gammaln(11) (and therefore D(10,10)) differs in the last digit.

Marco Caliari <caliari>
Project Member
Tue May 24 17:06:56 2016, comment #25:

What do you get for the intermediate values in D(10, 10)? I have

> format hex
> log(10)


> gammaln(11)


> D(10, 10)


Nir Krakauer <nir_krakauer>
Tue May 24 16:58:36 2016, comment #24:

Weird. It passes all tests on my 4.0.0 and 4.1.0+. Failure for D(10,10) means there is something in exp, log or gammaln. The new code is not used in this case.

Marco Caliari <caliari>
Project Member
Tue May 24 15:55:26 2016, comment #23:

I get 3 tolerances not met with the new D on Octave 4.0.2:

          • test

!!!!! test failed
ASSERT errors for: assert (D (10, 10),0.12511003572113329898476497894772544708420990097708600,-7 * eps)

Location | Observed | Expected | Reason
() 0.12511 0.12511 Rel err 3.3277e-15 exceeds tol 1.5543e-15

          • test

!!!!! test failed
ASSERT errors for: assert (D (10, -10),6.069903492836947893782490257188118487200593203967e7,-8 * eps)

Location | Observed | Expected | Reason
() 60699034.928 60699034.928 Rel err 5.1553e-15 exceeds tol 1.7764e-15

          • test

!!!!! test failed
ASSERT errors for: assert (D (9, -10),-6.069903492836947893782490257188118487200593203967e7,-8 * eps)

Location | Observed | Expected | Reason
() -60699034.928 -60699034.928 Rel err 5.1553e-15 exceeds tol 1.7764e-15

Nir Krakauer <nir_krakauer>
Mon May 23 07:00:18 2016, comment #22:

I include my new version of the subfunction D. It allows to reduce a lot the tolerances for the tests in ngammainc. It not vectorized, yet.

(file #37232)

Marco Caliari <caliari>
Project Member
Sun May 22 11:13:40 2016, comment #21:

The the handling of arrays is really nice -- not a single for loop!

Here is an updated version that copies most of the documentation from the existing C++ implementation.

I hadn't realised previously that the current implementation is in C++. That presumably will make it much faster than the current one. Would you propose to replace the existing C++ function by this one, or would you want to call the C++ function for tail=="lower"? Or should this be translated this into C++, now that you have the algorithms selected?

(file #37225)

Lachlan Andrew <lachlan>
Project Member
Fri May 20 16:46:05 2016, comment #20:

Thanks Andrew and Marco. I added a license notice and now provide for handling of array x,a inputs.

(file #37213)

Nir Krakauer <nir_krakauer>
Fri May 20 06:44:33 2016, comment #19:

Hmmm... Before this can be applied, it will definitely need to handle vectors, even if only by loops.

There are many special cases in this code. I'd imagine that at least some of them can be vectorised efficiently. The iterative components are probably the most expensive, and they seem to be vectorisable, although iteration would need to continue until all had converged, and so the actual FLOP count could be much higher than currently.

I'll add it to my to-do list, but will need reminding...

Lachlan Andrew <lachlan>
Project Member
Fri May 20 06:32:01 2016, comment #18:

I release my contribution under the GPL, too.

The only functionality missing with respect to the current Octave implementation (and Matlab as well) is the possibility to work with a and x vectors. I do not see an easy way to vectorize: in expint.m, for instance, there is a simple

Marco Caliari <caliari>
Project Member
Thu May 19 13:50:11 2016, comment #17:

Yes, I release my contribution under the GPL

Nir Krakauer <nir_krakauer>
Thu May 19 11:59:27 2016, comment #16:

Thanks to you both for your great work.

I've tidied the formatting to comply with Octave's coding standards, but haven't yet touched the docstring. The code has no licence. Are you both happy for it to be GPL'd?

FYI, the changes I've made to comply with the standards are:
- endif/endwhile/endfunction instead of end
- double quotes instead of single quotes
- ## instead of % to introduce full-line comments
- space before function call parenthesis
- spacing around operators
- ; after the "assert" statements
- lines wrapped after 72~76 columns.

In addition
- strcmp -> strcmpi
- Use of +=, *= etc when possible, since they are actually faster than "n = n + 1" etc.
- Removed what seemed to be a duplicated "aj = a;" before the comment

since there was also one after that comment.

(file #37206)

Lachlan Andrew <lachlan>
Project Member
Mon May 9 16:18:20 2016, comment #15:

Thanks, Marco.
I added the exponential sum algorithm for small integer a and small x, which gives near-exact results.
Also, I found a more recent (2012) discussion involving Temme at http://oai.cwi.nl/oai/asset/20433/20433B.pdf Their Fortran code is posted at http://personales.unican.es/gila/incgam.zip , unfortunately with no license.

(file #37114)

Nir Krakauer <nir_krakauer>
Mon May 9 13:52:26 2016, comment #14:


I include my final proposal. It has corner cases first, then a series and finally a continued fraction expansion. All tests gammainc(200,200,tail) are passed with at most relative error 78*eps. I used all the ideas discussed here (thanks Nir). Two points are still missing

1) accurate implementation of D(a,x) (seems hard to implement)
2) Matlab is exact for a integer. I found a close form (http://mathworld.wolfram.com/IncompleteGammaFunction.html, formula (2)), but can't implement without over/underflow.

(file #37113)

Marco Caliari <caliari>
Project Member
Fri May 6 16:57:58 2016, comment #13:

Yes, the scale factor seems to have more error than the series sum. We could adopt Temme's idea, but then we will need to accurately compute his "tempered gamma". Failing that, I was able to improve the error slightly:

#with previously sent program:
x = 200; a = 200;
scale = exp(x - alog(x) + gammaln(a+1)); #fractional error of 9E-15 compared to Wolfram Alpha's result of Gamma(201)e^200*200^-200 = 35.46385053215837215657814935957664087171927837002301455738
y = newgammainc(200,200,'scaledupper'); #essentially the series sum -- fractional error of 2E-15 from Gamma(201)e^200200^-200*GammaRegularized[200, 200] = 17.39844385537915051351229001995819645096209733412625912131
y2 = newgammainc(200,200,'scaledlower'); #fractional error of 2E-14 from Gamma(201)e^200200^-200*(1 - GammaRegularized[200, 200]) = 18.06540667677922164306585933961844442075718103589675543606
y3 = newgammainc(200,200,'upper'); #fractional error of 5E-14 from GammaRegularized[200, 200] = 0.490596581992763674972174540425472956845027831400859498457
y4 = newgammainc(200,200,'lower'); #fractional error of 5E-14 from 1 - GammaRegularized[200, 200] = 0.509403418007236325027825459574527043154972168599140501542
scale2 = exp(x - alog(x) + gammaln(a)); #fractional error of 5E-14 compared to Wolfram Alpha's result of Gamma(200)e^200*200^-200 = 0.177319252660791860782890746797883204358596391850115072786

#with new attached version, where scale instead of scale2 is used to compute the unscaled variants:
y3 = newgammainc(200,200,'upper'); #fractional error of 1E-14
y4 = newgammainc(200,200,'lower'); #fractional error of 1E-14

(file #37091)

Nir Krakauer <nir_krakauer>
Fri May 6 06:54:57 2016, comment #12:

Hi Nir. If I understand correctly, you (Gautschi) can avoid overflow/underflow by computing the series for the scaled version and scaling at the end. The Legendre continued fraction is instead formula (6.2.6) of Numerical Recipes. I used (6.2.7) (claimed to be faster), but only for abs(x) > a+1. Anyway, I found this interesting paper


In section 5.1 it is clear that either the series or the continued fraction method is used. But it is interesting the first part of the paper, in which the accurate computation of D(a,x)=x^aexp(-x)/Gamma(a+1) is discussed. I already notice that that standard way exp(alog(x)-x-gammaln(a+1)) is not always accurate (and may explain the loss of 3-4 digits).
To summarize, I would guess (or hope) that the series/continued fraction method + accurate computation of D(a,x) would manage all the cases (instead of currently two series and two continued fractions).

By the way, "improvement of special functions": what a nice project for next GSOC!

Marco Caliari <caliari>
Project Member
Fri May 6 05:10:10 2016, comment #11:

In case it helps with development, I've just added gammainc to Symbolic. Here's a useful recipe for experimenting:

I also put some 'xtest' BIST into '@sym/gammainc' that should pass once this bug is fixed.

I'm worried about the state of special functions in Octave :(

Colin Macdonald <cbm>
Thu May 5 20:14:04 2016, comment #10:

Hi Marco-- I added two more methods to your m-file to deal with positive a and x without overflow. Now all the tests pass, albeit at fractional tolerances of ~1000eps. I also streamlined the processing of scaled options.

Based on our results so far, I think we should first implement gammainc as an m-file, since the available Fortran programs don't work for all cases and are difficult to debug. Once we have a working implementation, we can look at increasing efficiency by calling C++ or Fortran for some branches.

(file #37083)

Nir Krakauer <nir_krakauer>
Thu May 5 12:47:36 2016, comment #9:

Thanks Nir,

but that code is quite inaccurate, try, for instance, gamain(2,3).
I started to implement, but how many corner cases! I used Numerical Recipes in Fortran77 (chapter 6.2). It is possible to use either a series or a continued fraction. I include my result, with some tests (the last still fails). Matlab is generally better for large input values, unless completely wrong. scaledupper and scaledlower options are not finished, yet. You can test it in Matlab (no endif...). The reference values in the tests were taken by wolframalpha. Don't know how to continue: modification of slatec functions (reliable, but forget x<0) or fixing the m-file.

(file #37075)

Marco Caliari <caliari>
Project Member
Wed May 4 16:25:52 2016, comment #8:

There is possibly useful LGPL code in different languages at http://people.sc.fsu.edu/~jburkardt/cpp_src/asa032/asa032.html

Nir Krakauer <nir_krakauer>
Wed May 4 14:23:13 2016, comment #7:

I had almost finished to implement the options scaledupper and scaledlower when I realized that Matlab supports negative x, while slatec (and thus Octave) does not. On the other hand, gammainc(-10,10) gives a complex result, while wolframalpha a real result (Matlab result's real part) and the usual series definition agrees with wolframalpha. gammainc(-10,10.1) gives the correct result, in Matlab and as the usual series. Now I think that a plain m file should be used (like expint, for instance).

Marco Caliari <caliari>
Project Member
Wed May 4 06:54:07 2016, comment #6:

Is there a reason why the file xgmainc.f (by jwe) has inside the subroutine xgammainc? How should I call the files and the subroutines (I think I will need two more subroutines, for the options "scaledlower" and "scaledupper")? Then, I will need some advice in order to incorporate it into Octave.

Marco Caliari <caliari>
Project Member
Tue May 3 22:46:55 2016, comment #5:

Marco: I haven't looked at your patch yet, but your description sounds like the right direction to get this fixed in Octave (adding more Fortran subroutines along the same lines as xgammainc and xsgammainc).

Mike Miller <mtmiller>
Project Administrator
Tue May 3 13:02:44 2016, comment #4:

Yes, it's the correct answer! [note the different orderings of a and x -- xcgmainc(6.0d0,60.0d0,result) = gammainc(60, 6, "upper") = GammaRegularized[6, 60] in Wolfram Alpha]

Nir Krakauer <nir_krakauer>
Tue May 3 10:56:45 2016, comment #3:

I attach xcgmainc.f, a modification of slatec dgamic, which computes the complementary incomplete Gamma functions. The modifications are

1) transformation into a subroutine (like xgmainc.f by jwe)
2) division by Gamma(A) (not present in dgamic)

It requires d9gmic (not in liboctave/cruft/slatec-fn). When invoked with call xcgmainc(6.0d0,60.0d0,result) it gives result=6.1802e-20. Am I on the right way for the incorporation into Octave? Because Matlab allows also 'scaledupper' and 'scaledlower', which I would like to implement. Of course, the single version is still missing.

(file #37056)

Marco Caliari <caliari>
Project Member
Mon May 2 06:54:36 2016, comment #2:

Yes Nir,

the function dgamic.f should probabily be used. I can give a look.

Marco Caliari <caliari>
Project Member
Thu Apr 28 18:11:03 2016, comment #1:

The problem is really in
There, gammainc(a, x, 'upper') is computed as 1 - gammainc(a, x), which expectedly evaluates to 0 if gammainc(a, x) is within eps of 1.

If we want more accurate results, we need a separate function to compute the complement.

Nir Krakauer <nir_krakauer>
Thu Apr 28 18:02:53 2016, original submission:

Consider this:

In Matlab:

>> gammainc(60,6,'upper')

ans =

In Octave 4.0.0 (same for 3.8.2):

>> gammainc(60,6,'upper')

ans = 0

This causes large problems, as norminv(6.1802e-20) = -9.0659 (the expected result), whereas norminv(0) = -Inf, and subsequent code crashes.



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

Attach File(s):

Attached Files
file #40696:  gammainc.diff added by m_ginesi (54kB - text/x-patch)
file #40115:  gammainc.diff added by m_ginesi (53kB - text/x-patch)
file #39928:  gammainc.diff added by m_ginesi (54kB - text/x-patch)
file #39689:  gammainc.diff added by m_ginesi (54kB - text/x-patch)
file #39668:  gammainc.diff added by m_ginesi (54kB - text/x-patch)
file #39669:  gammainc.m added by m_ginesi (13kB - text/x-objcsrc)
file #39670:  __gammainc_lentz.cc added by m_ginesi (3kB - text/x-c++src)
file #37341:  __gammainc_lentz.cc added by nir_krakauer (2kB - application/octet-stream)
file #37342:  gammainc.m added by nir_krakauer (11kB - application/octet-stream)
file #37335:  gammainc.m added by caliari (11kB - text/x-objcsrc)
file #37329:  gammainc.m added by nir_krakauer (11kB - application/octet-stream)
file #37328:  gammainc.m added by caliari (11kB - application/binary)
file #37232:  D.m added by caliari (3kB - text/x-objcsrc)
file #37225:  ngammainc.m added by lachlan (10kB - d2l/unknowntype)
file #37213:  ngammainc.m added by nir_krakauer (8kB - application/octet-stream)
file #37206:  ngammainc.m added by lachlan (6kB - d2l/unknowntype)
file #37114:  ngammainc.m added by nir_krakauer (5kB - application/octet-stream)
file #37113:  ngammainc.m added by caliari (4kB - application/vnd.wolfram.mathematica.package)
file #37091:  newgammainc.m added by nir_krakauer (5kB - application/octet-stream)
file #37083:  newgammainc.m added by nir_krakauer (5kB - application/octet-stream)
file #37075:  newgammainc.m added by caliari (3kB - application/vnd.wolfram.mathematica.package)
file #37056:  xcgmainc.f added by caliari (5kB - text/x-fortran)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by m_ginesi (Updated the item)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by lachlan (Updated the item)
  • -unavailable- added by cbm (Posted a comment)
  • -unavailable- added by cbm
  • -unavailable- added by caliari (Posted a comment)
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by nir_krakauer (Posted a comment)
  • -unavailable- added by None (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 25 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon May 15 20:18:53 2017m_ginesiAttached File-=>Added gammainc.diff, #40696
    Fri Mar 24 17:15:53 2017avinoamStatusIn Progress=>Patch Submitted
    Fri Mar 24 14:12:48 2017m_ginesiAttached File-=>Added gammainc.diff, #40115
    Tue Mar 7 18:05:52 2017m_ginesiAttached File-=>Added gammainc.diff, #39928
    Tue Feb 7 13:17:11 2017m_ginesiAttached File-=>Added gammainc.diff, #39689
    Sun Feb 5 11:21:31 2017m_ginesiAttached File-=>Added gammainc.diff, #39668
      Attached File-=>Added gammainc.m, #39669
      Attached File-=>Added __gammainc_lentz.cc, #39670
    Tue Jan 31 13:48:44 2017jweStatusPatch Reviewed=>In Progress
    Wed Jan 25 19:25:46 2017avinoamStatusPatch Submitted=>Patch Reviewed
    Wed Jun 1 19:08:02 2016nir_krakauerAttached File-=>Added __gammainc_lentz.cc, #37341
      Attached File-=>Added gammainc.m, #37342
    Wed Jun 1 15:42:38 2016caliariAttached File-=>Added gammainc.m, #37335
    Wed Jun 1 14:01:03 2016nir_krakauerAttached File-=>Added gammainc.m, #37329
    Wed Jun 1 12:53:09 2016caliariAttached File-=>Added gammainc.m, #37328
    Mon May 23 07:00:18 2016caliariAttached File-=>Added D.m, #37232
    Sun May 22 11:13:40 2016lachlanAttached File-=>Added ngammainc.m, #37225
    Fri May 20 16:46:05 2016nir_krakauerAttached File-=>Added ngammainc.m, #37213
    Thu May 19 11:59:27 2016lachlanAttached File-=>Added ngammainc.m, #37206
    Mon May 9 16:18:20 2016nir_krakauerAttached File-=>Added ngammainc.m, #37114
    Mon May 9 13:52:26 2016caliariAttached File-=>Added ngammainc.m, #37113
    Fri May 6 16:57:58 2016nir_krakauerAttached File-=>Added newgammainc.m, #37091
    Fri May 6 04:54:02 2016cbmCarbon-Copy-=>Added cbm
    Thu May 5 20:14:04 2016nir_krakauerAttached File-=>Added newgammainc.m, #37083
    Thu May 5 12:47:36 2016caliariAttached File-=>Added newgammainc.m, #37075

    Back to the top

    Powered by Savane 3.1-cleanup1