I believe that TimeReturn analyzer with the timeframe parameter set to TimeFrame.Days will calculate daily returns in %s. So at first glance the easiest way will be just to repeat TimeReturn analyzer code with the small change:
now
self.rets[self.dtkey] = (self._value / self._value_start) - 1.0
need
self.rets[self.dtkey] = self._value - self._value_start
Dear @P-dML ,
For sure your explanation makes sense to you, because you are deep into your problem. But as pointed out by @run-out in the question ... without code there is actually no way to know what you are doing. For example:
There is a getsizing(data) thrown into a sentence out of the blue ...
At least for me it is unclear why that isn't giving you the information you are missing, probably because I also don't know which data feeds are in the equation, what's being targeted, ...
Thank you for this reply Boss, I’m honored.
So you are telling me that Indicators can store things that evolve over time different than Lines?
Could it be better to create a Strategy attribute wich will be updated each next() call?
If there is no buffer ... this will happen ...
Exception was raised at line ... Index Error
What the condition indicates is: if the previous data point is greater than the previous stored line value do something, if not ... do something else. But looking into the past buffer (-1) will break if there is no buffer, it won't simply jump into the else statement.
@backtrader BTW, do you know how can I replace the following line?:
exec('self.lines.' + i + '[0] = DfMresistances.value.take([n])')
I tried to use thes two alternatives, but they don't work:
#option 1:
setattr(self, 'lines.' + i + '[0]', DfMresistances.value.take([n]))
#option 2:
setattr(self.lines, + i + '[0]', DfMresistances.value.take([n]))
@MarkWhatson answering your initial question - you need to add conditions for your force selling to __init__ or next() and then issue corresponding orders in the next(). This is all I can say based on what was shown here.
@Mariano-Bengeldorf said in Coupler indicator issue with timeframe mixing:
I still would like to know if it is possible to change the 5 count to 7.
The platform doesn't carry any count, the count is dictated by the data itself. If your daily data is made up of 7 bars, it will tick 7 times per week.
The problem here is the definition:
@da-zhang said in problems when ploting indicator:
The indicator varies between 0 and real number
This would seem to indicate that the indicator travels (like a stochastic, for example), between 0.0 and a given (may be open) upper limit. But IT IS NOT so. The real definition is:
It is a binary indicator with either 0.0 or a value which is not related in any way to a possible previous 0.0, but actually to the previous non-zero values.
That indicator needs rework to either remove the zeros or use them in a proper way.
@backtrader Sorry, I have tried to simplify my example to make easy to understand. It's right that this code raise an exception because lines is not a tuple. In my real use case I have defined 3 lines, so the code runs. But I added a comma in the declaration of lines to convert to a tuple, and skip the exception, but I have the same problem described in my post: the strategies doesn't run.
PD: I don't understand so much what you want to say with "That defines 14 lines ..."
This post helps clear some things up for me however i'm still struggling with one thing in particular. How would I go about dynamically changing the period from which to find the max value?
Ultimately whilst signal is 1 find max until signal is 0 then repeat. I may just not be able to rap my head around it properly but i cant see how this can be done in a declarative manner?
Thank you for the quick response
@franklili said in multiprocessing.pool.MaybeEncodingError:
multiprocessing.pool.MaybeEncodingError: Error sending result: '[<main.EmaMeanReversionStrategy object at 0x7f4ab7de6b38>]'. Reason: 'PicklingError("Can't pickle <class'main.EmaMeanReversionStrategy'>: it's not the same object as__main__.EmaMeanReversionStrategy")'
This multiprocessing error has to do with scoping in Python, hence the ("it's not the same ...") It is a well-known pickling problem.
My guess is that you have to take the core out of if __name ... and put it into a function of its own.
