Petar Mlinarić

> As a note: I compared `np.linalg.inv` with LU and Cholesky factorization. Cholesky worked in less cases than the rest and LU was slower than the inverse. It sounds strange...

> > > As a note: I compared `np.linalg.inv` with LU and Cholesky factorization. Cholesky worked in less cases than the rest and LU was slower than the inverse. >...

> An adaptive choice of **the right** (TM) method could thus be in order, depending on the size of the system to solve, or a configurable option. I'm afraid of...

> > > An adaptive choice of **the right** (TM) method could thus be in order, depending on the size of the system to solve, or a configurable option. >...

> To have > > > `lu_factor`, `gecon`, and `lu_solve` (default) > > would probably mean that we would have to do the lapack interfacing ourselves, right? Yes, we would...

Option 1 seems better to me. Personally, I like to think about multilinear operators as multi-dimensional arrays. Also, we would not need to think about `apply_adjoint`, one `apply` method would...

> Maybe it would help the discussion if we would try to list the main operations which need to be performed for multilinear operators (and for what). 1. For simulation,...

I don't have applications yet, but I guess `H` could be given elementwise or in a mode-1 matricization.

> Is there any reason why you chose linearly-spaced points as initialization? It's just the simplest thing I could think of. Note that in `mag_plot`, the log scale is applied...

> Well I guess that the x-axis can always be scaled with `ax.set_xscale('linear')` by hand, but usually this is not preferred. Also, points chosen adaptively in the logarithmic scale would...