[BUG] Printing arrays does not match standard NumPy

[sfe-SparkFro]

Describe the bug

Calling print(my_array) often does not match standard NumPy output. Multi-dimensional arrays also only summarized (inserted ... when the axis is long) along one axis; all other axes get fully printed, resulting in the REPL getting flooded with numbers if a large multi-dimensional array is printed. And there is no padding to align elements, so it can be hard to see what column an element is aligned with

ulab version: 6.8.0-4D-c

To Reproduce

Some examples:

# Multi-dimensional arrays only summarize (inserted `...`) along one axis
# Also happens with 3D and 4D arrays
my_array = np.zeros((25, 50), dtype=np.uint8)
print("Example 1 - Axis summarization")
print(my_array)

# Padding is not added to align elements
my_array = np.zeros((6, 6), dtype=np.uint8)
my_array[0:3, :] = 255
my_array[2:4, 2:4] = 50
print("Example 2 - Padding")
print(my_array)

Expected behavior

Example 1 - Axis summarization
[[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]]
Example 2 - Padding
[[255 255 255 255 255 255]
 [255 255 255 255 255 255]
 [255 255  50  50 255 255]
 [  0   0  50  50   0   0]
 [  0   0   0   0   0   0]
 [  0   0   0   0   0   0]]

Actual behavior

Example 1 - Axis summarization
array([[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, 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, 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]], dtype=uint8)
Example 2 - Padding
array([[255, 255, 255, 255, 255, 255],
       [255, 255, 255, 255, 255, 255],
       [255, 255, 50, 50, 255, 255],
       [0, 0, 50, 50, 0, 0],
       [0, 0, 0, 0, 0, 0],
       [0, 0, 0, 0, 0, 0]], dtype=uint8)

Additional context

There are other minor discrepancies, like ulab wrapping arrays with array(..., dtype=...) and ulab including parentheses when standard NumPy does not. Although I don't think the print output necessarily needs to be identical to standard NumPy (that would be great!), it would be a lot nicer if summarization worked along all axes, and if padding was added for alignment elements.

[v923z]

numpy has at least 12 print options, ulab implements but two: https://numpy.org/doc/stable/reference/generated/numpy.set_printoptions.html, and implementing all of them would take effort, and flash space for something that might not be particularly relevant.

Shortening all axes shouldn't be too hard, adding padding might be a bit trickier: first, you'd have to loop through the array twice, for you can't know beforehand, how long the padding would have to be. Second, floats are not always printed nicely, e.g., you might get something like 27.0000001, when the actual value is actually 27.0. What would be the criterion for truncating or padding in these cases?

I would, however, like to point out that I wanted to implement the precision option, so that floats would have a uniform lookout.

[sfe-SparkFro]

numpy has at least 12 print options, ulab implements but two: https://numpy.org/doc/stable/reference/generated/numpy.set_printoptions.html, and implementing all of them would take effort, and flash space for something that might not be particularly relevant.

That's fair, and I agree that it's probably not needed to implement all print options of standard NumPy. Though it would be great it ulab's default printing at least matched standard NumPy's default printing.

adding padding might be a bit trickier: first, you'd have to loop through the array twice, for you can't know beforehand, how long the padding would have to be.

True. Is this a concern about performance or development effort? I'm assuming performance. I'll note that printing is fundamentally a debugging feature, and debugging features should be optimized for usefulness over performance (within reason).

How much additional time does it actually take to loop through the whole array (or just the handful of values if it gets summarized) to find the required padding length? And how significant is that compared to how long it currently takes to print?

For example:

my_array = np.zeros((50, 50), dtype=np.uint8)
t0 = time.ticks_us()
print(my_array)
t1 = time.ticks_us()
print(t1-t0)

This takes around 8ms to print on RP2350. With dtype=np.float, it's about 15ms. How much additional time would be added with padding? If it's <1ms, then IMO that's totally worth it. If it's >100ms, then arguably not. Between those extremes is debatable.

Second, floats are not always printed nicely, e.g., you might get something like 27.0000001, when the actual value is actually 27.0. What would be the criterion for truncating or padding in these cases?

Well, standard NumPy's default precision print option is 8, so:

>>> my_array = np.array([[27.0000001, 0], [0,0]])
>>> print(my_array)
[[27.0000001  0.       ]
 [ 0.         0.       ]]

Add 2 more decimal places and it rounds:

>>> my_array = np.array([[27.123456789, 0], [0,0]])
>>> print(my_array)
[[27.12345679  0.        ]
 [ 0.          0.        ]]

So at least by default, I think 8 decimal places is the answer.

I would, however, like to point out that I wanted to implement the precision option, so that floats would have a uniform lookout.

Sounds great!