tag:blogger.com,1999:blog-5815834906618132494.post5090839097166958612..comments2019-12-01T13:02:15.490-06:00Comments on FOSS Trading: Margin Constraints with LSPMJoshua Ulrichhttp://www.blogger.com/profile/16641971932645230429noreply@blogger.comBlogger39125tag:blogger.com,1999:blog-5815834906618132494.post-25870692129806724952012-10-13T19:03:31.185-05:002012-10-13T19:03:31.185-05:00Hi Kostas,
The maxProbProfit function checks the ...Hi Kostas,<br /><br />The <i>maxProbProfit</i> function checks the margin constraint before calculating the probability of profit, and the probability of profit calculation does not currently check the margin constraint at each future time step. I would welcome suggestions about how to best incorporate this into the current code.<br /><br />Best,<br />Joshua<br />Joshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-86877710207812002612012-10-02T09:01:33.264-05:002012-10-02T09:01:33.264-05:00Hello Josh,
I have a relevant question when using...Hello Josh,<br /><br />I have a relevant question when using maxProbProfit with margin constraints. Basically when maximizing for horizon>1 , say 6 period, the function returns z- values close to -1 which means that rebalancing on each subsequent period becomes very aggressive which (in some cases) violates the margin constraint. My question is whether the maxProbProfit function takes into account the margin constraint on all subsequent periods during optimization.<br />I understand that i can cap the minimum z- values but i would expect the function to handle this.<br /><br />Many thanks in advance<br />Kostas MetaxasKostas Metaxashttps://www.blogger.com/profile/13660622390753681532noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-15238560720402424302011-11-29T10:20:45.733-06:002011-11-29T10:20:45.733-06:00Josh
My apologies - I made a mistake. The code is...Josh<br /><br />My apologies - I made a mistake. The code is working now.<br /><br />RegardsChrishttps://www.blogger.com/profile/01276455562887525056noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-26561634406070820422011-11-26T16:21:08.272-06:002011-11-26T16:21:08.272-06:00Josh
Thank you for your reply - I am however goin...Josh<br /><br />Thank you for your reply - I am however going to ignore the difference between the result in R and Excel for the moment. <br /><br />I am getting a "Error: subscript out of bounds" when I run the "# multiply each % return by last price" piece of the code you posted. Could the reason be the size of the matrix? I am working with a matrix that has 439 rows and 41 columns. Would multiplying by zero cause the error - some of the values in the matrix is zero because the price for some funds is the same for two days - resulting in the percentage difference being zero.<br /><br />I have searched the internet for an explanation of the error but could not find anything that seems related. I would appreciate your help.Chrishttps://www.blogger.com/profile/01276455562887525056noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-41375659268828960382011-11-25T09:32:42.805-06:002011-11-25T09:32:42.805-06:00Chris,
It's probably due to different calcula...Chris,<br /><br />It's probably due to different calculation methods. Read the ROC help page and compare the ROC calculation to how you're calculating % change in Excel.Joshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-36945923390661979142011-11-25T09:24:29.601-06:002011-11-25T09:24:29.601-06:00Brilliant Josh
Thank you. I replicated the calcul...Brilliant Josh<br /><br />Thank you. I replicated the calculations in Excel - to make sure that I understand what is being done where in the code you posted - and it works as I expected!<br /><br />There was an instance where the calculations in R were quite a bit different from the results in R. The two specific random values that R generated was 7.352263 and 5.678313. R gave a ROC of -0.25835388 while Excel gives -0.227678199 - which differs by 0.030675681. Do you think differences like this is small enough to ignore? R is probably more accurate in any case.Chrishttps://www.blogger.com/profile/01276455562887525056noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-70591013118704372442011-11-24T19:12:52.308-06:002011-11-24T19:12:52.308-06:00Chris,
Here's a snippet that should be close ...Chris,<br /><br />Here's a snippet that should be close to what you want to do.<br /><br /># create random price data<br />set.seed(21)<br />price <- matrix(1+rnorm(50)/10,10,5)<br />price <- rbind(runif(5)*10,price)<br />price <- apply(price,2,cumprod)<br /># calculate normalized P&L<br />library(TTR)<br /># calculate % return<br />rtns <- apply(price,2,ROC)<br /># initialize P&L object<br />pnl <- rtns<br /># multiply each % return by last price<br />for(i in 1:NCOL(pnl)) {<br /> pnl[,i] <- rtns[,i]*tail(price,1)[,i]<br />}Joshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-60979174871314201462011-11-23T00:18:44.960-06:002011-11-23T00:18:44.960-06:00Grant
I appreciate your reply. I agree that what ...Grant<br /><br />I appreciate your reply. I agree that what you have posted is a way to get CSV data in to R. I am however looking for a way to "normalize" the dollar returns. I use to do this in Excel by: converting closing prices to percentage returns and then multiplying the result by the current NAV. It is this manipulation that I want to do in R.Chrishttps://www.blogger.com/profile/01276455562887525056noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-22608153021435663522011-11-22T19:30:53.106-06:002011-11-22T19:30:53.106-06:00Hello Chris,
If you take a look at the example co...Hello Chris,<br /><br />If you take a look at the example code I posted above you can get your csv data into R with something as simple as:<br /><br />A <- read.csv("A.csv", header=FALSE, as.is=TRUE, sep=",", dec=".”)<br />B <- read.csv(“B.csv", header=FALSE, as.is=TRUE, sep=",", dec=".”)<br />.<br />.<br /><br />rtns <- cbind(A$V3,B$V3,…..)<br /><br />You can then manipulate your data in R as required.<br /><br />A$V3,B$V3,….. etc takes your data from the 3rd column.<br /><br />I’m no expert at R but this works for me, and hopefully for you too.<br /><br />GrantTradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-52138608918375406412011-11-22T14:41:18.404-06:002011-11-22T14:41:18.404-06:00Josh
In an earlier post you said that I should us...Josh<br /><br />In an earlier post you said that I should use normalized dollar returns. I have been preparing files in Excel. Is there an easy way command/method in R that I can use to normalize a file that has three columns - security name, date and NAV/close price for that day. A line in the file would for example read:<br />Fundname,20110217,1110.00<br /><br />RegardsChrishttps://www.blogger.com/profile/01276455562887525056noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-81559409434914183482011-11-14T20:38:37.353-06:002011-11-14T20:38:37.353-06:00Josh,
I have sent you the files necessary to repr...Josh,<br /><br />I have sent you the files necessary to reproduce the above results for yourself (by email).<br /><br />Please note that the above is one single report/comment which I sent in response to the conflicting expectations:<br /><br />"I would expect it to be less than 1.050796; let me know if you get a different result."<br /><br />Please take a look, because you have noted "My personal experience is that portfolios optimized for unconstrained-growth tend to be heavily concentrated in a few components". My own observations are showing this to be an issue with the integrated margining only, so this may be of interest for you also.<br /><br />Could you please also explain what "human error" you have observed.<br /><br />GrantTradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-86326994171670200712011-11-14T18:41:33.439-06:002011-11-14T18:41:33.439-06:00Grant,
Rather than making things clearer, your 4 ...Grant,<br /><br />Rather than making things clearer, your 4 comments only raise more questions. I'm afraid I can only respond to your 4 comments if you provide a reproducible example. I don't have the time to consider all the theoretical causes of the results you show, especially when one of them is human error (not necessarily yours).Joshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-79401097519573560642011-11-10T23:41:50.693-06:002011-11-10T23:41:50.693-06:00In Summary:
USING INTEGRATED MARGIN CONSTRAINTS
...In Summary:<br /><br /><b>USING INTEGRATED MARGIN CONSTRAINTS</b><br /><br />results <- optimalf(port, snow=clust, control=DEctrl, equity=equity, margin=margin)<br /><br />GHPR = <b>1.050796</b> Equity Required = <b>2e+06</b><br /><br /><br /><b>USING POST-OP MARGIN CONSTRAINTS</b><br /><br />results <- optimalf(port, snow=clust, control=DEctrl)<br /><br />GHPR = 1.493334 Equity Required = 50147451<br />GHPR = <b>1.215942</b> Equity Required = <b>2e+06</b><br /><br /><br /><b>USING POST-OP MARGIN CONSTRAINTS + RELEASING F FROM HITTING LIMITS</b><br /><br />port$maxLoss <- rep(max(port$maxLoss), N)<br />results <- optimalf(port, snow=clust, control=DEctrl)<br /><br />GHPR = 1.529956 Equity Required = 60538725<br />GHPR = <b>1.285853</b> Equity Required = <b>2e+06</b><br /><br />*********************************************<br /><br />I appreciate that this is a lot of information but hopefully it paints a clear picture now.<br /><br />GrantTradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-5940861642390549182011-11-10T23:22:18.123-06:002011-11-10T23:22:18.123-06:00Josh,
Looking at the above results further I noti...Josh,<br /><br />Looking at the above results further I noticed one other important point of interest.<br />Although I have been able to successfully rebalance portfolios by <b>NOT</b> using the integrated magining approach I did notice that the final two market systems had maxed out at f=1.000000<br /><br />This led me to believe that the port$maxLoss values were not always constraining ALL of the market-system f values between 0 and 1 when working with a multiple component case.<br /><br />It occurred to me to therefore set all the maxLoss values to a standard abitarry value that would accomodate for all components by simply setting to the smallest absolute value:<br /><br />port$maxLoss <- rep(max(port$maxLoss), N)<br /><br />This indeed proved successfull with all f$ (f-dollar) values stable at or below this absolute value.<br /><br />It was my hope that this refinement might address the margining issue we are discussing above but alas it is not related and the above integrated marginging issue still stands. However it did successfully address the f value bounding issue as you can see here:<br /><br />*********************************************<br /><br /># SETUP THE JPT<br /><br /> #port <- jointProbTable(rtns, n=rep(bins,N)) # BINNED<br /><br /> probs <- rep(1/nrow(A), nrow(A)) # RAW<br /> port <- lsp(rtns, probs) # RAW<br /><br /> <b>port$maxLoss <- rep(max(port$maxLoss), N)</b><br /><br /><br /># CALCULATE OPTIMAL F<br /><br /> #(Margin constrained)<br /> #system.time({ results <- optimalf(port, snow=clust, control=DEctrl, equity=equity, margin=margin) })<br /><br /> #(Unconstrained)<br /> system.time({ <b>results <- optimalf(port, snow=clust, control=DEctrl)</b> })<br /><br />*********************************************<br /><br />would result in the following:<br /><br />Iteration: 20000 bestvalit: -1.529956 bestmemit: 0.759071 0.248085 0.000000 0.267481 0.450634 0.907357 0.183890 0.608468 0.847335 0.883034<br /><br />which no longer hits f-value limits using the same data<br /><br />> results$G<br />[1] 1.529956<br />> # CHECK<br />> port$f <- results$f<br /><br /><b>> GHPR(port)<br />[1] 1.529956<br />> # Equity Required<br />> sum(equity/(-port$maxLoss/port$f)*unit)<br />[1] 60538725</b><br /><br />Adjusting for the available equity (equity/maginpct=2e+06) now we obtain a realistic GHPR value 0f 1.215942 that is still way above the integrated result of 1.050796 above on the same equity constraint of 2e+06:<br /><br />> weighting <- port$f/sum(port$f)/marginpct<br />> # CHECK<br />> sum(weighting)<br />[1] 2<br />> port$f <- weighting<br /><br /><b>> GHPR(port)<br />[1] 1.285853<br />> # Equity Required<br />> sum(weighting*equity)<br />[1] 2e+06</b><br /><br />GrantTradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-86493957827732132712011-11-10T22:48:56.559-06:002011-11-10T22:48:56.559-06:00*********************************************
Usi...*********************************************<br /><br />Using the integrated margin constraints:<br />results <- optimalf(port, snow=clust, control=DEctrl, equity=equity, margin=margin)<br /><br />would result in the following:<br /><br />Iteration: 20000 bestvalit: -1.050796 bestmemit: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.312016 0.000000 0.000000<br /><br />which clearly favours the 8th market-system above all else<br /><br />> results$G<br />[1] 1.050796<br />> # CHECK<br />> port$f <- results$f<br /><br /><b>> GHPR(port)<br />[1] 1.050796<br />> # Equity Required<br />> sum(equity/(-port$maxLoss/port$f)*unit)<br />[1] 2e+06</b><br /><br />*********************************************<br /><br />However if I am now to run without the integrated margin constraints<br />results <- optimalf(port, snow=clust, control=DEctrl)<br /><br />would result in the following:<br /><br />Iteration: 20000 bestvalit: -1.493334 bestmemit: 0.954889 0.332320 0.000000 0.485268 0.291476 0.806778 0.398070 0.941770 1.000000 1.000000<br /><br />which no longer favours any one market-system using the same data<br /><br />> results$G<br />[1] 1.493334<br />> # CHECK<br />> port$f <- results$f<br /><br /><b>> GHPR(port)<br />[1] 1.493334<br />> # Equity Required<br />> sum(equity/(-port$maxLoss/port$f)*unit)<br />[1] 50147451</b><br /><br />Adjusting for the available equity (equity/maginpct=2e+06) now we obtain a realistic GHPR value 0f 1.215942 that is still way above the integrated result of 1.050796 above on the same equity constraint of 2e+06:<br /><br />> weighting <- port$f/sum(port$f)/marginpct<br />> # CHECK<br />> sum(weighting)<br />[1] 2<br />> port$f <- weighting<br /><br /><b>> GHPR(port)<br />[1] 1.215942<br />> # Equity Required<br />> sum(weighting*equity)<br />[1] 2e+06</b><br /><br />*********************************************<br /><br />So taking these results alone we can see that there is indeed something untoward happening with the integrated magining approach.<br /><br />What are your thoughts on this?<br /><br />GrantTradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-40486114878644764872011-11-10T22:45:45.328-06:002011-11-10T22:45:45.328-06:00Josh,
You said:
"I would be interested in th...Josh,<br /><br />You said:<br />"I would be interested in the GHPR of the portfolio that was optimized without the margin constraint after adjusting for available equity. I would expect it to be less than 1.050796; let me know if you get a different result."<br /><br />Response:<br />I do infact optain results greater than 1.050796 even after adjusting for available equity, GHPR=1.493334 before and GHPR=1.215942 after (please see the details that follow)<br /><br />*********************************************<br /><br />Here is the setup with N = 10 stable market-systems:<br /><br /><br /># SETUP HPR DATA<br /><br /> setwd("xxxxx")<br /><br /> N <- 10 # The number of component strategies<br /><br /> A <- read.csv("A.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> B <- read.csv("B.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> C <- read.csv("C.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> D <- read.csv("D.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> E <- read.csv("E.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> F <- read.csv("F.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> G <- read.csv("G.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> H <- read.csv("H.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> I <- read.csv("I.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /> J <- read.csv("J.csv", header=FALSE, as.is=TRUE, sep=",", dec=".")<br /><br /> rtns <- cbind(<br /> A$V2,<br /> B$V2,<br /> C$V2,<br /> D$V2,<br /> E$V2,<br /> F$V2,<br /> G$V2,<br /> H$V2,<br /> I$V2,<br /> J$V2)<br /><br /># VARIABLES<br /><br /> cores = 8 # Number of CPU cores available<br /><br /> equity = 1000000 # Equity available for trading<br /> unit = 10000 # The size of one trade unit<br /> marginpct = 0.50 # Margin percentage<br /><br /> NP = 10*N # The number of population members<br /> iterations = 1000 # The maximum number of iterations<br /> crossover = 0.6 # The probability of crossover<br /><br /> bins = 20 # The number of bins<br /><br /># LOAD R PACKAGES<br /><br /> library(LSPM)<br /> library(parallel)<br /><br /># CREATE A SOCKET CLUSTER FOR ALL CORES<br /><br /> clust <- makePSOCKcluster(cores)<br /><br /># SETUP MARGIN<br /><br /> margin <- rep(marginpct*unit, N)<br /><br /># DEoptim PARAMETERS<br /><br /> #DEctrl <- list(NP=NP, itermax=iterations, CR=crossover, trace=iterations/50)<br /><br /> initialpop=matrix(runif(NP*N)/100,NP,N) # SETUP AN INITIAL POPULATION (if required)<br /> DEctrl <- list(NP=NP, itermax=iterations, CR=crossover, trace=iterations/50, initialpop=initialpop)<br /><br /># SETUP THE JPT<br /><br /> #port <- jointProbTable(rtns, n=rep(bins,N)) # BINNED<br /><br /> probs <- rep(1/nrow(A), nrow(A)) # RAW<br /> port <- lsp(rtns, probs) # RAW<br /><br />*********************************************TradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-72234488819661968462011-11-09T19:14:12.730-06:002011-11-09T19:14:12.730-06:00Grant,
My personal experience is that portfolios ...Grant,<br /><br />My personal experience is that portfolios optimized for unconstrained-growth tend to be heavily concentrated in a few components, so your results aren't terribly surprising. Try adding a maxDrawdown constraint of 5% or so and you should see more non-zero f values across components.<br /><br />I would be interested in the GHPR of the portfolio that was optimized without the margin constraint <i>after</i> adjusting for available equity. I would expect it to be less than 1.050796; let me know if you get a different result.<br /><br />The objective function code is in C, so you would have to look at the source code for <a href="https://r-forge.r-project.org/scm/viewvc.php/pkg/src/objectiveFunction.c?view=markup&root=lspm" rel="nofollow">objectiveFunction.c</a>.<br /><br />Best,<br />JoshJoshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-87764827237244791772011-11-07T23:11:25.880-06:002011-11-07T23:11:25.880-06:00Josh,
I often find that the integrated margining o...Josh,<br />I often find that the integrated margining often reduces component f values to zero for all but one component system in a portfolio.<br /><br />E.g.<br />Results <- optimalf(Port, snow=Clust, control=DEctrl, equity=Equity, margin=Margin)<br /><br />would result in<br /><br />Iteration: 10000 bestvalit: -1.050794 bestmemit: 0.000010 0.000001 0.000005 0.000001 0.000002 0.000002 0.000003 0.311963 0.000002 0.000024<br />.....<br />Iteration: 20000 bestvalit: -1.050796 bestmemit: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.312016 0.000000 0.000000<br /><br />whereas<br />Results <- optimalf(Port, snow=Clust, control=DEctrl)<br /><br />would result in a working allocation (after adjusting post-op for actual available equity of-course) such as<br /><br />Iteration: 10000 bestvalit: -1.493334 bestmemit: 0.954889 0.332320 0.000000 1.000000 0.485268 0.291476 1.000000 0.941770 0.806778 0.398070<br /><br />Have you seen this occurring from your end? Any idea why this could be occurring? Please let me know if you might require any further information to determine why this is happening.<br /><br />Grant<br /><br />Myself, I am not sure how to peer into the objective function code to see what is causing this<br />fun <- function(f, lsp, constrFun, constrVal, margin, equity, <br /> ...) {<br /> .Call("objFun_optimalf", f, lsp, margin, equity, constrFun, <br /> constrVal, new.env(), PACKAGE = "LSPM")TradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-90128934878921425542011-09-06T12:05:16.931-05:002011-09-06T12:05:16.931-05:00Thank you for your reply Josh,
I am conversant wit...Thank you for your reply Josh,<br />I am conversant with the reason for setting MaxLoss to bound f and so really my concern was just whether you might see any implication with setting an arbitary MaxLoss such as equal to Margin when this is not actually reflected in the JPT that keeps the original MaxLoss values in place.TradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-51367411297810304592011-09-04T17:48:20.277-05:002011-09-04T17:48:20.277-05:00Hi Grant,
Changing the max loss doesn't alter...Hi Grant,<br /><br />Changing the max loss doesn't alter the <i>optimum</i> of the leverage space landscape; it only exists to bound the f values between 0 and 1. The maximum GHPR and <i>f$</i> are invariant to max loss. If you're mathimatically inclined, you could think of it as a monotonic transformation.<br /><br />Chris was asking about mutual funds without margin, so his effective margin was 100% the NAV of the fund. Setting max loss equal to the NAV is optional, but I find it easiest to think of <i>f</i> in terms of "% lost if I lose everything" rather than "% lost if the worst outcome (up to this point) occurs".<br /><br />So, it's not generally the case that you should set margin = max loss = price.<br /><br />Hope that helps.<br /><br />Best,<br />JoshJoshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-87062463219850182582011-08-21T08:45:20.028-05:002011-08-21T08:45:20.028-05:00Correction! The lsp object would look like below (...Correction! The lsp object would look like below (the above you will see was for a RegT50% example):<br /><br /><br /> V1 V2 V3<br />f 0.1 0.1 0.1<br />Max Loss -1500.0 -1500.0 -1500.0<br /> probs V1 V2 V3<br /> [1,] 0.07692308 -150.000 253.000 533.000<br /> [2,] 0.07692308 -45.333 -1000.000 220.143<br /> [3,] 0.15384615 -45.333 -64.429 220.143<br /> [4,] 0.07692308 13.000 -64.429 -500.000<br /> [5,] 0.07692308 13.000 -64.429 533.000<br /> [6,] 0.07692308 13.000 253.000 220.143<br /> [7,] 0.07692308 13.000 253.000 799.000<br /> [8,] 0.07692308 13.000 448.000 220.143<br /> [9,] 0.07692308 79.667 -64.429 -325.000<br />[10,] 0.07692308 79.667 -64.429 220.143<br />[11,] 0.07692308 79.667 -64.429 533.000<br />[12,] 0.07692308 136.000 253.000 220.143TradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-70373340619194935312011-08-21T08:35:33.455-05:002011-08-21T08:35:33.455-05:00Josh,
I am still trying to wrap my brain around t...Josh,<br /><br />I am still trying to wrap my brain around the useful advise that you gave to Chris where you said:<br /><br />"For mutual funds, the margin is the current NAV of the fund. It doesn't necessarily have to be the same as maxLoss, but setting them both to the current NAV may make interpreting the output easier."<br /><br />For purposes of this discussion lets take an IB Portfolio Margin Account trading equities which will have a margin requirement of 15% [as opposed to Reg-T's 50%].<br />Let's also assume that 1 Unit in LSPM is equal to a fixed $10,000 amount/position as opposed to a fixed number of shares [We could view this as a unit of 1 share at a price of $10,000].<br /><br />So now my question: Bearing in mind that I do not want to alter the actual JPT in anyway are there any implications that I need to be aware of when setting maxLoss equal the to actual margin requirements as just defined with the following:<br /><br /><br />port$maxLoss <- c(-1500,-1500,-1500) # 15% Margin = 15% of $10,000 [Portfolio Margin Account]<br />margin <- -port$maxLoss<br /><br /><br />I assume that this is in line with what you were suggesting above.<br /><br />Taking data(port) by way of example we would thus end up with something looking like:<br /><br /><br /> V1 V2 V3<br />f 1e-01 1e-01 1e-01<br />Max Loss -5e+03 -5e+03 -5e+03<br /> probs V1 V2 V3<br /> [1,] 0.07692308 -150.000 253.000 533.000<br /> [2,] 0.07692308 -45.333 -1000.000 220.143<br /> [3,] 0.15384615 -45.333 -64.429 220.143<br /> [4,] 0.07692308 13.000 -64.429 -500.000<br /> [5,] 0.07692308 13.000 -64.429 533.000<br /> [6,] 0.07692308 13.000 253.000 220.143<br /> [7,] 0.07692308 13.000 253.000 799.000<br /> [8,] 0.07692308 13.000 448.000 220.143<br /> [9,] 0.07692308 79.667 -64.429 -325.000<br />[10,] 0.07692308 79.667 -64.429 220.143<br />[11,] 0.07692308 79.667 -64.429 533.000<br />[12,] 0.07692308 136.000 253.000 220.143<br /><br /><br />The JPT thus remains as is with only both of the maxLoss and margins altered.<br /><br />I am wondering how this might adversely impact upon the leverage space landscape?<br />I am also wondering just why it is that you said that setting them both the same makes interpreting the output easier?TradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-24468249950662671192011-08-18T21:20:16.893-05:002011-08-18T21:20:16.893-05:00On the same page with this now. Your clarification...On the same page with this now. Your clarifications have helped with this. Thank you.TradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-74882515824377000382011-08-18T10:50:14.849-05:002011-08-18T10:50:14.849-05:00Grant,
Your understanding is close. margin and e...Grant,<br /><br />Your understanding is close. margin and equity are used as part of the objective function, but they are only checked after GHPR is calculated. Instead of returning the calculated GHPR, the objective function returns a very large number if you're outside of your margin constraints, which causes DEoptim to ignore that particular set of f values.Joshua Ulrichhttps://www.blogger.com/profile/16641971932645230429noreply@blogger.comtag:blogger.com,1999:blog-5815834906618132494.post-81132429174458221352011-08-18T02:27:20.707-05:002011-08-18T02:27:20.707-05:00Thank you for your reply Josh.
It is actually a r...Thank you for your reply Josh.<br /><br />It is actually a relief to hear you say this and based upon the great work that you have already accomplished with LSPM implementation I am pretty sure that you must be correct on this.<br /><br />However, what I have a hard time with at times is trying to convince myself of such details until I see the logic laid out in front of me, especially as I am currently new to R.<br /><br />What I am seeing (and please correct me if I am wrong) is that both current margin and current equity is being passed by the objective function:<br /><br /> fun <- function(f, lsp, constrFun, constrVal, margin, equity, <br /> ...) {<br /> .Call("objFun_optimalf", f, lsp, margin, equity, constrFun, <br /> constrVal, new.env(), PACKAGE = "LSPM")<br /><br />to the genetic process:<br /><br /> de <- DEoptim(fun, lower = l, upper = u, lsp = lsp, constrFun = constrFun, <br /> constrVal = constrVal, margin = margin, equity = equity, <br /> ...)<br /><br />So, taking the stance that you are correct (although not convinced of it myself yet / and without delving into DEoptim) my question would therefore be:<br /><br />In your second example are margin and equity not actually used as part of the objective function to steer the genetic process but simply passed through to constrain the equity within limits at the end of each generation/iteration (much like your first example and Ralph does only once at the end of the last generation)?<br /><br />I hope I even got that question right? I think that it just needs a yes or a no. If the answer is yes then I'm on your page. Thanks Josh.<br /><br />GrantTradingProhttps://www.blogger.com/profile/01987456606418594625noreply@blogger.com