class NonWindowSafeInput(ZiplineError):  
    """  
    Raised when a Pipeline API term that is not deemed window safe is specified  
    as an input to another windowed term.  
    This is an error because it's generally not safe to compose windowed  
    functions on split/dividend adjusted data.  
    """  
    msg = (  
        "Can't compute windowed expression {parent} with "  
        "windowed input {child}."  
    )  

I see the above error explained in github but I'm still confused as to how it works. With reference to my custom factors above, what issues could potentially arise? and why is NotWindowSafeInput not a warning instead of an error?

Hi Jean-Michel,

I recently gave an explanation of window safety here which I think you might find helpful. It comes down to the idea that factors which are not normalized will have their values affected by splits and dividends. If you ask for a history of something like momentum, it's value could change dramatically if you ask for a historical window over a period where a split occurred. If you normalize the momentum factor, it will be unaffected by corporate actions and you can be sure that any changes in value are meaningful.

Let me know if this helps.

This does help, thank you.

You mentioned that returns are normalised, are you referring to the Returns() function? The reason why I'm asking is that I'm currently working on a user-defined returns function as shown below:

def tRet(offset=0, nbars=2, r_input=USEquityPricing.close):  
    class tRetFact(CustomFactor):  
        window_length = nbars + offset  
        inputs = [r_input]  
        def compute(self, today, assets, out, close):  
            df = pd.DataFrame(index=assets, data={  
                    "returns": ((close[-1 - offset] / close[(-1 - offset) - (nbars - 1)]) - 1) * 100  
                                 }  
                             )  
            out[:] = df['returns'].values  
    return tRetFact()  

I would like to use the above function as input into other custom factors. In this case, is it window_safe? If not, please may you suggest how it can be amended/normalized to be window_safe. Thanks

Hi Jean-Michel,

Yes, I was referring to the built-in Returns() factor, but any returns factor should be window safe. Yours looks window safe, but CustomFactors are not window safe by default. Out of curiosity, is there a reason why you aren't using the built-in factor? From what I can tell, it's doing the same thing as your CustomFactor. Note that nbars in your version is the same as window_length in the built-in.

Jamie

Hi Jamie

Its the offset parameter that's slightly different. The offset parameter allows one to choose a date that precedes the current date whilst maintaining the current date index. Here, I recently posted something similar - in this case it would be nice to remove the offset parameter altogether and somehow find a way to play with the "today" parameter in compute. If you could suggest something then that would be great!

I thought the NonWindowSafeInput error came from detecting window safety - are you saying that it justs picks up that window_safe is False by default. Put another way, when you say CustomFactors are not window safe by default does that mean we always have to manually force the window_safe variable to be true?