Julia: Inconsistent array indentation in REPL

[JaredCrean2]

julia> n = 8000512
8000512

julia> n./(16:16:208)
13-element Array{Float64,1}:
 500032.0      
 250016.0      
      1.66677e5
 125008.0      
      1.00006e5
  83338.7      
  71433.1      
  62504.0      
  55559.1      
  50003.2      
  45457.5      
  41669.3      
  38464.0 

using julia version:

Julia Version 0.4.4-pre+35
Commit 1a9429e* (2016-02-12 13:21 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i7 CPU       Q 820  @ 1.73GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[StefanKarpinski]

They're consistently aligned on the decimal point. What would you expect here?

[vtjnash]

Why does grisu switch formatting? Are we confusing it by adding .0 without accounting for it in the length cutoff?

[JaredCrean2]

I expected the leftmost characters to be aligned. Having different indentations looks messy to me. I was also surprised by the format switching back and forth

[JeffBezanson]

The exact cutoffs used can be debated, but I don't think there is a better way to show arrays with values of widely varying magnitude. How would you show an array that contains both 1.1 and 1.1e100? I think aligning the decimal points is essential.

[El-Zurdo-Sordo]

The problem is that only two of them are in scientific notation. If they really are of widely varying magnitude, then all of them should be in scientific notation and aligned by the decimal point, not mixed, where if you are not careful, you might miss the e5 at the end of two elements.

[JaredCrean2]

I would guess that the two values are in scientific notation because they have more digits after the decimal than the others. Making the entire array consistent would require inspecting the entire array before printing any elements, which could entail a significant performance hit for large arrays.

I do see the argument for not aligning the first characters because it would make the e5 easy to miss. I guess the current behavior is the best choice to handle the general case.

[KristofferC]

require inspecting the entire array before printing any elements, which could entail a significant performance hit for large arrays.

Shouldn't this be insignificant as compared to actually printing the elements. You only have to inspect those that you are going to print.

[JeffBezanson]

Yes, it does seem possible to pick scientific notation or not for the whole array. People sometimes get annoyed by 3e0 though.

[vtjnash]

the current behavior was decided upon in https://github.com/JuliaLang/julia/issues/6608 after review of the alternatives and implemented in https://github.com/JuliaLang/julia/commit/5d2a0ec06761ea2b445909757d7744b9f7a93072.

[JaredCrean2]

Interesting read. I like the idea of having a way for the user to specify a printing mode, like Matlab's format option. There will always be cases when even the best generic solution won't be optimal.