bugGNU Octave - Bugs: bug #62321, Wrong result for Airy function

 
 

bug #62321: Wrong result for Airy function

Submitter:  None
Submitted:  Sat 16 Apr 2022 11:31:38 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Zoïs Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 19 Apr 2022 03:17:19 PM UTC, comment #32: 

Oops. Wrong function.

Markus Mützel <mmuetzel>
Group administrator
Tue 19 Apr 2022 03:16:07 PM UTC, comment #31: 

@Arun: I'm not sure how you determined the Nmax in comment #27.

In Octave 7.1.0 (prior to these changes), e.g.:

>> besseli(0,700)
ans = 1.5296e+302


So it seems to have worked well beyond 107...

Markus Mützel <mmuetzel>
Group administrator
Tue 19 Apr 2022 06:32:43 AM UTC, comment #30: 

[comment #29] Thank you, Arun.

I am obviously bias here, but I agree with [comment #28], in addition, you get the right result for input of the form `-x - 0i` close to the negative real axis.

Anonymous
Tue 19 Apr 2022 12:39:25 AM UTC, comment #29: 

Added a few more BISTs to besselj.cc based on comment #14. https://hg.savannah.gnu.org/hgweb/octave/rev/e7032ef9a9c3

Passes "make check". I think that covers it. Closing as fixed. If there are any bugs that crop up we can reopen this.

Arun Giridhar <arungiridhar>
Group Member
Mon 18 Apr 2022 10:28:13 PM UTC, comment #28: 

My personal opinion is that the slightly increased range (Nmax of 107 vs. 103) isn't worth the extra complexity of having our own code.  I like just handing all of the calculation off to the FORTRAN libary.

Rik <rik5>
Group administrator
Mon 18 Apr 2022 09:26:56 PM UTC, comment #27: 

Some data comparing the Octave scaling to the Fortran scaling for airy and biry:

K      Nmax (Octave)      Nmax (Fortran)
0      107                103
1      107                103
2      104                103
3      104                103

For K = 0 and 1, the larger N values yield 0. For K = 2 and 3 they yield Inf or "Inf + Infi".

Here is a performance comparison.

This is for the Octave scaling:

octave:2> for K = 0:3, tic; for n = 1:1e6, airy (K, -1-i); end; toc, end
Elapsed time is 5.55388 seconds.
Elapsed time is 5.57121 seconds.
Elapsed time is 5.31694 seconds.
Elapsed time is 5.31827 seconds.


This is for the Fortran scaling:

octave:2> for K = 0:3, tic; for n = 1:1e6, airy (K, -1-i); end; toc, end
Elapsed time is 5.39528 seconds.
Elapsed time is 5.39728 seconds.
Elapsed time is 5.27584 seconds.
Elapsed time is 5.27875 seconds.


So the Fortran scaling is marginally faster while being marginally less accommodating of large inputs, compared to the Octave scaling.

What are your thoughts on which one to use?

Arun Giridhar <arungiridhar>
Group Member
Mon 18 Apr 2022 08:48:19 PM UTC, comment #26: 

Reviewing BIST tests in besselj.cc, I don't see that there are specific tests for bug #48316 or for the specific bug report from the Octave Maintainer's list in 2003


y = besseli (0,700)


I just tested the code above in both Octave and Matlab and the results agree to the last decimal point so Matlab is presumably also using AMOS libraries and scaling.

I also tried code that jwe had specified in 2003


x = 79.5:0.0001:80;
y = besseli (0, x);


I tried this in Octave and Matlab with and without the third additional scaling parameter and results agree.

I added two more BIST tests in this changeset http://hg.savannah.gnu.org/hgweb/octave/rev/e0aabe59c1aa.

Is there anything more to do on this bug report or can it be closed?

Rik <rik5>
Group administrator
Mon 18 Apr 2022 08:05:06 PM UTC, comment #25: 

I checked in a small change here (http://hg.savannah.gnu.org/hgweb/octave/rev/4727765dbc89) just to have the new BIST tests conform to Octave coding conventions.

It's rather fascinating that code can go unchanged for years and then suddenly see a flurry of activity.

Rik <rik5>
Group administrator
Mon 18 Apr 2022 07:51:10 PM UTC, comment #24: 

A check for airy (K, N) for K = 0,1,2,3 and 100 <= N <= 110 reveals that using the Octave scaling routines allows slightly higher N (like 105 instead of 103 for K = 3,4 and 107 instead of 104 for K = 0,1) compared to using Fortran's scaling routines.

Arun Giridhar <arungiridhar>
Group Member
Mon 18 Apr 2022 07:03:39 PM UTC, comment #23: 

Related bug discussion: bug #48316

Does anyone know if there are BISTs incorporating those large inputs?

Arun Giridhar <arungiridhar>
Group Member
Mon 18 Apr 2022 06:20:48 PM UTC, comment #22: 


comment #16:

> That reverts a change that was done years ago here:
> https://hg.savannah.gnu.org/hgweb/octave/rev/3c82fc8f822c
>
> That was way before I knew about Octave. But since this was done explicitly, there was probably a good reason for it...
>


Sorry -- I meant to quote comment #16.


https://lists.gnu.org/archive/html/help-octave/2003-09/msg00023.html
This is the discussion that led to that change.



Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 18 Apr 2022 06:12:13 PM UTC, comment #21: 


comment #17:

> Anyway, even if this should be okay now for some reason, it would probably be good to de-duplicate the code by using a variable (similar to `F77_INT id = (deriv ? 1 : 0);`)...



https://lists.gnu.org/archive/html/help-octave/2003-09/msg00023.html

This is the discussion that led to that change.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 18 Apr 2022 06:00:52 PM UTC, comment #20: 

The change for the Bessel functions was done here:
https://hg.savannah.gnu.org/hgweb/octave/rev/451f4f291f46

That included changes to the underlying implementation in Fortran. (I don't know if those were related or orthogonal to this.)

Michele's blog for his GSOC project might(?) give clues as to whether we would need changes to the Fortran implementation of the Airy functions, too:
https://gsocspecfun.blogspot.com/2017/08/final-resume.html


Markus Mützel <mmuetzel>
Group administrator
Mon 18 Apr 2022 05:36:15 PM UTC, comment #19: 

@mmuetzel: I've pushed the change you suggested in comment #17. Good catch. https://hg.savannah.gnu.org/hgweb/octave/rev/1f7fcac1fac9

I had no idea of that history either. Let's see if CI catches anything. Hopefully whatever the problem was in 2003 that required Octave to scale the results itself is no longer applicable. If not, I will revert lo-specfun.cc.

Arun Giridhar <arungiridhar>
Group Member
Mon 18 Apr 2022 05:20:16 PM UTC, comment #18: 

[comment #15] Thank you for all you did.

[comment #16] Hum that weird, can we contact the author of that change ?

I look around to see how other code do it. Both SciPy and SpecialFunctions.jl call the scaling from the FORTRAN amos.

Which does not make it right but increase my trust in it.

Additionally, from the ChangeLog you link, it says that the scaling for the Bessel function was also done in octave part. But, if you look how it is done now, for example for `besselj`, if you follow the argument `scaling/kode` in

the scaling version is call from the FORTRAN amos part. Maybe, if we find the ChangeLog of the Bessel change, we might find some information.

[comment #17] Yes, that would make it more homogeneous.

Anonymous
Mon 18 Apr 2022 01:43:16 PM UTC, comment #17: 

Anyway, even if this should be okay now for some reason, it would probably be good to de-duplicate the code by using a variable (similar to `F77_INT id = (deriv ? 1 : 0);`)...

Markus Mützel <mmuetzel>
Group administrator
Mon 18 Apr 2022 01:39:28 PM UTC, comment #16: 

That reverts a change that was done years ago here:
https://hg.savannah.gnu.org/hgweb/octave/rev/3c82fc8f822c

That was way before I knew about Octave. But since this was done explicitly, there was probably a good reason for it...

Markus Mützel <mmuetzel>
Group administrator
Mon 18 Apr 2022 01:37:28 PM UTC, comment #15: 

I pushed the changes to lo-specfun.cc here: https://hg.savannah.gnu.org/hgweb/octave/rev/84e7222b6b5c listing you as co-author.

It passes "make check" for me. Will wait for CI to check across all platforms.

Arun Giridhar <arungiridhar>
Group Member
Mon 18 Apr 2022 07:39:05 AM UTC, comment #14: 

Your patch in [comment #11] looks good to me.

Additionally, there is the "duplication" with the Airy function Bi, the scaling is implemented in the zbiry/cbiry FORTRAN code, but it is done in the ocatve code (l1388 and l1462).

As for some test, with your finding, we can reduce the bug to the simple example:

## Just the first element interests us here, but we need to put it in a complex vector,
## so it remembers that its `-1-0i` and not just `-1`.
z = [(-1-1i) + 1i, 1+1i];

## The error should be 0 for Ai
(airy(0, z) - airy(0, conj(z)))(1)

## and for Ai'.
(airy(1, z) - airy(1, conj(z)))(1)

and I have check that this code does not give machine precision on my `6.2.0` octave version.

You could also test the relations:

z = -1 + 1i;

## Those should be machine precision
airy(0, z, true) - airy(0, z, false) * exp(2/3 * z * sqrt(z))
airy(1, z, true) - airy(1, z, false) * exp(2/3 * z * sqrt(z))
airy(2, z, true) - airy(2, z, false) * exp(-abs(real(2/3 * z * sqrt(z))))
airy(3, z, true) - airy(3, z, false) * exp(-abs(real(2/3 * z * sqrt(z))))


Anonymous
Sun 17 Apr 2022 10:05:15 PM UTC, comment #13: 

I pushed more BISTs at https://hg.savannah.gnu.org/hgweb/octave/rev/272614f05636 to cover 4x4x2 = 32 basic input combinations.

Hopefully the next CI build will catch any test failures. More external validation is always welcome, as are tests for difficult inputs like the negative real axis.

Arun Giridhar <arungiridhar>
Group Member
Sun 17 Apr 2022 09:02:36 PM UTC, comment #12: 

I pushed some BISTs and input validation tests to besselj.cc here https://hg.savannah.gnu.org/hgweb/octave/rev/84944164799e

More BISTs will be welcome especially for marginally complex cases.

Marking as ready for test.

Please also verify the patch to lo-specfun.cc in comment #11.

Arun Giridhar <arungiridhar>
Group Member
Sun 17 Apr 2022 08:07:59 PM UTC, comment #11: 

Hmm... you're right about the Fortran external library code already doing the scaling so Octave doesn't need to. I am attaching a patch to remove that duplication of functionality for zairy and cairy for anyone who wants to review and test it.

Once I have a few known good test cases I'll add some BISTs for the airy function in besselj.cc.

(file #53103)

Arun Giridhar <arungiridhar>
Group Member
Sun 17 Apr 2022 04:57:34 PM UTC, comment #10: 

Thank you for the workaround and for all the work you quickly did.

The problem you describe in comment #9 comes from `sqrt` and not from `exp`. Because, the exponential function is continuous on the whole complex plane whereas square root function is discontinuous across the negative real axis.


sqrt(V)(1, 1)
##ans =       0 - 0.6819i

sqrt(V(1, 1))
##ans =       0 + 0.6819i


I do not understand why the scaling is done "by hand" in octave because if I look into the amos function `zairy` https://hg.savannah.gnu.org/hgweb/octave/file/30f7f409861a/liboctave/external/amos/zairy.f#l28 that is call, the argument `kode = 1` return the unscaled version of the Airy function. So why call the amos Airy function with `kode = 2` to get the scaled version and then do the unscaling on the C++ octave part when it is done correctly in FORTRAN amos part ?

Something like:


if scaled
{
    F77_FUNC (zairy, ZAIRY) (zr, zi, id, 2, ar, ai, nz, t_ierr);
}
else
{
    F77_FUNC (zairy, ZAIRY) (zr, zi, id, 1, ar, ai, nz, t_ierr);
}


Anonymous
Sun 17 Apr 2022 02:49:07 PM UTC, comment #9: 

I found out why expz returns the wrong complex conjugate. The original input V lists the real numbers in the first row as "-0.4649 - 0i" using the negative sign for the imaginary part. Even though the imaginary part for that element is zero and therefore should not make a difference, in this case it does, and exp returns the negative complex conjugate.

If I add the line

V = (V + i) - i;

to the original input then "x - 0i" is set to "x + 0i", and both P and Q agree, as they ought to. To the OP (Zoïs), this workaround would at least give you accurate results for now.

When Q is being computed element by element, the negative sign on the complex number is discarded and it is treated as a real number. When P is computed as a whole matrix, the negative sign on each element is retained, even if the imaginary part is zero, and the result is incorrect.

This raises the very mathematical questions of how to handle "x + 0i" vs "x - 0i", should they be treated the same or not, and are they both equivalent to the real number "x" or not. Evidently it's being treated as significant by exp() but in this case it caused weird behavior.

Arun Giridhar <arungiridhar>
Group Member
Sun 17 Apr 2022 02:23:06 PM UTC, comment #8: 

The problem is with the expression "Complex expz = exp (- 2.0 / 3.0 z sqrt (z));"

When calling "P = airy (0, V)", the values inside the airy function are this for V(1,1):

        Input: zr = -0.464938  zi = -0
        Raw output: ar = 0.458007  ai = -0.0982673
                z =        (-0.464938, -0)
                expz =        (0.977749, -0.20978)
        Scaled output: ar = 0.427202  ai = -0.192161
        Final output: ar = 0.427202  ai = 0


When calling from a loop "Q(i) = airy (0, V(i))", the values are this for the same element:

        Input: zr = -0.464938  zi = 0
        Raw output: ar = 0.458007  ai = -0.0982673
                z =        (-0.464938, 0)
                expz =        (0.977749, 0.20978)
        Scaled output: ar = 0.468431  ai = 2.93374e-18
        Final output: ar = 0.468431  ai = 0


Observe that the z = -0.464938 is the same input for both as it should be, but expz for the first is (0.977749, -0.20978) and expz for the second case is (0.977749, 0.20978). The second case is correct according to external validation of airy, so for some reason exp is returning the wrong complex conjugate for the first case.

Is this because of exp or is it because of sqrt?

Arun Giridhar <arungiridhar>
Group Member
Sun 17 Apr 2022 01:55:03 PM UTC, comment #7: 

I found some strange behavior. Consider the input matrix V from comment #2:

V =
   -0.4649 -       0i   -0.3135 -       0i   -0.2155 -       0i
   -4.5181 -  0.0036i   -9.2814 -  0.0080i  -19.2341 -  0.0171i

where the first row is real and the second row is complex. In that case, calling "P = airy (0, V)" gives different results for the first row than going element by element in a loop with "Q(i) = airy (0, V(i))". The second row agrees between P and Q, only the first row is incorrect for P.

The bizarre part is this: trying to isolate the bug, I used only the first row of V where the discrepancy was, and magically P and Q both agreed! The presence of the completely unrelated second row of V causes the first row to give wrong results.

When real and complex values are mixed in a matrix, then along the line something breaks down in applying the wrong function (real for complex or vice versa) and it returns wrong results.

Arun Giridhar <arungiridhar>
Group Member
Sat 16 Apr 2022 09:39:53 PM UTC, comment #6: 

Thank you Zoïs for checking which was correct.

That code is multiplying (ar + i*ai) by the complex number expz. The variable "tmp" is used because we cannot update both ar and ai to their new values without using at least one temp variable. The multiplication procedure itself is correct (verified by hand) but I do not know enough about Airy equations to say if expz has been computed with the correct expression in the first place.

The errors have two mysteries I cannot resolve yet:

  • The scaling code would be applied only to scalars, so for calling a matrix or array, the only difference is whether that array is passed to it from one of the other airy functions or from the user element-by-element via a loop. But somehow the first use case gives wrong results, so P is wrong and Q is right for unclear reasons.


  • The results are correct for complex but fail for real values.


The last code change to the airy functions was many years ago. Copying jwe and rik5 as more knowledgeable about the file lo-specfun.cc.

Arun Giridhar <arungiridhar>
Group Member
Sat 16 Apr 2022 08:58:25 PM UTC, comment #5: 

I have check with WolframAlpha (this computes `Ai(V(1, 1))`) and SciPy, and it is `Q` in comment #3 that is true and `P` that is false.

I am not that well verse in C++, so I might be wrong. From the C++ code in comment #3, I do not understand the use of the `tmp` variable. If I understand correctly, when we call the Airy function `airy(0, z)` it first computes the scaled version and since we want the "unscaled" version it goes into this bloc and multiply the complex scale result `ar + i*ai` by the complex scale factor `expz = rexpz + i*iexpz`. So, it is just a multiplication of two complex numbers, and we could rewrite this bloc as


if (! scaled)
    {
        Complex expz = exp (- 2.0 / 3.0 * z * sqrt (z));

        double rexpz = expz.real ();
        double iexpz = expz.imag ();

        ar = ar*rexpz - ai*iexpz;
        ai = ar*iexpz + ai*rexpz;
    }


I also remark the same pattern in

For the last two, the value `expz` is the exponential of a real value, so it is a real number, and we should be able to reduce the bloc to


if (! scaled)
    {
        double expz = exp (std::abs (std::real (2.0 / 3.0 * z * sqrt (z))));

        ar = ar*expz;
        ai = ai*expz;
    }


Anonymous
Sat 16 Apr 2022 03:12:34 PM UTC, comment #4: 

I pushed some input validation (comment #2) and general fixes to the airy function here: https://hg.savannah.gnu.org/hgweb/octave/rev/85a67c1a5712

Waiting on input regarding the scaling in lo-specfun.cc.

Arun Giridhar <arungiridhar>
Group Member
Sat 16 Apr 2022 02:04:38 PM UTC, comment #3: 

The bug has been isolated to the scaling code in lo-specfun.cc here: https://hg.savannah.gnu.org/hgweb/octave/file/30f7f409861a/liboctave/numeric/lo-specfun.cc#l146. I added print statements as follows:


      if (! scaled)
        {
          std::cout << "\tBefore scaling: ar = " << ar << "  ai = " << ai << '\n';
          Complex expz = exp (- 2.0 / 3.0 * z * sqrt (z));

          double rexpz = expz.real ();
          double iexpz = expz.imag ();

          double tmp = ar*rexpz - ai*iexpz;

          ai = ar*iexpz + ai*rexpz;
          ar = tmp;
          std::cout << "\tAfter scaling: ar = " << ar << "  ai = " << ai << '\n';
        }


If a scaling option is passed, that if-block is skipped and the two results agree, but if the scaling option is absent in the original call, then the function changes things inconsistently:


octave:7> P = airy (0, V);
        Before scaling: ar = 0.458007  ai = -0.0982673
        After scaling: ar = 0.427202  ai = -0.192161

        Before scaling: ar = 0.296766  ai = 0.037377
        After scaling: ar = 0.301429  ai = 0.00181715

        Before scaling: ar = 0.431173  ai = -0.0506924
        After scaling: ar = 0.422305  ai = -0.100691

        Before scaling: ar = 0.222491  ai = 0.00567896
        After scaling: ar = 0.22802  ai = 0.00557015

        Before scaling: ar = 0.409248  ai = -0.0273306
        After scaling: ar = 0.406518  ai = -0.0545397

        Before scaling: ar = 0.113542  ai = -0.019165
        After scaling: ar = 0.122791  ai = 0.0179474

octave:8> Q = zeros(size(V));
octave:9> for t = 1:numel(V)
>   Q(t) = airy (0, V(t));
> end

        Before scaling: ar = 0.458007  ai = -0.0982673
        After scaling: ar = 0.468431  ai = 2.93374e-18

        Before scaling: ar = 0.296766  ai = 0.037377
        After scaling: ar = 0.301429  ai = 0.00181715

        Before scaling: ar = 0.431173  ai = -0.0506924
        After scaling: ar = 0.434143  ai = -5.71596e-18

        Before scaling: ar = 0.222491  ai = 0.00567896
        After scaling: ar = 0.22802  ai = 0.00557015

        Before scaling: ar = 0.409248  ai = -0.0273306
        After scaling: ar = 0.41016  ai = 1.93428e-18

        Before scaling: ar = 0.113542  ai = -0.019165
        After scaling: ar = 0.122791  ai = 0.0179474


The two values ar and ai are equal going into the block, and get changed differently in there. I do not understand the math well enough to say what the error is -- please comment on what is wrong there. If you have a known good scaled value, it would help say whether P is in error or Q is in error.

Arun Giridhar <arungiridhar>
Group Member
Sat 16 Apr 2022 01:29:24 PM UTC, comment #2: 

Modified test:


nu = [20 65 200];
w = 1 + [0 0.5] .* exp(i * 1e-3);
[NU, W] = meshgrid(nu, w);
Z = W .* NU ./ (NU - 1);
ZETA = -power(1.5 .* (sqrt(Z .^ 2 - 1) - asec(Z)), 2/3);;
V = power(NU - 1, 2/3) .* ZETA

P = airy (0, V);
Q = zeros(size(V));
for t = 1:numel(V)
  Q(t) = airy (0, V(t));
end

P
Q
P-Q

## Pass the scaling option
R = airy (0, V, true);
S = zeros(size(V));
for t = 1:numel(V)
  S(t) = airy (0, V(t), true);
end

R
S
R-S


As seen above in the code, passing it the scaling option makes both of them agree, but in that process I uncovered another bug. The decision whether to scale the output or not is done only based on whether there are three input arguments, not based on the scaling option's value. Calling airy (0, V, false) erroneously gives the same results as airy (0, V, true) which would be very confusing to someone who thought they had disabled scaling. Further, calling airy (V, ...) ought to be the same as calling airy (0, V, ...) but that breaks if the scaling option is passed, and then airy (V, true) gives completely different results from airy (0, V, true), not even the same size.

The main lifting is being done by one of several functions in liboctave/numeric/lo-specfun.cc. That's the next place to look.

Arun Giridhar <arungiridhar>
Group Member
Sat 16 Apr 2022 12:32:52 PM UTC, comment #1: 

Confirmed. This is weird behavior because the airy function only calls math::airy or math::biry https://hg.savannah.gnu.org/hgweb/octave/file/30f7f409861a/libinterp/corefcn/besselj.cc#l700

It is exacerbated by there being no BISTs for airy yet.

Arun Giridhar <arungiridhar>
Group Member
Sat 16 Apr 2022 11:31:38 AM UTC, original submission:  

I get wrong results when I use the Airy function Ai with a complex matrix. To be more precise, I have a complex matrix `V` and I compute `airy(0, V)`. The issue is that the computation with one value `airy(0, V(1, 1))` does not equal `airy(0, V)(1, 1)`, see code below.


#### setup
nu = [20 200];

w = 1 .+ [0 0.5] .* exp(1i * 1e-6);

[NU, W] = meshgrid(nu, w);

Z = W .* NU ./ (NU .- 1);
ZETA = -power(1.5 .* (sqrt(Z .^ 2 .- 1) .- asec(Z)), 2/3);;
V = power(NU .- 1, 2/3) .* ZETA
##V =
##
## Column 1:
##
##  -4.649384436518988e-01 -                     0i
##  -4.518125470102409e+00 - 3.640776206195730e-06i
##
## Column 2:
##
##  -2.154794036370222e-01 -                     0i
##  -1.923412063083059e+01 - 1.706292717651351e-05i

#### Compare matrix and scalar
airy(0, V)(1, 1)
##ans = 0.427201580339303

airy(0, V(1, 1))
##ans = 0.468430597790334





Some additional information:

  • I am using version `6.2.0-1` from the Ubuntu repository.


Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #53103:  airy.patch added by arungiridhar (2KiB - text/x-patch)
file #53094:  issue_airy.m added by None (619B - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by arungiridhar (Odd behavior in lo-specfun.cc -- pls take a look when you can)
  • -email is unavailable- added by arungiridhar (Odd behavior in lo-specfun.cc -- pls take a look when you can)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-04-19 arungiridhar StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-04-18 rik5 Release6.2.0 dev
        SummaryWrong result for Airy funtion Wrong result for Airy function
    2022-04-17 arungiridhar StatusIn Progress Ready For Test
    2022-04-17 arungiridhar Attached File- Added airy.patch, #53103
    2022-04-17 arungiridhar StatusNeed Info In Progress
    2022-04-16 arungiridhar Carbon-Copy- Added jwe
        Carbon-Copy- Added rik5
    2022-04-16 arungiridhar StatusIn Progress Need Info
    2022-04-16 arungiridhar StatusNone In Progress
    2022-04-16 None Attached File- Added issue_airy.m, #53094

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code