Computing expint(x), where x is an array, locks up for some x but not others that are very similar

Hi all,

I'm computing y = expint(x) where x is an array of doubles. In the attached data, x, there are two very similar arrays of data. Setting column 1 as x, the array y computes instantly. Setting column 2 as x, MATLAB gets stuck (or takes far longer than I'm willing to wait - order minutes). I can obtain the array y from column 2 iteratively, but it is much slower than array computation which will ultimately inhibit its utilization within the parent script.

Thinking the issue is with the values being slightly higher/lower in column 2 than column 1, I attempted the same test with repmat of said higher or lower values. y computed instantly in both instances.

Does anyone have any idea why column 2 does not compute but column 1, repmat(max(column 2),24001,1), and repmat(min(column 2),24001,1) compute without issue?

Thank you in advance.

[Walter Roberson]

I do not know why but it has something to do with x2(2124) and x2(23846)

x2(2125:23846) is fast, and x2(2124:23845) is fast, but when both of those endpoints are included, the computation is slow.

I can see nothing at all special about those values. They appear effectively linear in the surrounding data.

[Scott]

That's interesting and cleaver detective work @Walter Roberson, thanks! I have something working now, but am going to report this to MATLAB as suggested by @John D'Errico.

Answer 1

[Scott]

Responding to my own question for others and in hopes MATLAB will fix the issue within expint. Seems the fine difference between these two lines exploits an edge case (or bug) in the expint function.

expint utilizes a loop where it calculates the next iteration of a continued fraction, finds the delta compared to the previous iteration, and checks to see if that delta is below some threshold step size. If the delta is bigger than the threshold for any input in the entire array, then a new iteration is run for all steps. The issue described in this question arises because it is possible for multiple extra iterations on a below-threshold point to cause it to go above the threshold and require more iterations. In the case of the above data, this prompted an infinite loop.

A temporary workaround is to edit the function to only update iterations for array entries above the threshold, instead of all.

[John D'Errico]

You won't get MathWorks to fix an issue that was only brought up in Answers. Answers is NOT tech support. Yes, you MIGHT get lucky and someone in the right department might see it. But to quote a well known movie, "Do ya feel lucky, punk?"

Instead, send this in as a question directly to tech support, in this case, as a clear bug. In a quick test, I sorted the second column. Then I sent in the first half of that sorted vector, and then the second half. It works well in both cases. So it looks like a convergence issue, where the tolerance gets screwed up by the too wide range of values in that second column.

In my experience with tech support, you will get a response very quickly, especially for a clear bug.

(Actually, I was going to answer your question until I saw your answer, with a response that said basically what I just said, and told you to send this in as a bug report.)

[Scott]

MATLAB confirmed this is a bug and may be fixed within a future update. Thanks everyone for your responses and independent confirmation of my findings.

Answer 2

[Torsten]

The computation of the second column is even faster. I wonder how matlab evaluates expint(x) if x is a vector different from evaluating the function for each x separately.

fileID = fopen('sampleData.txt','r');
formatSpec = '%f %f';
A = fscanf(fileID,formatSpec);
A = [A(1:2:end),A(2:2:end)];
n = 24001;
tic
for i = 1:n
  expint(A(i,1));
end
toc

Elapsed time is 0.217734 seconds.

tic
for i = 1:n
  expint(A(i,2));
end
toc

Elapsed time is 0.124268 seconds.