abridged and full string representation, string() and print()

[mschauer]

For arrays, all of string, print and show produce abridged representations. I would expect string() not to omit entries for readability. This comes with representations being shortened where one would not expect it: julia> writedlm(STDOUT, [([100 for i in 1:100],)], ' ') ([100, 100, 100, 100, 100, 100, 100 … 100, 100, 100, 100, 100, 100, 100],)

[mlubin]

+1. It's a bit confusing how to print out non-abridged versions. I've resorted to loops on occasion.

[kmsquire]

writedlm seems to be base on/inspired by Matlab's dlmwrite, which is mainly for reading and writing single numerical(ish) matrices and vectors to files, so the particular example is probably more of an issue with the documentation than with string (e.g., writedlm(STDOUT, [100 for i in 1:100]', ' ') works fine, as would writing out any other single vector or matrix containing numbers, and you probably shouldn't expect it to work on much else).

Do you have a particular need for a vector of tuples of vectors (or arrays of tuples of arrays)?

I do agree that string should probably produce the unabridged representation.

For printing to the screen, at least, showall often works, though not for your specific example:

julia> showall([([100 for i in 1:100],)])
[([100, 100, 100, 100, 100, 100, 100  …  100, 100, 100, 100, 100, 100],)]

julia> showall([100 for i in 1:100]')
1x100 Int64 Array:
 100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100  100

[mschauer]

@kmsquire basically I was unaware of showall, so i thought, writedlm takes this place. But I would consider a standard way to completely and in a homoiconic way print nested structures a necessity and find it more surprising, that showall doesn't do this.

julia> showall([([100 for i in 1:100],)])
[([100, 100, 100, 100, 100, 100, 100  …  100, 100, 100, 100, 100, 100],)]

@mlubin yes, I the situation is confusing for me as well, also with regard to the docs, it is not clear to me, what "thorough", "canonical" and "informative" mean in relation to each other. show - "write an informative text representation" repr - string using the show function. print - "canonical (un-decorated) text representation" or call show string - string using the print function showall - show x, printing all elements of arrays (shallow, not deep, calls show) dump - "write a thorough text representation"

[mschauer]

I opened a separate issue #2739 for the feature, a clarification of the relation of different print functions in the docs would still be useful.

[ViralBShah]

This would be good to have for 0.2.

[JeffBezanson]

I think this is already fixed --- only the REPL shows truncated output, and string() shows everything.

[ViralBShah]

Any reason to keep this open then?

[mschauer]

Hm, then showall has no meaning anymore? A clarification, what the moral difference between print and show is in the docs would be still helpful, for example what is the reason behind julia> print(:symbol) symbol6 julia> show(:symbol) :symbol

[JeffBezanson]

print is supposed to show an undecorated, canonical text representation, and show adds formatting that says more about the object.

Also I see that print and string of >1d arrays is still giving truncated output. Maybe for those functions we should print the full data in TSV format? @StefanKarpinski

[JeffBezanson]

It also seems suboptimal to have show, showall, showcompact, repl_show, and display. Surely some of these can be combined. For example writemime falls back to repl_show for text, so maybe repl_show should just be a method of display instead, and have the repl call display. If print shows full matrices as TSV, then showall can probably just be deleted. @stevengj @ViralBShah @StefanKarpinski

[stevengj]

Yes, it would certainly be feasible to replace repl_show(io, x) with display(io, ::@MIME("text/plain"), x), since the latter just calls the former now anyway.

If the REPL then calls display(x) instead of repl_show, it will automatically use a multimedia display of x if one is available (e.g. Image could automatically display in ImageView). I considered including this in my multimedia patch, but it seemed a dramatic enough change to be considered separately.

[StefanKarpinski]

I rather like where this is headed since it seems to build the general idea of being able to display things by various mime types into the base library. Considering showing something the be displaying it as text/plain seems natural to me. I wonder if it makes sense to distinguish showing a human-readable, truncated version of something versus a machine-parseable, complete version of something via their mime type?

[stevengj]

@StefanKarpinski, a multimedia MIME version of something is in general no more "complete" than the text/plain version; most conversions of Julia objects to MIME data will inevitably be lossy.

[StefanKarpinski]

What I meant was using mime types to distinguish different styles of printing things rather than having the menagerie of printing methods for objects that we currently have – print, show, display, repl_show, etc. – even write.

[JeffBezanson]

There is a text/csv type, and application/octet-stream. Beyond that it doesn't look like MIME types will fully solve this problem.

[JeffBezanson]

Maybe summary and showcompact can be combined too?

[ViralBShah]

DataFrames has a describe. It would be nice to consolidate.

[stevengj]

We also have help.

[JeffBezanson]

I'm wondering how best to factor this. Something like printing a truncated representation of a matrix doesn't really fit writemime, since the size to truncate to is display-specific. Is it reasonable for it to be a method of display(TextDisplay, ...)? Would IJulia's display methods then delegate to this for text/plain output?

[stevengj]

I'm pretty happy with the default matrix-truncation of repl_show in IJulia; the size is quite reasonable, and in this context it's not necessarily meaningful to try to change the size based on the display because there might be multiple front-ends.

IJulia never uses the TextDisplay, because its InlineDisplay is pushed on top of the display stack and knows how to display text/plain (it calls repl_show).

[JeffBezanson]

I'd like to get rid of repl_show. It strikes me as strange that writemime of an array as text/plain would always be truncated, but maybe that's ok? And use text/csv for full output?

[stevengj]

Since writemime is in general lossy, having truncated output for text/plain doesn't bother me—it's meant to be a representation of the data, not necessarily the data itself. For that matter, show is often lossy too.

Defining a text/csv method for AbstractMatrix and AbstractVector that writes the full array seems reasonable.

[stevengj]

See also #4065.