[Jprogramming] monad i. : implementation question/suggestion

[Henry Rich]

> 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.

I accept this judgement.  Only someone with access to the frequencies of 
primitives is able to say.  Monad i. occurs a lot, but it's fast 
already.  My approach would save a memory-allocation-and-free for each i. .

Henry Rich

> 
> 
> 
> ----- 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.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>