[Jprogramming] monad i. : implementation question/suggestion

[Roger Hui]

It's called an APV (arithmetic progression vector) and is
a special datatype.  Experience has shown that the
expense of the datatype (every primitive has to know about it)
is not worth the benefits (jaw dropping benchmarks).

J also does something with APVs.  Suitable for amusing 
tricks.  e.g.

   x=: i.1e6
   x=: 2 + x
   x=: o. x
   x=: _7 + x
   $ 5!:5 <'x'
49
   5!:5 <'x'
_0.71681469282041377+3.1415926535897931*i.1000000

   y=: 1e6 ? 1e6
   $ 5!:5 <'y'
6888889

What Henry is suggesting is different from an APV datatype
and is easier (only the monad i. has to know), but probably 
still not worthwhile.



----- Original Message -----
From: Don Guinn <donguinn at gmail.com>
Date: Friday, December 18, 2009 19:08
Subject: Re: [Jprogramming] monad i. : implementation question/suggestion
To: Programming forum <programming at jsoftware.com>

> 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 
> <olegykj at yahoo.com> 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 
> <HenryHRich at nc.rr.com> 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.