Alexander Mikhailov wrote: > found out that boxes slow things down quite > noticeably. So I'm trying to avoid need > for boxes as much as I can
Oh, thought you wanted to avoid boxes because you didn't like having to write extra code to do the boxing and unboxing (or found the resultant code harder to read than if the boxes were implied). I didn't address performance at all. My general advice is to write your programs in the natural way, and if that turns out to be slow, ask here. I wouldn't advise adopting any apriori coding strictures. That said, there are some guidelines (such as don't process a large number of boxes, or try to process as much data "at once" as possible), but these are not hard and fast rules. Now, one source of slowness is writing J programs the "natural way", where your natural inclinations were formed by using a scalar programming language. That is, don't try to write C (or Java, or whatever), in J. Write J in J. But once you've gotten the hang of that and you a natural J program you find unacceptably slow, then please raise the issue here, on these Forums. At the very worst, we'll probably be able to help you rephrase your expressions, or give you tips. At best, Roger might agree that the slowness is unreasonable, and improve the interpreter, to everyone's benefit. But I don't think you're writing "unnatural" boxy J programs. You clearly stated the uses of boxes in J: "boxes in J was to allow to have elements of different "kinds" - like ranks, or lengths, or types - in the same array" [1], so you're not abusing them or trying to get them to fit some pre-conceived mental model. So unless you have a specific boxy program that you think is too slow, then I'd say this is a non-issue and tell you not to worry about it. Go ahead and use boxes, they're useful & were included for a reason. But if you're specifically worried about this problem: > Once I was solving a problem "write a program > which puts + - * / ^ and () operations around > five 9 to make 1000", and found out that boxes > slow things down quite noticeably. then I'd be very interested to see your program. Both of them, actually, the boxy one and the final "fast" one. Maybe we can find a way to retain the simplicity of the boxy one and yet attain the speed of the fast one. Or maybe not. In either case I'm interested, this is one of those perennial problems I see and never get around to solving (and at first blush I can't see a way around the combinatorial explosion). -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
