KVO docs typo

[DaveSkender]

Documented KVO method should be fixed and not reflect Keltner. Typo. We'll need to also review the parameters and for other missing items while we taking a look.

is there a reason why the function for the KVO is called get_keltner() and not e.g. get_klinger()? See here: https://python.stockindicators.dev/indicators/Kvo/#content

Thanks,
Andy

Originally posted by @August1328 in DaveSkender/Stock.Indicators#446 (comment)

[LeeDongGeon1996]

@August1328 Please let us know, if you'd like to contribute on this. We can wait for it, if you need time to learn GitHub.

[DaveSkender]

Might be good to also add a note in the Guide about dataframe conversion. That seems to be a common thing. @LeeDongGeon1996 is dataframe something we want to accept as an alternative input form?

[LeeDongGeon1996]

Right. In most of use-cases in Python, people use Pandas dataframe, so It would be good to add in Guide.
Actually, I'm worrying about performance to convert them, so thinking about C-extension for Python to convert them faster.

While Python is a great language and a pleasure to code in, its dynamic nature results in overhead that can cause some code ( i.e. raw computations inside of for loops) to be up 10-100 times slower than equivalent code written in a static compiled language.
From Numpy docs: https://numpy.org/doc/stable/user/c-info.python-as-glue.html#calling-other-compiled-libraries-from-python)

dataframe consists of 1D-array of Numpy internally.

Do you think it is the case of above? or is it too much? (like a dtype feature we've discussed about before)

[DaveSkender]

I think we can just start with some guidance in docs. I suspect Python users simply know and accept that it’s slower in some aspects than compiled code. Exploring a C or C# extension is also a good idea.