Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

[Marten van Kerkwijk]

Hi Stephan,

I fear my example about thinking about `ndarray.__array_function__`
distracted from the gist of my question, which was whether for
`__array_function__` implementations *generally* it wouldn't be handier to
have all unique types rather than just those that override
`__array_function__`. It would seem that for any other implementation than
for numpy itself, the presence of __array_function__ is indeed almost
irrelevant. As a somewhat random example, why would it, e.g., for DASK be
useful to know that another argument is a Quantity, but not that it is a
file handle? (Presumably, it cannot handle either...)

All the best,

Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

[Marten van Kerkwijk]

More specifically:

Should we change this? It is quite trivially done, but perhaps I am missing
>> a reason for omitting the non-override types.
>>
>
> Realistically, without these other changes in NumPy, how would this
> improve code using __array_function__? From a general purpose dispatching
> perspective, are there cases where you'd want to return NotImplemented
> based on types that don't implement __array_function__?
>

I think, yes, that would be the closest analogy to the python operators.
Saves you from having separate cases for types that have and do not have
`__array_function__`.


> I guess this might help if your alternative array class is super-explicit,
> and doesn't automatically call `asmyarray()` on each argument. You could
> rely on __array_function__ to return NotImplement (and thus raise
> TypeError) rather than type checking in every function you write for your
> alternative arrays.
>

Indeed.


> One minor downside would speed: now __array_function__ implementations
> need to check a longer list of types.
>

That's true.

>
> Another minor downside: if users follow the example of
> NDArrayOperatorsMixin docstring, they would now need to explicitly list all
> of the scalar types (without __array_function__) that they support,
> including builtin types like int and type(None). I suppose this ties into
> our recommended best practices for doing type checking in
> __array_ufunc__/__array_function__ implementations, which should probably
> be updated regardless:
> https://github.com/numpy/numpy/issues/12258#issuecomment-432858949
>
>
Also true. It makes me wonder again whether passing on the types is useful
at all... But I end up thinking that it is not up to an implementation to
raise TypeError - it should just return NotImplemented.

If we'd wanted to give more information, we might also consider passing on
`overloaded_args` - then perhaps one has the best of both worlds.

All the best,

Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Implementations of ndarray.__array_function__ (and ndarray.__array_ufunc__)

[Marten van Kerkwijk]

On Sun, Nov 4, 2018 at 8:57 PM Stephan Hoyer  wrote:

> On Sun, Nov 4, 2018 at 8:45 AM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> Does the above make sense? I realize that the same would be true for
>> `__array_ufunc__`, though there the situation is slightly trickier since it
>> is not as easy to bypass any further override checks. Nevertheless, it does
>> seem like it would be correct to do the same there. (And if we agree this
>> is the case, I'd quite happily implement it -- with the merger of
>> multiarray and umath it has become much easier to do.)
>>
>
> Marten actually implemented a draft version of this already in
> https://github.com/numpy/numpy/pull/12328 :). I found reading over the PR
> helpful for understand this proposal.
>
> I guess the practical import of this change is that it makes it (much?)
> easier to write __array_function__ for ndarray subclasses: if there's a
> function where NumPy's default function works fine, you don't need to
> bother with returning anything other than NotImplemented from
> __array_function__. It's sort of like NotImplementedButCoercible, but only
> for ndarray subclasses.
>

Yes, return NotImplemented if there is another array, or, even simpler,
just call super.

Note that it is not quite like `NotImplementedButCoercible`, since no
actual coercion to ndarray would necessarily be needed - with adherence to
the Liskov substitution principle, the subclass might stay intact (if only
partially initialized).


> One minor downside is that this might make it harder to eventually
> deprecate and/or contemplate removing checks for 'mean' methods in
> functions like np.mean(), because __array_function__ implementers might
> still be relying on this.
>

I think this is somewhat minor indeed, since we can (and should) insist
that subclasses here properly behave as subclasses, so if an
ndarray-specific implementation breaks a subclass, that might well indicate
that the subclass is not quite good enough (and we can now point out there
is a way to override the function). It might also indicate that the code
itself could be better - that would be a win.

But so far, I think this makes sense.
>
> The PR includes additional changes to np.core.overrides, but I'm not sure
> if those are actually required here (or rather only possible due to this
> change). I guess they are needed if you want to be able to count on
> ndarray.__array_function__ being called after subclass __array_function__
> methods.
>

It is mostly a transfer of functionality from `get_override_types_and_args`
to the place where the implementation is decided upon. Perhaps more logical
even if we do not pursue this.

>
> I'm not sure I like this part: it means that ndarray.__array_function__
> actually gets called when other arguments implement __array_function__. For
> interactions with objects that aren't ndarray subclasses this is entirely
> pointless and would unnecessarily slow things down, since
> ndarray._array_function__ will always return NotImplemented.
>

Agreed here. I did in fact think about it, but wasn't sure (and didn't have
time to think how to check) that the gain in time for cases where an
ndarray comes before the relevant array mimic (and there thus a needless
call to ndarray.__array_function__ can be prevented) was worth it compared
to the cost of attempting to do the removal for cases where the array mimic
came first or where there was no regular ndarray in the first place. But I
think this is an implementation detail; for now, let me add a note to the
PR about it.

All the best,

Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

[Marten van Kerkwijk]

Hi Stephan,

Another part of your reply worth considering, though slightly off topic for
the question here, of what to pass on in `types`:


On Sun, Nov 4, 2018 at 7:51 PM Stephan Hoyer  wrote:

> On Sun, Nov 4, 2018 at 8:03 AM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> I thought of this partially as I was wondering how an implementation for
>> ndarray itself would look like. For that, it is definitely useful to know
>> all unique types, since if it is only ndarray, no casting whatsoever needs
>> to be done, while if there are integers, lists, etc, an attempt has to be
>> made to turn these into arrays
>>
>
> OK, so hypothetically we could invoke versions of each the numpy function
> that doesn't call `as[any]array`, and this would slightly speed-up
> subclasses that call super().__array_function__?
>
> A longer-term goal that I had in mind here was generally for the
implementations to just be able to assume their arguments are ndarray,
i.e., be free to assume there is a shape, dtype, etc. That is not
specifically useful for subclasses; for pure python code, it might also
mean array mimics could happily use the implementation.  But perhaps more
importantly, the code would become substantially cleaner.

Anyway, really a longer-term goal...

All the best,

Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] out parameter for np.fromfile

[Marten van Kerkwijk]

Hi Mark,

Having an `out` might make sense. With present numpy, if you are really
dealing with a file or file-like object, you might consider using
`np.memmap` to access the data more directly. If it is something that looks
more like a buffer, `np.frombuffer` may be useful (that doesn't copy data,
but points the array at the memory that holds the buffer).

All the best,

Marten


On Sun, Nov 4, 2018 at 10:35 PM Mark Harfouche 
wrote:

> I was wondering what would your thoughts be on adding an output parameter
> to np.fromfile?
>
> The advantage would be when interfacing with executables like ffmpeg
> which are arguably easier to use by calling them as a subprocess compared
> to a shared library in python.
>
> Having the output parameter in np.fromfile would enable pre-allocation of
> large arrays that are reused during the computation of new image frames
> when decoding large video files.
>
> Thoughts are appreciated!
>
> Mark
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Prep for NumPy 1.16.0 branch

[Marten van Kerkwijk]

For astropy, we also waiting a little before having a rip-python2-out
fiesta.

I think it is worth trying to get matmul in 1.16, independently of
__array_function__ - it really belongs to ufunc overwrites and all the
groundwork has been done.

For __array_function__, is it at all an option to go to the
disable-by-default step? I.e., by default have array_function_dispatch just
return the implementation instead of wrapping it? Though perhaps reversion
is indeed cleaner; most people who would like to play with it are quite
able to install the development version...

-- Marten

On Sun, Nov 4, 2018 at 10:43 PM Mark Harfouche 
wrote:

> > Thoughts on how to proceed are welcome.
>
> I've been involved in scikit-image and that project  tore out the python2
> only code rather quickly after 2.7 support was dropped. I think it caused a
> few hiccups when backporting bugfixes. I imagine that `1.16.1` and `1.16.2`
> releases will come out quickly and as such, I think removing `if else`
> statements for python2 immediately after `1.16` is released will cause
> annoyances in the first few months bugs are being ironed out.
>
> My 2cents.
>
> On Sun, Nov 4, 2018 at 10:04 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Sun, Nov 4, 2018 at 6:16 PM Stephan Hoyer  wrote:
>>
>>> On Sun, Nov 4, 2018 at 10:32 AM Marten van Kerkwijk <
>>> m.h.vankerkw...@gmail.com> wrote:
>>>
 Hi Chuck,

 For `__array_function__`, there was some discussion in
 https://github.com/numpy/numpy/issues/12225 that for 1.16 we might
 want to follow after all Nathaniel's suggestion of using an environment
 variable or so to opt in (since introspection breaks on python2 with our
 wrapped implementations).  Given also the possibly significant hit in
 performance, this may be the best option.
 All the best,

 Marten

>>>
>>> I am also leaning towards this right now, depending on how long we plan
>>> to wait for releasing 1.16. It will take us at least a little while to sort
>>> out performance issues for __array_function__, I'd guess at least a few
>>> weeks. Then a blocker still might turn up during the release candidate
>>> process (though I think we've found most of the major bugs / downstream
>>> issues already through tests on NumPy's dev branch).
>>>
>>
>> My tentative schedule is to branch in about two weeks, then allow 2 weeks
>> of testing for rc1, possibly another two weeks for rc2, and then a final.
>> so possibly about six weeks to final release. That leaves 2 to 4 weeks of
>> slack before 2019.
>>
>>
>>> Overall, it does feels a little misguided to rush in a change as
>>> pervasive as __array_function__ for a long term support release. If we
>>> exclude __array_function__ I expect the whole release process for 1.16
>>> would go much smoother. We might even try to get 1.17 out faster than
>>> usual, so we can minimize the number of additional changes besides
>>> __array_function__ and going Python 3 only -- that's already a good bit of
>>> change.
>>>
>>
>> I would like to get 1.17 out a bit early. I'm not sure how many backwards
>> incompatible changes we want to have in the first post python2 release. My
>> initial thoughts are to drop Python 2.7 testing, go to C99, and get the new
>> fft in. Beyond that, I'm hesitant to start tearing out all the Python2
>> special casing in the first new release, although that could certainly be
>> the main task for 1.17 and would clean up the code considerably. It might
>> also be a good time to catch up on changing deprecations to errors.
>> Thoughts on how to proceed are welcome.
>>
>>
>>> Note that if we make this change (reverting __array_function__), we'll
>>> need to revisit where we put a few deprecation warnings -- these will need
>>> to be restored into function bodies, not their dispatcher functions.
>>>
>>> Also: it would be really nice if we get matmul-as-ufunc in before (or at
>>> the same time) as __array_function__, so we have a complete story about it
>>> being possible to override everything in NumPy. This is another argument
>>> for delaying __array_function__, if matmul-as-ufunc can't make it in time
>>> for 1.16.
>>>
>>
>> That's two votes for matmul-as-ufunc. How much would it cost to simply
>> make __array_function__ a nop?
>>
>> Chuck
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] out parameter for np.fromfile

[Mark Harfouche]

Thanks Marten.

I tried memap for a few things but it seemed to create an other OS level
buffer in specific situations. I think the `seek` operation in the `memmap`
also caused some performance bottlenecks. Maybe I'll have time to summarize
my findings an other day.

The particular usecase of `ffmpeg` is tricky since it is grabbing a lot of
data from `stdout` which isn't a typical file buffer. Specifically, it is
often `buffered` but `unseekable`.

On Mon, Nov 5, 2018 at 9:38 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Hi Mark,
>
> Having an `out` might make sense. With present numpy, if you are really
> dealing with a file or file-like object, you might consider using
> `np.memmap` to access the data more directly. If it is something that looks
> more like a buffer, `np.frombuffer` may be useful (that doesn't copy data,
> but points the array at the memory that holds the buffer).
>
> All the best,
>
> Marten
>
>
> On Sun, Nov 4, 2018 at 10:35 PM Mark Harfouche 
> wrote:
>
>> I was wondering what would your thoughts be on adding an output parameter
>> to np.fromfile?
>>
>> The advantage would be when interfacing with executables like ffmpeg
>> which are arguably easier to use by calling them as a subprocess compared
>> to a shared library in python.
>>
>> Having the output parameter in np.fromfile would enable pre-allocation
>> of large arrays that are reused during the computation of new image frames
>> when decoding large video files.
>>
>> Thoughts are appreciated!
>>
>> Mark
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy pprint?

[Foad Sojoodi Farimani]

Hello everyone,

Following this question , I'm
convinced that numpy ndarrays are not MATLAB/mathematical multidimentional
matrices and I should stop expecting them to be. However I still think it
would have a lot of benefit to have a function like sympy's pprint to
pretty print. something like pandas .head and .tail method plus  .left
.right .UpLeft .UpRight .DownLeft .DownRight methods. when nothing
mentioned it would show 4 corners and put dots in the middle if the array
is to big for the terminal.

Best,
Foad
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy pprint?

[Mark Harfouche]

Foad,

Visualizing data is definitely a complex field. I definitely feel your pain.
Printing your data is but one way of visualizing it, and probably only
useful for very small and constrained datasets.
Have you looked into set_printoptions

to see how numpy’s existing capabilities might help you with your
visualization?

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.
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.

Your original post seems to have some confusion about C Style vs F Style
ordering. I hope that has been resolved.
There is also a lot of good documentation
https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html#numpy-for-matlab-users-notes
about transitioning from matlab.

Mark

On Mon, Nov 5, 2018 at 4:46 PM Foad Sojoodi Farimani 
wrote:

> Hello everyone,
>
> Following this question ,
> I'm convinced that numpy ndarrays are not MATLAB/mathematical
> multidimentional matrices and I should stop expecting them to be. However I
> still think it would have a lot of benefit to have a function like sympy's
> pprint to pretty print. something like pandas .head and .tail method plus
> .left .right .UpLeft .UpRight .DownLeft .DownRight methods. when nothing
> mentioned it would show 4 corners and put dots in the middle if the array
> is to big for the terminal.
>
> Best,
> Foad
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy pprint?

[Eric Wieser]

Hijacking this thread while on the topic of pprint - we might want to look
into a table-based `_html_repr_` or `_latex_repr_` for use in ipython -
where we can print the full array and let scrollbars replace ellipses.

Eric

On Mon, 5 Nov 2018 at 21:11 Mark Harfouche  wrote:

> Foad,
>
> Visualizing data is definitely a complex field. I definitely feel your
> pain.
> Printing your data is but one way of visualizing it, and probably only
> useful for very small and constrained datasets.
> Have you looked into set_printoptions
> 
> to see how numpy’s existing capabilities might help you with your
> visualization?
>
> 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.
> 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.
>
> Your original post seems to have some confusion about C Style vs F Style
> ordering. I hope that has been resolved.
> There is also a lot of good documentation
>
> https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html#numpy-for-matlab-users-notes
> about transitioning from matlab.
>
> Mark
>
> On Mon, Nov 5, 2018 at 4:46 PM Foad Sojoodi Farimani <
> f.s.farim...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> Following this question ,
>> I'm convinced that numpy ndarrays are not MATLAB/mathematical
>> multidimentional matrices and I should stop expecting them to be. However I
>> still think it would have a lot of benefit to have a function like sympy's
>> pprint to pretty print. something like pandas .head and .tail method plus
>> .left .right .UpLeft .UpRight .DownLeft .DownRight methods. when nothing
>> mentioned it would show 4 corners and put dots in the middle if the array
>> is to big for the terminal.
>>
>> Best,
>> Foad
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy pprint?

[Foad Sojoodi Farimani]

Dear Mark,

Thanks for the reply. I will write in between your lines:

On Tue, Nov 6, 2018 at 6:11 AM Mark Harfouche 
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.

> There is also a lot of good documentation
>
> https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html#numpy-for-matlab-users-notes
> about transitioning from matlab.
>
I have seen this one and many others, which I'm trying to comprehend and
then put in some slides made in Jupyter notebooks. Maybe when they are
ready I will create a GitHub repo and upload them alongside the possible
video recordings of the workshops.

Foad

> Mark
>
> On Mon, Nov 5, 2018 at 4:46 PM Foad Sojoodi Farimani <
> f.s.farim...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> Following this question ,
>> I'm convinced that numpy ndarrays are not MATLAB/mathematical
>> multidimentional matrices and I should stop expecting them to be. However I
>> still think it would have a lot of benefit to have a function like sympy's
>> pprint to pretty print. something like pandas .head and .tail method plus
>> .left .right .UpLeft .UpRight .DownLeft .DownRight methods. when nothing
>> mentioned it would show 4 corners and put dots in the middle if the array
>> is to big for the terminal.
>>
>> Best,
>> Foad
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy pprint?

[Foad Sojoodi Farimani]

It is not highking if I asked for it :))
for IPython/Jupyter using Markdown/LaTeX would be awesome
or even better using HTML to add sliders just like Pandas...

F.

On Tue, Nov 6, 2018 at 6:51 AM Eric Wieser 
wrote:

> Hijacking this thread while on the topic of pprint - we might want to look
> into a table-based `_html_repr_` or `_latex_repr_` for use in ipython -
> where we can print the full array and let scrollbars replace ellipses.
>
> Eric
>
> On Mon, 5 Nov 2018 at 21:11 Mark Harfouche 
> wrote:
>
>> Foad,
>>
>> Visualizing data is definitely a complex field. I definitely feel your
>> pain.
>> Printing your data is but one way of visualizing it, and probably only
>> useful for very small and constrained datasets.
>> Have you looked into set_printoptions
>> 
>> to see how numpy’s existing capabilities might help you with your
>> visualization?
>>
>> 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.
>> 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.
>>
>> Your original post seems to have some confusion about C Style vs F Style
>> ordering. I hope that has been resolved.
>> There is also a lot of good documentation
>>
>> https://docs.scipy.org/doc/numpy/user/numpy-for-matlab-users.html#numpy-for-matlab-users-notes
>> about transitioning from matlab.
>>
>> Mark
>>
>> On Mon, Nov 5, 2018 at 4:46 PM Foad Sojoodi Farimani <
>> f.s.farim...@gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>> Following this question ,
>>> I'm convinced that numpy ndarrays are not MATLAB/mathematical
>>> multidimentional matrices and I should stop expecting them to be. However I
>>> still think it would have a lot of benefit to have a function like sympy's
>>> pprint to pretty print. something like pandas .head and .tail method plus
>>> .left .right .UpLeft .UpRight .DownLeft .DownRight methods. when nothing
>>> mentioned it would show 4 corners and put dots in the middle if the array
>>> is to big for the terminal.
>>>
>>> Best,
>>> Foad
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion