This is my main concern on using the Optimize API as requirement for the contest. The Optimize API are too limitating at the moment. Until they start supporting multiple portfolios in the same algorithm they are just a pain in the neck.

Good point. I'll have to think a bit more about this, but it is not clear that one wants multiple portfolios trading on different time scales within a given algo. It should be possible to update the entire portfolio at a frequency commensurate with the highest frequency factor. It may mean that lower frequency factors need to be smoothed (low-pass filtered), so that one isn't trading on noise.

Each factor has a rebalancing period at which it maximizes its alpha. If you trade the same factor over a different time scale you'll end up losing alpha. So you want to trade each factor at its best frequency.

Also, even if you have only one factor that you trade every five days, you still do better splitting your capital in 5 interleaved sub-portfolios: trade each sub-portfolio in subsequent days and rebalance each one every 5 days.

Not sure I follow. Say a 60/40 stock/bond mix provides the SR I need. And I only need to rebalance quarterly to achieve the SR. Well, I could rebalance every day, and in the limit of negligible trading expenses, I should do potentially better, not worse, I would think.

I'm just wondering if the concept of a "holding period" on a per symbol basis is fundamentally flawed. It just seems like the factors and the factor combination method should be constructed in such a way that almost continuous portfolio adjustment would be supported (up to the frequency of the highest frequency factor).

This is not addressed on https://blog.quantopian.com/a-professional-quant-equity-workflow/. Perhaps a Q braniac could comment?

Uhmmm, the 60/40 stock/bond mix is not a factor. We are probably talking about different things.

I'll try to give more context to my arguments. A factor is the model used to explain the asset returns and it is used to predict the future assets price or return. The factor assigns a value, the score, to each asset in the trading universe that represents the prediction for the asset future returns. Classical examples of factors are: momentum, mean reversion, value, quality etc. etc.

Assumptions:
- we have a factor computed daily.
- the factor has the maximum alpha after 3 days (the spread between the mean return of lower and upper quantiles reaches its most after 3 days. This makes much more sense thinking at Alphalens report)

How can I trade this factor? First option is to trade it every 3 days, in this case I'd maximize the alpha but I wouldn't use one third of the factor computations. Second option I'd create 3 sub-portfolios, each one traded in a subsequent day, so that each one would use the factor computation that the others don't use and each sub-portfolio is rebalanced every 3 days. This method increases the IR , has lower volatility, the returns are independent from the starting day and, very important, the algorithm capacity is increased by 3 times since the capital is split between 3 sub-portfolios and the slippage impact is decreased by 3.

Thanks Luca -

I'll continue to think about this one, as it is an important point. I pinged Q support with a request for feedback on this thread. We'll see if they respond.

I was working under the assumption that daily rebalancing might be the way to go, and the framework natively supports it, but it doesn't really fit with Alphalens, for one thing, which provides guidance on what time scale a given factor should be applied. Using Alphalens, one could end up with factors on daily, weekly, bi-monthly, etc. time scales. So the question is, how to implement the factors in a single algo?

Eventually Quantopian will ask for factors only and they'll implement their algorithm combining them as they like ;)

Let's say we have a factor that we think works best with a holding period of 5 days. Could we let the optimizer compute optimal weights every day for 1/5th of our capital, and trade 5 separate 'portfolios' this way with some clever bookkeeping? Or would this disqualify us from the contest because we didn't actually use the optimizer's order() function? (Even though we did use its calculated weights)

I think I can answer my own question by reading this: https://www.quantopian.com/posts/optimize-api-required-for-allocations
It seems all orders have to go through order_optimal_portfolio() because there are some external/global restrictions that need to be applied to the order.

In that thread James Villa mentions these extra unknown restrictions can impact performance quite a bit, but we can't test these restrictions in the backtester. Thread died after that.

Thanks everyone for your input on this. Much appreciated!

It would be nice to hear from someone at Q regarding this rather than being kept in the dark. Perhaps there's a good reason for why rebalancing of multiple portfolios in the same strategy is not supported in Optimize API. One reason might be because it may be quite tricky to design and implement such a solution within Optimize API. Another reason might be that even if there is a reasonable solution available, it may not currently be an immediate priority.

Both are quite fair and understandable reasons in my book, but it would be nice to know why we're effectively 'forced' to rebalance daily with daily factors only (or create multiple strategies that rebalance on different days) unless one's happy leaving significant alpha on the table.

Maybe there's some creative way of doing this? Perhaps by creating 'blacklists' for each portfolio rebalancing, or by reducing opt.MaxGrossExposure so in aggregate they all add up to 1 (e.g. 0.2 max leverage for each portfolio in a 5 portfolio strategy), or a combination of this?

I might give this a try but if any of you more experienced players think this approach is flawed, please give me a shout so I don't waste too much time on this (won't be completely wasted as I'm sure I'll learn something from it).

@ Joakim -

I'm wondering if this constraint might be a piece of the puzzle:

class Frozen(asset_or_assets, max_error_display=10)

Constraint for assets whose positions cannot change.  
Parameters:   asset_or_assets (Asset or sequence[Asset]) – Asset(s) whose weight(s) cannot change.

It is not quite clear from the help page description what it does, however. Presumably, it captures the current number of shares (and long or short) of any asset in the list, and applies a constraint in the Optimize API to keep the number of shares fixed. The max_error_display parameter is not documented, as far as I can tell. I've never seen Frozen used in any posted examples.

The reason I used the stock/bond asset allocation example above is that I'd been thinking of the Quantopian framework in a similar fashion (perhaps wrongly). For example, if one takes the risk model style factors:

factors = [Momentum, ShortTermReversal, Size, Value, Volatility]

At any point in time, one can run each factor across the entire QTradableStocksUS and then combine the 5 styles into one. For example, the time scales for the Momentum and ShortTermReversal factors are quite different. The former is based on an 11-month trailing period, whereas the latter is based on a 14-day trailing time frame. So, say I rebalance every day, with these two factors:

factors = [Momentum, ShortTermReversal]

On a continuous basis, the portfolio is weighted based on the the forecast tendency for a given stock to be momentum-ish and for that same stock to undergo a short-term reversal. There's no harm in running the Momentum factor daily, since it shouldn't change the allocation much, and superimposing the ShortTermReversal factor, which would be expected to change the allocation more frequently (but at any given time, could be negligible, in which case, Momentum could dominate).

Maybe this thinking is flawed, but it had been my interpretation that the idea is to quasi-continuously evaluate all factors and adjust the portfolio vector per the highest frequency factor (assuming that the high-frequency factor actually generates enough profit to overcome trading cost).

Hey @Grant,

Great find on the Frozen constraint. I didn't know it existed either. Could indeed be part of the puzzle, I just wish it wouldn't have to be this difficult (if it's possible at all). I'm happy to be wrong, but to me it seems like a reasonable question/request to be able to rebalance multiple portfolios at different holding periods in the same strategy, but again, maybe I'm missing something?

Regarding the Risk factors, I don't quite follow your reasoning. If you're able to find a way to consistently generate alpha from the Risk factors, that's great and would be well deserved. Personally however, I think that's quite difficult (they are way too common) and I'm happy to just rely on the Q Risk model API to limit any unintentional over/under exposure to any of these investing/trading styles. The factors may not be perfect and they have their limitations, but I'd rather have them than not as they add another dimension in how to measure risk exposure. (They also give Q and investors a bit of insight as to what type of factors are in the strategy without actually looking at the code).

@ Joakim -

I just picked the risk factors as a handy example.

I haven't had much time to put into Quantopian lately, however, when I get back to it, I'll recall your point. Thanks for bringing this up!

Hi Joakim -

I'll ping Q support again to see if they can comment on this thread. This would seem to be a fundamental question on their entire workflow. Once one identifies multiple factors using Alphalens, operating on different time scales, how are they best combined into one algo?

Hi Grant,

Thanks, much appreciated! Seems like a fair question to me, but maybe I’m missing something. Not holding my breath we’ll get a response.

Have you thought about how you would expect/want the factors of different frequencies to interact? For example, if you have signal A (weekly) and signal B (daily) operating on the same set of stocks, would you want to combine the signals on the one day a week on which they align, and then have signal B move the equivalent of half the portfolio on every other day of the week? If so, I'm wondering if you can simply combine your two signals on the one day a week where they align by using an average or weighted average. And then for the rest of the week, run a similar average or weighted average combination technique, but use the most recently updated context.output.daily_alpha with the context.output.weekly_alpha from the last weekly rebalance?

I think it's fair to say that it's not necessarily straightforward to handle multiple signals in order_optimal_portfolio, but I'm wondering what the ideal solution would look like. The problem of enforcing portfolio-level constraints becomes harder if you allow the optimizer to manage multiple sub-portfolios. Following the example above, if you have a weekly and daily signal, would you expect the positions held from the weekly signal to remain untouched on days where you only use the daily signal? I'd be curious if you might be able to get into a more efficient portfolio if you were able to combine your signal into a netted score on a daily basis. My first instinct would probably be to figure out how to turn my multiple signals into one number each day, but I'm sure there are other ways to do it.

I'm curious what the rest of you think.

@Jamie -

Have you thought about how you would expect/want the factors of
different frequencies to interact? For example, if you have signal A
(weekly) and signal B (daily) operating on the same set of stocks,
would you want to combine the signals on the one day a week on which
they align, and then have signal B move the equivalent of half the
portfolio on every other day of the week?

Yes, that would be like having two separate portfolios.

If so, I'm wondering if you
can simply combine your two signals on the one day a week where they
align by using an average or weighted average. And then for the rest
of the week, run a similar average or weighted average combination
technique, but use the most recently updated
context.output.daily_alpha with the context.output.weekly_alpha from
the last weekly rebalance?

We could do that but what is the effect of this weighting scheme on the weekly_alpha? Would that change the performance of weekly_alpha?

I think it's fair to say that it's not necessarily straightforward to
handle multiple signals in order_optimal_portfolio, but I'm wondering
what the ideal solution would look like.

Allow order_optimal_portfolio to accept a portfolio on which it has to operate (by default it is context.portfolio but it can be a subset of it) so that we can call order_optimal_portfolio on different subsets of the total portfolios. This means we have to manually keep track of the sub-portfolios (what stock belongs to what sub-portfolio) but at least we have a solution.

We could do that but what is the effect of this weighting scheme on the weekly_alpha? Would that change the performance of weekly_alpha?
I'm not sure that I follow. weekly_alpha is an input signal. If you want to build a portfolio on just that signal, wouldn't it make sense to run it as its own algorithm? It seems that the problem you're describing is one of attribution (i.e. if you run multiple signals in a single algorithm, how can you attribute the returns to each of them), which I think is distinct from the problem of actually moving your portfolio.

I think it would make most sense to aggregate your signals before moving your portfolio if you are actually interested in the interaction between those two signals. If you want them to stay completely independent of each other, it's best to put them in separate algorithms. Remember that the contest criteria are applied to the whole portfolio. If you were running two portfolios in the same algorithm, it's not clear to me how the optimizer would be able to reliably apply algo-level constraints since it would be operating on the two sub-portfolios independently.

If you were running two portfolios in the same algorithm, it's not clear to me how the optimizer would be able to reliably apply algo-level constraints since it would be operating on the two sub-portfolios independently.

@ Jamie - It may be true that in its current form, the optimizer would not work so well. However, imagine that each sub-portfolio were like an ETF. You would have information about it (e.g. sector exposure, Q risk factor exposure, fundamentals, etc.), but could not change the allocation within the ETF. The only option would be to decide long or short and by how much for each ETF. So, the problem becomes supporting N sub-portfolios, S_1, S_2, ..., S_N, and their respective weights, w_1, w_2, ..., w_N. When it comes time to update S_1 (say weekly), the algo only makes large changes to individual stock allocations within S_1, and minor adjustments to w_1, w_2, ..., w_N, for portfolio-level risk management (the adjustments to w_1, w_2, ..., w_N could even be asynchronous with changes to the stock allocations within S_1, S2, ..., S_N).

If you want them to stay completely independent of each other, it's best to put them in separate algorithms.

The thing is, you don't judge portfolios of algos (and users have no way to adjust weights, e.g. by adjusting gross leverage, even if you did). So, this would seem to be a dead end, unless you are talking about figuring out how to support users combining algos for the contest/fund.

I agree with your points @Grant

@ Jamie -

If you are thinking of supporting judging of baskets of algorithms, one step in that direction would be to provide an example of how to run a tear sheet on N algos. I'm guessing that you'd need to provide an API that would accept a list of backtests, and for starters, a list of fixed algo weights. This way, you could iterate through the backtests and apply the weights, flushing memory after each add of the backtest results.

The problem, of course, is that fixed algo weights is not ideal. At a minimum, one would want to adjust the weights according to a schedule (e.g. quarterly, as one might do for a portfolio of ETFs). This would seem to require more of an effort--an algo of algos API, that would allow one to adjust the relative capital applied to each algo dynamically.

@Grant, you could add an enabling vector of ones and zeros to control portfolio sections according to strategy design. The payoff matrix could be divided in say 3 sections of 30 stocks each with their own strategies. Σ(H∙ΔP) = Σ(H(a)∙ΔP) + Σ(H(b)∙ΔP) + Σ(H(c)∙ΔP), where H has row length: len(H) = len(H(a)) + len(H(b))+ len(H(c)).

But this will still make it an allocation problem. You cannot finance each section as if it was the whole portfolio. However, you could have 3 or more strategies co-exist or be enabled at various degree, including selection of only one at a time. Giving you the ability to switch, emphasize or enhance any of the sets.

The concatenated vector: a_1, b_1, c_1 could have its enabler ea_1, …, ea_n = 0 while eb_1, …, eb_m = 1. By passing the optimize_weight to the API, making sure your weights sum to 1 would give you the ability to instantly switch from one portfolio to the next based on whatever criteria you want.

This would require that your system remembers in which column it placed everything. But that is the whole purpose of the payoff matrix. This way you could switch regime, switch stocks on or off and even switch portfolio stance to whatever you want to govern the ball.

@ Jamie -

I've had limited time lately to work on Quantopian, but this basic architectural topic is of interest. I can see how having the ability to isolate various baskets/sub-portfolios of stocks and trade them on different time scales would be beneficial. The Optimize API is pretty fancy-dancy, and at first-glance, it should support this sort of thing with some cajoling.

Some questions:

1. What does max_error_display control?
   
2. What does Frozen do? It says "Constraint for assets whose positions cannot change" but then it says "Asset(s) whose weight(s) cannot change." So, does it constrain positions (i.e. number of shares held) or relative portfolio weights (i.e. percent of total portfolio value)?
   
3. Does FixedWeight take only a single asset? If so, how does one apply fixed weights to multiple assets?
   
4. When running calculate_optimal_portfolio with a specified current_portfolio will it ignore stocks outside of the defined current portfolio? How does it account for cash?
   
5. It would seem that if one uses calculate_optimal_portfolio with a specified current_portfolio and MaximizeAlpha(alphas) with alphas containing only the stocks in current_portfolio that other positions would be ignored. Is this correct?

(2) frozen_test() for understanding Frozen() & verifying whether it is working properly. In the first output for example, CRI is not clear to me.

@ Blue Seahawk -

So what is your conclusion? Is Frozen working correctly?

@Grant - It doesn't look like it. The position sizes are changing, aren't they? I don't know. Everything with the optimizer is over my head.

It's not exactly clear to me what freezing one factor for a week via frozen while another factor rebalances daily would even look like, unless you segregate your factors such that each factor operates on a unique universe of stocks. If there's any overlap in the stocks identified by each factor, there's no getting by combining them.

Even if you keep your weekly-factor static for the week, rebalancing it daily instead of weekly will have an effect. As Grant pointed out, this effect would typically be advantageous, and I think this is because of the volatility inherent in the market. If the stocks favored by the factor exhibit a lot of day-to-day volatility/reversion characteristics then daily rebalancing will augment the returns (as you'll be repeatedly selling high and buying low). If stocks favored by the factor exhibit momentum characteristics on the weekly scale, rebalancing daily will dampen the returns (because you'll keep selling off some of the best performing stocks to buy more of the poorly performing stocks).

So if you have identified that your weekly-factor is hurt by daily rebalancing... while it's unavoidable that you'd need to combine your weekly- and daily- factors every day, I think this is as simple as adjusting your weekly-factor's weights every day to take into account the changes in each stock's price (psuedocode):

for stock in context.weekly_factor_weights.keys():  
      context.weekly_factor_weights[stock] *= todays_price[stock] / yesterdays_price[stock]  

Talk about a simple solution to a complex problem -- two lines of code! (I hope I'm right on this.) And actually, if you find that the stocks selected by your factor benefit from this due to their momentum characteristics, then there's no reason why you couldn't push it further / exponential instead of linear.

@Joakim there most definitely is alpha in the common "risk" factors. Fairly consistent.

In the previous backtest, CRI and others that were being closed without having been instructed to close remain mysteries.
This time the output appears to be exactly as expected closing only those specified in Frozen(). One difference is that the previous backtest had open orders when frozen_test was run. Here, any open orders are canceled and initial capital also reduced for better fill. See source for output at the top.
With any luck, someone might find an answer to the previous mystery.

It's not exactly clear to me what freezing one factor for a week via frozen while another factor rebalances daily would even look like, unless you segregate your factors such that each factor operates on a unique universe of stocks. If there's any overlap in the stocks identified by each factor, there's no getting by combining them.

Not sure I follow. For example, one could have a portfolio of ETFs, with some stocks common to two or more ETFs. Each ETF is treated as a synthetic investment, with its own set of aggregate characteristics, without delving into the underlying investments. Each ETF is managed internally, without consideration to other ETFs. And the internal management could be on varying time scales. The question is how would would accomplish such a thing, within the Quantopian framework, and specifically the contest/fund rules and the requirement to use the Optimize API?

The question is how would would accomplish such a thing, within the
Quantopian framework, and specifically the contest/fund rules and the
requirement to use the Optimize API?

I think my solution solves that. Say factor A (which we can think of as an analog of an ETF) adjusts its weights once a week. At the start of the week it gives OSTK a weight of 0.05. The next day OSTK's stock price has increased by 10%, so what you do is adjust factor A's weights by the stock price change, now OSTK has a weight of 0.055. Then normalize it so all the weights add up to 1.0 again. Now you can rebalance and no buying or selling will occur. You do the same process to any factor that does not provide new values every day. But lets say you have a factor B that--like in the original question--returns new weights every day. When you combine factor A and factor B, the only buying and selling will be because of the changes in factor B.

Obviously this only works with TargetWeights, not MaximizeAlpha, which has a totally different behavior. Also, obviously in practice some buying and selling may occur due to the optimizer meeting constraints, but that's just the trade-off for keeping things risk-neutral. This seems like the desired behavior. If you really want to avoid this, then don't use constraints with the optimizer. (But why would you not want that?)

I think you guys are making this out to be a much more complex problem than it is. It's like four lines of code to solve this.

@ Viridian Hawk -

Yes, I think if one is attempting to use TargetWeights like order_target_percent it should be straightforward to do what was requested in the original question.

Yes, I think if one is attempting to use TargetWeights like order_target_percent it should be straightforward to do what was requested in the original question

Or use calculate_optimal_portfolio to calculate the optimized portfolio for each strategy (at the desired frequency). You can feed it either TargetWeights and/or MaximizeAlpha and get the optimized weights as output. Then on a daily basis run the applicable adjustments and combine the portfolios before feeding it back into order_optimal_portfolio.. Should behave like the ETF-style use-case you suggested, no?

Anyone up for collaborating on a simple 'dummy' algo (with little to no alpha) to try to figure this out? Perhaps using PsychSignal's stocktwits sentiments as a weekly factor, rebalancing each weekday (with 10% of total capital for each weekday) each portfolio holding for a week, and fcf_yield as the daily rebalancing factor using the other 50% of the capital?

Yeah. Post the two factors and I'll take a stab at combining them.

Thanks @Viridian! Will post the algo tomorrow (I’ve started one already which I’ll attach).

Here it is. A smooth short play if you ask me, haha. :)

I don't really know how to analyze this properly, but my guess would be that the 'weekly_factor' is effectively rebalancing daily rather than weekly, and the strategy gets effectively killed by trading costs (mostly).

Anyone care to help to see if the weekly factor can rebalance (and hold positions) weekly, independently of the daily factor as well as independently of the other weekly factors rebalancing on different days of the week?

Any other constructive critical feedback also welcome (other than perhaps just stating the obvious... :))

PS: I was going to attach AlphaLens analysis notebooks for both the daily and weekly factors, but ran into a number of (mostly user related) issues, so this will have to wait unfortunately.

Well, this resolves the overlap. And 8 of 9, with only turnover constraint beyond limit here.
Frozen() might be useful in keeping daily and weekly operations from tromping on each other.
Weekly is sentiment. In adding it back in, maybe try bull_scored_messages instead of bull_minus_bear.

@Viridian & @Blue,

Great, that's awesome! How would one go about confirming that it's actually doing what it's intended to do? (too far over my head)

@Viridian,

Looking at the 'Distribution of daily turnover rates' to me it looks like it's indeed working as intended, but maybe I'm interpreting this chart incorrectly?

I guess you could check whether it's working properly by removing the daily factor (from whether they're combined) and checking the transaction log for the other days of the week.

I'm realizing that a simpler, more accurate approach would be to take the weights from the weekly factor and convert that to number of shares. Then on the other week days convert that back to weights based on the current prices. That should be foolproof. I'll go ahead and code that up when I have a free moment. Downside with that approach though is if there is a split/reverse split that would throw it off.

Quantopian rounds to the nearest share when ordering by weight, correct? (As oppose to rounding down.)

@Viridian,

Man, you da MAN, man! Thank you for doing this! Personally I think I prefer the first one, as it's less exposed to corporate events risks (and I'm happy to exclude half-days).

Thanks also for providing so many helpful comments in your code, really appreciated! Very helpful for a python beginner like myself to more easily understand what's actually going on under the hood.

Do you have any idea why leverage is still hovering around 60% though, and the strategy never seems to be fully invested (100%)? Do you think it's possible that the Weekly Portfolio only gets rebalanced once per week (on Mondays?) using 10% of the capital, instead of using 10% of the capital for each weekday. I.e. 10% on Mondays, rebalancing the following Monday; 10% on Tuesdays, rebalancing the following Tuesday (independently from the Monday portfolio as well as the Daily portfolio), etc.?

So capital usage is 50% from the Daily portfolio + 10% from the Weekly Portfolio = 60% total capital usage, instead of the intended (my intention anyway) 50% from Daily + 10% * 5 Weekly portfolios = 100% total capital usage? Effectively, I was thinking of having 6 independent portfolios, 1 daily (using 50% capital) and 5 weekly (each using 10% of the capital). Perhaps it's already doing this, but as a python novice I'm still not able to tell completely from the code, even with the very helpful commentary.

Apologies if I don't explain this very well. Please also shout if you (or anyone else) think this approach is flawed in any way.

Aha, I get what you're saying. I like it -- diversify day-of-the-week risk. Currently it's only doing the Monday rebalance. I'll do the rolling weekly portfolio change... (backtesting now........)

Awesome! Eagerly awaiting what you can come up with.

It's not only diversification of week-day risk, but unless you do this you're actually leaving 4/5ths of the alpha from the weekly factor on the table (see Luca's earlier comments from June 7th close to the beginning of the thread).

I'm curious whether this confirms your hypothesis. Do you see better performance by having 5 rolling weekly factors as opposed to one?

Thank you @Viridian,

I will try test it over the weekend and hopefully get back to you on Monday.

If you don’t see any improvement it could be that there’s not much alpha in the ‘sentiment’ factor as is, so I may try to find something else. Perhaps use Fundamentals.earning_yield.latest instead for the weekly factor. There should be plenty of alpha in that during this test period.

Thanks again.

Hi @VH,

Sorry for the delay. I usually don't have much time on the weekends to spend on Q unfortunately.

I've replaced the 'sentiment' weekly factor with the Fundamentals.earning_yield.latest factor instead (earning_yield_winsorized) in both your first algo (1 weekly portfolio rebalancing only on Mondays) and the last one (5 weekly portfolios, each rebalancing on different days of the week). The performance definitely looks better in the latter one, but I suppose this could be because it's using close to 100% of the capital, instead of just around 60% that the former one uses.

Here's the first one (1 daily and 1 weekly portfolio, weekly rebalancing only on Mondays).

And here's the second one (1 daily portfolio, and 5 weekly portfolios rebalancing on different days of the week), using the same weekly factor (earning_yield_winsorized).

The second one has higher total returns, but this could be because it's using more capital (though they both appear to be using >90% of the capital most of the time). They both have about the same specific returns, but the first one has a slightly higher average rolling sharpe ratio.

Honestly I don't really know what's going on here - sorry. Someone smarter than me (@Luca, @Grant, @Blue, yourself) might be able to help? I'm moving on to focus most of my time on my new GARP PARTY strategy. :)

Do fields that update once a quarter exhibit a strong weekly alpha?

I think a reason why it might be underleveraging is the weekly factor might give a stock positive weight while the daily factor might weight it negative, and when combined they cancel each other out.

I'm surprised that the version that diversifies across days of the week exhibits higher volatility.

One approach would be to low-pass filter factors on different time scales prior to combination. I posted an example of how to do this recursively (based on Tony Morland's question) here:

https://www.quantopian.com/posts/recursive-function-calls-for-price-data-series-dot-dot-dot-python-help-please

The low-pass filtering should allow one to do daily portfolio updates with multiple factors on different time scales (it should also help smooth out returns, and reduce unprofitable turnover). By building the filter into the factor, one can adjust the time scale to an optimum via Alphalens.