LoopSum(“Month=1”, 50) returns 50 in the screener. Is this the way it is supposed to work? SHOULD this be the way it is supposed to work?
It’s working as intended. Nothing is changing in your tested string, so it’s true 50 times. If you run it with an as-of date that’s not in January, you’ll see it fail 50 times.
If that is the intent then I suggest it should be changed. A way should be devised to tie the loop to a time series to make it useful. Current date functions are extremely limited compared to other platforms. They should be given higher priority.
It can be tied to a time series with the special variable CTR w/ CTR providing the offset value into the time series
Your example asks is the current month January and it does it 50x.
What are you trying to do?
Walter
I was trying to see if I could figure out a workaround for the lack of precise time referencing functions by using LoopSum to sum the last number of days in the last 50 that were in the month of January to come up with the number of trading days or bars in January.
It’s strange there is a PrevBarDaysAgo function which is very narrow in its possible application but there is not a more generalized function for counting bars/trading days. This should be considered basic functionality. Considering a lot of what we do is defining setups for exit and entry the inability to easily and precisely describe the timing of conditions is a significant obstacle.
I see. Unfortunately, I don’t know how to do what you want. If you have particular date/time functions in mind, submit a feature request.
Walter
I already did that. The feature request is here. I also did so long before that but I made the mistake of combining requests into one feature request. The feature request I combined it with? The feature request for what has become LoopSum.
Sterling,
What you need to request is that function Month is point-in-time, so what month it was xx bars ago. If that is implemented, the screener syntax would be:
Setvar(@M, Month(0)) // month number at last closing price
Setvar(@TradingDays,Loopsum(“Eval(Month(CTR)=@M,1,0)”,23)) // number of trading days since month started
I’m just curious, what’s an example trading strategy that requires this functionality?
Florian, you’re probably right that Month needs to be requested to be point-in-time to solve this particular problem of mine. To unlock the full potential though a function that counts bars should also be implemented.
Mbclark the combination of bar counting and date/time/month referencing allows for precise year-to-date return computation, multiple time frame analysis, and seasonality analysis among other things. One could dispense with developing new functions for weekly and monthly bars.
A bar counting function alone is invaluable for being able to define setups precisely. For example if you have an entry setup with 3 conditions A, B and C you currently can only trigger the entry when all three conditions are met simultaneously at a specific point in time or else write out a very laborious tediously specific code. With a bar counting function it is far easier to describe a setup’s order: condition A occurs first, then condition B and finally condition C. Bar counting function is absolutely fundamental in my opinion.
I’m not sure what exactly you’re trying to do Sterling. In order to have the LoopSum work on a recursive variable, you have include “CTR”. If you want to find out how many bars there were in January, you’re going to have to work with serial date functions which are not available. In general, many things would be much easier if there were a programmatic way to work with serial dates.
See requests:
https://www.portfolio123.com/feature_request.jsp?view=my&cat=-1&featureReqID=1325
https://www.portfolio123.com/feature_request.jsp?view=my&cat=-1&featureReqID=1324
Yes improving date referencing would be very helpful. I don’t think most people realize just how much. It’s hard to explain to others just how helpful precise bar and date referencing is and the concept of serialized dates probably comes across in a clunky manner given the current reaction to primus’s feature requests. I have an idea of what “serialized dates” based on his usage is because I have an interest in similar and related features but it might confuse someone coming across it with no previous interest and cause them to ask what is a serialized date?
I am thinking bar counting might be easier to implement for Marco and the gang since the CrossOver and CrossUnder functions already implement a bar counting field. All that needs to be done is to take the code for that and then open it up for more generalized use in a new function.