On Sat, Jan 26, 2013 at 10:15 PM, Linda Alvord <[email protected]> wrote: > But if you change the data, a new challenge emerges. > f > ([: i: 0 { +.) j./ [: i: 1 { +. > g > j./&i:/@+. > > What should the answer be for two complex numbers: > $f 7j3 2j5 > 2 15 2 11 > $g 7j3 2j5 > 2 15 11 > > Probably g is better, but I'm not sure. Any ideas?
I am going to give you a non-answer, because I think it's important. For now, I would ignore the "rank greater than zero" case or I would make it an error case. That probably seems stupid, so I will try to explain: When working with code, one of the most important issue is understanding the requirements for that code. And, that's a "people thing" that drives everything else. One way to understand the requirements of course, is to experiment, and try things out. This tends to be inefficient and can consume a lot of time, but it can also give you interesting perspectives. Another way to understand requirements is to find someone that owns them and talk with them. This works best when this person exists. Ultimately, though, this is similar to the issue which writers constantly need to deal with, which is: understanding your audience. Or audiences. Anyways, the point I think I am trying to make is that there is no one answer. And, when I often tried to code "generally" to "anticipate future requirements", I have found that the best way to anticipate future requirements is to keep the code as simple as possible. Simple code is easier to work with than complex code. And, the distinguishing feature of future requirements is that I do not have them yet. What happens with complex code is that I often become somewhat paralyzed (or slowed) by "features" that no one ever wanted - it becomes hard to distinguish between aspects of the code that are important and aspects that are irrelevant. One approach that really helps here, though, involves building feature tests to represent the requirements for myself for the future. And, one of the simplest ways of making sure that those are correct involves using such tests to build the first instance of the code (that way I can review the tests when writing the code, to make sure that I feel that they represent the issues I feel are important in the implementation). Another technique that can be helpful involves enforced errors, for cases I am ignoring. The assert statement can be helpful here, but there's other things also. For example if I'm going to be writing a lot of code that works with numeric vectors of length 3, I might introduce a 0 0 0 + phrase. I sometimes wish for similarly neutral phrases for enforcing other kinds of constraints (for my taste, it needs to be fast and simple to be worth bothering with, mostly, though some applications can tolerate a defined word representing a context where I need a certain kind of data). You can get really elaborate here, also, but... simplicity is a virtue. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
