Correction - 4/1000ths - care even less now. On 11/9/07, Devon McCormick <[EMAIL PROTECTED]> wrote: > > Note also that the apparent differences between the latter three in the > second-to-last set of timings is also illusory: > > (6!:2 'nopR0 i.1e6'),(6!:2 'nopRI i.1e6'),(6!:2 '+"0 i.1e6'),6!:2 '+ > i.1e6' > 2.94895 0.0156787 0.00952978 0.0135826 > (6!:2 'nopR0 i.1e6'),(6!:2 '+ i.1e6'),(6!:2 'nopRI i.1e6'),6!:2 '+"0 > i.1e6' NB. Shifted order > 2.83201 0.0135546 0.00921856 0.0132901 > (6!:2 'nopR0 i.1e6'),(6!:2 '+"0 i.1e6'),(6!:2 '+ i.1e6'),6!:2 'nopRI > i.1e6' NB. Shifted again > 2.86211 0.0129981 0.00930746 0.0136853 > > Why is there a 4/100ths of a second difference because of relative > position? I plead ignorance > and apathy: I don't know and I don't care. > > > On 11/9/07, Devon McCormick <[EMAIL PROTECTED]> wrote: > > > > Tacit may make something run faster but other considerations may greatly > > outweigh this. > > (I often prefer explicit formulations because I find them clearer and, > > very often, performance > > lust wastes the most important time - _my_ time) > > > > For instance, in your example the performance penalty is because you are > > creating a > > rank 0 verb, not because one is tacit versus explicit. > > > > nopR0=: 3 : '+y'"0 NB. Rank 0 > > nopRI=: 3 : '+y' NB. Default (infinite) rank > > 6!:2 'nopR0 i.1e5' > > 0.305895 > > 6!:2 'nopRI i.1e5' NB. Same time as each of the following > > 0.000675471 > > 6!:2 '+"0 i. 1e5' > > 0.000687262 > > 6!:2 '+ i. 1e5' > > 0.00067315 > > > > For larger argument: > > > > (6!:2 'nopR0 i.1e6'),(6!:2 'nopRI i.1e6'),(6!:2 '+"0 i. 1e6'),6!:2 '+ > > i. 1e6' > > 2.84852 0.0131968 0.00916575 0.0129643 > > > > Taking to heart the lesson we learned earlier today shows just how > > polluted these timings are: > > DAT=: i. 1e6 > > (6!:2 'nopR0 DAT'),(6!:2 'nopRI DAT'),(6!:2 '+"0 DAT'),6!:2 '+ DAT' > > 2.91231 0.00770098 0.00558609 0.00726959 > > > > > > On 11/9/07, danil osipchuk <[EMAIL PROTECTED] > wrote: > > > > > > Hello list, > > > > > > As I understand, in J you have to write tacitly to make things be fast > > > (is > > > this right?). > > > Sometimes I would like to store and to extract intermediate results > > > from > > > inside of a tacit verb, when processing large array. I believe, this > > > may > > > considerably reduce complexity and execution penalty of a verb. > > > Unfortunately, I don't see an effective way to do this. > > > The idea is something like this: > > > > > > setA =: 13 : 'A=:y'"0 > > > 6!:2 'setA i. 1000000' > > > 5.63823 > > > setA > > > +----------+-+-+ > > > |+-+-+----+|"|0| > > > ||3|:|A=:y|| | | > > > |+-+-+----+| | | > > > +----------+-+-+ > > > ^^^No, way... > > > There is no tacit representation for this. Also performance is not > > > good due > > > to the parsing inside of a loop, I guess. The name lookup and the > > > update > > > itself probably don't consume a lot, if compared to this: > > > > > > nop =: 3 : '+y'"0 > > > nop > > > +--------+-+-+ > > > |+-+-+--+|"|0| > > > ||3|:|+y|| | | > > > |+-+-+--+| | | > > > +--------+-+-+ > > > 6!:2 'nop i. 1000000' > > > 5.05352 > > > > > > Of course, the tacit equivalent of noop is much faster: > > > > > > 6!:2 '+"0 i. 1000000' > > > 0.011353 > > > > > > So, how would you deal with this? Should one really always stretch his > > > brain > > > for the pure tacit solutions without use of 'temp variables'? > > > > > > regards, > > > Danil > > > ---------------------------------------------------------------------- > > > > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > > > > -- > > Devon McCormick, CFA > > ^me^ at acm. > > org is my > > preferred e-mail > > > > > -- > Devon McCormick, CFA > ^me^ at acm. > org is my > preferred e-mail >
-- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
