[Kde-finance-apps] Brainstorming requirements for an Alkimia Quotes Backend: Feedback/Reality-Check Needed Please :)

[Brian Cappello]

On Wed, May 26, 2010 at 4:18 AM, Thomas Baumgart <thb at net-bembel.de> wrote:

> Hi all,
>
> on Wednesday 26 May 2010 08:43:44 Brian Cappello wrote:
>
> [...]
>
> >  Meanwhile, TA-Lib provides some 150+ indicators/pattern recognitions
> >  specifically designed and tweaked for financial market analysis.
> (Granted,
> >  probably 3/4 of those can be "easily" recreated with basic algebra and
> >  simple/exponential moving averages (and/or less commonly statistics
> stuff)
> >  - but, the way I see it, why reinvent the wheel?)
>
> Yep, try to avoid the re-invention path.
>
> > Anyways, between yours and Thomas' input and my now being able to better
> > understand the AlkValue class, I think I'm going to try to store prices
> as
> > QList<AlkValue> (as opposed to float[] or double[]).
>
> The container class you use to store the values should be influenced by the
> methods you need to access them. Lists are great to iterate over but have a
> bad performance when you search specific values in them.
>

Thomas,
Good call, I hadn't really given that much thought. Major oops, thanks!
Luckily I was able to fit in a course on data structures, but, my
understanding of various types of trees is significantly broken/nonexistent
:(   [I should probably get on that...] Dates will definitely need to be
searched, but aside from finding a maximum and/or minimum, personally at
least I can't see much of a reason to need to search prices/volume. [Can
anybody think of one?] Having prices/volume easily iteratable at least makes
time conversion/adjusting prices a snap. (And adding high/low detection to
those algorithms shouldn't be hard; every value is already being walked
over.)

Maybe dates could be duplicated by using them as keys in a map/hash that
stores the list-index of each date's price data? That would still need
"probing" if the user say, gave a Saturday as the start date, but that'd
still be much cheaper than trying to search a list! Keying dates would also
mean the most recent close should probably be stored at the end, but that's
certainly possible - all the math is just "mirrored" and therefore a little
more tricky (at least for me) to understand/get right. Or, maybe, some kind
of tree is more appropriate... but even with my limited understanding I
don't *think* that's the case? I'm pretty busy today, so it might not be
until tomorrow, but I'll see what I can do to put together an initial
graphical overview of the building blocks :)

>
> > If at some point down
> > the road I've learned enough to be able to write code that can detect and
> > work with optional dependencies, then maybe I'll consider adding TA-Lib
> > support via a "middle man" prices holder class. [Memory just keeps
> getting
> > cheaper, no?] But, in the mean time, it's beginning to seem a little dumb
> >  to trade off both convenience and accuracy for the possibility of future
> >  laziness :)  [Or maybe I'm missing/don't know something? I know that
> >  happens all the time with me... :]
>
> Once we know all the building blocks and see how they fit together we can
> think about packaging and dependencies. Some sort of graphical overview on
> how
> all this fits together would be a good start (just my 0.02).
>
>
> --
>
> Regards
>
> Thomas Baumgart
>
> GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
> -------------------------------------------------------------
> Flying is absolutely safe as long as you land as often
> as you take off. -- Klaus Klages
> -------------------------------------------------------------
>
> _______________________________________________
> Kde-finance-apps mailing list
> Kde-finance-apps at kde.org
> https://mail.kde.org/mailman/listinfo/kde-finance-apps
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100526/7a2c8960/attachment.htm