@lukesneeringer Hi.
This question was already raised in #15 .
I tend to say that we do not need it and close the issue, but I'd like to hear from you what is the necessity to have Decimal support?

My reason is basically the same as the one in #15: I am trying to avoid the use of floats; every number in the project is an integer or a decimal.

I agree that for many of the outputs of ta, precision is less important, but it is not unimportant. Also, a lot of the folks writing against the API I am writing are less technical and I do not want to give them one sub-integer type consistently. This is also important because decimals support all the arithmetic operators with each other, but not with f64s -- meaning if I give my users a f64 in some places and a decimal in others, comparing them or manipulating them is more difficult than it ought to be.

I also expect this can be done in a reasonably generic way to not add very much code duplication. rust_decimal::Decimal supports all the arithmetic traits, after all.

Decimals important for storing money and making operations with money, I do agree. But this does not apply to technical analysis.
I would argue that precision of f64 is more than needed for TA, and it's not enough, then you're probably fooling yourself, thinking that being super precise gives an advantage to your trading strategy.
As Warren Buffet once said: "It is better to be approximately right than precisely wrong."

meaning if I give my users a f64 in some places and a decimal in others, comparing them or manipulating them is more difficult than it ought to be.

You can implement a wrapper around the existing indactors, that would convert f64 -> Decimal. But generally I would suggest.. just convert the values where you want to do comparison. Moving averages, is probably the only case when you actually want to compare prices with indicator values.

then you're probably fooling yourself, thinking that being super precise gives an advantage to your trading strategy.

It is not so much that I think the precision of decimals is critical in this case. I am much more interested in API simplicity. I want my folks to work with decimals all the time rather than having to take on converting between decimals and floats.

@greyblake Following up on this, because it's still something I am hoping for. I'm willing to implement it myself, but I don't want to do it if you're going to reject the PR. :-)

I'd do it behind a feature gate, so it won't affect anyone who doesn't want it.

@lukesneeringer Hi, thanks for reaching me.
I still hold the same opinion as before (decimal is MUST for prices, money amounts in bookkeeping, but not for TA indicators).

Unfortunately I don't have much spare time at the moment to dedicate to ta.
I am not sure what to suggest. Maybe you can do it a for 2-3 indicators and ask me to take a look?

That's fair. I think I know how this should be done that would work well. I'll send you a PR.