Need better array printing - especially for complex arrays

[StefanKarpinski]

Our array printing is currently quite embarrassing. It needs to be fixed.

[ViralBShah]

Actually, while we are at it, perhaps we should think of what features we should have in printing. Do we want to support a simple markup (maybe just basic html tags)? The markup can be then interpreted differently in different environments such as the console, an IDE, in a browser etc. That way, we can avoid hardcoding newlines and spaces into the printed output, and let the presentation layer figure it out. For example, if you resize the window, things can be made to look nicer automatically etc.

[StefanKarpinski]

That's a cool idea, but I'm not sure we should go there just yet. Maybe we can make a speculative feature issue for that one.

[ViralBShah]

Agree that this is for a future date. This was the first realization I had when I tried repl-cloud.

-viral

On Jun 3, 2011, at 7:36 PM, StefanKarpinski wrote:

That's a cool idea, but I'm not sure we should go there just yet. Maybe we can make a speculative feature issue for that one.

Reply to this email directly or view it on GitHub:
#29 (comment)

[ViralBShah]

Might be worthwhile to implement printf, and then implement pretty printing of arrays with printf. What's the way to do this? Implement printf in julia, or is it possible to just call the C printf?

[ViralBShah]

Well, I guess printf can be done easily:

julia> ccall(:printf, Void, (Ptr{Uint8}, Int32, Int32), "%d, %d\n", 1, 2)
1, 2

[ViralBShah]

This crashes though:

julia> ccall(:printf, Void, (Ptr{Uint8}, Float64, Int32), "%5.2lf, %d\n", 1/3, 2)
mach_port_mod_refs(reply_port) failed: (os/kern) invalid name
julia(49885,0x7fff70bafcc0) malloc: *** error for object 0x1010b7ba8: pointer being freed was not allocated

[StefanKarpinski]

I'm guessing that it may have something to do with calling a varargs function. I'm not convinced this is the best way for us to do this, especially since printf is notoriously unsafe. That's acceptable in C because lots of things are unsafe, so printf is in equally dodgy company, but Julia code really ought to be much safer.

[JeffBezanson]

Works on linux. But yes, there's probably something strange about passing arguments of different types to a varargs function.

We should write a wrapper for printf that looks at the format string to check/convert arguments, then calls printf on each format specifier individually.

[StefanKarpinski]

I can take that on. Parsing strings is something I've done a lot of in Julia at this point.

[StefanKarpinski]

This is shockingly hard to implement.

[StefanKarpinski]

This is like 90% done as of d1af957. The only thing that remains is to implement new printing for tensors with N ≥ 3. Any thoughts on how that should work?

[JeffBezanson]

This is so great. Bravo.
Can't N-d arrays display a series of slices like they used to? No additional work is needed. I see my code to do that has been deleted ;)

A couple comments:

1. I don't like that 1-d arrays look the same as 1xN arrays:

julia> rand(3)
3-element Float64 Array:
 0.62891254833711341 0.14606580619349141 0.84381987352173238

julia> rand(1,3)
1x3 Float64 Array:
 0.79781283426537208 0.20546768541258831 0.25826778395199779

This is especially confusing in light of how our [] syntax works.

2. Complex numbers seem to be tricky:

julia> complex(rand(4,4),rand(4,4))

4x4 Complex128 Array:
 0.68162889320235931 + 0.67685489562472401im  :  0.60328471800565153 + 0.54200719032276257im
 0.57500572887828594 + 0.15107298345567055im     0.75639571382615522 + 0.78558217991623347im
 0.70901455376957778 + 0.13065340624964672im     0.88806184730527993 + 0.6202979241604607im 
 0.96557556248153475 + 0.593232999318827im        0.4792539900349897 + 0.73795275897182777im

There's a misaligned decimal in there.

3. Obviously what we need next is to show fewer decimal places. I can only see 3 columns in a default terminal, which is very little.

[JeffBezanson]

OK, another one: using this format for cell arrays makes certain data structures really ugly:

julia> ({1,2,3},{2,3})
(3-element Any Array:
 1 2 3,2-element Any Array:
 2 3)

I think the former special case for 1-d arrays was justified.