google
NDArray support
Sometimes users want to support NDArrays in this library, e.g., np.array([[a, b], [c, d]]) to
$$\left( \begin{array}{cc}a&b \\ c&d\end{array} \right)$$
This is definitely useful, but often it is not possible to compile:
- Large arrays.
- Arrays with more than 2 dimensions.
I think we could start implementing it with reasonable restrictions (e.g., only NDArrays with <= 2 dimensions with small lengths), but it would be also good to keep discussion.
Refs:
- #38
- #53
- #75
For 2D arrays, limiting the maximum size to 10 x 10 is perhaps a reasonable starting point. Larger arrays, especially if they are dense, are not great as visual aids even if they are rendered into LaTex.
For 2D arrays, limiting the maximum size to
10 x 10is perhaps a reasonable starting point. Larger arrays, especially if they are dense, are not great as visual aids even if they are rendered into LaTex.
I think it's a great idea to constraint the maximum size of matrices. I won't use matrix larger than 10 * 10 in Latex.
@Casper-Guo Yes I think it is reasonable. maybe we restrict to show only $(R, 1)$, $(1, C)$ and $(R, C)$ arrays with size $R \le R_{max}$ and $C \le C{max}$, where $R_{max}$ and $C_{max}$ are configs defaulted to some number (10 for example)
What should the configuration interface look like? I feel this should be file level rather than function level.
cc: @lakeblair
@Casper-Guo We can start with hard-coding the constraint into the code until we decided the structure of config files.
I was able to implement a basic version of this within src/latexify/function_codegen.py by editing visit_Call
if func_str == "ndarray":
# construct matrix
matrix_str = r"\begin{bmatrix} "
# iterate over rows
for row in node.args[0].elts:
for col in row.elts:
matrix_str += self.visit(col) + r" & "
matrix_str = matrix_str[:-2] + r" \\ "
matrix_str = matrix_str[:-3] + r"\end{bmatrix}"
return matrix_str
However, this isn't very extendable especially if we want to support functions like np.eye or np.ones or np.zeroes, so do you have any suggestions on how i can implement this better?
We can also potentially support multiple types of matrix formatting (square brackets vs round brackets vs curly brackets) via a config option?
np.eye, np.ones and other matrix functions will probably be dealt with separately. I think the biggest issue with your current implementation is that it doesn’t generalize to 1D arrays / vectors
If anything, the matrix processing should probably be a separate function instead of resting in, say a visit_x. That will make implementing support for np.inv and np.transpose etc. more straightforward