Replies: 4 comments 1 reply
-
This is an interesting idea, good to split this in a separate discussion/PR. Just to repeat my initial thoughts in #2155 (comment): Can you give some use cases for the new methods |
Beta Was this translation helpful? Give feedback.
-
Implementing this as an iterator instead of returning an Array with columns makes a lot of sense to me: then there is no conflict whatsoever with the current API. An iterator is not currently usable in the expression parser, but there is no reason not be able to use it in the expression parser when implementing support for loops there, see #518, #2184. |
Beta Was this translation helpful? Give feedback.
-
The motivation for introducing this feature will be reduced slightly by the adoption of #3036 solving #3014; should we close it as wontfix? Or if not, then I think it should at least be moved to a discussion, as it doesn't seem immediately actionable in any case. |
Beta Was this translation helpful? Give feedback.
-
I understand what you mean though this is a more generic idea to have more options to iterate through rows/columns and do "some" matrix operation. Let's move this idea to the discussions section, we do not have concrete plans to implement it right now (and no much demand for it so far). |
Beta Was this translation helpful? Give feedback.
-
Right now there is no comfortable way of doing something like this:
The implementation of such a function would be very easy (using generators), but I'd like to discuss the design first.
Things we should address:
mat._data
)Matrix
only (as amat.something
method), or rather as a global method that works for arrays too?columns
is at risk for being misread ascolumn
(an already existing method), whileiterateColumns
feels awkward in afor..of
(the codefor (cons col of iterateColumns(mat))
doesn't read like a grammatical sentence). MaybecolumnsOf(mat)
androwsOf(mat)
could be better. Or maybe I'm just bikeshedding.Beta Was this translation helpful? Give feedback.
All reactions