On Tue, Nov 6, 2018 at 8:26 AM Foad Sojoodi Farimani <f.s.farimani@gmail.com> wrote:
Dear Mark,
Thanks for the reply. I will write in between your lines:
On Tue, Nov 6, 2018 at 6:11 AM Mark Harfouche <mark.harfouche@gmail.com> wrote:
Foad,
Visualizing data is definitely a complex field. I definitely feel your pain.
I have actually been using numpy for a couple of years without noticing these issues. recently I have been trying to encourage my collogues to move from MATLAB to Python and also prepare some workshops for PhD network of my university.
Printing your data is but one way of visualizing it, and probably only useful for very small and constrained datasets.
well actually it can be very useful. Consider Pandas .head() and .tail() methods or Sympy's pretty printing functionalities. for bigger datasets the function can get the terminals width and height and then based on the input (U(n),D(n),L(n),R(n),UR(n,m),UL(n,m),DR(n,m),DL(n,m)) display what can be shown and put horizontal 3-dots \u2026 … or vertical/inclined ones. Or id it is Jupyter then one can use Markdown/LaTeX for pretty printing or even HTML to add sliders as suggested by Eric.
Have you looked into set_printoptions to see how numpy’s existing capabilities might help you with your visualization?
This is indeed very useful. specially the threshold option can help a lot with adjusting the width. but only for specific cases.
The code you showed seems quite good. I wouldn’t worry about performance when it comes to functions that will seldom be called in tight loops.
Thanks but I know it is very bad:
it does not work properly for floats it only works for 1D and 2D there can be some recursive function I believe.
As you’ll learn more about python and numpy, you’ll keep expanding it to include more use cases. For many of my projects, I create small submodules for visualization tailored to the specific needs of the particular project. I’ll try to incorporate your functions and see how I use them.
Thanks a lot. looking forwards to your feedback
Your original post seems to have some confusion about C Style vs F Style ordering. I hope that has been resolved.
I actually came to the conclusion that calling it C-Style or F-Style or maybe row-major column-major are bad practices. Numpy's ndarrays are not mathematical multidimensional arrays but Pythons nested, homogenous and uniform lists. it means for example 1, [1], [[1]] and [[[1]]] are all different, while in all other mathematical languages out there (including Sympy's matrices) they are the same.
I'm probably missing your point, because I don't understand your claim. Mathematically speaking, 1 and [1] and [[1] and [[[1]]] are different objects. One is a scalar, the second is an element of R^n with n=1 which is basically a scalar too from a math perspective, the third one is a 2-index object (an operator acting on R^1), the last one is a three-index object. These are all mathematically distinct. Furthermore, row-major and column-major order are a purely technical detail describing how the underlying data that is being represented by these multidimensional arrays is laid out in memory. So C/F-style order and the semantics of multidimensional arrays, at least as I see it, are independent notions. András