Talk:Element-wise operations

From Rosetta Code

Can we cut back on the matrix fetish? If you need it for serious work, go get a good quality matrix library for your language. Implementing your own matrix class is always a bad idea. The task could have said "vector", which is a lot simpler to write a short clean implementation for and much more to the point.

And the task with the Lisp example is lousy. Do you check if the dimensions match? Can you even tell if the object is indeed a matrix? If the dimensions are wrong, does it just blow up or silently give some undefined answer? -- Ledrug 18:57, 9 June 2011 (UTC)

It may be fine for educational purposes as long as we add a disclaimer saying that this is probably not the best way to do things in most languages (although we already have a disclaimer here that says code here shouldn't be used for so called "serious work"). This task is probably pretty much perfect for array programming languages like APL and J. --Mwn3d 20:54, 9 June 2011 (UTC)
I'm not worried about someone mistakenly using any code for mission critical job, but rather that choosing matrix as the subject here is suboptimal. The task basically wants to demonstrate operator overloading, and using a 1-D vector is good enough to show it--in fact better, because there would be less cruft involved. It's also questionable if it illustrates anything for a real matrix-oriented environment: in Matlab, you do element-wise multiplication between matrices by "a = b .* c", which is rather boring. And how is this task really unique from all the other existing matrix-related tasks on this site? --Ledrug 21:52, 9 June 2011 (UTC)
We do "suboptimal" tasks all the time (e.g. Sorting algorithms/Bogosort, and Arithmetic/Complex and Stack probably fit your third-party library argument). The point here isn't necessarily to have useful/the best code examples (though it does happen sometimes). The point is to compare languages. Just because something is boring in one language doesn't preclude it from being interesting to show in all other languages or using user-generated code (see Factorial#J). Operator overloading is not the only route to go here. Basically any mathematical task we have here that takes arguments could be done as an operator (as long as you choose a symbol). This task wants to see the language idioms related to particular matrix operations should a user decide to implement them himself. Sometimes there is hidden value in these academic exercises (which is probably why they choose to use some of them in academia). --Mwn3d 22:20, 9 June 2011 (UTC)
Hi Ledrug. What fetish? The goal of the site is language comparison although some of the algorithms shown are used in serious work. Not every language will have a matrix library. Not every program will warrent the use of a library for handling matrices. Implementing your own matrix routines is not always a bad idea. A vector, (1d), is not a matrix, (2d); and different considerations may come into play. Maybe it would help if you explained a bit more, or lurked a bit more to get a better idea of what RC and the community are trying to achieve? --Paddy3118 23:23, 9 June 2011 (UTC)
If the point of this task is to demonstrate how to work with matrices, there are already multiple other tasks doing just that. If it's to show how to iterate through an array and do something to each element, a vector suffices and would make the relevant part easier to see (and there are already multiple other tasks doing just that). Basically, how is this task not a duplicate of effort, and why does it have to be more complicated than necessary if it's just to show language features? --Ledrug 23:50, 9 June 2011 (UTC)
Hi, sometimes we do get duplicate tasks. Would you point out which other task(s) are the same as this one? Thanks. --Paddy3118 07:08, 10 June 2011 (UTC)
These tasks: vector products, Matrix multiplication, Matrix transposition, Matrix-exponentiation operator, Quaternion type, and the current one, all do pretty much the samething: represent something probably with an array, and do simple math to it. They are not exact dupes per se, but doing all of them would seriously be a duplicate of effort. Quaternion is a arguable, but all the others could have been put in the same place--I mean, what next, a task to "Display Each Element of a Matrix"? --Ledrug 21:44, 10 June 2011 (UTC)
RC does have tasks that are near duplicates, especially at the more mundane level. RC also tries to categorise those tasks and flag/remove duplicates. Speaking as just one member of a community, I personally wouldn't vote to try and remove the tasks you mention and replace them with a composite task. I might however vote for a rename of some to Matrix/Multiplication, Matrix/Transposition, Matrix/Exponation operator; which can make things a little tidier. (Like the Sorting algorithms/... tasks)
Often tasks are kept small to encourage new contributors and contributions: people have a finite time to spend and might feel prompted to contribute whole examples if the task encourages short examples. --Paddy3118 00:58, 11 June 2011 (UTC)
Then it leads back to my "using vector instead of matrix as example is better" argument, doesn't it? I don't really care how others would implement their matrix system, but if I want to write the tasks, having to do the same thing at four different places gets very tiresome. --Ledrug 02:16, 11 June 2011 (UTC)
"I don't really care how others would implement their matrix system"
Then you would miss out on useful comparisons with those languages which have different levels of support for single and two dimensional arrays. Perl and Python for example have lists that are straightforward when used to ape 1D arrays, but 2D structures can be done in more than one way - I've used dicts of tuples as well as nested lists in the past. Heavy array users might turn to add-in libraries such as numpy for Python.
I guess RC is about caring about how others might view things to some degree. I've found it useful in day-to-day life too. --Paddy3118 07:54, 11 June 2011 (UTC)
Oh please. I don't care about how people implement matrices around here, because I can write the same ad hoc stuff myself for demonstrations, and it's as unsuitable for real work as anyone else's. I don't care how LAPACK implemented matrices even though I use it on clusters all the time, because I only need to know how to use it, not reinventing one. It's not like many Python users know how the dictionary hash function works or how a .pyc corresponds to the code in a .py, is it? You sure they are missing out much? --Ledrug 08:34, 11 June 2011 (UTC)