Yes, in fact doing string rep it will show it "compressed" but I also saw other cases similar to what I gave.
On Dec 18, 2009, at 10:07 PM, Don Guinn <[email protected]> wrote: Didn't IBM's APL have a special data representation for iota? A special representation consisting of a starting number, an increment and a length. Able to handle arithmetic applied to this representation quite efficiently. On Fri, Dec 18, 2009 at 7:42 PM, Oleg Kobchenko <[email protected]> wrote: Frankly I don't see much merit if there were such optimization. Are there use cases when it is critical? Below aren't plausible. You can also have 100#2 2*i.100 etc Oleg On Dec 18, 2009, at 9:07 PM, Henry Rich <[email protected]> wrote: 100000 ts 'i. 100' 2.82902e_6 1152 100000 ts 'i. 400' 3.51904e_6 2688 100000 ts 'i. 800' 4.16341e_6 4736 Yes, it's fast; but it appears that monad i. actually creates an array. Wouldn't it be better to have a single copy of i. 16384 (or so), with data headers of all the sizes from 0 to 16384 pre-built, so that executing i. merely pointed to the correct header? If you started the use count of each of the canned headers at 1, there would be no possibility of a primitive's modifying the shared i. vector. This optimization seems obvious, so I await enlightenment from someone who knows how the interpreter works. Henry Rich ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
