# How to work around Mathematica hanging when showing a large SparseArray?

Bug introduced in 9.0 and fixed in 9.0.1

In Mathematica 9, if I display any large SparseArray object in the default way (which looks something like SparseArray[<97293>, {25000, 25000}]), the MathKernel process will keep using 100% CPU, the Front End will hang and eventually display the "Kernel is not responding to a dynamic evaluation; Abort or Continue waiting?" dialog. Pressing Abort will kill the kernel process.

I am looking for a way to avoid / work around this.

### Reproducing the problem

Try

g = RandomGraph[{25000, 50000}];
AdjacencyMatrix[g]  (* note missing semicolon *)


In a few seconds after the result is displayed Mathematica 9 will hang in the sense that:

• the beachball cursor shows intermittently (on OS X)
• the kernel uses 100% CPU (one core)
• subsequent evaluations will be impossible until the kernel is killed

Mathematica 8 will not hang.

### Observations

• Not displaying the SparseArray (putting a semicolon after AdjacencyMatrix[g];) avoid the problem.

• The displayed form of the SparseArray is very short. This is true even for the cell expression. The problem is not caused by an overwhelming amount of data being sent to the front end.

• I still want to keep track of how many non-zero elements there are in the SparseArray so I would like to display it

• Disabling Dynamic updating from the Evaluation menu does not change anything. That would have been a usable temporary workaround.

• The problem does not appear when using the command line version (kernel only) of Mathematica

• Killing the kernel manually (not using the front end) causes INTERNAL SELF-TEST ERROR: Kernels|c|6568

I believe this to be a bug and I'll contact support, but some analysis of why the problem happens would be useful to work around it. Or perhaps just a way to find the number of non-zero elements quickly. Then maybe I could write an alternate Format for SparseArray objects.

### Version & system info

This happens with Mathematica 9.0.0.0 on OS X 10.8.2, 16 GB RAM. Can someone on OS X try to reproduce the problem?

-
Also works very zippy here on V9, Win 7 64 bit, 16GB RAM, Intel i7. –  Yves Klett Jan 17 '13 at 18:32
@Yves and Silvia Thanks for testing this! Can you please check the CPU usage of the MathKernel process too and confirm that after the result is returned, it is not using any more CPU time? The result is returned in an instant here as well, but the kernel hangs after the result is returned. –  Szabolcs Jan 17 '13 at 18:55
The evaluation and display was instantaneous (v9 on OS X 10.8.2), but MathKernel does continue to eat 100% CPU after the display. Although the cell bracket indicates that the evaluation is complete, it hangs/waits on the next evaluation. –  The Toad Jan 17 '13 at 19:00
Yes, I can confirm the problem. It looks like a problem with the suggestion bar. With the bar disabled, everything looks fine. With the bar enabled, the kernel in charge of evaluation crashed automatically. –  Silvia Jan 17 '13 at 19:31
It seems it was noted here already. –  b.gatessucks Jan 17 '13 at 20:37

As Silvia notes in the comments, this behaviour is because of the predictive interface that is new in version 9. Mathematica tries to inspect the contents of the output to determine which contextual menu options to show in the suggestions bar depending on whether it is an array of integers/reals/mixed or if it is square/rectangular, etc. My guess is that somewhere along the line in the implementation, they must be inadvertently converting the sparse matrix to a full one.

One obvious solution then, is to simply disable the suggestive interface. This however disables it for all notebooks and all operations. An alternative to this would be to disable it only if the output contains a SparseArray object. This can be done using the $Pre and $Post commands:

$Pre = (SetOptions[EvaluationNotebook[], ShowPredictiveInterface -> True]; #) &$Post = Function[expr,
If[
FreeQ[expr, SparseArray],
expr,
SetOptions[EvaluationNotebook[], ShowPredictiveInterface -> False];expr
],
HoldAll
]


The $Pre setting is necessary to turn it back on for the next evaluation after $Post turns it off (or might have turned it off).

-
P.S. The wonky indenting is due to this bug –  The Toad Jan 17 '13 at 20:32