[moving this to devel now] Am 24.10.2017 um 15:13 schrieb Artur Tarassow: > Am 24.10.2017 um 14:36 schrieb Sven Schreiber: >> Because each call to randgen1() should be giving you a new random >> number, if you know what I mean. In the original code (now in >> SBslow()) this looks different. > > Good point, Sven. I was also thinking about the purpose for the 2nd > draw. It's actually taken from K. Sheppard's code. Please show us. From a quick look at what he has online it didn't seem to me that way.

> Are there any theoretical points on this? Of course drawing another > time costs computational time... Well it's quite a different thing. And yes, a side effect is more computational effort. > Yes, we have to call SB() each time. I guess that incorporating the > MC-part (calling SB many times) into the function environment could > speed up things due to reduced transfer costs (copy/return). As I said, by using the 'const' declaration most of the copy should be gone I'd hope.

> its current form, SB() is very flexible and not limited to some > specific purpose (some specific time-series model or so). Well, you could add an optional argument 'numdraws' or something. If numdraws==1 (the default) everything stays as it is now. Otherwise you return a matrix with the number of columns equal to numdraws. This might save you some function call overhead.

> Still, the MATLAB example shares the same architecture and is so much > faster. Yes, it is an interesting comparison in any case. Maybe Matlab is doing some just-in-time compilation, don't know.

Am 24.10.2017 um 15:55 schrieb Artur Tarassow: > Am 24.10.2017 um 15:38 schrieb Sven Schreiber: >> [moving this to devel now] >> >> Am 24.10.2017 um 15:13 schrieb Artur Tarassow: >>> Am 24.10.2017 um 14:36 schrieb Sven Schreiber: >> >>>> Because each call to randgen1() should be giving you a new random >>>> number, if you know what I mean. In the original code (now in >>>> SBslow()) this looks different. >>> >>> Good point, Sven. I was also thinking about the purpose for the 2nd >>> draw. It's actually taken from K. Sheppard's code. >> >> Please show us. From a quick look at what he has online it didn't >> seem to me that way. > > Please look at slide 34: > https://www.kevinsheppard.com/images/6/64/AFE_Week_1_handout.pdf Yes, well, but it's an old handout, and is that actually used in his current production code? Those people make mistakes, too, you know.

I _briefly_ looked at his MFE toolbox and there the relevant code looked quite different to me.

>> As I said, by using the 'const' declaration most of the copy should >> be gone I'd hope. > > The 'const' declaration does not change (or maybe only marginally) > computational time in my examples even if the vector has 10000 rows. Too bad. >> might save you some function call overhead. > > That's a good point. Let me experiment with this. It might be a useful extension. OTOH I wouldn't expect speed wonders, either.

Am 24.10.2017 um 16:51 schrieb Artur Tarassow: > Am 24.10.2017 um 16:45 schrieb Sven Schreiber: >> Yes, well, but it's an old handout, and is that actually used in his >> current production code? Those people make mistakes, too, you know. > > Yes, of course. Guess we should correct this (potential bug) in SB() > then. For the record: I am not sure it is a bug, I'm just asking, because it seemed to me that it _might_ be a bug. I don't claim to be an expert for the underlying conceptual algorithm. I guess it would be useful if Stefano could weigh in. The question is, is the new SB() code equivalent to the old SBslow() code in terms of output, apart from any speed concerns.

Am 24.10.2017 um 15:55 schrieb Artur Tarassow: > Am 24.10.2017 um 15:38 schrieb Sven Schreiber: >> [moving this to devel now] >> >> Am 24.10.2017 um 15:13 schrieb Artur Tarassow: >>> Am 24.10.2017 um 14:36 schrieb Sven Schreiber: >> >>>> Because each call to randgen1() should be giving you a new random >>>> number, if you know what I mean. In the original code (now in SBslow()) >>>> this looks different. >>> >>> Good point, Sven. I was also thinking about the purpose for the 2nd draw. >>> It's actually taken from K. Sheppard's code. >> >> Please show us. From a quick look at what he has online it didn't seem to >> me that way. > > Please look at slide 34: > https://www.kevinsheppard.com/images/6/64/AFE_Week_1_handout.pdf Yes, well, but it's an old handout, and is that actually used in his current production code? Those people make mistakes, too, you know.

Am 24.10.2017 um 18:38 schrieb Allin Cottrell: >>>>> Am 24.10.2017 um 14:36 schrieb Sven Schreiber: >>>>>> number, if you know what I mean. In the original code (now in >>>>>> SBslow()) this looks different. > I'm sure Sheppard is right (and so Artur's SB is also right). If you > used a single random value for both (i) the decision on whether to > start a new block or select a consecutive value and (ii) to select the > starting point for a new block, then your blocks would always start in > the initial 1/b fraction of the data (where b = expected block size). > And surely you don't want that. Fair enough. My question all along has been whether Artur's algorithm and/or Sheppard's handout were equivalent conceptually to some other implementations that I (only briefly) looked at -- including the previous SBslow code by Stefano et al., and also some part in Sheppard's MFE toolbox that I _thought_ was about the stationary bootstrap and that was different from the handout.