Now I am confused. The plot above does look binary as expected, much different than the backtest plot in the IDE.

The backtest plot in the IDE is averaging. If you have 100 on one day, and 0 on 4 days, and then the week gets merged into one data point, it shows on the graph as 20. I think that's what you're seeing as partials, probably?

If you're trying to get into detail, you need to use the full backtest and the tools there. Also logging - the log.debug() command will generate the numbers you can look at, and verify there aren't partials.

That "algo not saved" bug is driving me crazy too. I'll put it on my "hot" list to fix. In general, it's giving a false positive. The save worked, probably. But the popup should be more accurate!

I am running the "full backtest". I do see what I would have expected digging into the tables, but it would be good for the plots to have the resolution that they do in the forums, as in above. Please clone the code to see what I see, as even the changes are fairly widely spaced, and you can have it readout these false data points, so I'm surprised the plot is that coarse. Maybe that is only for the custom data, as the performance plot is full res, it would appear.

So - having the same plotting performance in the IDE as we can in the forums, I think is a good suggestion to add. A daily plot should plot.. daily. :)

I expect minute plots and pixel resolution is another issue where averaging may be appropriate, but on these daily plots, we're no where near that limitation. Otherwise, one feels very unconfident when rapidly trying out several permutations, and you feel you need to validate each step with multiple data outputs. Having a reliable accurate plot of indicators and variables would be beneficial. (yes, I know we didn't even have anything at all a little while ago :) )

Thanks for the reassurance on the save bug -- it did seem to be ok, but wasn't sure if it was an indicator of something underlying.

Thanks,
Ken

Thanks for the feedback. I agree, that's too much intellectual overhead. We'll see what we can do.

Hi Dan,

I'll cast my vote, too, for a review of how Quantopian handles custom plots (see https://www.quantopian.com/posts/plotting-question, as well). There is some sort of averaging going on (weekly?) that basically makes some plots useless (e.g. looking for anomalies/extremes).

Grant

We modified the way plots are drawn this afternoon. Before, most of the plots were aimed at 2 pixels (px) per data point. We reduced that to 1px per datapoint. The average IDE graph window is 650px. That means you get 2.5 years of daily data in one window.

Once it gets too tight, then it changes to weekly. Custom signals are averaged in that week. We have the option of doing other things - summation being an obviously bad one for most things, but using the "close" value might be better than average. I can think of good arguments in both directions.

I think one of the remaining pieces of work for us on this is to more clearly signal when it flips from daily to weekly. That should be more easy to understand.

The net of this is that you should get more data points before things start averaging, but averaging still happens when we run out of pixels.

Hope that helps.

Thanks Dan. I'll give it a go, and let you know how things look. --Grant

Beautiful - now the graph in the IDE looks like it does in the forum post above!

And, if I am not fooling myself, it looks like the transactions line is improved as well from what I remembered in another algo.

Thanks!
Ken