Weird behavior for pagemrdivide matlab 2022b vs 2022a

I am noticing some strange behaviour when using pagemrdivide. When I run the code below, the Dpage variable contains a lot of NaN, while the Dfor variable computes just fine. I expect these two to be equal, but they are not. Has anyone else encountered this behaviour before?

When I run the same code in matlab 2022a, I don't get this behaviour, it seems to be introduced in 2022b.

F = 300;
D = randn(2,2,F) + 1i*randn(2,2,F);
P = [0     0     1     0
     1     0     0     0
     0     0     0     1
     0    -1     0     0];
P11 = P(1:2,1:2);
P12 = P(1:2,3:4);
P21 = P(3:4,1:2);
P22 = P(3:4,3:4);
Dpage = pagemrdivide(pagemtimes(P11,D) + P12, pagemtimes(P21,D)+P22);
Dfor = zeros(size(D));
for ff = 1 : F
    Dfor(:,:,ff) = mrdivide(P11*D(:,:,ff)+P12,P21*D(:,:,ff)+P22);
end

nnz(isnan(Dpage))

ans = 600

nnz(isnan(Dfor))

ans = 0

[Walter Roberson]

You are right, it is pretty bad, giving all nan and inf results if asked to process more than one page

format long g

D = cat(3, [1 2; 3 4], [2 -1; 3 5]) + 1i*cat(3, [20 19; 18 17], [-1 5; 7 9])

D = 
D(:,:,1) =

                          1 +                    20i                          2 +                    19i
                          3 +                    18i                          4 +                    17i


D(:,:,2) =

                          2 -                     1i                         -1 +                     5i
                          3 +                     7i                          5 +                     9i

P = [0     0     1     0
     1     0     0     0
     0     0     0     1
     0    -1     0     0];
P11 = P(1:2,1:2);
P12 = P(1:2,3:4);
P21 = P(3:4,1:2);
P22 = P(3:4,3:4);
arg1 = pagemtimes(P11,D) + P12

arg1 = 
arg1(:,:,1) =

                          1 +                     0i                          0 +                     0i
                          1 +                    20i                          2 +                    19i


arg1(:,:,2) =

                          1 +                     0i                          0 +                     0i
                          2 -                     1i                         -1 +                     5i

arg2 = pagemtimes(P21,D) + P22

arg2 = 
arg2(:,:,1) =

                          0 +                     0i                          1 +                     0i
                         -3 -                    18i                         -4 -                    17i


arg2(:,:,2) =

                          0 +                     0i                          1 +                     0i
                         -3 -                     7i                         -5 -                     9i

Dpage = pagemrdivide(arg1, arg2)

Dpage = 
Dpage(:,:,1) =

                        Inf +                   NaNi                        Inf -                   Infi
                        Inf +                   Infi                        Inf +                   NaNi


Dpage(:,:,2) =

                        Inf +                   NaNi                        Inf -                   Infi
                        Inf -                   Infi                        NaN -                   Infi

Dpage2 = cat(3, pagemrdivide(arg1(:,:,1), arg2(:,:,1)), pagemrdivide(arg1(:,:,2), arg2(:,:,2)))

Dpage2 = 
Dpage2(:,:,1) =

         -0.954954954954955 +    0.0630630630630631i       -0.00900900900900901 +    0.0540540540540541i
         -0.216216216216216 -    0.0360360360360339i          -1.09009009009009 -     0.126126126126126i


Dpage2(:,:,2) =

           -1.3448275862069 +     0.137931034482759i        -0.0517241379310345 +     0.120689655172414i
          -3.55172413793103 +      6.62068965517241i         0.0172413793103448 +     0.293103448275862i

nnz(isnan(arg1))

ans = 
     0

nnz(isnan(arg2))

ans = 
     0

nnz(isnan(Dpage))

ans = 
     4

nnz(isnan(Dpage2))

ans = 
     0

The debugging confirms that it is not the fault of pagemtimes, and confirms that if you only do one page at a time that the problem does not occur.

[the cyclist]

Seems to be pretty clear-cut bug, introduced in R2022b. (The function itself was only introduced in R2022a!)

I did not see this listed as a known issue. I recommend submitting a bug report here.

[Paul]

Also, pagemldivide doesn't work for @Walter Roberson's example. Pehaps even worse, pagemldivide on multiple pages doesn't yield a result that's obviously incorrect, i.e., with nan or inf entries. Just returns realistic looking, but incorrect, numbers for a few entries.

format long g
D = cat(3, [1 2; 3 4], [2 -1; 3 5]) + 1i*cat(3, [20 19; 18 17], [-1 5; 7 9]);
P = [0     0     1     0
     1     0     0     0
     0     0     0     1
     0    -1     0     0];
P11 = P(1:2,1:2);
P12 = P(1:2,3:4);
P21 = P(3:4,1:2);
P22 = P(3:4,3:4);
arg1 = pagemtimes(P11,D) + P12;
arg2 = pagemtimes(P21,D) + P22;

Both pages at once

Dpage = pagemldivide(arg1, arg2)

Dpage = 
Dpage(:,:,1) =

                          0 +                     0i                          1 +                     0i
         -0.953424657534247 +    0.0575342465753425i         -0.906849315068493 +     0.115068493150685i


Dpage(:,:,2) =

                          0 +                     0i                          1 +                     0i
          -1.23076923076923 +     0.846153846153846i          -1.53846153846154 +      1.30769230769231i

Use plain vanilla mldivide

Dpage1 = cat(3,arg1(:,:,1)\arg2(:,:,1),arg1(:,:,2)\arg2(:,:,2))

Dpage1 = 
Dpage1(:,:,1) =

                          0 +                     0i                          1 +                     0i
         -0.953424657534247 +    0.0575342465753425i          -1.95342465753425 +    0.0575342465753425i


Dpage1(:,:,2) =

                          0 +                     0i                          1 +                     0i
          -1.23076923076923 +     0.846153846153846i          -1.26923076923077 +      1.65384615384615i

pagemldivide one page at a time.

Dpage2 = cat(3, pagemldivide(arg1(:,:,1), arg2(:,:,1)), pagemldivide(arg1(:,:,2), arg2(:,:,2)))

Dpage2 = 
Dpage2(:,:,1) =

                          0 +                     0i                          1 +                     0i
         -0.953424657534247 +    0.0575342465753425i          -1.95342465753425 +    0.0575342465753425i


Dpage2(:,:,2) =

                          0 +                     0i                          1 +                     0i
          -1.23076923076923 +     0.846153846153846i          -1.26923076923077 +      1.65384615384615i

nnz(isnan(arg1))

ans = 
     0

nnz(isnan(arg2))

ans = 
     0

nnz(isnan(Dpage))

ans = 
     0

nnz(isnan(Dpage2))

ans = 
     0

Dpage - Dpage1

ans = 
ans(:,:,1) =

                          0 +                     0i                          0 +                     0i
                          0 +                     0i           1.04657534246575 +    0.0575342465753425i


ans(:,:,2) =

                          0 +                     0i                          0 +                     0i
                          0 +                     0i         -0.269230769230769 -     0.346153846153846i

Dpage - Dpage2

ans = 
ans(:,:,1) =

                          0 +                     0i                          0 +                     0i
                          0 +                     0i           1.04657534246575 +    0.0575342465753425i


ans(:,:,2) =

                          0 +                     0i                          0 +                     0i
                          0 +                     0i         -0.269230769230769 -     0.346153846153846i

Dpage1 - Dpage2

ans = 
ans(:,:,1) =

     0     0
     0     0


ans(:,:,2) =

     0     0
     0     0

Any thoughts on checking the other page* functions?

[Walter Roberson]

Good point, Paul.

[Adam]

Thanks for the quick replies, I will file a bug report with the mathworks and refer to this page in it.

[Paul]

@Adam

Would you mind posting back here the outcome of your interaction with Tech Support?

[Adam]

I got the following reply from Tech support.

Thanks for reporting this issue. I can also reproduce it in R2022b and R2023a Prerelease.

As far as I can see a colleague already saw the MATLAB Answers post and created an internal bug report.

I will link your case to it, so you will be notified when the bug was fixed.

Besides this I will nominate this bug for a R2022b update release.

So it seems we can expect a fix for this quite soon via an update.

I will update when I get some more information

[Paul]

Thanks! I always find it interesting when they find something worthy of an "internal bug report," but don't list it on the the external Bugs page. The criteria for what's shown on that page has always been a mystery to me.

[Adam]

Yeah, also, I would expect that a change to the function shows up in the Version History part of the documentation for that function. The pagemrdivide page does not list any change to the function, so we were not expecting any change during debugging of this issue and lost quite a lot of time due to this.

The pagemldivide page does mention a performance increasing change in its version history, maybe they also touched mrdivide with this change.

[Heiko Weichelt]

Thanks for reporting this. The external bug report is under review and will be published shortly (modulo holiday break).

We identified and fixed the issue and working on getting the fix out as soon as possible.

When introduced in R2022a, pagemldivide/pagemridivide only distingished between rectangular -> using QR and square -> using LU. In R2022b, we unified pagemldivide/pagemrdivide and mldivide/mrdivide using the same algorithms underneath (a few exceptions apply; compare https://www.mathworks.com/help/matlab/ref/pagemldivide.html#mw_b5069599-8b9b-4941-934f-c94c53d4dd56 with https://www.mathworks.com/help/matlab/ref/mldivide.html#bt4jslc-6).

The algorithm detecting the structure introduced the faulty behavior for complex inputs of a certain structure.

[Paul]

@Adam or anyone else ....

Any new information on this issue? I still don't see the external bug report on the bug reports page.

[Adam]

I am also still waiting for news about the issue.

They closed my ticket because of the existing internal ticket, but that means there is no information available

[Heiko Weichelt]

EBR is online:

https://www.mathworks.com/support/bugreports/2898758

As mentioned before, R2022b Update 4, which will be released in a few days, will contain the fix.

Answer 1

[Adam Danz]

Be on the lookout for the next update (update 4) to MATLAB R2022b.

3 Ways to check for MATLAB Updates

https://www.mathworks.com/help/matlab/matlab_env/check-for-software-updates.html

1. From MATLAB Desktop, go to the home tab and select the dropdown menu under Help, then select "Check for Updates".
2. Look for a red bell in the upper right corner of the desktop (it's gray when there are no available updates). Click it.
3. Check the manual download page https://www.mathworks.com/downloads/, Select "Get Updates" from the "I WANT TO" dropdown menu.

[Paul]

@Adam Danz

Are you willing and able to comment on why this bug isn't listed on the bug reports page?

More generally, are you willing and able to explain the criteria TMW uses to determine which bugs to share or not share with their customers on the bug reports page?

[Adam Danz]

I'm not a spokesman for MW, I just like to help folks out in between tasks or when I'm on a break :)

This might answer some of your questions: Bug Report FAQs.

[Paul]

Thanks for the link, never saw that before.

And thanks for helping folks out when you're on break! You should take more breaks.

I realize you can't comment on this, but:

"Published bug reports are for bugs that have been reported in this system that may be of interest to customers, based on general use of our products."

Seems like this bug would qualify, considering that many of othe bug reports are much, much more esoteric IMO as compared to core functionality like matrix division.

[Bruno Luong]

The reason might be that TMW has internal bug ticket before it has been officialy reported from us (Adam). One bug one ticket.

The bug is beeing fixed and will be released in Update 4, the next one, probably in few days or weeks. What else do you want to know?

[Paul]

I want to know why this bug is not considered worthy of being on the external bugs page. And I want to know how TMW determines, in general, which bugs "may be of interest to customers." My concern is about the process, not the status of this bug.

[Bruno Luong]

You imply that *this* bug is not logged externally because they think is not of interested to costumers, which perhaps not correct. Here is the reason

"They closed my ticket because of the existing internal ticket"

Secondly you need to talk to the specific person who has decided the bug is not logged externally and speak in the public place.

If you have experience in the large corporate as TMW you will know that is not going to happen.

[Steven Lord]

We are working on writing, reviewing, and publishing the bug report for this bug. It's taking longer than expected due to the holidays (as Heiko indicated) and other factors unrelated to whether or not this is "of interest to customers." I will make sure that when it is published either Heiko or I post a comment linking to it.

[Heiko Weichelt]

EBR is online:

https://www.mathworks.com/support/bugreports/2898758

As mentioned before, R2022b Update 4, which will be released in a few days, will contain the fix.

[Bruno Luong]

@Heiko Weichelt thanks.

Side topic: are you aware of this bug on GPU, log it or have fixed it?

It looks pretty similar to this one. If you need me to fire a bug report I'll happy to do it.

[Heiko Weichelt]

I was not aware of this but GPU code is separate and not my expertise. I'll poke some of my colleagues about it. Thanks.