How to print arrays inside functions?

It is useful to peak at an array when debugging a function. However, the macro @show prints arrays like vectors. How to print arrays in the correct REPL way?

zeros(5, 5)
#>5×5 Array{Float64,2}:
#> 0.0  0.0  0.0  0.0  0.0
#> 0.0  0.0  0.0  0.0  0.0
#> 0.0  0.0  0.0  0.0  0.0
#> 0.0  0.0  0.0  0.0  0.0
#> 0.0  0.0  0.0  0.0  0.0
function f(x)
   @show x
   return nothing
f(zeros(5, 5))
#> x = [0.0 0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0 0.0]

I also was looking for it at some point, it’s the Base.showarray function.

julia> Base.showarray(STDOUT,rand(3,3),false)
3×3 Array{Float64,2}:
 0.935581  0.591996  0.532917
 0.130619  0.385825  0.580087
 0.486295  0.323777  0.920276
1 Like

Thanks! Do you know why it’s not the default — i.e. why we don’t have

show(io::IO, X::AbstractArray) = showarray(io, X, false)

instead of this line?

When a type supports both single-line output (for things like println) and a more-verbose multi-line format, then the former is via show(io, x) and the latter is via show(io, "text/plain", x) … see:

So, in this case you can do:

julia> show(STDOUT, "text/plain", rand(3,3))
3×3 Array{Float64,2}:
 0.559556  0.520583  0.64307 
 0.300074  0.833891  0.478954
 0.266339  0.558122  0.912018

instead of using the undocumented internal Base.showarray function.

Note that show(io, "text/plain", x) is a shortcut for show(io, MIME("text/plain"), x).


I always get confused by all the printing functions, but in the end I do display(A) in my tests, is this not the way to go?

There’s nothing wrong with calling the display function in your program. But you shouldn’t call it in show(io, x), because show is different:

  • show has to write specifically to io, whereas display outputs to whatever display handler is registered.

  • show(io, x) should always output in text/plain format, whereas the display backend may choose a richer format to display if available.

1 Like

OK. It’s worth mentioning that, when I search for “julia print arrays” on google, a ton of suggestions come up (show, println, print, show, showall, showcompact and @show), none of which do what I want (pretty-printing an array as the REPL does).

Coupled with the lack of a debugger, this makes for a very frustrating experience for a casual user that wants to port their script from matlab and wants to print an array inside a loop to check it’s correct. So, if someone finds this topic by searching on google for “julia print arrays”, here’s the answer you’re looking for: display.


If you look in the manual for “pretty printing,” you’ll find the section explaining the difference between show(io, x) (terse one-line display, used e.g. in print) and show(io, "text/plain", x) (multiline verbose pretty printing, used e.g. in REPL output and display).

The three-argument show may be preferable to display if you specifically want text output (display can use e.g. graphical output for some types if the UI supports it, though you can also supply a MIME type to display) or if you want to output to a specific file/stream/buffer (not STDOUT).


The default behaviour of printing array to one line is confusing and hard to use. Would be better to switch the default behaviour.

print(zeros(4, 4))
[0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0; 0.0 0.0 0.0 0.0]

Very inconvenient if trying to print from the script.jl without notebook or REPL

Have you tried display(zeros(4, 4)) instead of print?

1 Like

Thanks @jbrea I found a way to print it in a nice way. The problem is that it is not simple and intuitive. Why forcing people to know print, display, show - and with different arguments like io or stringbuffer (if you want show to print to string and not to stdout).

1 Like

I wouldn’t mind if those extra stuff were supposed to be used only by super-users or library developers. But that’s not the case. You need to know it in the simplest case - just to be able to print things nicely.

Different contexts and use cases require different interfaces. It is neither possible nor desirable for the language to guess what the user wants.

Incidentally, please don’t resurrect old topics (the Discourse interface probably warned you about this).