Matrix power memory full error

[suazhero]

Describe the bug

Take any matrix nxn with n high enough (6x6 is enough to reproduce). Raise it to a power high enough (5 is enough on Android, 7 or 8 on hw device). You get a memory full error message!!

This is very commonly asked operations in Sr high es for graphes... Urgent patch needed!

Screenshots

To Reproduce

Just create a 6x6 matrix filled with ones and raise it to 5 (on Android) or 7-8 on real device. Fails with many others...

Expected behavior

No crash whatsoever. Please clarify what's the capability in terms of similar operations we're allowed to expect...

Environment

12.x.x on any environment. Android & hw device at least

[LeaNumworks]

Hello @suazhero, Thank you for creating this issue, it has already been corrected and the fix will be available in the next update. Have a good day!

[suazhero]

Thx :)

[LeaNumworks]

I am closing the issue since this bug does not appear anymore.

[suazhero]

Hello, where is it fixed? Cause I just tried with the very lastest master branch and still have the issue. @LeaNumworks

Edit: Ok I think things just improved a bit but the issue still occurs in case you have a matrix filled with something else than 1s or in case you raise it to a higher power. Hence my request to understand the capabilities (boundaries) of the module (since i can understand it would not be supported to raise to a very high power like 100). But here, on windows emulator, latest master branch, still fails with 6x6 1s matrix raised to power 8. Let me know whether I should take another branch.

[suazhero]

Feeback? Can you confirm you're able to reproduce? Thx @LeaNumworks Could you open it back in case you do? Generally speaking, could you also link issues to pull requests or commits for better tracking?

[EmilieNumworks]

Hi @suazhero, I can't reproduce a memory error with a 6x6 matrix full of 1 raised to power 8. I tried on the N0110 device, on the macos simulator and on the windows simulator.

The memory failure depends on what you previously input because the computation takes place in the same buffer used to store previous displayed calculations. Could you describe your scenario, maybe with screenshots?

Doing so, I discovered a weird behaviour: you can input (transpose([1,2,3,4,5,6])[1,2,3,4,5,6])^8 once without failing, but not twice, even if you clean the history (on the macos simulator). This should not be the case, the memory state should be identical at the second attempt. I am going to investigate this issue (I reopen this issue by the way).

I also found out a scrolling error doing so which I'll investigate later.

[suazhero]

Thx you for reopening. Good points you make. So i ran a few tests and here's what actually happens:

I generate the 6x6 1s matrix multiplying a 6x1 by a 1x6 matrix with 1s (less 1s to type :) - it doesn't seem to matter much doing so after some tests. I thought it did in the first place but that's actually something else)

Raise the result to 8 => OK Right after that, just issue the same command again, and you get the memory full message.

In my previous test, i generated the 6x6 matrix the same way I just described, then raised it to 6 to check whether it was ok or not and finally raised it to 8 and that's where it was failing. This mislead me to think raising to 8 wasn't ok where it actually was without similar operation before.

So it looks like the issue you just described, where it fails the second time you run large operations.

All operations described in this post were done on windows simulator.

Thx

[suazhero]

Just ran a new test with a 7x7 matrix filled with 1s generated multiplying 7x1 by 1x7 as described before. Raise the result to 8 => fails

Note that in this case, the way the 7x7 matrix is generated matters since raising to 8 the same matrix without previous operations works.

So it seems we're quite limited in that regard. I guess optimizations are needed for this module

[EmilieNumworks]

The #1317 PR should resolve the first inconsistency: inputing the same computation in the same historical context should always have the same behaviour (handling the computation or failing with memory error).

[EmilieNumworks]

The fact that memory errors occur sooner when the calculation history is more filled is inherent to how we coded things. There are different ways to improve this behaviour; we have to decide how we do it and we'll then optimise this in future versions. I let this issue open in the meantime.

[suazhero]

Thank you. Just tested that: running several times the 6x6 matrix raised to 8 power works fine. Just tried the same with the same matrix raised to 9. Works the first time, fails the next one.

Steps: 1) Create 6x6 matrix filled with 1s multiplying 6x1 by 1x6 1s matrixes 2) Raise it to 9 power => OK 3) Replay the operation => memory error

[nsajko]

@suazhero That is what Emilie meant when she said

The fact that memory errors occur sooner when the calculation history is more filled is inherent to how we coded thing.

[suazhero]

Hum, thought

"inputing the same computation in the same historical context should always have the same behaviour (handling the computation or failing with memory error)."

would mean that no matter how full the calculation history is, the result should always be the same

But ok i think i get it. Same behaviour with same history. Meaning clear after each test to verify. Ok thanks.

[EmilieNumworks]

I meant that for an identical history, the behaviour should be the same (which was not true before PR #1317). However, as @nsajko said, if you input calculations and you don't remove them from the history, same input might have different results. The more you fill the history, the less space you have in the working buffer, the more likely is the memory failure. This isn't really a bug as we know it works this way but it is indeed something we will improve in the future.