-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IndicatorResult
needs refactoring
#13
Labels
enhancement
New feature or request
Comments
amv-dev
added
enhancement
New feature or request
indicator
Something with indicator implementation
labels
Jan 24, 2021
amv-dev
changed the title
Jan 25, 2021
IndicatorResult
need refactoringIndicatorResult
needs refactoring
I agree with this. Personally, I don't care about Keltner Channel's signals, but want to use its values. I'm also not a fan of the (arbitrary) 4 signals limit nor the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For now every indicator must implements both
value
s andsignal
s calculation logic. That might be a problem if you want to use values to implement your ownsignal
s logic because of performance degradation.So the current proposal is to make an
IndicatorResult
as atrait
which will only be responsible for representing values. The idea behind is that every indicator should have it's ownIndicatorResult
type. This will help keep indicators values more verbose.A single
struct
, that implementsIndicatorResult
, must contain all the values, that indicator returns. As a bonus there might be different types of values: not onlyf64
like now.Then for signals create another
trait Signal
and make two internal signal types:BinarySignal
for signals like {-1; 0; +1} andFloatSignal
for signals in range[-1.0; 1.0]
. Every single signal must have it's ownstruct
representation.This approach has next pros:
f64
s like now;IndicatorResult
may have more verbose documentation and explanation;Cons:
More code must be written to get a signal from indicator: you need to create
IndicatorConfig
, then initializeIndicatorInstance
(like now), then calculateIndicatorResult
, then initialize appropriateSignal
, then throwIndicatorResult
intoSignal
and finally get your signal.The text was updated successfully, but these errors were encountered: