Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: RE: Local macros and strings: yet another query...


From   Höchle, Daniel (MI Switzerland) <daniel.hoechle@rmf.ch>
To   <statalist@hsphsun2.harvard.edu>
Subject   Re: st: RE: Local macros and strings: yet another query...
Date   Tue, 24 Jun 2008 16:49:21 +0200

Nick and Sergiy,

Thanks again for your help.

Finally, I found a workaround for my problem. The code now looks something like this:

-- snip --

  sysuse sp500, clear
  
  * This is the manual version of the string:
  local ManualStr "myCommand, Opt1(\`Val1') Opt2(\`Val2')"
  
  * Here, the string is replicated by looping through a forval loop:
  local LoopStr "myCommand,"
  forval j=1/2 {
      local LoopStr "`LoopStr' Opt`j'(qq_Val`j'')"        // <-- use qq_ (or another string) rather than \`
  }
  local LoopStr = subinstr("`LoopStr'", "qq_", "\`", .)   // <-- replace "qq_" by "\`". This works.

  * Here is the reason why values Val1 and Val2 cannot be defined in advance:
  gen Result = .
  sum date
  local N=r(N)
  forval t=2/`N' {
	local Val1 = close[`t']
    	local Val2 = volume[`t']
      `LoopStr'    // <-- Evaluation of LoopStr
      replace Result = r(myResult) in `t'
      replace close = close[`t'-1] + Result - open  in `t'
      replace volume = volume[`t'-1] - Result + open in `t'
  }
 
-- snip --

Like this it is sufficient to derive the "LoopStr" only once. Afterwards, "LoopStr" is evaluated for observations t=2,...,`N'.

What for do I need this? I am evaluating several investment strategies. These strategies basically consist of three parts: Trading signal (should I buy or sell a certain asset on a given day t), transaction size (how much to trade), and position size (how much is held by end of the day). The size of the position by end of day t-1 impacts on the trading signal which in turn determines the position size by end of day t. Since there are various signal and position sizing algorithms I am looking at, my backtesting procedure (an ado program) should allow for quite some flexibility. To me an evaluation string (i.e. the "LoopStr") seems like a good idea for implementing such a task. Of course I totally agree with Nick's claim that one should define inputs in advance. However, I could not figure out how to efficiently code this in this specific case.

Thanks again.

Cheers,
Daniel







Any information in this communication is confidential and may be privileged or otherwise protected from disclosure without our consent. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. You are requested to please telephone or email the sender and delete this message and any attachment from your system.
	
Due to the electronic nature of e-mail, there is a risk that the information contained in this message has been modified. Consequently we can accept no responsibility or liability as to the completeness or accuracy of the information.
    
A-03-03-E


*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index