On Thu, Feb 27, 2014 at 8:54 AM, Pascal Jasmin <godspiral2...@yahoo.ca> wrote: > with sparse arrays though, it does something weird and not obviously > necessary: > > lr $. 0 0 3 0 5 > 3 5 (2 4)}1$.(,5);(,0);0+-~2 > > lr 10 + $. 0 0 3 0 5 0 > 13 15 (2 4)}1$.(,6);(,0);10+-~2 > > The weird part is the little piece at the end. x+-~2 is x + 2 - 2 .... or x.
Mathematically speaking , +-~2 is +0, however: typetag=: 3!:0 typetag -~2 4 typetag 0 1 In other words, -~2 is integer - this automatically ensures that sparse arrays will be integer (or a larger type) while keeping the code that emits them modular. Basically, you are seeing the result of a tradeoff. Since the linear representation of sparse arrays is not something that gets exercised often, it's important to minimize the branching in the implementation behind that representation. The more branches you have in your code, the more opportunities you are creating for errors and the harder it will be to detect and isolate those errors. Of course, if you are a big fan of errors, you might want to take a different approach here. Or, if you wanted to make heavy use of sparse arrays you might want to upgrade J with code optimized for your uses (or you might want a J subset compiler, so that you could address your issues at the application level). (Errors can actually be very useful for programmers - a skilled programmer will use errors to help them focus on what steps to take next, when writing a large program. These errors can be syntactic or runtime errors. Of course, errors are also frustrating to deal with. And, regardless of the presence or absence of errors, there are people who will blame their frustrations on their tools. And there is some justice to this, but it's only a part of the picture.) Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
